Re: [fpc-pascal] fpc-pascal] Static linking against the indigo cheminformatics package under Linux x64 complains undefined reference to __dso_handle when Free Pascal is used
Dear Joans, After some digging, it seems that Free Pascal cannot link to C++ object file directly, which means Free Pascal cannot link to C++ static libraries directly. Runtime Error 216 errorrs. http://stackoverflow.com/questions/23647522 http://stackoverflow.com/questions/8174998 This feature is on Free Pascal road map. http://www.freepascal.org/future.var Best wishes, Xichen Li --- Original message --- Message: 5 Date: Thu, 15 May 2014 11:11:45 +0200 From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] Static linking against the indigo cheminformatics package under Linux x64 complains undefined reference to __dso_handle when Free Pascal is used Message-ID: 11213114-55c9-41f0-a45a-a84a4c949...@elis.ugent.be Content-Type: text/plain; charset=us-ascii On 14 May 2014, at 08:54, Xichen Li wrote: However, it complains undefined reference to __dso_handle. The Error msg is shown below: You also have to link against libc. gcc does that by default, but FPC does not. Joans -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal End of fpc-pascal Digest, Vol 119, Issue 25 *** ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
Just a suggestion. Try to rewrite the code not to use anonymous functions. The need for their support in FPC will go away. Seriously! no trolling here. thanks, Dmitry On Thu, May 15, 2014 at 1:05 AM, Craig Peterson cr...@scootersoftware.comwrote: Hi all, What's the current state of FPC's anonymous functions/closures support? Is anyone working on it? Is it something that a bounty would help with? Thanks, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
2014-05-16 11:13 GMT-03:00 Dmitry Boyarintsev skalogryz.li...@gmail.com: Just a suggestion. Try to rewrite the code not to use anonymous functions. The need for their support in FPC will go away. Seriously! no trolling here. I agree. thanks, Dmitry On Thu, May 15, 2014 at 1:05 AM, Craig Peterson cr...@scootersoftware.com wrote: Hi all, What's the current state of FPC's anonymous functions/closures support? Is anyone working on it? Is it something that a bounty would help with? Thanks, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/16/2014 9:13 AM, Dmitry Boyarintsev wrote: Just a suggestion. Try to rewrite the code not to use anonymous functions. The need for their support in FPC will go away. The code in question doesn't use anonymous methods yet, but I've already tried the alternatives and they are not an improvement. I don't really want to re-open the debate about their merits and syntax, but I can explain why I need them: 1) I want to use the OmniThreadLibrary. Setting up objects and thread descendents is fine in moderation, but it's too much of a hassle when you just want a quick parallel for loop. 2) Our application has multiple independent top-level windows, like a web browser. There is no MainForm. Each window can show modal dialogs that only disable that specific window. In a traditional Delphi/Lazarus app, showing a modal dialog looks something like this: procedure TMyForm.ShowMyDialog; begin Dlg := TMyDialog.Create(...) try if Dlg.ShowModal = mrOk then Do something finally Dlg.Free end; end; To make that work without blocking the rest of the application that needs to be split into two functions: procedure TMyForm.ShowMyDialog; begin Dlg := TMyDialog.Create(...); Dlg.ShowModalNonBlocking(ShowMyDialogDone); end; procedure TMyForm.ShowMyDialogDone(ADialog: TForm); begin if ADialog.ModalResult = mrOk then Do something ADialog.Free end; It's unwieldy with the simplest of dialogs, and gets much worse if you need to share state between the Show and Done functions, or if the dialog is only shown selectively. To solve that, years ago we started using cooperative threads (coroutines/fibers) in our GUI thread. I re-implemented ShowModal so it handles the details internally. When you call it it displays the dialog, just like the ShowModalNonBlocking() call would, but then switches to another thread that processes messages. When the dialog is finally closed the running thread switches back to the ShowModal call, which then exits like normal. As a result, even though we can have several independent modal dialogs up at once, the code is all identical to the first example. Everything is nicely encapsulated and sharing state before and after the dialog is trivial. Unfortunately, fibers introduce incompatibilities on both Windows and OS X, and are deprecated on OS X, so we need to stop using them. They are by far the cleanest approach, and I'd keep using them if I had any choice whatsoever. The second best alternative is to use closures and anonymous methods. The syntax isn't as clean, but at least everything is kept within a single ShowMyDialog call. In that case it would become something like: procedure TMyForm.ShowMyDialog; begin Dlg := TMyDialog.Create(...); Dlg.ShowModal( procedure begin if Dlg.ModalResult = mrOk then Do something Dlg.Free; end; end; Again, these examples are extremely simplified. The benefits are much greater when you need to use variables in the outer scope. In our application we have over 90 dialogs and almost 400 calls to ShowModal, so the easier I can make that the better. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
Am 16.05.2014 17:45, schrieb Craig Peterson: 1) I want to use the OmniThreadLibrary. Setting up objects and thread descendents is fine in moderation, but it's too much of a hassle when you just want a quick parallel for loop. Isn't using anonymous methods in this case only a work around for missing OpenMP support? To solve that, years ago we started using cooperative threads (coroutines/fibers) in our GUI thread. I re-implemented ShowModal so it handles the details internally. When you call it it displays the dialog, just like the ShowModalNonBlocking() call would, but then switches to another thread that processes messages. When the dialog is finally closed the running thread switches back to the ShowModal call, which then exits like normal. As a result, even though we can have several independent modal dialogs up at once, the code is all identical to the first example. Everything is nicely encapsulated and sharing state before and after the dialog is trivial. Unfortunately, fibers introduce incompatibilities on both Windows and OS X, and are deprecated on OS X, so we need to stop using them. They are by far the cleanest approach, and I'd keep using them if I had any choice whatsoever. The second best alternative is to use closures and anonymous methods. I still don't get how closures/anonymous methods help you to get rid of fibers? I mean, anonymous methods are only a short cut; closures allow you to capture the state of the variables of the outer scope even if the outer scope is left. But that's it? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
Hi, 2014-05-16 18:18 GMT+02:00 Florian Klämpfl flor...@freepascal.org: ... I mean, anonymous methods are only a short cut; closures allow you to capture the state of the variables of the outer scope even if the outer scope is left. But that's it? I need anonymous methods too. They have no full-value replacement: 1. Full Generics.Collections compatibility (btw. I'am still working on the most cool ever Generics.* version ;) ) :P 2. More functional programming. 3. It will be possible to implement LINQ (! short way from anonymous methods to lambda expressions, and then LINQ). 4. :D Not everyone is an old pascal procedural dinosaur :) anonymous methods = fresh air. Regards Maciej Izak (hnb) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/16/2014 11:18 AM, Florian Klämpfl wrote: Isn't using anonymous methods in this case only a work around for missing OpenMP support? Absolutely, but neither Free Pascal nor Delphi implement OpenMP. The OpenMP page on the Free Pascal wiki hasn't been significantly changed since 2008, which coincidentally is the last time Allen Bauer blogged about his Delphi Parallel Library. I'm looking for something that I can use soon, not in 5 years. Also, while I prefer the OpenMP proposals in the wiki, I don't see us dropping Delphi for Lazarus on Windows anytime soon. Short term we'll be too busy moving our Linux version over from Kylix and then re-porting our OS X version from LCL/Carbon to LCL/Cocoa. I still don't get how closures/anonymous methods help you to get rid of fibers? I mean, anonymous methods are only a short cut; closures allow you to capture the state of the variables of the outer scope even if the outer scope is left. But that's it? No, it doesn't completely replace fibers. That will require some very painful detangling and much uglier, asynchronous code. However, a majority of the usage is just doing calculations, showing a dialog, then doing something with the dialog results. In cases like that it should be relatively easy to do fairly mechanical conversions to something based on anonymous methods and closures. I'm not sure what you mean by the But that's it? though. Yes, they're just syntax sugar. The alternative is creating a second procedure (polluting the namespace), declaring, allocating, and initializing a record with the local state, then passing it to that second function. It's doable, and that's exactly what we did before I implemented the fiber support, but it's certainly not ideal. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] For-in-loop question about GetEnumerator
Hi, This article is quite clear for me: http://wiki.freepascal.org/for-in_loop But let say that I have this class: TMyList = class private FList: TList public constructor Create; destructor Destroy; procedure Add; procedure Remove; end; Now I want to do: for a in MyClass do begin end; Can I do this without creating new enumerator? I mean pass enumerator from FList? I'm confused because if I create function: function TMyClass.GetEnumerator: TListEnumerator begin Result := FList.GetEnumerator; end; ... then FList.GetEnumerator create new object (TListEnumerator.Create(Self)). My question is, where it is freed? Is it freed automatically on runtime after exit from loop? I don't want memory leak Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] For-in-loop question about GetEnumerator
2014-05-16 18:13 GMT-03:00 Krzysztof dib...@wp.pl: Hi, This article is quite clear for me: http://wiki.freepascal.org/for-in_loop But let say that I have this class: TMyList = class private FList: TList public constructor Create; destructor Destroy; procedure Add; procedure Remove; end; Now I want to do: for a in MyClass do begin end; Can I do this without creating new enumerator? I mean pass enumerator from FList? I'm confused because if I create function: function TMyClass.GetEnumerator: TListEnumerator begin Result := FList.GetEnumerator; end; ... then FList.GetEnumerator create new object (TListEnumerator.Create(Self)). My question is, where it is freed? Is it freed automatically on runtime after exit from loop? I don't want memory leak Regards You need to create a enumerator, and it will be freed by your owner. See internal implementation: Function TComponent.GetEnumerator: TComponentEnumerator; begin Result:=TComponentEnumerator.Create(Self); // Self is the owner component, and it will free your enumerator automatically in destroy end; -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Annual Inform
Annual Inform: To FreePascal project: Sorry, I don’t speak English. Thanks a lot for your compiler. I’m programming LibreN3D for animations in FreeDOS-POVRay. My project advances very slowly. I’m convinced is useful and very possible. In this link http://www.filefactory.com/file/4zko0fsusvh9/FreeRay_2013%20y%20CAFE2011.zip you can see FreeRay2013. This package contains twenty 3D LGPL objects with HTML documentation. Eighteen of them are FreeDOS compatibles. In this package you also encounters older objects. Your project helps me a lot. Sorry, I don’t have competitive 3D free games, only commercial ones for now. “Bloques Iniciales”, “Origamis Iniciales” have 32bit versions for Windows, MAC and FreeDOS. I’m very interested in Linux, but I have a lot of problems with graphics in SDL, and pure FreePascal. Text mode is O.K. I’m planning future games for Linux also. I really think a process unit for DOS is very useful for me. For example, CAFE2011, in the package, is a virtual LGPL spreadsheet. I’m planning, not sure is a bad or good idea, to incorporate core code for games in CAFE. The program will generate virtual pages without graphics in *.TGA format, process unit read this and other information for your 3D programs and you will put it in your display. You will need an external modeler, LibreN3D will be functional afterwards 2020. CAFE reads your UDO or some RAW data for 3D objects and process this information. This sounds complicated, it’s complicated… ¿Why NOT an SDL or pure GRAPH extension? I’m don’t know. CAFE is a solution more general, but SDL is faster. Fast is very, very important in games… I’m don’t know. Process unit with Multi Core in DOS sounds very good, but process unit in Single Core is sufficient good for me, of course. Marie and Jesus bless you. Rafael Angel Campos Vargas rofoelcom...@hotmail.com Office box. 964-1250 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] For-in-loop question about GetEnumerator
On Fri, 16 May 2014 23:13:43 +0200 Krzysztof dib...@wp.pl wrote: [...] This article is quite clear for me: http://wiki.freepascal.org/for-in_loop [...] ... then FList.GetEnumerator create new object (TListEnumerator.Create(Self)). My question is, where it is freed? Is it freed automatically on runtime after exit from loop? Yes. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] For-in-loop question about GetEnumerator
Thanks! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Armv7 fpc openocd v8
Hi everyone, I have recently got open ocd v8 to talk to my nxp lpc 1343 via a stlinkv2 , should fpc ( 2.6.4 or higher support this type of CPU and does anyone have any ideas how to hook up gdb to openocd ? I am thinking of using Lazarus to step through some code if possible) Justin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
