Re: [fpc-pascal] Delphi compatible anonymous functions
On 05/26/2014 05:02 PM, Dmitry Boyarintsev wrote: Using a threading for GUI control is generally bad idea. Most of standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - do not use in multiple threads. Introducing threads to handle GUI is potentially dangerous (due to all threading syncing issues) and an overhead. Most of solutions doesn't really need threads, as well as usage of threads increases resources consumption. Some time ago I did some tests on that behalf. Trying to do a multithreaded GUI (i.e. accessing multiple instances of the OS'es widgets set from a single application) might be possible but a lot of hassle and dangerous indeed. But it does make sense, as you would allow multiple processors to work concurrently on the Library code (in the application) and the WidgetSet code (outside of the application) Here supposedly the more promising way is to start multiple display applications and have them communicate in a decent way with a business logic application.. -Michael ___ 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 05/26/2014 06:49 PM, Dmitry Boyarintsev wrote: My fear here is that anonymous functions will be misused dramatically once being available. Very valid point ! This also holds for parallel loops (my current favorite encapsulation for OpenMP or similar libraries): Users _will_ try to do GUI stuff in a parallel loop. So this needs to be prevented (at best at compile time, but supposedly only a runtime check is possible). -Michael ___ 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 05/23/2014 05:46 PM, Craig Peterson wrote: On 5/23/2014 2:09 AM, Michael Schnell wrote: rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) I'm not sure exactly what you're asking/proposing. Yes, there are alternative syntaxes for closures that might be more Pascalish, but I want something that's compatible with Delphi because we need to keep using it on Windows for the foreseeable future. Hmmm parallel loop and future in fact _is_ compatible with Delphi: here Delphi Prism. (It's not the fault of Lazarus, that Delphi is not compatible with itself :-( .) The discussion has somehow moved from, anonymous functions do OpenMP support. I understand that anonymous functions is some kind of syntax candy for stuff that - with some additional typing - could be done without, OpenMP support is about allowing parallel work - especially useful on the now ubiquitous multi-processor boxes - by means of the rtl. parallel loop and future is about syntax candy for parallel execution - e.g. via OpenMP. So my question was about the real target of the discussion. -Michael ___ 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 26.05.2014 09:52 schrieb Michael Schnell mschn...@lumino.de: On 05/23/2014 05:46 PM, Craig Peterson wrote: On 5/23/2014 2:09 AM, Michael Schnell wrote: rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) I'm not sure exactly what you're asking/proposing. Yes, there are alternative syntaxes for closures that might be more Pascalish, but I want something that's compatible with Delphi because we need to keep using it on Windows for the foreseeable future. Hmmm parallel loop and future in fact _is_ compatible with Delphi: here Delphi Prism. (It's not the fault of Lazarus, that Delphi is not compatible with itself :-( .) That's because Delphi Prism is not Delphi. It's a product they licensed and added the name Delphi Prism on. Oxygene (what Prism is based on) was never intended to stay Delphi compatible. Regards, Sven ___ 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 05/26/2014 11:35 AM, Sven Barth wrote: That's because Delphi Prism is not Delphi. It's a product they licensed and added the name Delphi Prism on. Oxygene (what Prism is based on) was never intended to stay Delphi compatible. Of course I do know this, But They decided to call It Delphi, while the original name by RemObj was just Oxygen. Moreover the mobile stuff they include with Delhi XE seems to be nearly as poorly compatible with the mainstream Delphi as Prism is. Hence Lazarus' quest for overall Delphi compatibility is not a possible aim. (even disregarding maybe nearly solvable issues like codepage based strings.) -Michael ___ 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
In our previous episode, Michael Schnell said: using it on Windows for the foreseeable future. Hmmm parallel loop and future in fact _is_ compatible with Delphi: here Delphi Prism. (It's not the fault of Lazarus, that Delphi is not compatible with itself :-( .) It is not a part of Delphi we are compatible with. And before you ask, neither we are compatible with 3rd rail or radphp. ___ 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 05/26/2014 02:03 PM, Marco van de Voort wrote: neither we are compatible with 3rd rail or radphp. I never heard somebody call one of these Delphi. -Michael ___ 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 May 26, 2014, at 7:47 AM, Michael Schnell mschn...@lumino.de wrote: neither we are compatible with 3rd rail or radphp. I never heard somebody call one of these Delphi. RadPHP was originally marketed under the name Delphi for PHP. -- 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
On 05/26/2014 03:20 PM, Craig Peterson wrote: RadPHP was originally marketed under the name Delphi for PHP. very funny stuff :-) . -Michael ___ 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 May 26, 2014, at 2:52 AM, Michael Schnell mschn...@lumino.de wrote: I understand that anonymous functions is some kind of syntax candy for stuff that - with some additional typing - could be done without, OpenMP support is about allowing parallel work - especially useful on the now ubiquitous multi-processor boxes - by means of the rtl. parallel loop and future is about syntax candy for parallel execution - e.g. via OpenMP. So my question was about the real target of the discussion. I am interested in anonymous functions specifically. See my second post in the thread for why. OpenMP support would be a nice feature, but even if it were Delphi/VCL compatible, it only gets me half of my goal, and I only included the threading support first because it was shorter to describe. Replacing our usage of fibers/coroutines is a *much* more pressing issue. In any case, neither Free Pascal nor Delphi support OpenMP right now, but Delphi does support futures and parallel loops using the OmniThreadLibrary, which requires anonymous methods. Getting anonymous methods into Free Pascal is a much more manageable short term goal than waiting for OpenMP support to be specified, implemented, and debugged. -- 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
On 05/26/2014 03:32 PM, Craig Peterson wrote: In any case, neither Free Pascal nor Delphi support OpenMP right now, but Delphi does support futures and parallel loops using the OmniThreadLibrary, ... Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? which requires anonymous methods. Getting anonymous methods into Free Pascal is a much more manageable short term goal than waiting for OpenMP support to be specified, implemented, and debugged. seems like a viable way to go. -Michael ___ 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/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- 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
I might be wrong, but reading through OmniThreadLibrary - the usage of anonymous functions is optional. The regular language structures could be used: global functions/object methods. Why having anonymous support is critical for the usage of the library? thanks, Dmitry On Mon, May 26, 2014 at 9:49 AM, Craig Peterson cr...@scootersoftware.comwrote: On 5/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- 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
Sorry, you've actually somehow answered my questions earlier... I'm rereading the thread now. On Mon, May 26, 2014 at 9:53 AM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: I might be wrong, but reading through OmniThreadLibrary - the usage of anonymous functions is optional. The regular language structures could be used: global functions/object methods. Why having anonymous support is critical for the usage of the library? thanks, Dmitry On Mon, May 26, 2014 at 9:49 AM, Craig Peterson cr...@scootersoftware.com wrote: On 5/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- 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
On Fri, May 16, 2014 at 11:45 AM, Craig Peterson cr...@scootersoftware.comwrote: 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. [snip] Ugh, but with anonymous functions replacing ShowMyDialog vs ShowMyDialogDone, you're in much worse positions. It's likely that you would have to the duplicate code. I'd assume that after modal dialog code is somehow matches to some other code in the system. Model-View-Controller pattern comes into play. The dialog itself is just a way to get a confirmation from a user to do an actions. It's likely that the same action could take place without a confirmation from a user. So, with anonymous functions, you'd need to duplicate the same action code across the system. (Anonymous functions are just for here-and-now usage). No reason to enumerate the cons of code duplication. No directly related to usage of anonymous functions... ...and please note, I'm not trying to criticize your work, but give an excuses for my point of view... Using a threading for GUI control is generally bad idea. Most of standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - do not use in multiple threads. Introducing threads to handle GUI is potentially dangerous (due to all threading syncing issues) and an overhead. Most of solutions doesn't really need threads, as well as usage of threads increases resources consumption. ...back to anonymous: So making a choice of changing the code to use Fibers, rather than using ShowDialog / DoneDialog was not so good after all. Right now you're in position to change the code code from Fibers to something more portable... And yet again using ShowDialog / DoneDialog is one of the options. Another point to use anonymous functions is storing of State that could be later use in processing the resulting code. The compiler is doing for you it's good and bad. Good - you don't need to write any extra code, Bad - pretty much anything could go into the state, even the things you don't need to be there (or do need to be there, but not there at all). So, I do think that storing the state explicitly is a better option, even though extra lines of code would be required. thanks, Dmitry ___ 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 Fri, May 16, 2014 at 11:45 AM, Craig Peterson cr...@scootersoftware.comwrote: 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. Anonymous functions are bad for unit testing. Why? Because they do exist only at the place of the call and depends on the state of at the time the call. And thus they cannot be tested separately without the caller. I'd assume the parallel execution is definitely needed since the actions you're separating are time consuming. They're time consuming, because they might be complex. Having an ability to test a complex code separately (outside the execution environment/application) is a big benefit. Yet again - the re-usage of the code. What if you switch from OmniThreadLibrary to OpenMP (or whatever other threading library) that doesn't provide support for anonymous functions. What if you'd need to write a separate application, that doesn't have the requirement to use threads. Using the regular code (in procedures or methods) reduces the number of changes you'd need to do. I've mentioned it before OmniThreadLibrary doesn't require you to use anonymous functions. thanks, Dmitry ___ 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/26/2014 10:02 AM, Dmitry Boyarintsev wrote: Ugh, but with anonymous functions replacing ShowMyDialog vs ShowMyDialogDone, you're in much worse positions. It's likely that you would have to the duplicate code. I'd assume that after modal dialog code is somehow matches to some other code in the system. Model-View-Controller pattern comes into play. The dialog itself is just a way to get a confirmation from a user to do an actions. It's likely that the same action could take place without a confirmation from a user. So, with anonymous functions, you'd need to duplicate the same action code across the system. (Anonymous functions are just for here-and-now usage). No reason to enumerate the cons of code duplication. Dmitry, no offense, but you're making a lot of assumptions about our code with no basis to do so, and I'm honestly not interested in getting into a philosophical debate about the correct way to develop software. There are cases where anonymous methods will work well and cases where we'll have to split it up. It's a tool that I'd like to have available, not something I'm going to cram where it doesn't belong. Using a threading for GUI control is generally bad idea. Most of standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - do not use in multiple threads. Introducing threads to handle GUI is potentially dangerous (due to all threading syncing issues) and an overhead. Most of solutions doesn't really need threads, as well as usage of threads increases resources consumption. Fibers are cooperative threads, not pre-emptive ones. They're the way GUI APIs worked in the past (Windows 3.1, MacOS Classic) and GUI APIs generally still support them just fine. Recent releases of OS X have started having trouble with it, but older ones worked just fine. There are no synchronization issues because there isn't more than one running at the same time. So making a choice of changing the code to use Fibers, rather than using ShowDialog / DoneDialog was not so good after all. Right now you're in position to change the code code from Fibers to something more portable... And yet again using ShowDialog / DoneDialog is one of the options. Cocoa already has what I'm asking for built in to Objective C language and the Cocoa/sheets API. Many of the functions that show dialogs, that previously would have had ShowDialog/DoneDialog behavior, accept Objective C blocks now, which are very similar to how anonymous methods would work in this context. In any case, we've already done the ShowDialog/DoneDialog thing and it was unpleasant to work with and resulted code that was much harder to understand. Anonymous functions are bad for unit testing. Why? Because they do exist only at the place of the call and depends on the state of at the time the call. And thus they cannot be tested separately without the caller. *GUIs* are bad for unit testing. *Threading* is bad for unit testing. Anonymous functions are an implementation detail and are no better or worse for testing than ShowDialog/DoneDialog or OpenMP would be. In the cases where we'd use it for things like parallel loops, I'd test the outer function as a whole, and the inner functions that it calls. I don't need to unit test the anonymous function separately just because it has function in it's name. You might as well be arguing that I should break out every for loop and if statement into its own function that I can test it separately. Having an ability to test a complex code separately (outside the execution environment/application) is a big benefit. Again, you're assuming things about the testability and structure of our code that have nothing to do with the discussion at hand. What if you switch from OmniThreadLibrary to OpenMP (or whatever other threading library) that doesn't provide support for anonymous functions. What if you'd need to write a separate application, that doesn't have the requirement to use threads. Using the regular code (in procedures or methods) reduces the number of changes you'd need to do. Switching from OmniThreadLibrary to some eventual OpenMP implementation would involve removing the anonymous function syntax and turning it into a regular begin..end block for a parallel for loop. That wouldn't involve any visible changes to the objects themselves because that's all encapsulated in the outer function call. The chances of our code being reused in something that doesn't use threads is non-existent, and irrelevant either way. I've mentioned it before OmniThreadLibrary doesn't require you to use anonymous functions. Even if that's true, it would significantly reduce the expressiveness of the resulting code, and I don't know how true it is because the author has specifically said that he doesn't support FPC because of how intrinsic anonymous functions are to the design. -- Craig Peterson Scooter Software
Re: [fpc-pascal] Delphi compatible anonymous functions
On Mon, May 26, 2014 at 12:17 PM, Craig Peterson cr...@scootersoftware.comwrote: Dmitry, no offense, but you're making a lot of assumptions about our code with no basis to do so, and I'm honestly not interested in getting into a philosophical debate about the correct way to develop software. There are cases where anonymous methods will work well and cases where we'll have to split it up. It's a tool that I'd like to have available, not something I'm going to cram where it doesn't belong. That's very valid point. I do not know how your code, I don't know who is based and organized. So I have to go from my experience on how the problems (with UI) are solved. I also have a vast experience of (language/libraries) tools being misused and underused. (My fear here is that anonymous functions will be misused dramatically once being available. And I'm fine with that for C-syntax languages, but I'd hate to handle in future for Pascal) My general point is - in many cases (pascal) language is underused. And many problems could be solved without a new language constructions. Use the reasonable minimum as much as possible. So sticking to an existing syntax minimum improves portability of the code (portability not just across platforms and/or compilers, but for integration with different 3d-party libraries). You've done your considerations and you've done your choice, so let's wait until anonymous functions are available in FPC. thanks, Dmitry ___ 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 05/22/2014 06:17 PM, Craig Peterson wrote: This is exactly the data marshalling I was talking about. .. And what you seemingly want to avoid. I suppose technically this method - especially when using the event record pool Marco mentioned - does not seem to have any great disadvantages. As said, for the user some syntax candy might be beneficial. rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) What do you think, -Michael ___ 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/23/2014 2:09 AM, Michael Schnell wrote: rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) I'm not sure exactly what you're asking/proposing. Yes, there are alternative syntaxes for closures that might be more Pascalish, but I want something that's compatible with Delphi because we need to keep using it on Windows for the foreseeable future. -- 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
On 05/21/2014 05:52 PM, Craig Peterson wrote: I think it's useful for encapsulating asynchronous callbacks and improving readability by keeping the callback code near the setup location and removing data marshalling scaffolding. For complex asynchronous events, I tested this: - Define a class (sibling of TObject) ) that holds some data and the procedure to be used in the asynchronous callback. The procedure has no parameters - To through the callback event, create an instance and fill the data structure in the instance and then use TThread.Queue to through the event: procedure TmyThread.Execute begin ... AsyncEvent := TAsyncEvent.create; AsyncEvent.DataX := . AsyncEvent.DataY := . Queue(AsyncEvent.DoIt); - now forget the variable AsyncEvent :-) . - some time later the main Thread calls DoIt here we go: procedure DoIt... begin X := DataX; Y := DataY; ... do stuff ... Free; end; Here, the procedure just frees it's own instance. This does not seem to be a problem. (Obviously exception handling needs to be added.) So I get away without the use of Interfaces. To me this seems like the most pascalish way to implement a closure for encapsulating asynchronous callbacks. As syntax candy you might want to define a procedure as having a closure attribute and have same call free just before exiting (even when exiting by an exception). -Michael ___ 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 22.05.2014 09:44 schrieb ko paka kopa...@gmail.com: Hello, just out of curiosity - by packages do you mean delphi style dynamic packages - bpl ? Yes. Though first step is compile time packages and runtime packages later... Regards, Sven ___ 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
In our previous episode, Michael Schnell said: - To through the callback event, create an instance and fill the data structure in the instance and then use TThread.Queue to through the event: procedure TmyThread.Execute begin ... AsyncEvent := TAsyncEvent.create; AsyncEvent.DataX := . AsyncEvent.DataY := . Queue(AsyncEvent.DoIt); - now forget the variable AsyncEvent :-) . - some time later the main Thread calls DoIt here we go: procedure DoIt... begin X := DataX; Y := DataY; ... do stuff ... Free; end; I do something similar, but pool these event records in generic pools, so at the end of the generic doit (I call it execute) it puts itself back in the pool. The generic pool is complemented by a generic factory class. I originally only pooled allocations over 1 MB, but since generics pooling become easier I pool more readily. (never benchmarked if that matters for small allocs of course. Big chance that the tthreadlist lock in the pool is worse than the allocation/free with modern threadaware heapmgrs, since those probably lock only once to sync multiple deallocations) ___ 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 05/22/2014 11:33 AM, Marco van de Voort wrote: I do something similar, but pool these event records in generic pools, Great ! Could we have this in the RTL ? Is it viable to create closure as a syntax candy on top of this ? -Michael ___ 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-22 11:18 GMT+02:00 Sven Barth pascaldra...@googlemail.com: Yes. Though first step is compile time packages and runtime packages later... Any timeline? Regards, 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/21/2014 3:53 PM, Sven Barth wrote: While I consider bounties a valuable instrument for Open Source development I personally don't like them. Especially in the way you are mentioning it (no offence here!) it would put quite some pressure on me which I'm honestly not a fan of. No offense taken. I'm a bit uncomfortable with it myself because I don't want to disrupt the existing release plans, and things like generics and packages do seem like better uses for your time. Unfortunately there aren't that many people we could hire short term who understand the code and would be able to do it in a reasonable timeframe. Ideally I'd just like to give the money to Blaise to finish the work, but he didn't respond to my email. -- 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
On 5/22/2014 2:35 AM, Michael Schnell wrote: For complex asynchronous events, I tested this: - Define a class (sibling of TObject) ) that holds some data and the procedure to be used in the asynchronous callback. - To through the callback event, create an instance and fill the data structure This is exactly the data marshalling I was talking about. Our application is heavily asynchronous and it isn't an exaggeration to say that there are hundreds of different calls with different functions and parameter lists. Having to define a new object, or even just a new method and record and fill in that data is a lot of code, and consequently there are plenty of cases that would benefit from more asynchronous behavior or parallism that don't do so. -- 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
On 5/18/2014 2:34 AM, Florian Klämpfl wrote: I wanted only to point out that personally I would first work on OpenMP support than implementing anonymous methods (which I consider anyways very un-pascalish) and closures. That's fair. I wouldn't expect anyone who's philosophically opposed to the idea to work on it. The last time it came up it sounded like some of the other devs were interested, and there was at least grudging acceptance that it would eventually be added for Delphi compatibility. I'd just like to hurry that up. OpenMP support would certainly be nice, but it's also only half of the reason I want anonymous methods, and it doesn't seem like the timeframe for that would be any faster. To be honest, I see anonymous methods and closures not much earlier in a stable release: if they are not implemented and merged during the next few months, they will not go into the next major release (somewhere in 2015). Between major releases we have usually 3 years, so 4 years at least as well for anonymous methods/closures. I don't mind keeping a fork of a stable release with the feature backported, if that's what it takes, though obviously I'd prefer it to be in properly. Sven, if you're still following the thread, would a bounty help bump the priority enough for you to work on it before the 2.8 cutoff? Yes, that's what I meant. Closures/anonymous methods allow sometimes (in my eyes seldomly) some source line savings in modern pascal, no more no less. We'll have to agree to disagree on that. I think it's useful for encapsulating asynchronous callbacks and improving readability by keeping the callback code near the setup location and removing data marshalling scaffolding. I know our GUI design combined with the number of different asynchronous calls is rare in the Pascal community though, so I agree that for a lot of developers it won't be as large of a benefit. -- 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
On 5/15/2014 12:58 AM, Sven Barth wrote: As Michal said, someone was working on that, but I didn't hear anything from him in the past year or so... maybe when I find the time and have some other topics removed from my list I'll look into reintegrating and finishing what he has begun... I sent an email to Blaine, but he hasn't responded. Vasiliy, the one who brought it up last year said he didn't finish his work either and wouldn't have time to, though he did point me to his repository at https://github.com/vkevroletin/freepascal/tree/closures-via-interfaces I don't want to step on toes, especially since we've already benefited significantly from the team's work as a whole, but I would really like to get this feature in. I'm happy to offer a larger amount than previous bounties, and I'm ok with it either going to one person or split up, and we can take it off-list if it would help. -- 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 21.05.2014 17:53 schrieb Craig Peterson cr...@scootersoftware.com: I don't mind keeping a fork of a stable release with the feature backported, if that's what it takes, though obviously I'd prefer it to be in properly. Sven, if you're still following the thread, would a bounty help bump the priority enough for you to work on it before the 2.8 cutoff? While I consider bounties a valuable instrument for Open Source development I personally don't like them. Especially in the way you are mentioning it (no offence here!) it would put quite some pressure on me which I'm honestly not a fan of. I don't promise anything - especially since generics and packages are higher up on my priority list - but if I find the time... Regards, Sven ___ 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 05/16/2014 07:00 PM, Craig Peterson wrote: Absolutely, but neither Free Pascal nor Delphi implement OpenMP. Do you think just a library is what should be done ? I feel the Pascal syntax candy provided by Prism (parallel loop, future, ...) might be a good way to encapsulate parallel functionality implemented in the RTL (maybe using the work done for OpenMP. -Michael ___ 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
In our previous episode, Florian Kl?mpfl said: Absolutely, but neither Free Pascal nor Delphi implement OpenMP. I wanted only to point out that personally I would first work on OpenMP support than implementing anonymous methods (which I consider anyways very un-pascalish) and closures. How useful is OpenMP for this? If I look in the wikipedia, it is all about paralellizing batch calculations, not about communication between unrelated threads. ___ 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 19.05.2014 11:36, schrieb Marco van de Voort: In our previous episode, Florian Kl?mpfl said: Absolutely, but neither Free Pascal nor Delphi implement OpenMP. I wanted only to point out that personally I would first work on OpenMP support than implementing anonymous methods (which I consider anyways very un-pascalish) and closures. How useful is OpenMP for this? This part of the thread was about using anonymous methods and closure for parallelizing loops so OpenMP is very usefull in this case. If I look in the wikipedia, it is all about paralellizing batch calculations, not about communication between unrelated threads. ___ 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
Am 16.05.2014 19:00, schrieb Craig Peterson: 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. I wanted only to point out that personally I would first work on OpenMP support than implementing anonymous methods (which I consider anyways very un-pascalish) and closures. 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. To be honest, I see anonymous methods and closures not much earlier in a stable release: if they are not implemented and merged during the next few months, they will not go into the next major release (somewhere in 2015). Between major releases we have usually 3 years, so 4 years at least as well for anonymous methods/closures. I'm not sure what you mean by the But that's it? though. Yes, they're just syntax sugar. Yes, that's what I meant. Closures/anonymous methods allow sometimes (in my eyes seldomly) some source line savings in modern pascal, no more no less. ___ 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] Delphi compatible anonymous functions
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
Re: [fpc-pascal] Delphi compatible anonymous functions
Hey Craig, I've been experimenting with anonymous functions in FPC and have working code, but they're not at all like what Delphi provides: https://github.com/tangentstorm/tangentlabs/blob/master/pascal/funops.pas (On the other hand, they require 0 compiler changes...) I asked about lambdas in the IRC channel a few months back, and Sven told me someone had started work on anonymous methods sometime in the past, but the work sort of stalled out. If you're interested in funding this and nobody else pipes up, I'm interested in implementing it. It's something I've been wanting to do anyway, but I just haven't had the time/energy to dig into the FPC internals. On Thu, May 15, 2014 at 12: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
On 15.05.2014 07:05, Craig Peterson 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? As Michal said, someone was working on that, but I didn't hear anything from him in the past year or so... maybe when I find the time and have some other topics removed from my list I'll look into reintegrating and finishing what he has begun... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
