Board index » kylix » Re: What about a new IDE for dcc and bc++

2003-11-27 08:21:26 PM
kylix1
Marco,
Regards,
Oliver
 

message system using sempaphores ore other inert process communication
means. In Delphi you can do even do this using TThreadList and TEvent
(but the problem remains how to create a Delphi language event from a
TEvent in the main thread, or is this even solved in FP ?).
converts Mouse and Keyboards (and other) events into "Delkphi language
events". It should be quite easy to hook incoming (system V) messages in
here.
and commercial components that are avvailable in source code for Delphi
and enhence our productivity greatly.
It's got a "memory to memory" architecture (operations usually are done
without using registers, which is not a tradoff, as it has a dual ported
internal ram and can do e.g. A:=A+B for non-register variables in a
single cycle (4 nSec). Moreover it has internal multithreadding with 0
cycle task switching overhead. So the FP port would be an "iuntersting"
task <g>.
Thanks, Michael
 

On 2003-11-27, Michael Schnell < XXXX@XXXXX.COM >wrote:
What do you mean by "language" events btw? The message modifier for classes?
code was immense, and doesn't disappear.
Some faction in the company that typically wants the newest stuff, or some
manager decides to conform to marketplace standards (read: what everybody is
using and has the biggest representation on bookshelfs) Totally independant
of real points in favour of against. This can happen quite fast, in only
a year.
Everything belonging to Delphi just gets {*word*221}stamped "legacy", because it
is considered a dead end, and then no money (employee time) is invested
anymore in anything Delphi related, components, tools and packages are not
updated, a few new Windows/IE/Office gadgets are not supported, and the
vicious circle starts.
FPC is formally independant of Borland (actually we get no cooperation what
so ever, not even some BP legacy code like Turbo Vision), however FPC's
userbase will be hit hard if the Delphi part of Borland stops (I don't
consider Delphi.NET to be Delphi, if most code must be rewritten from near
scratch).
Most of the FPC users own Delphi (specially the more serious ones, excluding
the usual people that do a one semester structured programming course), but
simply use FPC to go places where Delphi/Kylix can't go.
So if Borland Delphi colapses, it will hit FPC, but also e.g. Jedi within a
year, decreasing userbases, shorter involvement.
The Slashdot like "company dies, so all users will switch to the open source
equivalent" is pretty much nonsense, and only goes for exceptional cases.
FPC will loose the contributors that work with Delphi professionally over
time, and that will hurt. Badly. The few people still working with Delphi
will be effectively working on legacy codebases, and therefore won't spent
enough time on FPC enough to make a significant impact, only to solve their
direct problem at best.
The legacy users are only interested in full compability, and nothing more.
Most don't even expect to have to read manuals. Nothing will effectively
flow back into the project, while maintaining even 95% compability is
already a significant effort.
Only the people that _already_ have invested in creating clean and portable
code will be able to make a conversion.
The only beneficial effect of such a colapse would be the release of some
former shareware and freeware codebases into PD or under an Open Source
license.
out of academic interest are not likely. It is simply too much work.
 

{smallsort}

easily create your own "Events" in classes nicely by using a property
with a procedure type.
In Borland Delphi/Kylix, in the main thread of a GUI application, the
programmer usually creates nothing but events, hooking his code to
events that are provided by (standard) components. In Windows these
events are initially triggered by OS messages (Mouse, Keyboard, timer
etc.) The conversion Message->Callback seems to be done by Windows
itself. Linux does not offer this functionality, so it's done by QT (no
idea how). If FP really can do GUI applications in Delphi style (they
say you can compile some Delphi projects unchanged in FP and run them
ion Linux), this functionality seems to be implemented in the RTL. So
adding "some kind of message" ->event does not seem like a huge
problem.
Delphi and an FP branch. So FP needs to be as compatible as possible.
some papers provided by borland and others ? It seems that many delphi
applications can be ported easily (or nearly unchanged) to Delphi.Net.
The course being that .NET was designed by the main architect of Delphi
(C# being Delphi in disguise, it's inner principles much nearer to
Delphi than to C++) and, based on the same ideas, .NET can be seen like
the "bottom part" of Delphi.
applications, but of course embedded is not the main issue for FP,
though it seems to be the best tool to do embedded stuff in Pascal.
-Michael
 

On Fri, 28 Nov 2003 11:23:57 +0100, Michael Schnell wrote:
But then the way GUI stuff works in FPC is just that you have a bunch of
method pointers and hidden away in TApplication.Run you have a loop that
checks for GUI "events" and then calls the appropriate method (via a
method pointer that was assigned somewhere).
How the "events" are initially triggered doesn't matter, as long as you
have method pointers (which of course FPC has). Windows doesn't do the
"Message->Callback" conversion, TApplication.Run internally just goes over
the windows message queue and checks who the message was for, and calls
the appropriate method (via a method pointer).
I think there's some confusion here as to the definition of "event". You
seem to apply that an event is something triggered by the OS, yet inside
the RTL its simply some mechanism of checking for GUI/OS/XYZ events and
calling the appropriate "event handler" (which is just a method on some
object).
You'll always need some kind of main application processing loop here, so
I don't quite understand your point about FPC /supporting/ events. Of
course it has method pointers. Yes, you can write GUI programs and
TApplication.Run provides a main application loop that gets GTK events and
calls the appropriate methods to handle them.
Windows doesn't do any event handling, it just sends messages out. Linux
doesn't do event handling either, but the toolkit is responsible for
providing some way to check for messages. In windows you do this via
PeekMessage and related calls, in gtk you do this via the gtk_main_* calls
(afaik), and I don't know about qt.
johannes
 

On 2003-11-28, Michael Schnell < XXXX@XXXXX.COM >wrote:
event (for that object).
Of course this works in FPC, but this whole system is something of the GUI
libraries, not of the language or basic runtime.
But keep in mind that something like ICS is running, relatively unmodified.
For an idea of the required changes see www.stack.nl/~marcov/ics.html
Only the dependance on _real_ messaging is afaik slightly less inside
lazarus, this because most other widgetsets (gtk) use procedural callbacks,
not messaging.
system doesn't depend on messaging. Don't forget that the X windowing system
is nearly entirely userland based (like Windows NT had before 4.0)
Just like you can access the Windows GUI system via different api's (3.x apis,
win32 api, NT native, .NET probably)
, so it's done by QT (no idea how).
same order etc.
(FPC is probably capable of compiling the VCL, if we would spend some time
in it)
all people not really interested in FPC, but only for a cheap way out,
only full 100% compability will do, which is near impossible, and even
undesirable, since both delphi and kylix are OS and processor specific.
We want to keep the 95% good stuff, and don't waste time on providing
compability.
But the main point is that FPC is not just about Delphi legacy code. People
create new programs with FPC, and near all contributors of the project are
of this kind.
You can't simply say that developers should work on maintaining Delphi
legacy compability because:
- Legacy and compability work is not popular with developers, people expect
to get paid for it.
- legacy crowds are not the most thankful crowds. Sure, it will attract a lot
of users, but not the kind that donates or improves something. They'll only
come when the compability is 100%, and do a single recompile, and be gone.
they earn from Delphi training, and then specially training in _new_
features.
If I see Borland's own changelist, and I see the avg delphi app, this is
nonsense. Oh, and btw, recompiled with Delphi.NET is IMHO fully managed
code.
same person made it, and used the same set of filosophies doesn't guarantee
any compability at all, spescially when the architectures are so far apart.
Sure, it might make it easier for people that want to create refactoring
tools, but it doesn't eliminate pointers, win32 behaviour, database drivers,
3rd party components, string<->pchar conversions etc etc.
It's like saying a spaceshuttle is a plane because they both have wings.
Delphi.NET is not evil, it might be a nice productive environment, and a
good entry into the .NET platform, if you need to. (I don't before 2006),
and you might be able to take reasonable portable code with you, if you have
it.
It might also be a vehicle to slowly migrate to .NET, by not directly go
full .NET but slowly replacing unmanaged code by managed code. (I don't
know how well this works)
But a compatible platform like the series D2->D7? Not even close.
internal priority list or so.
But developers
tend to make ports to archs they own, and they are more likely to own
popular archs.
If somebody submits a nonstandard port, wants to maintain it, and it is
suitable for inclusion, it would be included I think.
 

loops in a user application eating up 100 % CPU time. Of course you can
do "nice" calls, but this will slow down the application (not usable for
embedded stuff).
but you can wait for the next message to arrive in the main thread. If
all messages are served by the appropriate events you can _wait_ (by a
system call) until the next message does arrive. No CPU time is wasted.
of the "event driven" way of programming, Delphi imposes on the
programmer in the main thread, would neither waist CPU time by speedy
polling for "outside" events which "fire" Delphi callback "events", nor
slow down the application by not being able to react at once on an
outside event that occurs. In Windows this seems to be easy using the
message interface of the OS. I have no idea, how GUI "events" (e.g.
mouse click) can be handled in that way in Linux, but events that are to
be "fired" because a worker thread wants to notify the main thread, can
be done e.g. using Linux messages. If the GUI events (and Timers) can
only be handled by polling, maybe it might be a good idea to do this
(relatively slowly) in a worker thread and notify the main thread by
some kind of "message". A message mechanism could use Linux messages or
do this simply by using a single semaphore, the main thread waits for if
it has done all (event) work and which is released by any worker thread
that wrote a message in some kind of FIFO (e.g. a TThreadlist).
nothing is to do, and restart _at_once_ if something is to be done.
messages.) ?
message with some API call and thus does not waste CPU time and can
react instantly on an Windows "event" occurring (e.g. Mouse click,
timer event or message from a worker thread.)
-Michael
 

Michael Schnell < XXXX@XXXXX.COM >wrote in
interface units, and LCL messages. It's been a while since I looked at
them or worked on them myself, so the underlying structure may have changed
some, but I doubt it has changed more than this brief overview...
Windows "events" (mouse click etc.) are signaled by a message with a
certain WM_* message type and optionally some data in wparam and lparam.
You set up a message loop that registers which messages you are interested
in based on window handles, and call ReadMessage, which blocks until there
is an actual message. Thus you don't eat CPU time polling. The message
loop is the single "callback" for the windows system.
GTK "events" don't work that way. For them, each "event" is a callback.
Instead of setting the callback to the message handler, you set the
callback directly to the "event" handler. So to make this compatible to
the way Windows works, and thus Delphi, a method had to be found to emulate
the Windows message loop.
(Here's where my memory gets fuzzy, so check the source). What was done
was to define LM_* message constants to emulate the windows WM_* constants.
The message loop, to register messages based on LM_* constants, called
helper routines that in turn registered a GTK helper callback. Enough info
was stored so that the helper GTK callback could determine the source
component, thus the the "window handler loop", and then call back the
"window handler", which then calls the component's event handler (such as
OnClick). The important thing to note is that the GTK "window handler"
isn't a loop like in Windows. It is a callback to the callback to the GTK
object. Therefore it too does not eat CPU cycles. When you add an event,
the "handler" is called long enough to set up the callback sequence, and
when a GTK event occurs, the callback sequence generates the correct LM_*
message to the top callback "handler" that dispatches it to the component.
Mapping GTK events to Windows events, and thus to what Delphi programmers
expect and what component code expects, is hideously complicated. So these
intermediate callbacks are doing a lot of work. Even things like the
window bounds are different, as one includes borders and title bars and the
other doesn't. A whole lot of work has gone into making the GTK calls look
similar to Windows calls so that Windows components can be ported easily.
Jeff.
P.S. This is at least two years ago that I last got into the code, likely a
lot has changed, maybe even the fundamentals, so I suggest you download the
code and check it out.
 

Jeff,
Thanks a lot for all your comments !
I think this is encouraging enough to plan to d/l the Lazarus stuff.
If GTK just does callbacks, that means that such a callback can
"interrupt" an already running callback from some other event. That is
why a loop is necessary to serialize this.
Is it possible to include inter-thread communication in the "event loop"
scheme ? I suppose a worker thread could raise a signal to inform the
main thread about an event it wants to be handled and put additional
information in a TThreadlist or something like that. Is this already
implemented in FP/Lazarus ? Can this be implemented "on top" of the
normal version ? Could it be done (with reasonable effort) by modifying
the source code ?
What I'm interested in is a platform independent way of inter-thread
signaling. Some kind of "Messages" (a TMessage object or such) seems
like a good candidate. IMHO the "best" (most
Delphi-language-appropriate) solution would be a "remote event"
implementation (meaning that in any thread you can define an event that
is to be run as part of another thread, but this would imply that _each_
thread has an "event scheduler" to serialize these beasts, which is not
implemented in Delphi and maybe would need to be a language extension).
By that event driven programming would be enabled for worker threads,
too.
Thanks - Michael
 

Michael Schnell < XXXX@XXXXX.COM >wrote in
that portion of it. Plus, from what I've seen on the mailing lists, the
whole threading units in FPC have been majorly overhauled, so some of that
may have carried into the Lazarus implementation.
Jeff.
 

On 2003-12-02, Jeffrey A. Wormsley < XXXX@XXXXX.COM >wrote:
1.0.x and 1.9.x branch (the one that used to be 1.1.x before it went into
beta), and still works with 1.0.x
 

On Tue, 02 Dec 2003 10:35:08 +0100, Michael Schnell wrote:
somewhere. Unfortunately gtk doesn't give you an fd to select() on,
because then I could also use an fd() to do Synchronize signalisation and
thus select() on both at the same time.
So a thread would:
instead of
while not Terminated do begin ... end
do
while not Terminated do begin CheckEvents; ... end
and call CheckEvents appropriately at other points too
instead of doing Sleep(xyz) it would need some sleep that would select()
on the event fd (lets take a fd for given), and then do those events. But
then the timing becomes inaccurate, so maybe not what you want either.
The application main loop would have to do this as well, again with the
limitation that it needs to be polling two event sources somehow, because
gtk doesn't give you something to select() on. Maybe it does internally, I
don't know. If it does, it may be possible to wait for gui events and
internal events at the same time.
Basically, I think what you want can be implemented without any special
support from the language.
johannes
 

I can describe a very simple example:
A GUI program has a text field on a form.
A worker thread is spawned that waits for some hardware event (e.g. a
character from a serial device in a blocking read operation).
If a character comes in, the main thread should display it (at once) in
the
text field.
In Windows/Delphi I would use a message object in the main thread and
send a
message from the worker thread to the main thread when a character comes
in.
(The character can be a parameter of the message.)
The message fires a Delphi event (callback) in the main thread, when no
more
previous messages are in the queue to be serviced.
How would I do this in FP (Windows and Linux) ?
Thanks for caring.
-Michael
 

day and try out what it can get me.
-Michael