HI fpc team,

for doing an extension to the Lazarus LCL, I need the "TThread extensions" such as
- CurrentThread,
- Queue, and
- GetTickCount64

It already works fine with the svn version of fpc.

I installed the "official" X86-64 fpc release (Debian Package, provided by the Debian store). This is version 2.6.0-9 and it does not have the TThread extensions.

So my questions are:
- what is the current official version ?
- does it have the TThread extensions ?
- is there a Debian Package with this version (X86-32, X86-64, and ARM (BeagleBone) ), and where to find it ?

Thanks,
-Michael

"Michael Schnell" wrote

- what is the current official version ?

2.6.4

- does it have the TThread extensions ?

No

- is there a Debian Package with this version (X86-32, X86-64, and ARM

(BeagleBone) ), and where to find it ?
We had some problems with building Deb packages when we released, I don't know whether they were resolved in the meantime...

Regards,
Sven

So I supposedly need to hold off this projects :-( .

-Michael

What kind of argument is that ?

Trunk is quite stable, the functionality you need is present since ages.

You can perfectly just develop with trunk and be ready to release when the trunk version is released as a stable version. If you want to wait for trunk to be released to start your project, you're needlessly restricting yourself.

Michael.

Michael Van Canneyt wrote

Trunk is quite stable, the functionality you need is present since ages.

Did I commit inappropriate phrasing ?

I meant, I need to hold off the enhancement I have in mind until an rtl version that provides TThread.Queue is officially released, as this project is simply not doable without TThread.Queue.

More explicit;
I need an Event queue, and IMHO for this project it is not appropriate at all to implement a second Event queue, while the rtl with TThread.Queue provides a perfectly usable one. As I do not practically need any working program (and in fact can create one using the svn fpc version, if I should need one) I can happily wait. But for implementing something in a once-to-be-released Lazarus LCL, it can't rely on a not released fpc version.

Am I wrong ?
-Michael

P.S.: perhaps the project is not even doable (in a perfectly compatible way) with the (Delphi compatible) implementation of TThread.Queue. (I just would need to be able to feed an Event in the Queue, but those means are "private" in TThread.) So maybe the holdoff will be forever.

You clearly didn't understand my remark. Please re-read it.

Michael.

1. The nogui LCL functions can be implemented without this.
2. If you insist using the new RTL features, then add the LCL features using $IFs.

Am I wrong ?

Were you ever?

Mattias

Michael Van Canneyt wrote

You clearly didn't understand my remark. Please re-read it.

OK.

So your point is that I can do the development and hold-off just the release.

If so:

- The development of the functionality (using the svn release of fpc) id done and seems to work just fine
- For "release" I would need to work with the Lazarus team. Here the discussion is whether or not this makes sense if it will not compile with the (currently) released fpc rtl.

Finally: maybe for perfect compatibility with existing Lazarus WidgetTypes maybe even the current svn version (TThread.Queue implementation) might be not usable (as it is said to do a direct call instead of a schedule when called from the Main thread <for Delphi compatibility>). Here I maybe would need yet another (non TThread-private) function to push an Event in the Queue (say class procedure TThread.QueueDirect). I'll take a look at this ASAP.

-Michael

Mattias Gaertner wrote

2. If you insist using the new RTL features, then add the LCL features using $IFs.

I do not _need_ anything. I just want to enhance the functionality in the best possible way, if I can.

With the ActiveNoGUI Application there is no sensible way to implement Application.QueuAsyncCall without using TThread.Queue (or similar). I will not implement a second Event Queue.

Using $IFs I already did a working implementation that with the released fpc RTL does provide TTimers (but not in a really decent way) but not Application.QueuAsyncCall. I am not up to "release" this.

-Michael

You can do it like the nogui widgetset. Application.QueuAsyncCall works there.

Using $IFs I already did a working implementation that with the released fpc RTL does provide TTimers (but not in a really decent way) but not Application.QueuAsyncCall. I am not up to "release" this.

Why not?

Mattias

Give the man a cigar and a drink ;)

The lazarus team makes pretty sure that Lazarus compiles with released and trunk versions.

Really, I think you are looking for problems where there are none.

Michael.

Michael Van Canneyt wrote

The lazarus team makes pretty sure that Lazarus compiles with released and trunk versions.

Yep. Exactly this is why my would-be LCL enhancement needs to wait until the next fpc release.

Really, I think you are looking for problems where there are none.

You need to see that I do not want to do an application (that already works just fine), but an enhancement to the LCL.

-Michael

Mattias Gaertner wrote

You can do it like the nogui widgetset. Application.QueuAsyncCall works there.

You already stated that it only works if the user calls Application.ProcessMessages. This is not what I am up to.

(I'll take a look at the NoGUI implementation, anyway..)

-Michael

Strange. I came to exactly the opposite conclusion.

Michael.

Michael Van Canneyt wrote

Strange. I came to exactly the opposite conclusion.

Sorry. I am not able to understand your argument :-( .

-Michael

Why can't you use trunk and $IFs like everyone else?

Mattias

Mattias Gaertner wrote

Why can't you use trunk and $IFs like everyone else?

I do _need_ TThread.Queue (and I do _need_ TThread.GetTickCount64 (or another decent timing source).

The released rtl version does not have TThread.Queue and for timing only fpgettimeofday() is provided, which is not a "permanent ticker"-source but jumps back and foreword when the UTC system time is updated.

Hence I of course can use $ifs to make it compilable with the released rtl version but it will have no

Mattias

Mattias Gaertner wrote

In other words: Nothing stops you, except yourself.

Yep.
(see the discussion in lazarus-devel.)

-Michael

Michael Schnell wrote

The released rtl version does not have TThread.Queue and for timing only fpgettimeofday() is provided, which is not a "permanent ticker"-source but jumps back and foreword when the UTC system time is updated.

The latest release (2.6.4) has clock_gettime() in unit linux.

Henry

I checked the code of TThread.Queue and in fact it does not queue the call if TThread.Queue is executed from the main thread, but performs the call right away.

This supposedly is not compatible with how Application.QueueAsyncCall works in other WidgetTypes.

Unfortunately the svn-version of the rtl does not provide a means to prevent this (queer, Delphi compatible) behavior.

So for full compatibility we would need an enhancement in the fpc-rtl.

-Michael

Henry Vermaak wrote

The latest release (2.6.4) has clock_gettime() in unit linux.

On Debian I seemingly only have 2.6.0-9 :-(

-Michael

Michael Van Canneyt wrote

You can perfectly just develop with trunk and be ready to release when the trunk version is released as a stable version.

I finally was able to try to implement a version of my "interface" unit that is supposed to work with the trunk version i.e. without using TThread.Queue.

While it is possible to use TThread's "waking" mechanism by means of GetThreadManager() --> RTLEventResetEvent, pushing events in TThread's queue is not possible because ThreadQueueLock and ThreadQueueTail are private in TThread and hence can't be accessed by my code.

-Michael

Michael Schnell wrote

RTLEventResetEven

RTLEventSetEvent (sorry for sloppy cut and Paste)

-Michael

Michael Schnell wrote

with the trunk version without using TThread.Queue.

The purpose being to make it run with the _released_ version (that does not feature TThread.Queue), while I of course do my tests using the svn trunk version.

-Michael