Boian Mitov wrote:
See... this is the point. In order to properly implement parallel loops
etc. even in their limited form the compiler needs specific RTL support.
So we break one of the basic principles that the compiler is the root,
and the RTL is a library compiled in it. Once you start getti
See... this is the point. In order to properly implement parallel loops etc.
even in their limited form the compiler needs specific RTL support.
So we break one of the basic principles that the compiler is the root, and
the RTL is a library compiled in it. Once you start getting the compiler to
If ARC is missing you need to call "free". No Critical section is involved
with that.
Incorrect the pointer on which you call free needs to be guarded.
Yep. But with ARC you force synchronization in occasions where it would
not be necessary without ref counting.
That is very questionable, usual
We already implement equivalent of signals as I mentioned in Mitov.Runtime,
however they are anonymous methods based, and we call them TMultiProc but
they are the same thing. I even showed a code snippet in another post.
With best regards,
Boian Mitov
--
On 9/26/2014 4:51 AM, Mattias Gaertner wrote:
On Fri, 26 Sep 2014 10:38:04 +0200 (CEST)
Michael Van Canneyt wrote:
[...]
To allow for doing this with thread, an event queue for worker threads needs
to be provided.
Huh? WHY ?
That's why:
https://www.youtube.com/watch?v=BKorP55Aqvg
ROTFLM
Michael Schnell wrote:
On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote:
.
A parallel loop syntax is very attractive, but the practical
difficulty is that it would probably have to sit on top of threads and
getting code distributed promptly over multiple worker threads, i.e.
starting up withi
On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote:
.
A parallel loop syntax is very attractive, but the practical
difficulty is that it would probably have to sit on top of threads and
getting code distributed promptly over multiple worker threads, i.e.
starting up within 10s of nSec rather tha
Michael Schnell wrote:
On 09/25/2014 07:27 PM, Boian Mitov wrote:
What I am saying is that the parallel loop handles only one specific
case of parallelization, and with limited options.
A library implementation on the other hand offers full flexibility.
Of course I did understand that.
What I
Thinking harder I remember that I did not send it to the Forum but in a
private mail to the one person who seemed interested.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-de
On 09/26/2014 02:09 PM, Reinier Olislagers wrote:
Well, that says a lot, I suppose.
As it did work for me, it says that nobody is interested in an
ActiveNoGUI Widget Type for Lazarus right now.
I can use it with the svn version of fpc if I want to.
So I decided to hold off until the released
On 26/09/2014 14:04, Michael Schnell wrote:
> On 09/26/2014 01:57 PM, Reinier Olislagers wrote:
> Moreover I did not find that anybody besides myself has been interested
> in this issue.
> I seem to remember that I once posted a zip file with a current testing
> version (either here or in the Lazar
On 09/26/2014 01:57 PM, Reinier Olislagers wrote:
So why not include your own version of TThread with IFDEFS to
check for FPC version so it can be retired when an FPC 2.7.1+ is
used/stable?
I don't suppose it makes sense to do a version of TThread that does not
reside in the rtl / and "classes
On 26/09/2014 13:52, Michael Schnell wrote:
> On 09/26/2014 01:41 PM, Reinier Olislagers wrote:
> As I already pointed out multiple times it works just fine for me,
> but can't be included in the LCL as it needs TThread.Queue and same
> is not in the released version of fpc and hence not usable for
On 09/26/2014 01:41 PM, Reinier Olislagers wrote:
Which reminds me - how is that library (non-GUI event loop IIRC) coming
along? Is there any code repository where interested people can look?
As I already pointed out multiple times it works just fine for me, but
can't be included in the LCL a
On 26/09/2014 12:08, Michael Schnell wrote:
> On 09/26/2014 11:36 AM, Mark Morgan Lloyd wrote:
> Of course the colleague was not able to clearly distinguish between fpc
> and Lazarus. But we obviously are in the wrong forum here, as the
> "culprit" seems to be the inability of Lazarus LCL to do eve
On 09/26/2014 11:36 AM, Mark Morgan Lloyd wrote:
so that we're not groping in the dark based on your account of his
recollection of the rumours he's picked up from sources that might not
be reliable.
I was just trying to help fpc to be a winner (here and elsewhere). ;-)
In fact it seems that
On 09/26/2014 11:40 AM, Michael Van Canneyt wrote:
That is an implementation detail of Qt. Not so in FPC.
Correct.
Hence - if you say the signaling stuff is not / should not be a language
feature but just a matter of a library (I don't disagree here) fpc is
unrelated to this. I feel that fpc
2014-09-26 6:37 GMT-03:00 Sven Barth :
> Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" >:
> >
> > If you want asynchronous, or if you want the signal executed in the
> context of a thread in case of multiple threads, that is another matter.
> >
> > Although I am having difficulty seeing how y
On 09/26/2014 11:37 AM, Sven Barth wrote:
In Qt it does. Each QObject has a thread it is owned by and thus the
signal handling mechanism knows to which thread to queue to deliver a
signal to a certain object.
Making the appropriate ("signalable") Objects instances of TThread
siblings woul
On Fri, 26 Sep 2014, Sven Barth wrote:
Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" :
>
>
>
> On Fri, 26 Sep 2014, Martin Schreiber wrote:
>
>> On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote:
Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is no
Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" :
>
>
>
> On Fri, 26 Sep 2014, Martin Schreiber wrote:
>
>> On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote:
Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not
so easy to implement as it seems. ;-)
Michael Schnell wrote:
Yesterday, I had a discussion with a colleague about programming languages.
He said that he did not like Object-Pascal / fpc because it lacks the
concept of "signals" he finds in other languages / libraries. (He is not
an expert but discusses on base of rumors he collect
On Fri, 26 Sep 2014, Michael Schnell wrote:
On 09/26/2014 11:11 AM, Michael Van Canneyt wrote:
Please look at the link Mattias provided.
It's enlightening.
In another forum I already used this video as an example myself.
Please read my initial post at the top of the thread: the request f
On 09/26/2014 11:11 AM, Michael Van Canneyt wrote:
Please look at the link Mattias provided.
It's enlightening.
In another forum I already used this video as an example myself.
Please read my initial post at the top of the thread: the request for
sending "Signals" from one thread to one or
On 09/26/2014 11:12 AM, Michael Van Canneyt wrote:
But the signaling mechanism we talked about is obviously asynchronous.
This may come as a shock to you, but no, it is not "obvious".
???
I described: sending "Signals" from one thread to one or more others,
sender and receipient can be as
On Fri, 26 Sep 2014, Michael Schnell wrote:
On 09/26/2014 10:58 AM, Michael Van Canneyt wrote:
Absolutely. A signaling mechanism, synchronous, is not hard.
I suppose an _synchronous_ mechanism can be done on base of or similar to
"Dispatch".
But the signaling mechanism we talked about
On Fri, 26 Sep 2014, Michael Schnell wrote:
On 09/26/2014 10:38 AM, Michael Van Canneyt wrote:
To allow for doing this with thread, an event queue for worker threads
needs to be provided.
Huh? WHY ?
When handling asynchronous Events with a thread, you need an event queue and
a mechanism to
On 09/26/2014 10:58 AM, Michael Van Canneyt wrote:
Absolutely. A signaling mechanism, synchronous, is not hard.
I suppose an _synchronous_ mechanism can be done on base of or similar
to "Dispatch".
But the signaling mechanism we talked about is obviously asynchronous.
-Michael
__
On 09/26/2014 10:38 AM, Michael Van Canneyt wrote:
To allow for doing this with thread, an event queue for worker
threads needs to be provided.
Huh? WHY ?
When handling asynchronous Events with a thread, you need an event queue
and a mechanism to have the thread sleep until the queue gets not-e
On Fri, 26 Sep 2014, Martin Schreiber wrote:
On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote:
Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not
so easy to implement as it seems. ;-)
It is. Depends on your definition of difficult, of course.
Or the impl
On Fri, 26 Sep 2014 10:38:04 +0200 (CEST)
Michael Van Canneyt wrote:
>[...]
> > To allow for doing this with thread, an event queue for worker threads
> > needs
> > to be provided.
>
> Huh? WHY ?
That's why:
https://www.youtube.com/watch?v=BKorP55Aqvg
Mattias
___
On 09/26/2014 10:19 AM, Martin Schreiber wrote:
Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so
easy to implement as it seems. ;-)
Nice :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.f
On 06/09/2014 11:26, Reinier Olislagers wrote:
> Periodically I try to cross-compile a simple program [1] for my
> router with fpc trunk.
Recap: mips big endian, no FPU (openwrt router). Test program hung.
Thanks to commits in trunk between my last test and now, the sample
program below works.
-T
On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote:
> > Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not
> > so easy to implement as it seems. ;-)
>
> It is. Depends on your definition of difficult, of course.
>
Or the implemented functionality.
Martin
__
On Fri, 26 Sep 2014, Michael Schnell wrote:
On 09/26/2014 09:39 AM, Michael Van Canneyt wrote:
You can use the Observer pattern; it is in the classes unit.
I'll take a look.
And to be honest, this is not a language concept, but a library concept.
AFAIK he mentioned QT as a library provi
On Fri, 26 Sep 2014, Martin Schreiber wrote:
On Friday 26 September 2014 09:57:43 Michael Schnell wrote:
On 09/26/2014 09:39 AM, Michael Van Canneyt wrote:
You can use the Observer pattern; it is in the classes unit.
I'll take a look.
And to be honest, this is not a language concept, but
On Friday 26 September 2014 09:57:43 Michael Schnell wrote:
> On 09/26/2014 09:39 AM, Michael Van Canneyt wrote:
> > You can use the Observer pattern; it is in the classes unit.
>
> I'll take a look.
>
> > And to be honest, this is not a language concept, but a library concept.
>
> AFAIK he mention
On 09/26/2014 09:39 AM, Michael Van Canneyt wrote:
You can use the Observer pattern; it is in the classes unit.
I'll take a look.
And to be honest, this is not a language concept, but a library concept.
AFAIK he mentioned QT as a library providing this.
It can be easily implemented.
If
On 09/25/2014 05:14 PM, Sven Barth wrote:
ARC objects will only be destroyed when the last reference to them has
gone out of scope. If there is still a reference, then there's still
the object.
I understood, the example showed that the object might survive even if
there is no reference any
On 09/25/2014 07:30 PM, Boian Mitov wrote:
Strongly disagree...
You can't deny it. Please read some technical docs about the cost of
interlocked operation in multicore systems.
As compare to the cost of other locking methods such as critical
sections that have to be implemented instead if the A
On Fri, 26 Sep 2014, Michael Schnell wrote:
Yesterday, I had a discussion with a colleague about programming languages.
He said that he did not like Object-Pascal / fpc because it lacks the concept
of "signals" he finds in other languages / libraries. (He is not an expert
but discusses on b
On 09/25/2014 07:27 PM, Boian Mitov wrote:
What I am saying is that the parallel loop handles only one specific
case of parallelization, and with limited options.
A library implementation on the other hand offers full flexibility.
Of course I did understand that.
What I was saying that providin
On 09/25/2014 05:11 PM, Sven Barth wrote:
Of course the user can see it.
But he does not _need_ to. :-)
Namely to introduce refcounting to classes where he/she can't
influence the parent class (simple example: a TStrings descendant)
Sounds like a great concept.
-Michael
Yesterday, I had a discussion with a colleague about programming languages.
He said that he did not like Object-Pascal / fpc because it lacks the
concept of "signals" he finds in other languages / libraries. (He is not
an expert but discusses on base of rumors he collected.)
With "signals" he
44 matches
Mail list logo
