On Thu, 9 Nov 2006, Micha Nelissen wrote:
> Daniël Mantione wrote:
> > Add to this the enable/disable system of commands. I.e. disable cmCut and
> > all menu
> > bars, status bars, buttons, context menu's and whatever thing
> > that can generate a cmCut turns grey.
>
> In Delphi/VCL this is
On Thu, 9 Nov 2006, Daniël Mantione wrote:
>
>
> Op Thu, 9 Nov 2006, schreef Florian Klaempfl:
>
> > Michael Schnell schrieb:
> > > BTW.:
> > >
> > > TPC comes with Free Vision.
> > >
> > > The FPC IDE based on Free Vision seems to work fine.
> > >
> > > The Free Vision "Non-GUI" seems to
Daniël Mantione wrote:
> Add to this the enable/disable system of commands. I.e. disable cmCut and all
> menu
> bars, status bars, buttons, context menu's and whatever thing
> that can generate a cmCut turns grey.
In Delphi/VCL this is called a TAction, which can be assigned to
speedbutton, too
Op Thu, 9 Nov 2006, schreef Florian Klaempfl:
> Michael Schnell schrieb:
> > BTW.:
> >
> > TPC comes with Free Vision.
> >
> > The FPC IDE based on Free Vision seems to work fine.
> >
> > The Free Vision "Non-GUI" seems to be event driven and thus needs to
> > implement a kind of event schedu
Michael Schnell schrieb:
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision "Non-GUI" seems to be event driven and thus needs to
implement a kind of event scheduler.
It's an event handling loop using queues for input events. Very primitive
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision "Non-GUI" seems to be event driven and thus needs to
implement a kind of event scheduler.
Maybe same might be worth looking at.
-Michael
___
fpc
Why don't you simply go ahead, implement something (cross-platform) and then
we can see how this can be integrated in FPC, if this integration is needed at all...
I did do first steps of this already some years ago. I hope I will be
able to start over in January.
-Michael
_
On Thu, 9 Nov 2006, Michael Schnell wrote:
>
> > Alas, Object Pascal lacks a decent portable OS tasking interface.
> >
> With Delphi we successfully used Windows Messages for inter Thread
> communication.
>
> With FPC on Linux a friend of mine used System 5 Messages queues for the same
> pu
Alas, Object Pascal
lacks a decent portable OS tasking interface.
With Delphi we successfully used Windows Messages for inter Thread
communication.
With FPC on Linux a friend of mine used System 5 Messages queues for the
same purpose.
So IMHO inter Thread messages is a good way to go.
On Thursday 09 November 2006 08:22, Michael Schnell wrote:
> > Yes, of course, this still *is* nothing more than an event loop,
> > ...
>
> A decent event loop should use an OS API to free the processor until
> the next event is scheduled:
That's why I wrote the example in Esterel.
Give me that A
Yes, of course, this still *is* nothing more than an event loop, ...
A decent event loop should use an OS API to free the processor until the
next event is scheduled:
Meta code:
repeat
if (event in event queue) begin // this is either an OS API call or
the event queue is done with user
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > The answer to my "I always thought a timer is more comparable to an
> > interrupt or signal than a polling loop." was "That is a very
> > common misconception." which I still refuse as being a correct
> > answer
Your code can perfectly be implemented as an add-on unit, which we can
distribute.
The first goal I see is that FPC comes with portable support for TTimer
and Delphi/Lazarus compatible thread support, that can be used in a
GUI-less Application - thus without Lazarus. If that's possible wit
Vinzent Hoefler wrote:
The answer to my "I always thought a timer is more comparable to an
interrupt or signal than a polling loop." was "That is a very common
misconception." which I still refuse as being a correct answer.
The irony is of course that you clamp to your interrupt definition, bu
The answer to my "I always thought a timer is more comparable to an
interrupt or signal than a polling loop." was "That is a very common
misconception." which I still refuse as being a correct answer.
I misunderstood that you meant a Delphi TTimer. And I wanted to point
out that many Delphi
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> >> but it's not realtime by any definition.
> >
> > First, I never said "real-time" in that context and second: it sure
> > can
>
> I concluded that from your quote:
>
>
> Timing events allow for a handler to be
Vinzent Hoefler wrote:
but it's not realtime by any definition.
First, I never said "real-time" in that context and second: it sure can
I concluded that from your quote:
Timing events allow for a handler to be executed at a future point in
time in an efficient way, as it is a standalone ti
On Wed, 8 Nov 2006, Michael Schnell wrote:
> Michael Van Canneyt wrote:
> > TThread.Synchronize does not need to be changed. You can set a series
> > of callbacks (from classes unit) which you can then use to configure
> > the whole synchronize issue...
> >
> >
> Sounds great !
> > Seems corr
Michael Van Canneyt wrote:
TThread.Synchronize does not need to be changed. You can set a series
of callbacks (from classes unit) which you can then use to configure
the whole synchronize issue...
Sounds great !
Seems correct. And all this cross-platform, of course :-)
Of course !!! :-)
On Wed, 8 Nov 2006, Michael Schnell wrote:
>
> > There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
> > descends
> > from it. All you need to do is create a descendent of TCustomApplication
> > which
> > can implement all the messaging you wish for...
> >
> I took a loo
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> >repeat
> > SysUtils.Sleep (self.Interval);
> > self.Logger.Flush;
> >until self.Terminated;
> >
> > is totally impossible to work? To implement something less crude
> > you
>
> It works,
Oh w
Vinzent Hoefler wrote:
repeat
SysUtils.Sleep (self.Interval);
self.Logger.Flush;
until self.Terminated;
is totally impossible to work? To implement something less crude you
It works, but it's not realtime by any definition.
Micha
___
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication which
can implement all the messaging you wish for...
I took a look at TCustomApplication. Same does not provide anything that
is relate
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > So, the semantics would be about the same as in a signal (apart
> > from the "softer" timing), but you would have much less
> > restrictions in the handler's implementation compared to a real OS
> > signal, whic
Vinzent Hoefler wrote:
So, the semantics would be about the same as in a signal (apart from the
"softer" timing), but you would have much less restrictions in the
handler's implementation compared to a real OS signal, which acts more
like an interrupt.
Impossible. You'll end with TThread.Sync
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote:
Sorry for all the confusion, I'm trying to clarify what I actually mean
(or what I would *expect* from such a timer object):
> I don't see how async timers can be useful for software (maybe to
> control hardware perhaps, but only the tri
Micha Nelissen wrote:
Preemptive means same thread, as it 'preempts' it. That's what a (unix)
signal is. That's what Vincent meant (I think).
Sorry, "Vinzent", it is.
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
Micha Nelissen wrote:
Michael Schnell wrote:
An asynchronous timer needs to do a preemptive callback.
No.
Ooops ? What is an asynchronous timer according to your definition ?
Preemptive execution needs it's own thread.
No.
Ooops ? What do you think is preemptive ? By definition preempti
> Michael Schnell wrote:
>
> I don't see how async timers can be useful for software (maybe to
> control hardware perhaps, but only the trivial kind as well, no complex
> state allowed), as you cannot take any locks, and must be re-entrant.
No, not reentrant, unless you use the same event in t
Michael Schnell wrote:
An asynchronous timer needs to do a preemptive callback.
No.
Preemptive
execution needs it's own thread.
No.
This is a way to provide the timer with
a thread.
Preemptive means same thread, as it 'preempts' it. That's what a (unix)
signal is. That's what Vincent
This is not an async timer in the way Vincent meant it, assuming I
read his mails correctly. Also, pre-emptive multitasking is different
from the async timer as you're explaining here in exactly this detail.
An asynchronous timer needs to do a preemptive callback. Preemptive
execution needs it
Michael Schnell wrote:
I don't see how async timers can be useful for software
It decreases the latency. This is always the reason to do _preemptive_
multitasking.
This is not an async timer in the way Vincent meant it, assuming I read
his mails correctly. Also, pre-emptive multitasking is di
No, the timer will still be synchronous, only to the current thread's
event handler, not to the main (GUI) one.
These timers are assigned to a thread.
They are synchronous (non-preemptive) regarding their own thread and
asynchronous (preemptive) regarding all other threads. So, by accessing
Separate event scheduler and application.
Hint registered and saved in the to-do list :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Also I think a base thread should remain free from this. You can of course
create a descendant of tthread that is event driven (e.g. messagequeue, pump
and list of known events/methodvars in overriden tthread.execute)
Right. That is a decent way to do it "optionally" (as I of course would
do
Michael Schnell wrote:
the need for a GUI, I'd like to enhance the concept by optionally having
an TApplication object for any thread (e.g. TThread.Application) and
It shouldn't be named Application, because there is only one application
per process.
thus having an event scheduler for same.
Sorry, if it caused confusion, ...
No problem, taking more ideas as an input is always useful !
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
But now ... rereading the post, the original text was "You can't just
put a TTimer in which works in it's own thread and then calls some
callback in it's own thread," and I still wonder why I shouldn't be
able to do that (well, if TTimer would actually do what its name
suggests and no-one els
Vinzent Hoefler wrote:
Maintaining
thread-safety ain't so complex once you start following some simple
rules.
Either you're underestimating thread-safety or you're a genius. Can you
document those simple rules on the wiki ?
Micha
___
fpc-devel mai
On Wednesday 08 November 2006 10:26, Ales Katona wrote:
> This is an old problem, and not fixable by wishing it. If you want a
> good async. timer, sure make one, but don't expect it to work safely
> by magic.
I'm sure I won't, I'm paranoid. :)
> That's what I ment, it won't simply "just work wi
> If you take a look the start of this thread, I mentioned that after
> implementing Delphi/Lazarus like behavior for the main thread without
> the need for a GUI, I'd like to enhance the concept by optionally having
> an TApplication object for any thread
Not every thread or program is event
Michael Van Canneyt wrote:
It can't because X-Windows or MS-Windows are not thread-safe.
FTR: AFAIK MS WinAPI is thread safe, just don't do stupid things
yourself of course (like passing buffers that are going to be messed
with by another thread and such).
Micha
Well, I don't consider it beautiful, I consider it a hack. :)
It's beautiful, as the user does not need to care about mutually exclude
access of the objects that are used both in the main line code and the
timer callbacks. Most "application programmers" would not be able to
deal with this
On Wednesday 08 November 2006 10:14, Michael Schnell wrote:
> If you take a look the start of this thread, I mentioned that after
> implementing Delphi/Lazarus like behavior for the main thread without
> the need for a GUI, I'd like to enhance the concept by optionally
> having an TApplication obj
You can call a callback in same thread, but since you can't ensure what
the callback does from your "lib" you can't make it threadsafe in any
way. Even if you put the callback itself into a "criticalsection" it
might eg: change some variable which was "just in use" by the main
thread, and once the
It can't because X-Windows or MS-Windows are not thread-safe.
Yeah, right. And threading in DOS is not possible either, because DOS
is non-reentrant, is it?
You _can_ use threads in an X-Windows, MS-Windows or DOS environment,
you just can't do X-Windows, MS-Windows or
On Wednesday 08 November 2006 10:01, Michael Schnell wrote:
> But doing a function call (or hence using a callback) does not change
> the thread context you are running in and thus you are still the same
> thread. IOW: code lines are not _dedicated_ to a thread context.
Oh that, of course. Seem
It all depends on what you're trying to accomplish. I still like to have
a "asynchronous timer event" model. It would still simplify some code.
You are right that this would be desirable.
Normal Delphi/Lazarus like TTimers are non-preemptive (you may call it
synchronous) for a good reason
I even call the callback of another thread. :P
No you can't.
You still refuse to tell me why, so please stop telling me what I can't
do, especially when I *am* doing it.
Of course you can call any callback that exists in the application from
anywher
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote:
> On Wed, 8 Nov 2006, Vinzent Hoefler wrote:
> > On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
> > > On Wed, 8 Nov 2006, Michael Schnell wrote:
> > > > > As for general use, you can't do a Timer this way.
> > > >
> >
On Wednesday 08 November 2006 09:27, Ales Katona wrote:
> On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote:
> > On Tuesday 07 November 2006 16:10, Ales Katona wrote:
> > > As for general use, you can't do a Timer this way.
> >
> > Believe me, I can. :)
> >
> > > You can't just put
> > > a T
On Wed, 8 Nov 2006, Vinzent Hoefler wrote:
> On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
> > On Wed, 8 Nov 2006, Michael Schnell wrote:
> > > > As for general use, you can't do a Timer this way.
> > >
> > > Right ! The beauty of TTimer (and GUI events as well) is that it
> >
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication which
can implement all the messaging you wish for...
That sounds very good. :-) I'll take a look at this. (Supposedly in
January :
Vinzent Hoefler wrote:
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
Of course, because the common concept of a timer is as asynchronous
as in "multi-threaded" or even "interrupt".
That is not true ! (See my other post.)
Well, a timer i
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
> On Wed, 8 Nov 2006, Michael Schnell wrote:
> > > As for general use, you can't do a Timer this way.
> >
> > Right ! The beauty of TTimer (and GUI events as well) is that it
> > does not work in a thread. Otherwise it e.g. would not b
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote:
> On Tuesday 07 November 2006 16:10, Ales Katona wrote:
>
> > As for general use, you can't do a Timer this way.
>
> Believe me, I can. :)
>
> > You can't just put
> > a TTimer in which works in it's own thread and then calls some
> > cal
On Wednesday 08 November 2006 09:15, Michael Schnell wrote:
> Right ! The beauty of TTimer (and GUI events as well) is that it does
> not work in a thread.
Well, I don't consider it beautiful, I consider it a hack. :)
Vinzent.
___
fpc-devel maillist
On Wed, 8 Nov 2006, Michael Schnell wrote:
>
> > As for general use, you can't do a Timer this way.
> Right ! The beauty of TTimer (and GUI events as well) is that it does not work
> in a thread. Otherwise it e.g. would not be possible to do GUI stuff in a
> timer event, as VCL and LCL are not
As for general use, you can't do a Timer this way.
Right ! The beauty of TTimer (and GUI events as well) is that it does
not work in a thread. Otherwise it e.g. would not be possible to do GUI
stuff in a timer event, as VCL and LCL are not thread save (and probably
can't be made thread save).
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
> > Of course, because the common concept of a timer is as asynchronous
> > as in "multi-threaded" or even "interrupt".
>
> That is not true ! (See my other post.)
Well, a timer is, even though the Delphi implementation of a so-called
TTim
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
> As for general use, you can't do a Timer this way.
Believe me, I can. :)
> You can't just put
> a TTimer in which works in it's own thread and then calls some
> callback in it's own thread,
I even call the callback of another thread. :P
>
On Tuesday 07 November 2006 18.34, Michael Schnell wrote:
> > MSEgui has teventthread (lib/common/kernel/msethread.pas), there is also
> > a timer implementation (lib/common/kernel/msetimer.pas).
> >
> > http://mypage.bluewin.ch/msegui/
>
> Thanks for the pointer. I'll take a look at this tomorrow.
On Tue, 7 Nov 2006, Michael Schnell wrote:
>
> > I don't even care, because I simply don't understand what "time" as in
> > "timer" has to do with "graphics" as in "graphical". For me that's two
> > completely different subjects unless we're talking about animations where
> > those two subjects
MSEgui has teventthread (lib/common/kernel/msethread.pas), there is also a
timer implementation (lib/common/kernel/msetimer.pas).
http://mypage.bluewin.ch/msegui/
Thanks for the pointer. I'll take a look at this tomorrow.
What is the purpose of msetimer ?
Do you think this can show a way
The big advantage is that you do not need to protect any resources
from multi-threaded access if you do not explicitly create a thread
by means of TThread.
And the big disadvantage seems to be a overly complicated programming
model. Guess, what I'd prefer.
As said, we
I don't
even care, because I simply don't understand what "time" as in "timer"
has to do with "graphics" as in "graphical". For me that's two
completely different subjects unless we're talking about animations
where those two subjects meet.
Viewing from top you are right, and I do need a plat
Of course, because the common concept of a timer is as asynchronous as
in "multi-threaded" or even "interrupt".
That is not true ! (See my other post.)
Timer events are queued in a line (message-queue) with all
"hardware"/"GUI" events. Main Thread event callbacks are never
interrupted (p
>
> Of course, because the common concept of a timer is as asynchronous as
> in "multi-threaded" or even "interrupt".
>
> You're not seriously trying to work around that simple fact, do you?
>
Actualy I am, because lNet is single-threaded non-blocking.
As for general use, you can't do a Timer
On Tuesday 07 November 2006 15.14, Michael Schnell wrote:
> > Remember you need to call the "HandleEvents" as fast as possible to
> > stay effective (otherwise you lose precision)
>
> I want to avoid this by any means !
>
> That is why I want to have a message driven system (as described in the
>
On Tuesday 07 November 2006 15:17, Ales Katona wrote:
> So eg: if you want to do something every 1000ms, you could put a
> TThread based timer in, and make it Sleep(1000) and then call the
> code, but you must be sure that your main thread cannot have
> conflicts if this code is called at any time
On Tuesday 07 November 2006 15:02, Michael Schnell wrote:
> > I always thought a timer is more comparable to an interrupt or
> > signal than a polling loop.
>
> That is a very common misconception.
Indeed. Even a paper in "Embedded Computing Design" about Ada 2005
follows that "very common" misc
> This is how lNet already works, no ? Where's the difference ?
Indeed but it's only there because there's no other way, if I could just
make it "magicly" work without "CallAction" I'd love to.
You can't call callbacks in threads (you can but only in one thread, not
between threads), and you can
On Tuesday 07 November 2006 14:47, Michael Schnell wrote:
> > Well, for me it would have saved me some time which I wasted in
> > creating threads that implement "timing events" by simply sleeping
> > for a particular time.
>
> IMHO this should be done following the Delphi paradigms to be nice to
I always thought a timer is more comparable to an interrupt or
signal than a polling loop.
That is a very common misconception. A TTimer event is not an interrupt
in that it does not interrupt any code in the Application. such an
"automatic event" is always done in the main thread and onl
I can't call callbacks in threads? Why's that? Or am I understanding
something wrong?
Of course you can use "events" (aka class properties that are
functions) in threads. That is just the Object Pascal syntax. But in
the main thread in Delphi or Lazarus events of GUI objects (e.g.
TBut
Remember you need to call the "HandleEvents" as fast as possible to
stay effective (otherwise you lose precision)
I want to avoid this by any means !
That is why I want to have a message driven system (as described in the
other post):
TAppllication creates an event from a message generat
If you need an event-based loop and callbacks you can make
TApplication. If you don't want LCL ok, then make your own, it's
generaly needed to be very problem-specific anyhow, eg: the TLEventers
I use are ment for handling events on handles (files and sockets atm,
sockets only in windows).
On Tuesday 07 November 2006 12:42, Ales Katona wrote:
> If you want a "Timer" a "polling" mechanism has to take place which
> looks if something happened on some timer for example,
Is that so?
> OnTimer is "ready to be fired" (you can't call callbacks in threads,
I can't call callbacks in threa
Ales Katona wrote:
Apart from asynchronous stuff like watching handles etc. I don't see
much use for this relativly complicated program model. Remember you need
to call the "HandleEvents" as fast as possible to stay effective
(otherwise you lose precision)
This is how lNet already works, no ?
I'm not sure I see the value behind these ideas.
If you need an event-based loop and callbacks you can make TApplication. If you don't want LCL ok, then make your own, it's generaly needed to be very problem-specific anyhow, eg: the TLEventers I use are ment for handling events on handles (files
lNet is
a networking library, and has an internal event loop already
implemented, cross-platform.
Wouldn't it b e better to first implement an independent cross-platform
event loop ("Application!" thingy) in the RTL that can be used by
TTimer, TThread.Synchronize and lNet ?!?!?
If lNet's
Michael Schnell wrote:
If the Eventer class in lNet can be moved into general FCL this would
be possible because I was planning to create a TLTimer, for use with
lNet eventer.
Could you elaborate on that (I don't know what lNet is at the moment).
lNet is a networking library, and has an i
If the Eventer class in lNet can be moved into general FCL this would
be possible because I was planning to create a TLTimer, for use with
lNet eventer.
Could you elaborate on that (I don't know what lNet is at the moment).
But IMHO there should not be a separate TLTimer but the RTL (that
Graeme Geldenhuys wrote:
I would also love to see a TTimer in FPC rather than Lazarus. TTimer
without any GUI depenencies.
If the Eventer class in lNet can be moved into general FCL this would be
possible because I was planning to create a TLTimer, for use with lNet
eventer.
Micha
On 07/11/06, Michael Schnell <[EMAIL PROTECTED]> wrote:
That's really bad ! IMHO it should be possible to use TTimer and TThread in
a simple non-GUI way. (I maybe will need to do an embedded project on an
ARM/Linux system that does not have X or any widget library.)
I would also love to see a
..., at least for the beginning !
Why ? You don't need language enhancements for this IMHO. Scheduling and
messaging is OS territory, not programming language territory.
e.g. Ada provides multithreading means as language elements and AFAIK,
other languages also provide "
On Tue, 7 Nov 2006, Michael Schnell wrote:
>
> > It does.
> >
> Great !
> > None currently. Only 'Synchronize' is implemented.
> >
> Like with Delphi :-) :-( .
> > Feel free to implement this, but not as a language enhancement, a simple
> > unit should be enough.
> >
> ..., at le
Really ? Does TThread.Suspend work on linux ?
IMHO, the need for this function means your design is broken, but
maybe it's just me ...
As Delphi does provide TThread.Suspend, I suppose FPC should do so on
any platform (unless that is really impossible, which I don't think).
Of course you ar
It does.
Great !
None currently. Only 'Synchronize' is implemented.
Like with Delphi :-) :-( .
Feel free to implement this, but not as a language enhancement, a simple
unit should be enough.
..., at least for the beginning !
I'm sure I'll do this (supposedly in
On Tue, 7 Nov 2006, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > > 1) How is the state on this issue? Does the latest released version of the
> > > FPC
> > > RTL already provide a decent implementation of the threading primitives
> > > known
> > > from Delphi ? (e.g. TThread.Suspend, T
Michael Van Canneyt wrote:
1) How is the state on this issue? Does the latest released version of the FPC
RTL already provide a decent implementation of the threading primitives known
from Delphi ? (e.g. TThread.Suspend, TThread.Synchronize, TEvent,
TCriticalSection, TThreadList, etc) as well for
On Tue, 7 Nov 2006, Michael Schnell wrote:
> Hi FPC experts.
>
> I read this thread in the list archive and as I'm very interested in this
> topic (since years), I'm very happy do see this evolving and would like to
> provide some comment (and maybe contribute some code once I'm up to speed wit
92 matches
Mail list logo
