Am 19.08.2013 06:00, schrieb Paul Robinson:
I've been busy, I have other things I had to attend to, then I
realized I couldn't figure out what was going on without a decent
cross reference program, but nothing that's out there supports the
UNIT construct, nor do they know how to skip over
Hi Experts.
Since ages I am searching for an easy method to do normal (i.e.
event driven) Pascal programming using Lazarus as an IDE and targeting
headless embedded devices (with no GUI hardware and/or GUI software
infrastructure).
I understand that the fpc RTL already provides
On Mon, 19 Aug 2013, Michael Schnell wrote:
Hi Experts.
I would happily try to do something like that myself, but at least for the
rest of this year I will not find the time :( . But as this thought comes in
my mind, I now try to collect information on this issue.
I am having a déjà vu
On Monday 19 August 2013 11:28:25 Michael Van Canneyt wrote:
It should not take more than an hour to implement.
Maybe some additional minutes for the implementation of an efficient and
precise timer queue. ;-)
Martin
___
fpc-devel maillist -
On 08/19/2013 11:28 AM, Michael Van Canneyt wrote:
I am having a déjà vu :-)
Yep.
But at that time I (maybe completely erroneously) decided to do this as
an LCL Widget Type as I had extensions in mind that would fit just there
(such as stuff based on ExtPascal or mse-ifi).
If memory serves
On 08/19/2013 11:51 AM, Martin Schreiber wrote:
Maybe some additional minutes for the implementation of an efficient
and precise timer queue. ;-)
_MANY_ thanks for the support, making me feel that I am not completely
insane.
-Michael
___
fpc-devel
Based on information and belief, on Mon, 19 Aug 2013 10:37:43 +0200, Sven Barth
pascaldra...@googlemail.com wrote to the Free Pascal list:
I don't get what you're trying to say here.
I mean I spent the better part of a year writing a cross-reference tool for
Free Pascal since the compiler
On Mon, 19 Aug 2013, Michael Schnell wrote:
On 08/19/2013 11:28 AM, Michael Van Canneyt wrote:
I am having a déjà vu :-)
Yep.
But at that time I (maybe completely erroneously) decided to do this as an
LCL Widget Type as I had extensions in mind that would fit just there (such
as stuff
On 08/19/2013 01:47 PM, Michael Van Canneyt wrote:
YOU DO NOT NEED TO DO THIS.
Just implement the loop and let it call CheckSynchronize at regular
intervals.
All the rest will be done for you.
Did you ever do embedded software ?
The result of the event in the main queue is not having
On Monday 19 August 2013 11:55:37 Michael Schnell wrote:
On 08/19/2013 11:51 AM, Martin Schreiber wrote:
Maybe some additional minutes for the implementation of an efficient
and precise timer queue. ;-)
_MANY_ thanks for the support, making me feel that I am not completely
insane.
BTW,
On Mon, Aug 19, 2013 at 02:03:11PM +0200, Michael Schnell wrote:
On 08/19/2013 01:47 PM, Michael Van Canneyt wrote:
YOU DO NOT NEED TO DO THIS.
Just implement the loop and let it call CheckSynchronize at
regular intervals.
All the rest will be done for you.
Did you ever do embedded
Am 19.08.2013 13:47, schrieb Michael Van Canneyt:
TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, as
well for Linux and for Windows in a ready to use way (including
documentation).
YOU DO NOT NEED TO DO THIS.
Just implement the loop and let it call CheckSynchronize at
On 08/19/2013 02:21 PM, Martin Schreiber wrote:
BTW, why don't you simply use MSEgui which provides all this out of
the box instead to constantly annoy FPC and Lazarus people? ;-)
(We already did discuss this years ago ;-) . I do hope that just asking
a question each year is not too
On 08/19/2013 02:27 PM, Henry Vermaak wrote:
How you implement WakeMainThread will depend on your event loop
mechanism. A simple way to do this is with the self-pipe trick.
Of course this is exactly what I have in mind.
(But as said, I am doing nothing but groundwork research and don't have
On 08/19/2013 02:29 PM, Sven Barth wrote:
(Except QueueAsyncCall which is only implemented in the LCL's
TApplication and is not triggered by CheckSynchronize)
...and (AFAI understand) TTimer is not implemented at all.
I suppose both events can be implemented similar to TThread.Queue.
On Mon, 19 Aug 2013, Michael Schnell wrote:
On 08/19/2013 01:47 PM, Michael Van Canneyt wrote:
YOU DO NOT NEED TO DO THIS.
Just implement the loop and let it call CheckSynchronize at regular
intervals.
All the rest will be done for you.
Did you ever do embedded software ?
Yes.
The
On 08/19/2013 02:35 PM, Michael Van Canneyt wrote:
So what ? That's a detail of the event loop.
My comment was not regarding event loop but regarding regular
intervals.
If you implement an event loop that does not do turns on regular
intervals but only when it gets tickled by the event
On Mon, 19 Aug 2013, Michael Schnell wrote:
On 08/19/2013 02:35 PM, Michael Van Canneyt wrote:
So what ? That's a detail of the event loop.
My comment was not regarding event loop but regarding regular
intervals.
If you implement an event loop that does not do turns on regular
On 08/19/2013 02:48 PM, Michael Van Canneyt wrote:
I will not implement anything, you will :)
Right you are :-) .
I sincerely hope I once will find the time to do this, now that we
TThread.Queue which proves that it in fact is possible.
-Michael
Michael Schnell schrieb:
So - if I would start doing anything on that behalf - I would do
something with as wide reach as possible: providing (at least) all of
TTimer, TThread.Synchronize, TThread,Queue, and
Application.QueuAsnycCall, as well for Linux and for Windows in a ready
to use way
On 08/19/2013 02:27 PM, Henry Vermaak wrote:
A simple way to do this is with the self-pipe trick.
I suppose in Windows we would use a message. In Linux I would prefer a
semaphore or - supposedly best if really usable here - pthread.mutex as
same uses FUTEX whenever the underlying arch allows
On Mon, Aug 19, 2013 at 03:49:53PM +0200, Michael Schnell wrote:
On 08/19/2013 02:27 PM, Henry Vermaak wrote:
A simple way to do this is with the self-pipe trick.
I suppose in Windows we would use a message. In Linux I would prefer
a semaphore or - supposedly best if really usable here -
On 08/19/2013 04:31 PM, Henry Vermaak wrote:
How do you suppose that a mutex in linux will wake up an event loop?
The mutex gets taken before the loop is started. Now the loop blocks
when taking it. It is freed whenever an event is scheduled.
Whether or not a mutex blocks when the same
On Mon, Aug 19, 2013 at 04:43:52PM +0200, Michael Schnell wrote:
On 08/19/2013 04:31 PM, Henry Vermaak wrote:
How do you suppose that a mutex in linux will wake up an event loop?
The mutex gets taken before the loop is started. Now the loop blocks
when taking it. It is freed whenever an
On 08/19/2013 08:45 AM, Michael Schnell wrote:
On 08/19/2013 02:48 PM, Michael Van Canneyt wrote:
I will not implement anything, you will :)
Right you are :-) .
I sincerely hope I once will find the time to do this, now that we
TThread.Queue which proves that it in fact is possible.
I'm
Am 19.08.2013 10:37, schrieb Sven Barth:
Adding a new platform to FPC is not cheesecake and you should know how
the compiler's backend work. Just looking at the output of a target
won't help you!
A good start is aarch64: I tried to work in it as structured as possible
to make it some draft for
26 matches
Mail list logo
