Blog

All Blog Posts  |  Next Post  |  Previous Post

Should we make FlexCel work in Lazarus?

Bookmarks: 

Tuesday, June 7, 2022

As many might know, FPC announced support for anonymous methods some days ago. This was one of the last pieces missing for us to be able to port TMS FlexCel to Lazarus and FPC. 

So we decided to give it a try, and after a couple of days fixing stuff, we could make it compile. It wasn't simple, there were internal compiler errors, there is missing functionality that had to be rewritten, and we haven't reached 100% of the code, but most is compiling. Of course, compiling it is one thing, but getting it to work is a different matter. When we tried, we couldn't create a simple xls or xlsx file. After a couple more days, we could get first xlsx and then xls working. We needed to do some patching in fpc, and we needed to workaround  some other stuff, but that's the point where we are at right now. All of FlexCel code is compiling. It works in simple cases, but we haven't tried our test suite yet.

You can see here a little video of Lazarus in a M1 mac (but running as intel under rosetta) of me creating a simple xlsx file.


And now comes the big question. Would you like us to spend more time on it so we add Lazarus support, or do we stop it now and focus in FlexCel for Delphi and FlexCel .NET as usual?  While we now have simple apps working, we won't launch "Lazarus support" unless we have all tests passing, and FlexCel tests are quite difficult to pass. I expect some extra weeks of work to make it all pass.

At least for now, we would focus in supporting Windows, OSX and Linux. No plans for iOS or Android.

Important: To release support for Lazarus, we will require using the Trunk release until the current trunk is promoted to stable.

We would really be interested in your opinion. If you want to share it with us, please answer the poll below or let us know what you think in the comments.




Adrian Gallero


Bookmarks: 

This blog post has received 6 comments.


1. Tuesday, June 7, 2022 at 6:42:10 PM

After more than 20 years with Delphi we are currently moving to Lazarus. So having FlexCel in Lazarus would be more than welcome!

Nick


2. Tuesday, June 7, 2022 at 7:08:44 PM

I do not know if it''s doable, but Aurelius would be a viable candidate too.

Pelletier Martin


3. Tuesday, June 7, 2022 at 7:55:40 PM

Hi Adrian,
Flexcel is a very nice library and until now I use the DLL version with Lazarus, limited to Windows. It really works fast. FPC brings more and more on the table and I would be really happy to see Flexcel ported to Lazarus.
Not sure about speed gains but this would be nice to see that such a complexe piece of code can now be handled by the FPC compiler. Of course Aurelius and XData would be nice too :)

Luc


4. Thursday, June 9, 2022 at 10:29:48 AM

In the company I''m working for, I introduced FlexCel for .Net and I''m really amazed about the quality and speed this library offers. I would not hesitate to buy a private licence for a Lazarus version. Its just the question whether there are enough customers to make it possible to maintain the code for this version of FlexCel. Thank you for your efforts to make it possible.

Ulrich Groffy


5. Tuesday, June 21, 2022 at 9:56:02 AM

Nice to see someone stress testing the anonymous functions feature. :)
If you haven''t done so already, would it be possible for you to report the internal errors you encountered (including examples to reproduce them of course), cause the more is reported (and fixed) the better this functionality will be once 3.4.0 comes around. :)
Also is there a reason you used x86_64 Lazarus on the M1? Cause it would be good to know if the code works correctly for Aarch64 as well. :)

PascalDragon


6. Thursday, July 14, 2022 at 4:23:47 PM

@PascalDragon

Thanks for all the effort you guys put in Fpc/Lazarus! I didn''t see your comment before because the blog notification sends mails when it wants to.
Now about the news:
1. Today we are (finally) releasing 7.15 with support for Fpc/Lazarus trunk :)
2. It is working fine in the M1! I didn''t test it at the time of writing the blog just because fpcupdate wasn''t installing it. But now I did install the M1 version and it is working great
3. All in all it is working great. I''ve reported the bugs I could reproduce with a reasonably small use case (see https://gitlab.com/freepascal.org/fpc/source/-/issues/39761 and https://gitlab.com/freepascal.org/fpc/source/-/issues/39758#note_971719621 ) but some others were just too complex to get a reproducible example. One case was an anonymous method that captured like 10 different variables, and then it wouldn''t update some of them when returning to the main method. I tried to reproduce it, but when I started removing code the bug would go away. So I finally moved the full anonymous method to a class, because it was probably cleaner as a class anyway. I''m also seeing issues in linux (64 bit intel) in code that works fine in other platforms (including the M1). But again, it is very complex to isolate, and I have to make 100% sure the issue isn''t in my code. I''ve been debugging it with Valgrind to make sure it is not due ot memory corruptions, but code seems ok. But well, it is an equilibrium: What I can I of course report it, but when it is too difficult to get a reproducible case, I sometimes just workaround it. One silly example of workarounds:
fpc gives me a warning in this code:

function a: string;
begin
raise Exception.Create(''this method is not to be called in this platform!'');
end;

while Delphi gives me a hint if I assign a value to Result, since it won''t be used. So I have to write many:
function a: string;
begin
{[$IFDEF FPC}Result := nil;{$ENDIF}
raise Exception.Create(''this method is not to be called in this platform!'');
end;



Adrian Gallero




Add a new comment

You will receive a confirmation mail with a link to validate your comment, please use a valid email address.
All fields are required.



All Blog Posts  |  Next Post  |  Previous Post