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
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 that will
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
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
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.
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
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
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=9t=6664start=15
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
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
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
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 elaborate on
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
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
since this
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
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
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 access
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
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. The
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,
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
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.
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
08.02.2013 7:30, Gerhard Scholz пишет:
0:25:46,51 G:\ob\syncdirsppc386 -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 g...@g--s.de:
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
08.02.2013 14:03, Sven Barth пишет:
0:25:46,51 G:\ob\syncdirsppc386 -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 i...@kmiac.ru:
08.02.2013 14:03, Sven Barth пишет:
0:25:46,51 G:\ob\syncdirsppc386 -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
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
29 matches
Mail list logo
