forums.silverfrost.com

[mrpmorris]

Hi everyone

I am evaluating your .net compiler. I am trying to compile an existing project. This project compiles fine for Win32 (Watcom compiler), but I am getting the above error on the last line of the following code

CHARACTER*4 cvtmap(27)/
& 'C','K','F','R',
& 'M','CM','MM','FT','IN',
& 'M/S','FT/S','FT/M','MPH','KTS','KPH',
& 'KG','LB','KN',
& 'S','MIN','HR',
& 'KPA','HPA','PSI','IHG',
& '#','%'/

As I mentioned, this works in Watcom for Win32. Can anyone suggest what is wrong with it?

[Andrew]

The initialisation technique used in your code is a VAX extension to the standard. There is a valid workaround for what you want to do however. This is to use a data statement such as:

[mrpmorris]

That is brilliant news. I can't wait to try it out. Do you have a planned release date for the next buidl yet, or is it still to be decided?

[Andrew]

There has only just been a release (December) of version 4.7. As yet there is no planned date, there have not been any significant changes since 4.7. Sorry I cannot be more specific, we will post an announcement on the forums when a new version is available.

[mrpmorris]

>There has only just been a release (December)

Argh! If only I had trialled the compiler in November!


>there have not been any significant changes since 4.7

This change is actually significant to me. I wont both you with the details, but for many reasons I am not allowed to alter any text within a subroutine which is provided to me. All I am allowed to do is to add that subroutine to a project and use it.

I am currently able to compile this project for Win32 using Watcom, but I would really love to get this working in .net on the compact framework (it just reads / writes data files and crunches some numbers).

Rather than me waiting until your next release and then potentially discovering another peculiarity in the source like this one, do you think I could possible fieldtest your next compiler before release?

[Andrew]

Please see your private email

[mrpmorris]

Excellent, things are looking very good!

I was able to compile the project first time. Amazingly it only took seconds, I am used to the LaheyFujistu Fortran.net compiler taking about 10-15 minutes to compile the same code!

I'm now trying to call some methods within the assembly from a C# WinForms application. The method is declared as...

SUBROUTINE SetXXX(VALUE)

IMPLICIT NONE

CHARACTER*(*) VALUE
XXX = VALUE
END

In Visual Studio / C# it is expecting the following...

(Salford.Fortran.Character * value, int _length_of_value)

If I wanted to pass Application.ExecutablePath, how would I do that?

Thanks

Pete

[mrpmorris]

I'm sure I have already posted this, but I don't see it so I will post it again.

The new build is great! It compiled the project completely unaltered the first time. Amazingly it took about 15 seconds, whereas another well known Fortran compiler for VS takes 10-15 minutes to compile the same project!

I'm not trying to execute this Fotran routine from a C# WinForms application. One of the routines expects the following

SetXXX(Salford.Fortran.Char XXX, int _length_of_XXX_)

What do I need to pass from C# if I want to pass Application.ExecutablePath (a string)?


SUBROUTINE SetXXX(VALUE)

IMPLICIT NONE

CHARACTER*(*) VALUE
XXX = VALUE
END

[mrpmorris]

I'm sure I have already posted this, but I don't see it so I will post it again.

The new build is great! It compiled the project completely unaltered the first time. Amazingly it took about 15 seconds, whereas another well known Fortran compiler for VS takes 10-15 minutes to compile the same project!

I'm not trying to execute this Fotran routine from a C# WinForms application. One of the routines expects the following

SetXXX(Salford.Fortran.Char XXX, int _length_of_XXX_)

What do I need to pass from C# if I want to pass Application.ExecutablePath (a string)?


SUBROUTINE SetXXX(VALUE)

IMPLICIT NONE

CHARACTER*(*) VALUE
XXX = VALUE
END

[Anonymous]

This usage of a forward slash is a VAX extension to standard Fortran.
FTN95 can normally handle this VAX extension but it fails in this case.
The standard Fortran is to use a separate DATA statement.