SentinelPro Dongles and IVF

[jackosullivan]

Has anyone experience with using the SentinelPro hardware keys (dongles) with Intel Visual Fortran?

We've used them very successfully in Compaq Visual Fortran, but the Rainbow/SafeNet company have not yet developed the interface for the IVF, and do not seem to be too enthused about doing so for the old "SentinelPro". Since we have quite a number of these older dongles spread around the world, I'm hoping there is some sneaky way to just slip the old CVF modules into the new IVF.

Thanks very much and God bless!

Jack

[Steven_L_Intel1]

You can't use the CVF .mod files, but if they document the interfaces, or provide the .f90 sources, it should be straightforward to make the conversion.

[Jugoslav_Dujic]

Steve,

1) Is the .mod file format for CVF and IVF publicly available? I guess not, and I don't see why it wouldn't be, (as I don't see how such information could help violating copyrights). Guess it's too late for CVF, but it can be done for IVF. That can be quite useful e.g for 3rd-party software -- e.g. a tool for reverse-engineering a .f90 module header section (minus contained procedure) from a .mod file would be extremely useful, as this thread shows (again, I don't see possible copyright issues).

2) On the same wavelength, are there any plans for solving infamous "Compilation cascade" problem in IVF? Again, there are some independent solutions with makefile tricks, but they're awkward to use if not built into the compiler itself. Basically, the trick is to analyse the old .mod file (modulo timestamp) and not touch it if the new mod file would be identical. I don't think it's too difficult to implement, and it would IMO yield an immense quality leap.

Jugoslav

[Steven_L_Intel1]

The .mod file format is sort of a compressed dump of the compiler's symbol table. The format is not public, changes over time,and would be hard to document for use with external tools. If the vendor offers a C header file, that is pretty easy to convert to Fortran.

While we don't currently have plans for such a mod file feature, we are collecting ideas for future versions and I'll add this to it.

[Paul_Curtis]

WRT Jugoslav's 2nd question, I had previously submitted the non-functionality (non-existence?)of the much-promised IVF dependency checker to Premier support, with a sample project of highly interdependent modules illustrating the problem. After only a few weeks, I have been assured that this problem has 1) been replicated, and 2) been solved, and that the solution may be expected in some future release.

[Steven_L_Intel1]

I am glad to hear that you got a quick response on your issue - too often it seems all I read are complaints! However, I think what Jugoslav is asking for is a bit different. He would like "minimal recompilation" to be extended such that if compiling a source does not change the representation in the .mod file (for example, only the executable code changes, not the declarations), that the existing .mod file is left unchanged. This would also necessitate "just in time" dependence checking, which I am not sure the IDE does.

[Paul_Curtis]

My point -- seemingly confirmed by Premier support -- is that the IDE doesn't do any dependence checking at all: early, late, "just-in-time"or ever. This is a problem, and makes for poor performance in (re)compilations of multi-module projects.

[Steven_L_Intel1]

That's simply not true - it does do dependence checking and does a much better job than CVF does. I have seen it in action myself many times. I do know of some cases where it gets confused - in particular, if you name INCLUDE files as .h - but generally it works well.

[jackosullivan]

Thanks for the tip, Steve. I now have a direction to head off in.

As usual, right on the money and very prompt.

Thanks so much for your dedication.

Happy Thanksgiving to all, and of course, God bless!

Jack

[Jugoslav_Dujic]

Just to clarify: yes, the Steve is right about my request. I even did (actually, was about to) write a small application which

1) opens the .mod file, skips the timestamp in the header, treat the rest as a raw binary stream and calculate some kind of CRC/hash code.

2) store the CRC/hash somewhere (e.g. in modulename.crc file).

3) install the "file watching hook" (ReadDirectoryChanges).

4) when the .mod file is changed, read it again & calculate CRC, and check it against the stored CRC. If they're thesame, do a SetFileTime to the old time.

In theory, this would enable that, when you change a line in CONTAINed source, you don't have to rebuild all dependent modules. The algorithm aboveis not so complicated. However, as Steve just pointed out, the big problem is when to run it. It should be immediately after the file compiling (thus I suggested that it's built-in into the compiler). However again, the current dependency analyser does not work "just in time" -- i.e. it first looks foreverything it should recompile, then does the "blind" recompiling. Thus, even if I succeeded to have my application successfullyfixing mod file time, the dependent sources would still be recompiled. Instead,the dependency analysershould check for file dependencies just before every file is about to be recompiled-- I didn't see that obstacle in my previous post in this thread.

For further reading:

http://www.theochem.uwa.edu.au/fortran/recompile/

Jugoslav