Hi all,

Last month I converted a 500.000 lines Delphi project to FreePascal, and I wanted to thank those who replied to my questions over the mailing list and the whole FPC / Lazarus team for delivering a great product. Also all contributors to wiki pages, newsgroups and forums: thanks! Even the smallest pages or postings contained useful information and are a valuable source of information.

The converted application is an output viewer for calculations based on the finite element method. It is intended for 2-Dimensional and 3-Dimensional geotechnical analysis of deformation and stability of soil structures, as well as groundwater and heat flow, in geo-engineering applications such as excavation, foundations, embankments and tunnels. (so this is a result viewer, the actual calculations are performed with another application).

The conversion was a pilot with the main reason for trying FPC the need for 64 bit. During conversion I encountered lots of small issues (Unicode, OpenGL, images with scanline manipulation, generics, anonymous methods, class constants and functions, MDI forms, treeview with custom drawing, Steema TChart, custom controls and more). For most of the encountered issues I created a list with their solution, I'll try to clean it up and see if I can post it somewhere because it might also be helpful for others.

Attached you will find some screenshots of the result, these give you an idea of what the program does.

With kind regards,
Birger Jansen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot 1.JPG
Type: image/jpeg
Size: 34103 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110103/b027a83a/attachment-0004.jpe> -------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot 2.JPG
Type: image/jpeg
Size: 36920 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110103/b027a83a/attachment-0005.jpe> -------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot 4.JPG
Type: image/jpeg
Size: 30383 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110103/b027a83a/attachment-0006.jpe> -------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot 6.JPG
Type: image/jpeg
Size: 29344 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110103/b027a83a/attachment-0007.jpe>

Impressive!

Looks an idea candidate for being added here:

http://wiki.lazarus.freepascal.org/Lazarus_Application_Gallery

Hi Birger,

The list is definitely of interest to me and others! If possible please create patches and add them to the bug tracker. This will help not only future conversions but "ordinary" projects as well.

Regards, Darius

That reminds me I need to update http://port2laz.blogspot.com soon. There's a lot of new things happening right now with the new version.

2011/1/3 Darius Blaszyk

Hi Darius,

The list is definitely of interest to me and others! If possible please create patches and add them to the bug tracker. This will help not only future conversions but "ordinary" projects as well.

I'll clean up the list and post it on the mailing list. I didn't need to create any patches, most of the work was just to find out the Lazarus / FPC way of doing Delphi stuff and making some libraries work.

Some patches that I needed (for generics and class functions) were already supplied by the team within a matter of hours after I submitted my problem. (Try that with Embarcadero...!)

Kind regards,
Birger

Really great! I have a similar problem in conversion to FPC/Lazarus of a visualization package of physical data. But this package uses number crunching DLL:s created using an Intel Fortran compiler...

Nevertheless I would like to know your solutions to the programmatic conversion problems because our package also uses MDI forms and the graphics is OpenGL via GLScene.
Ideally I would like to be able to move it to 64 bit to enhance the computational speed and model sizes.
And of course compile also for Linux...
Did you test your conversion also on Linux?

Finally a little hint:
When you make screenshots to post it is usually much better to save them as PNG files rather than JPG. JPG is lossy and the first things that go are straight lines and text, which becomes blurry. PNG is non-loss and also compresses the data much better (for a typical screenshot) so the resulting file is smaller too...

Hi Bo,

Really great! I have a similar problem in conversion to FPC/Lazarus of a visualization package of physical data. But this package uses number crunching DLL:s created using an Intel Fortran compiler...

I didn't have a look at the processing part of the application, but I believe this is done in Fortran as well.

I did try to make the MDI forms work, but didn't found a good working solution. As a temp solution the main form keeps a list of all opened forms and has some functions to provide ActiveMDIChild and other MDI values. This works, but some interface redesign will make it better.

Graphics were also provide by (a modified version of) GLScene, and I had very little problems with making this work. However, an older version of GLScene was used and while it supported Lazarus under Windows, Linux support was not available in that version.

The reason for the conversion was also to be able to handle larger model sizes, we managed to load some models up to 4GB without problems.

And of course compile also for Linux... Did you test your conversion also on Linux?

We did some command line tests with Linux. Loading a model into memory and performing some basic calculations was no problem. However, in the available time that I had for this project I couldn't get the newer GLScene with Linux support to work, but I am convinced that it should be possible given enough time.

Finally a little hint: JPG -> PNG

Thanks, I knew one of the two was better and I choose the wrong one. I'll remember for the next time.

Kind regards,
Birger

Op 2011-01-03 13:48, Bo Berglund het geskryf:

Very true!
Also note that because PNG is non-lossy, the size could be large (150+ KB) per image. So if a small amount of color loss is not too important, then you can save the image as an Indexed PNG (and the 256 color Index Palette is optimised based on the image colors itself), it will greatly reduce the image size to just a few kilobytes. I often see images drop from 200KB to 20-30KB because of this.

Gimp (free image editor for all platforms) does this very nice and easily.

Regards,
- Graeme -

PNG is non-loss and also compresses the data much better (for a typical screenshot) so the resulting file is smaller too...

Why should a loss-less compression compress better than a a lossy compression?
In general this is not true, just the opposite. But you are right that for screenshots
PNG is much better because it was optimized for computer generated pictures (like screenshots). JPG was made for photos and reduces their size dramatically
because it takes into account human picture recognition. If you have photos (made by
a camera) you will always get the best results with JPG.

The problem with jpg is when people start to edit then re-save them. Have a look on google images for joke images where someone has added a border and some text to the image. Often times you'll see an bit of fussy-error area at some point. This is the lossy-ness being introduced by opening then re-saving, opening the new image and re-saving again 2-3 times or more.

I am not sure whether browsers like Firefox also have lossy-ness when you find an image and right-click then do a save image as... I think so, but maybe not, as it probably really only copies the image from the browser's cache to the new location, hence not really saving but actually copying.

I always prefer to use png image as masters for editing then output final image as jpg or png. As this is a duplication problem and also for the re-saving errors, I tend to only keep png's.

pew

2011/1/3 Birger Jansen

For most of the encountered issues I created a list with their solution, I'll try to clean it up and see if I can post it somewhere because it might also be helpful for others.

Such a list could also help a future automatic conversion. Currently any "real" projects are far away from automatic conversion. It would require deeper analysis of the code and replacing both classes and their methods with their FPC/Lazarus equivalents.
Maybe some day...

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110103/09c93431/attachment.html>

2011/1/3 Bo Berglund

Really great! I have a similar problem in conversion to FPC/Lazarus of a visualization package of physical data. But this package uses number crunching DLL:s created using an Intel Fortran compiler...

Bo, so you finally didn't get your Fortran code converted to Pascal. What was the main problem?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110103/d335ce32/attachment.html>

Well, there were two different problems:

1) My intrinsic lack of Fortran know-how

2) The fortran code failed to translate when it turned out that Fortran could change the type of a matrix multiplication depending on the dimensions of the two input matrices.
Sometimes the output was a simple vector and sometimes a true 2-d matrix and I failed to undretand how to translate these functions. It seemed like Fortran didn't give a damn about variable types and since Pascal is so strongly typed this made a big clash.

I converted a fair amount of them but when I reached this problem I had a lot to go and gave up.....

2011/1/4 Bo Berglund

Interesting. I don't know Fortran either but it looked like it could map directly to Pascal.
Apparently it does not.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110104/5f711677/attachment.html>

Bo Berglund wrote

2) The fortran code failed to translate when it turned out that Fortran could change the type of a matrix multiplication depending on the dimensions of the two input matrices.

With Fortran in a function, the array idex bounds can be obtained from function parameters.

This can be overcome by using dynamic arrays in Pascal.

We (i.e. my son) once created a library with some matrix calculation/solving functions using dynamic arrays as vector and Matrix types.

This worked out very nicely, e.g. as Pivoting results in very fast pointer operations that avoids moving the values around.

-Michael

OK, maybe I will have a restart on that project... In any case it has to be put off until my embedded project is done. But then I have the nagging feeling that maybe the Pascal implementation would not be as fast as the Fortran compiler's, which would then slow down the number crunching for large models.

Fortran uses COMMON blocks for data storage, and it's up to the coder to specify the *intended* structure of every such memory block, in every module. Typically the structure is different in different modules, in detail with matrices. This is quite the opposite of Pascal type-safe declarations - more something like variant records with arbitrary (maybe same) field names for every variation :-(

Fortran is different from almost every other programming language in many aspects, so that porting Fortran code to Pascal or even C is near impossible. Either get an Fortran compiler that can compile the code, or give up.

DoDi

Bo Berglund wrote

2) The fortran code failed to translate when it turned out that Fortran could change the type of a matrix multiplication depending on the dimensions of the two input matrices.

You couldn't translate the code or the function declarations? Calling the fortran code from freepascal might be possible, then you don't have to translate the code itself, just call it.

Micha

This might not help him in the long run if he wants to port his project to x86_64 or even ARM.

Regards,
Sven

this was discussed but IIRC it seemed that determining the proper calling procedures came up... if the library wasn't callable in "pascal" or "C" format or some such... one would need to be able to compile those libraries in a FPC/Lazarus compatible format for the ""normal"" callouts (is that the proper term) to work... since this was hard to do (ie: no compiler with this capability??) it was looked into that those routines could be recoded in pascal format... this too has not been able to be done because there's no available FORTRAN <-> PASCAL coder who can make the conversion...

IIRC^2 : the original coder is long gone and no longer available for consultation...

2011/1/3 Birger Jansen

Hi all,

Last month I converted a 500.000 lines Delphi project to FreePascal, and I

Hi Jansen
although it is no longer my main job I am geotechnical engineer and I'm curious on the finite elements application: did you do it? is it in pascal? what is his name?
As for the viewer it look very professional so BRAVO! Regard
Salvatore

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110106/ab44c9af/attachment.html>

2011/1/6 Salvatore Coppola :

If l interpreted the screenshots correctly, it is plaxis: http://www.plaxis.nl/page/home/

Vincent

If l interpreted the screenshots correctly, it is plaxis: http://www.plaxis.nl/page/home/

You are correct, it is Plaxis. I did not do any work on the application itself, just did a pilot conversion to see how portable the code is to FPC.

I believe this application, like many in its genre, works as 3 separate programs: input, processing, output. Processing is done in (I think) Fortran and the rest is Delphi. For this pilot I worked on the output only.

Kind regards,
Birger

Many moons ago, when I was writing projects in both FORTRAN and Pascal on a DEC PDP-11, the limitations of the hardware were such that we used to have to compile to assembler and then patch breakpoints into the code in order to debug it.

Things have almost certainly changed since those days, but I do remember that while the Pascal compiler we used pushed and popped parameters via the stack, as you would expect, the FORTRAN compiler instead pointed a register at a parameter list in memory.

The compilers then were DEC's FORTRAN-IV-PLUS and Oregon Pascal, which DEC later bought and renamed RSX Pascal.

I also had to do some digging into assembly language listings from Hewlett-Packard's FORTRAN-1000 compiler running under RTE-A, and found that used the same technique, passing a pointer to a parameter list via a register.

This is all ancient history now, I'm talking about back in the 1980s, but it may be relevant to doing parameter list conversions. I don't know how much of my FORTRAN I can remember, but I do know that mismatched COMMON blocks were a superb way of having your program disappear up its own CPU stack, I ended up putting in place a standard whereby all COMMON blocks had to be declared in an INCLUDE file, so that there was no possibility of mismatches.

FORTRAN's parameter and type checking made C (note, no ++) look good.

Brian.

2011/1/6 Birger Jansen

> If l interpreted the screenshots correctly, it is plaxis: > http://www.plaxis.nl/page/home/

You are correct, it is Plaxis. I did not do any work on the application

thanks now I can see. Thanks to Vincent to

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110109/a616e2d3/attachment.html>