On 2013-02-06 20:10, Sven Barth wrote:
>
> We don't have semaphores yet in SyncObjs.
Correct. FPC's SyncObjs unit has quite a few missing features compared
to Delphi.
http://docwiki.embarcadero.com/Libraries/XE2/en/System.SyncObjs
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform G
On 2013-02-06 20:17, Sven Barth wrote:
>
> 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.
Yes tha
Thanks Ewald. What you described is exactly what I started, and had in
mind. Thanks for your feedback.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist - fp
As we now are in a dedicated thread:
- I suppose this should be discussed in the Lazarus mailing List.
- Does openocd not use gdb ?
. - If yes, support maybe should be provided by the
GDBMIServerDebugger unit (or similar). We are discussing a similar issue
in the German Lazarus Forum right
Am 07.02.2013 09:41, schrieb Graeme Geldenhuys:
On 2013-02-06 20:10, Sven Barth wrote:
We don't have semaphores yet in SyncObjs.
Correct. FPC's SyncObjs unit has quite a few missing features compared
to Delphi.
http://docwiki.embarcadero.com/Libraries/XE2/en/System.SyncObjs
Yes, I noticed t
Am 07.02.2013 09:46, schrieb Graeme Geldenhuys:
On 2013-02-06 20:17, Sven Barth wrote:
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 Fr
On 2013-02-07 09:13, Sven Barth wrote:
> But the ifdefs will only be in one location.
I understand that, but there will be IFDEF's none the less. As I said, I
hate IFDEF's in application/library code. They have their place in FPC
source code, but I don't like them anywhere else. That's just me.
Am 07.02.2013 10:37, schrieb Graeme Geldenhuys:
This way you'd reduce that to one and rely on OS functionality
nevertheless (which is known to work - if used correctly :P ).
Having a clean Object Pascal based Semaphore implementation will be
useful, and clean code. My unit testing and usage of
On 06 Feb 2013, at 23:16, Ewald wrote:
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:
Yes, OpenOCD implements a gdbserver so debugging is done via gdb.
I did not want to break existing code so I created a new class based on
TGDBMIServerDebugger, this has been done before for the ssh based
debugging so I followed this road.
I will join the german lazarus forum, see you there...
On 02/07/2013 12:11 PM, Michael Ring wrote:
I did not want to break existing code so I created a new class based
on TGDBMIServerDebugger, this has been done before for the ssh based
debugging so I followed this road.
I just checked how this works:
The nioce Lazarus team implemented the Int
Hi Jonas,
Interesting, there is no mention of those limitations in the FPC 2.6.0
documentation. I looked in the RTL docs. It this is a concern, it is
something that should be mentioned in the docs.
Do you know more specifically what platforms or CPU's are affected, so
Michael could update the doc
On 02/07/2013 12:11 PM, Michael Ring wrote:
I will join the german lazarus forum, see you there.
http://www.lazarusforum.de/viewtopic.php?f=9&t=6664&start=15
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasc
On 07 Feb 2013, at 12:27, Graeme Geldenhuys wrote:
Interesting, there is no mention of those limitations in the FPC 2.6.0
documentation. I looked in the RTL docs. It this is a concern, it is
something that should be mentioned in the docs.
That has nothing to do with the programming la
On 07 Feb 2013, at 12:52, Jonas Maebe wrote:
It doesn't belong in our manuals. Anyone who wants to manually
create low level thread synchronisation primitives will have to know
a lot more about cpu architecture and memory consistency models then
we could ever describe in our documentation.
Once upon a time, on 02/07/2013 11:57 AM to be precise, Jonas Maebe said:
>
> On 06 Feb 2013, at 23:16, Ewald wrote:
>
>> 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 elab
On 07 Feb 2013, at 13:39, Ewald wrote:
Well, I always thought that the InterLoackedCompareExchange boiles
down
to [**]
.Lock CMPXCHG
Or something quite like that. The `.Lock` there is the important part
since this does insure a memory barier.
It's only a memory barrier if you don't use SSE
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe said:
>
> On 07 Feb 2013, at 13:39, Ewald wrote:
>
>> Well, I always thought that the InterLoackedCompareExchange boiles down
>> to [**]
>> .Lock CMPXCHG
>>
>> Or something quite like that. The `.Lock` there is the important part
>
On Thu, Feb 07, 2013 at 01:01:47PM +0100, Jonas Maebe wrote:
>
> On 07 Feb 2013, at 12:52, Jonas Maebe wrote:
>
> >It doesn't belong in our manuals. Anyone who wants to manually
> >create low level thread synchronisation primitives will have to
> >know a lot more about cpu architecture and memory
On 07 Feb 2013, at 14:29, Ewald wrote:
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe
said:
On 07 Feb 2013, at 13:39, Ewald wrote:
Well, I always thought that the InterLoackedCompareExchange boiles
down
to [**]
.Lock CMPXCHG
Or something quite like that. The `.Lock`
On Thu, Feb 07, 2013 at 03:11:00PM +0100, Jonas Maebe wrote:
> The interlocked* routines only guarantee that that particular value
> is updated in atomic way across multiple cores. It does not
> guarantee anything about memory access performed before or after
> that interlocked* call. The memory ba
On Thu, Feb 07, 2013 at 02:43:11PM +, Henry Vermaak wrote:
> On Thu, Feb 07, 2013 at 03:11:00PM +0100, Jonas Maebe wrote:
> > The interlocked* routines only guarantee that that particular value
> > is updated in atomic way across multiple cores. It does not
> > guarantee anything about memory a
On 07/02/2013 07:14, Michael Ring wrote:
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 invisi
Once upon a time, on 02/07/2013 03:11 PM to be precise, Jonas Maebe said:
> The interlocked* routines only guarantee that that particular value is
> updated in atomic way across multiple cores. It does not guarantee
> anything about memory access performed before or after that
> interlocked* call.
On 6-2-2013 12:13, Henry Vermaak wrote:
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, th
On 2013-02-06 19:24, Graeme Geldenhuys wrote:
> 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.
Progress... It was rather simple so far. I created a semaphore
On Thu, Feb 7, 2013 at 2:33 PM, Graeme Geldenhuys
wrote:
> On 2013-02-06 19:24, Graeme Geldenhuys wrote:
>> Semaphore functionality seems pretty simple though, (...)
Not if you want high performance and multi-processor support.
___
fpc-devel maillist -
Am 07.02.13 16:04, schrieb Martin:
On 07/02/2013 07:14, Michael Ring wrote:
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
On 07/02/2013 23:51, Michael Ring wrote:
Index: debugger/debugger.pp
===
--- debugger/debugger.pp(revision 40204)
+++ debugger/debugger.pp(working copy)
@@ -3304,6 +3304,7 @@
const
OLD_GDB_DBG_NAME = 'GNU debugge
On 2013-02-07 17:55, Flávio Etrusco wrote:
>
> Not if you want high performance and multi-processor support.
I'll prefer _working_ code to start. Currently semaphores are broken in
FPC+FreeBSD. My implementation at least works everywhere I have tested -
without hacks or jumping through loops.
R
Hello,
I tried to compile the example:
type
TLongIntHelper = type helper for LongInt
class procedure Test; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Test');
end;
var
i: LongInt;
begin
i.Test;
$12345678.Test;
LongInt.Test;
end.
Result:
0:25:46,51
G:\o
08.02.2013 7:30, Gerhard Scholz пишет:
0:25:46,51 G:\ob\syncdirs>ppc386 -vv -al -CioOrt -Cs600 -gclt
-Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u
-Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u
-FiP:\gs\tp55\includes -Fif:\-u -FE. thelper
thelper.pas(2,33)
Am 08.02.2013 02:03 schrieb "Gerhard Scholz" :
>
> Hello,
>
> I tried to compile the example:
>
>
> type
> TLongIntHelper = type helper for LongInt
> class procedure Test; static;
> end;
>
> class procedure TLongIntHelper.Test;
> begin
> Writeln('Test');
> end;
>
> var
> i: LongInt;
> b
08.02.2013 14:03, Sven Barth пишет:
> 0:25:46,51 G:\ob\syncdirs>ppc386 -vv -al -CioOrt -Cs600 -gclt
-Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u
-Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u
-FiP:\gs\tp55\includes -Fif:\-u -FE. thelper
> thelper.pas(2,33)
Am 08.02.2013 07:22 schrieb "Paul Ishenin" :
>
> 08.02.2013 14:03, Sven Barth пишет:
>
>> > 0:25:46,51 G:\ob\syncdirs>ppc386 -vv -al -CioOrt -Cs600 -gclt
>> -Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u
>> -Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u
>> -FiP
I have made some small modifications to the serial unit for Win32 created by
Luis R. Hilario.
It now, can be used in Delphi (5, 7), FPC for Win32 and FPC for WinCE.
I am using it with all compilers.
I think it could be useful for some people who are moving between Windows/WinCE
and
Linux.
It is
36 matches
Mail list logo
