Re: [fpc-devel] Feature announcement: Type helpers
On Wed, 6 Feb 2013, Sven Barth wrote: Hello Free Pascal community! I'm pleased to announce the addition of type helpers which extend the existing helper concept with the ability to extend primitive types. Haha, finally after 7 years of waiting we catch up with Morfik... Thank you very much Sven, excellent work ! :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
In our previous episode, Michael Van Canneyt said: With helpers you can do i.ctrl-space and get a list of methods, for example ToString; Which, for newbies, is easier than guessing IntToStr() We'll have to make some units with 'standard' helpers. Well, newbies are not to strong in knowing what is which unit either :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On Wed, 6 Feb 2013, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: With helpers you can do i.ctrl-space and get a list of methods, for example ToString; Which, for newbies, is easier than guessing IntToStr() We'll have to make some units with 'standard' helpers. Well, newbies are not to strong in knowing what is which unit either :-) If we're talking newbies and IDE: They don't need to, if the IDE puts the unit in the uses clause to start with... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
In our previous episode, Michael Van Canneyt said: Well, newbies are not to strong in knowing what is which unit either :-) If we're talking newbies and IDE: They don't need to, if the IDE puts the unit in the uses clause to start with... That's completely new functionality. Afaik most unit adding of IDEs is hardcoded?. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On Wed, 6 Feb 2013, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Well, newbies are not to strong in knowing what is which unit either :-) If we're talking newbies and IDE: They don't need to, if the IDE puts the unit in the uses clause to start with... That's completely new functionality. Afaik most unit adding of IDEs is hardcoded?. I know. The codetools need to recognize type helpers in the first place. Then we can start thinking about changing the default unit uses clause. For instance in the package lazarusforeducation or so. Anyway, I just wanted to point out which advantages I see (or do not see) in type helpers. By themselves, I think they are worthless. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Marco van de Voort mar...@stack.nl hat am 6. Februar 2013 um 11:41 geschrieben: In our previous episode, Michael Van Canneyt said: Well, newbies are not to strong in knowing what is which unit either :-) If we're talking newbies and IDE: They don't need to, if the IDE puts the unit in the uses clause to start with... That's completely new functionality. Afaik most unit adding of IDEs is hardcoded?. No. Code completion and identifier completion add the units it finds. Maybe you mean the hard coded uses sections when creating a new project/unit? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Michael Van Canneyt mich...@freepascal.org hat am 6. Februar 2013 um 11:38 geschrieben: On Wed, 6 Feb 2013, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: With helpers you can do i.ctrl-space and get a list of methods, for example ToString; Which, for newbies, is easier than guessing IntToStr() We'll have to make some units with 'standard' helpers. Well, newbies are not to strong in knowing what is which unit either :-) If we're talking newbies and IDE: They don't need to, if the IDE puts the unit in the uses clause to start with... i.ctrl-space will only show identifiers in scope, that excludes units not in the uses section. Cody's identifier dictionary can add identifiers and units, that are not in scope. But it currently only supports top level identifiers. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testsuite database
Hi Pierre, Sorry for late reply, my main computer (with mail) was temporarily out of order. I'm happy to confirm that the problem no longer exists. I do not get any error messages anymore. Also, it looks like query results are produced much faster now. Good work! Actually, I reported the issue not because I suffered much from it right now but more because I thought it was a dangerous sympthom. Anyway, its good that the problem has been solved. Thanks. Nikolai 02.02.2013 21:00, Pierre Free Pascal: Thanks to your email, Yuri Sidorov (member of the core team) took the time to look at the problems of the testsuite.cgi program and fixed several issues he found. Please test and report if you still find problems... Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On Wed, Feb 06, 2013 at 11:52:27AM +0100, Michael Van Canneyt wrote:
On Wed, 6 Feb 2013, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Well, newbies are not to strong in knowing what is which unit either :-)
If we're talking newbies and IDE:
They don't need to, if the IDE puts the unit in the uses clause to start
with...
That's completely new functionality. Afaik most unit adding of IDEs is
hardcoded?.
I know. The codetools need to recognize type helpers in the first
place.
Then we can start thinking about changing the default unit uses clause.
For instance in the package lazarusforeducation or so.
Anyway, I just wanted to point out which advantages I see (or do not see) in
type helpers.
Thanks for pointing out the advantages. I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
What I'm trying to say with this (admittedly contrived) example is that
when you are forced to read the docs to find out which functions you can
use for converting numbers to strings, you'll probably discover
functions like Format. At least in my case, the most useful tricks I
learn come from reading the documentation for something, then exploring
a bit.
I apologise if I come across as overly cynical and I do appreciate
Sven's work in the compiler!
Henry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
2013/2/6 Michael Van Canneyt mich...@freepascal.org On Wed, 6 Feb 2013, Marco van de Voort wrote: Anyway, I just wanted to point out which advantages I see (or do not see) in type helpers. By themselves, I think they are worthless. If used appropriately, they can improve the readability. R# Michael. __**_ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-develhttp://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On 02/06/2013 12:13 PM, Henry Vermaak wrote:
I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
In fact to me the first expression does look really nice (even though I
am 60 Years old and do Pascal since the Turbo days and C since ages,
ad strongly dislike weakly typed languages).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On Wed, 6 Feb 2013, Henry Vermaak wrote:
On Wed, Feb 06, 2013 at 11:52:27AM +0100, Michael Van Canneyt wrote:
On Wed, 6 Feb 2013, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Well, newbies are not to strong in knowing what is which unit either :-)
If we're talking newbies and IDE:
They don't need to, if the IDE puts the unit in the uses clause to start with...
That's completely new functionality. Afaik most unit adding of IDEs is
hardcoded?.
I know. The codetools need to recognize type helpers in the first
place.
Then we can start thinking about changing the default unit uses clause.
For instance in the package lazarusforeducation or so.
Anyway, I just wanted to point out which advantages I see (or do not see) in
type helpers.
Thanks for pointing out the advantages. I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
What I'm trying to say with this (admittedly contrived) example is that
when you are forced to read the docs to find out which functions you can
use for converting numbers to strings, you'll probably discover
functions like Format. At least in my case, the most useful tricks I
learn come from reading the documentation for something, then exploring
a bit.
True. It gets worse:
One can wonder whether
s:='(%d, %d)'.format([x, y]);
is more or less clear than
s := Format('(%d, %d)', [x, y]);
:-)
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On 02/06/2013 12:29 PM, Michael Schnell wrote: point.x := x; point.y := y; s := point.ToString; or s := (x,y).ToString; Has there not recently been a discussion on Tupels ?!?!?! :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
06.02.13, 19:29, Michael Schnell пишет: but I feel point.x := x; point.y := y; s := point.ToString; is most clear. This is what you can already do in FPC 2.6.0 with advanced records feature active. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Am 06.02.2013 10:58, schrieb Mattias Gaertner: On Wed, 06 Feb 2013 10:49:36 +0100 Sven Barth pascaldra...@googlemail.com wrote: [...] Hello Free Pascal community! === example begin === var i: LongInt; begin Writeln(i.ToString); end. And how is toString declared? I've mentioned it directly above the example in the prosa text. I thought this was clear enough; seems that I was wrong... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extract the color data and alpha from a PNG image
silvioprog silviop...@gmail.com hat am 5. Februar 2013 um 16:08 geschrieben: 2013/2/5 Mattias Gaertner nc-gaert...@netcologne.de mailto:nc-gaert...@netcologne.de On Tue, 5 Feb 2013 12:37:24 -0200 silvioprog silviop...@gmail.com mailto:silviop...@gmail.com wrote: Hello friends, I'm trying to extract the color data and alpha from a PNG image. In PHP it is very easy to implement, but in FPC I don't know how to do it. I tried to do it via chunk.data, ZData etc., but, without success. Attached two files to test it. To test the PHP code run this command in your terminal: php -f fpdf.php The in FPC code is partially complete. Have you tried fpimage? uses fpreadpng, fpimage; var image: TFPCustomImage; reader: TFPCustomImageReader; x,y: integer; c: TFPColor; begin Image := TFPMemoryImage.Create(0, 0); Reader := TFPReaderPNG.Create; Image.LoadFromFile(AFileName, Reader); for y:=0 to Image.Height-1 do for x:=0 to Image.Width-1 do begin c:=Image.Colors[x,y]; writeln(c.Alpha,' ',c.Blue); end; //... Mattias Yes, I tried it too, but, without success. :( See my new code in attached. It generates the data, but with wrong content. c.Alpha, c.Blue are word, not byte. BTW, reading and writing to/from Filestream should be done in chunks, not in bytes. That's dog slow. Use a TMemoryStream as cache. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On Wed, Feb 06, 2013 at 01:12:59PM +0100, Sven Barth wrote:
Am 06.02.2013 12:13, schrieb Henry Vermaak:
Thanks for pointing out the advantages. I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
I suppose there are quite some people (especially newbies ^^) who
write it like this:
s := '(' + IntToStr(x) + ', ' + IntToStr(y) + ')';
And here I would prefer the ToString variant (but my personal
favorit is the Format one :) )
No, you miss my point. Let me put it this way: You're trading one type
of discoverability for another.
With type helpers, it becomes easy to discover that I can type
x.Ctrl-Space and immediately see ToString. But I'll never learn of
Format(), Trim(), etc. this way.
With IntToStr, the initial discoverability is hard, since I need to know
about IntToStr in the first place. But when I Ctrl-Click on IntToStr,
I immediately see Format(), Trim(), AdjustLineBreaks(), etc.
Henry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On 02/06/2013 01:12 PM, Sven Barth wrote:
Am 06.02.2013 12:13, schrieb Henry Vermaak:
Thanks for pointing out the advantages. I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
I suppose there are quite some people (especially newbies ^^) who write
it like this:
s := '(' + IntToStr(x) + ', ' + IntToStr(y) + ')';
And here I would prefer the ToString variant (but my personal favorit
is the Format one :) )
Funny to see that all these fans of a strongly typed pascal prefer
Format() that is using variants, has an undetermined number of
parameters, doesn't give the compiler any opportunity to check the types
used and causes runtime errors when a wrong type or a wrong number of
parameters is passed ;)
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Am 06.02.2013 14:26, schrieb Ludo Brands:
On 02/06/2013 01:12 PM, Sven Barth wrote:
Am 06.02.2013 12:13, schrieb Henry Vermaak:
Thanks for pointing out the advantages. I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
I suppose there are quite some people (especially newbies ^^) who write
it like this:
s := '(' + IntToStr(x) + ', ' + IntToStr(y) + ')';
And here I would prefer the ToString variant (but my personal favorit
is the Format one :) )
Funny to see that all these fans of a strongly typed pascal prefer
Format() that is using variants, has an undetermined number of
parameters, doesn't give the compiler any opportunity to check the types
used and causes runtime errors when a wrong type or a wrong number of
parameters is passed ;)
But you seperate the view (the format string) from the model (the data
which is passed in), which is good :)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Am 06.02.2013 14:03, schrieb Henry Vermaak:
On Wed, Feb 06, 2013 at 01:12:59PM +0100, Sven Barth wrote:
Am 06.02.2013 12:13, schrieb Henry Vermaak:
Thanks for pointing out the advantages. I can see the point, but can't
help to think that I'll be reading code like this soon:
s := '(' + x.ToString + ', ' + y.ToString + ')';
Instead of
s := Format('(%d, %d)', [x, y]);
I suppose there are quite some people (especially newbies ^^) who
write it like this:
s := '(' + IntToStr(x) + ', ' + IntToStr(y) + ')';
And here I would prefer the ToString variant (but my personal
favorit is the Format one :) )
No, you miss my point. Let me put it this way: You're trading one type
of discoverability for another.
With type helpers, it becomes easy to discover that I can type
x.Ctrl-Space and immediately see ToString. But I'll never learn of
Format(), Trim(), etc. this way.
With IntToStr, the initial discoverability is hard, since I need to know
about IntToStr in the first place. But when I Ctrl-Click on IntToStr,
I immediately see Format(), Trim(), AdjustLineBreaks(), etc.
But he might or might not scroll far enough to see these methods... and
even then it is not known whether he'll immediately relate Format to
I can get a string from e.g. Integers.
Note: As I've wrote, I personally prefer Format, so I'm not necesserily
defending the use of type helpers...
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Am 06.02.2013 12:54, schrieb Paul Ishenin: 06.02.13, 19:29, Michael Schnell пишет: but I feel point.x := x; point.y := y; s := point.ToString; is most clear. This is what you can already do in FPC 2.6.0 with advanced records feature active. Or by using record helpers if one can not modify the used record type (e.g. because it's part of the RTL or FCL). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
Ludo Brands wrote: Funny to see that all these fans of a strongly typed pascal prefer Format() that is using variants, has an undetermined number of parameters, doesn't give the compiler any opportunity to check the types used and causes runtime errors when a wrong type or a wrong number of parameters is passed ;) Format has two parameters. OK, so the second one is a bit weird... :-) Perhaps somebody would like to correct me, but I think that in the case of output messages Format() has the big advantage that the order of the placeholders in the string can be changed easily when messages are translated from one language to another. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On Wed, Feb 6, 2013 at 10:31 PM, Michael Schnell mschn...@lumino.de wrote: point.x := x; point.y := y; s := point.ToString; or s := (x,y).ToString; Has there not recently been a discussion on Tupels ?!?!?! :-) At least according to my proposal, tuples will not be a type, so you'll have to force a type by constructor: s := TPoint(x,y).ToString; or, as it is currently, by a special function: s := Point(x,y).ToString; -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
06.02.13, 21:51, Alexander Klenin пишет: On Wed, Feb 6, 2013 at 10:31 PM, Michael Schnell mschn...@lumino.de wrote: point.x := x; point.y := y; s := point.ToString; or s := (x,y).ToString; Has there not recently been a discussion on Tupels ?!?!?! :-) At least according to my proposal, tuples will not be a type, so you'll have to force a type by constructor: s := TPoint(x,y).ToString; or, as it is currently, by a special function: s := Point(x,y).ToString; or with a record constructor: TPoint.Create(X, Y).ToString; Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Hi, OK, now that we established that semaphores are broken in FreeBSD using FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative. An alternative for two reasons. - I hate IFDEF code, and the semaphore code between Linux, FreeBSD and Windows are different. - Semaphore sem_t structure is incorrectly defined for FreeBSD, so I'll have to implement a special case for that platform. Semaphore functionality seems pretty simple though, so I am thinking of creating my own Object Pascal based cross-platform semaphore - no low level code or OS specific library API's. It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
In our previous episode, Graeme Geldenhuys said: OK, now that we established that semaphores are broken in FreeBSD using FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative. An alternative for two reasons. - I hate IFDEF code, and the semaphore code between Linux, FreeBSD and Windows are different. - Semaphore sem_t structure is incorrectly defined for FreeBSD, so I'll have to implement a special case for that platform. Why do you not use the standard syncobjs implementations? In 2.6.2 they should be ok. (only the types exported by unixtype/unix/baseunix are wrong) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Am 06.02.2013 20:43 schrieb Marco van de Voort mar...@stack.nl: In our previous episode, Graeme Geldenhuys said: OK, now that we established that semaphores are broken in FreeBSD using FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative. An alternative for two reasons. - I hate IFDEF code, and the semaphore code between Linux, FreeBSD and Windows are different. - Semaphore sem_t structure is incorrectly defined for FreeBSD, so I'll have to implement a special case for that platform. Why do you not use the standard syncobjs implementations? In 2.6.2 they should be ok. (only the types exported by unixtype/unix/baseunix are wrong) We don't have semaphores yet in SyncObjs. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Am 06.02.2013 20:24 schrieb Graeme Geldenhuys gra...@geldenhuys.co.uk: Hi, OK, now that we established that semaphores are broken in FreeBSD using FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative. An alternative for two reasons. - I hate IFDEF code, and the semaphore code between Linux, FreeBSD and Windows are different. - Semaphore sem_t structure is incorrectly defined for FreeBSD, so I'll have to implement a special case for that platform. If you just define your own semaphore class that contains the platform specific types and lock and unlock methods then you only need to add an additional array[0..4] of Longint after the sem_t field for FreeBSD. Then you should be okay. Semaphore functionality seems pretty simple though, so I am thinking of creating my own Object Pascal based cross-platform semaphore - no low level code or OS specific library API's. You need to use at least synchronisation primitives like mutexes otherwise it won't be threadsafe. It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. If you really want to do this the hard way you should read corresponding articles. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Hello, You can use some structure to lock an integer. `Some structure` can for example be a mutex, a critical section, some busy waiting loop based on CMPXCH, etc... Say that you lock the integer by calling `Lock;` and you unlock it by calling `UnLock;`. Then you can define a class TSemaphore like this: === Code Begin === Type TSemaphore = Class Private DaValue: Integer; Lock: TLockType; Public Constructor Create;// sem_init Function GetValue: Integer;// sem_getvalue Procedure Post; // sem_post Function TryWait: Boolean; //sem_trywait End; Constructor TSemaphore.Create; Begin inherited Create; DaValue:= 0; //Initialize lock here to unlocked state. End; Function TSemaphore.GetValue; Begin Lock; Result:= DaValue; UnLock; End; Procedure TSemaphore.Post; Begin Lock; DaValue+= 1; UnLock; End; // True if the semaphore is hereby decremented; false otherwise Function TSemaphore.TryWait: Boolean; Begin Lock; If DaValue 0 Then Begin DaValue-= 1; Result:= True; End Else Result:= False; UnLock; End; //True if this function returned immediately, false otherwise. Function TSemaphore.Wait: Boolean; Begin Result:= True; While True Do Begin Lock; If DaValue 0 Then Begin DaValue-= 1; Break; End; Result:= False; UnLock; End; End; === Code End === The only function missing is sem_timedwait, but this could easily be implemented by combining `nanosleep`, `trywait` and `timeofday`. NOTE: The above code is not tested, it more of a thing which I just wrote, so you will probably find some syntax errors and possible race conditions; altough I doubt the latter. Concerning the locking mechanism, you can uses mutex(en/es/ii) or you can do this by a busy waiting loop with an integer (of course there are other possibilities). To elaborate on the latter a bit more: * TLockType = Integer; * Initialization: `Lock:= 0;` * Lock unlock: === Code Begin === Procedure WaitLockVar(var aLock: Integer); Begin Repeat Until InterLockedCompareExchange(aLock, 1, 0) = 0; End; Procedure UnlockVar(var aLock: Integer); Begin InterlockedExchange(aLock, 0); End; === Code End === This last code is tested and works. Hope it is of any use. Once upon a time, on 02/06/2013 08:24 PM to be precise, Graeme Geldenhuys said: It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On Wednesday 06 February 2013 20:24:34 Graeme Geldenhuys wrote: It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. MSEgui has a semaphore implementation. On Linux it uses the libc interface, on Windows an own implementation with a windows event object, lib/kernel/windows/msesysintf1.pas. Works so far, but with sync mechanics one never knows... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
Hi Martin, Thank you for your detailed answers and for pointing me to the testcases. I am having a look at the breakpoint code and will see what I can do so that debugging works with only a limited number of available breakpoints. One more thing, do you know why ExecuteCommand is defined as protected and not public in GDBMIDebugger? I need to send some extra commands to GDB to make the remote connection, using ExecuteCommand is an elegant way to do this. But the method is invisible in my class because it is protected. Can the ExecuteCommand methods be made public or is this a no-go? Which GDB version is your prefered version for debugging FreePascal? Thank you again, Michael On 05/02/2013 22:14, Michael Ring wrote: I have integrated openocd debugger class as a child of the gdbmi debugger classes, basic code upload debugging now works for me in lazarus, still has some rough edges, this is why I am seeking for support by the arm-embedded hackers here in fpc-devel. ... single stepping works, I seem to have trouble with creating breakpoints, I run out of them very fast, for example lazarus shows me 3 breakpoints, openocd complains that it is already at breakpoint #11, is this a well known problem or do I need to investigate deeper into this? Hi. I don't know much about openocd. But I do know the debugger stuff in Lazarus. Since you say it is based on the gdbmi classes: There are a number of breakpoints inserted by GDBMI at startup. First GDBMI runs the exe to the main-entry-point. It does that in order to then set other breakpoints and do other initialization (which on some platform depending on gdb and god knows what, can only succeed *after* the initial run). a) up to 4 breakpoints (each by name AND address) to stop at main entry point. find function: function RunToMain(EntryPoint: String): integer; b) 3 breakpoints in fpc, to catch exception, run-error and some other c) run the program. So that gives the breakpoints you see. This can be moved to a virtual method, if a suitable patch is supplied. Also, visibility of variables is not that good, I can see simple variables in my procedures but more complex variables are usually invisible. Is this a known problem or is there just some magic I need to apply in the startup of gdb? Complex variables are read via a great many conditions. Each GDB reports slightly different, and needs slightly different corrections e.g a class may have to be deferred (Foo^.FField), or even first typecasted (to the type already detected by GDB via ptype). That is mostly done in GDBTypeInfo I have run various commands, for various datatypes against a dozen different GDB (and I keep doing for new releases). Some examples are in debugger\test\gdb responses\ For in IDE testing define (be warned, you can screw the debug session. Do NOT run or step). DBG_WITH_DEBUGGER_DEBUG // adds commandline to debug output window DBG_WITH_GDB_WATCHES // Allows watches or eval-window gdb_command Another issue is that I cannot do the loading of my binary from within gdb, at the moment I still need to do direct telnet communication with openocd. Not sure if it helps, there also is a class that started work on gdbserver / it is in SVN Which library should I use for doing the telnet session? I read on the freepascal wiki that fcl-net is a little outdated, so which library should I use, I do not want to introduce additional dependencies to the lazarus build by including synapse or indy. If your exe is remote, you need to disable the pause functionality (which is also called if you change breakpoints while running (not paused). Because it sends a signal to a local process ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
