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
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
On Mon, May 26, 2014 at 12:17 PM, Craig Peterson
wrote:
> 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 whe
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 i
On Fri, May 16, 2014 at 11:45 AM, Craig Peterson
wrote:
> 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?
On Fri, May 16, 2014 at 11:45 AM, Craig Peterson
wrote:
> 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 rep
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
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
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
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 synta
> On May 26, 2014, at 2:52 AM, Michael Schnell 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 m
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/list
> On May 26, 2014, at 7:47 AM, Michael Schnell 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
_
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/cg
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 p
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 "D
Am 26.05.2014 09:52 schrieb "Michael Schnell" :
>
> 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
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):
-
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
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
disadvantage
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
>
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 offens
2014-05-22 11:18 GMT+02:00 Sven Barth :
> 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/mailma
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-pa
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;
Am 22.05.2014 09:44 schrieb "ko paka" :
>
> 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 maill
Hello,
just out of curiosity - by packages do you mean delphi style dynamic
packages - bpl ?
tomas
On Wed, May 21, 2014 at 10:53 PM, Sven Barth wrote:
> Am 21.05.2014 17:53 schrieb "Craig Peterson" :
>
> > I don't mind keeping a fork of a stable release with the feature
> > backported, if that
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 cla
Am 21.05.2014 17:53 schrieb "Craig Peterson" :
> 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
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 s
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
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
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
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 functi
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 perso
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
Hi,
2014-05-16 18:18 GMT+02:00 Florian Klämpfl :
>
> ... 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 replac
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
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 improve
2014-05-16 11:13 GMT-03:00 Dmitry Boyarintsev :
> 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 >
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
wrote:
> Hi all,
>
> What's the current state of FPC's anonymous functions/closu
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 yea
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
43 matches
Mail list logo
