On 20 May 2009, at 22:13, Micha Nelissen wrote:
Jonas Maebe wrote:
On 20 May 2009, at 22:01, Jonas Maebe wrote:
The problem you have right now is that the program and each of
your libraries each contain their own copy of the exception class,
and therefore do not recognise (Pascal) exceptio
In our previous episode, Micha Nelissen said:
> Jonas Maebe wrote:
> > On 20 May 2009, at 22:01, Jonas Maebe wrote:
> >> The problem you have right now is that the program and each of your
> >> libraries each contain their own copy of the exception class, and
> >> therefore do not recognise (Pasc
Jonas Maebe wrote:
On 20 May 2009, at 22:01, Jonas Maebe wrote:
The problem you have right now is that the program and each of your
libraries each contain their own copy of the exception class, and
therefore do not recognise (Pascal) exceptions raised by any of the
others.
Well, that and the
On 20 May 2009, at 22:01, Jonas Maebe wrote:
The problem you have right now is that the program and each of your
libraries each contain their own copy of the exception class, and
therefore do not recognise (Pascal) exceptions raised by any of the
others.
Well, that and the fact that more
Jonas,
Thank you very much for the explanation.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.free
On 20 May 2009, at 21:50, Seth Grover wrote:
Imagine this scenario. I have an FPC-compiled executable (fpcprog) and
two FPC-compiled shared object libraries (libfpc1.so and libfpc2.so).
Each of which installs its own set of signal handlers:
That's not possible. Per process, Unix only supports
Actually, looking closer at this fix (bug 12704, fixed in rev 13077),
it might not be exactly what I was expecting it to be. Maybe somebody
could clear up something I've been thinking about for a while now.
Imagine this scenario. I have an FPC-compiled executable (fpcprog) and
two FPC-compiled sha
A huge thanks to Jonas for fixing issue 12704. I'm going to grab a
copy of the trunk and compile it just so I can try this out. Thank you
so much!
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=13077
Is there any chance of this being merged into the 2.2.x fixes branch?
Or will thi
On 20 May 2009, at 16:15, Roland Turcan wrote:
I just didn't find relation of fpfsync function to mac os x
implementation.
rtl/unix/unxdeclh.inc:
Function fpfsync (fd : cint) : cint; cdecl; external clib name 'fsync';
JM> uses
JM>unix;
JM> ...
JM>fpfsync(handle).
I have the same a
<<< 20.5.2009 15:54 - Jonas Maebe "jonas.ma...@elis.ugent.be" >>>
JM> On 20 May 2009, at 15:40, Roland Turcan wrote:
>> I need to flush buffers from TFileStream which I should use function
>> "fpfsync (Handle)", but as far as I found, there is no implementation
>> of DO_SYSCALL for mac. DO_SYSCAL
On 20 May 2009, at 15:40, Roland Turcan wrote:
I need to flush buffers from TFileStream which I should use function
"fpfsync (Handle)", but as far as I found, there is no implementation
of DO_SYSCALL for mac. DO_SYSCALL is implemented only for BSD.
Why do you think that you need DO_SYSCALL?
Hello FPC-Pascal users discussions!
I need to flush buffers from TFileStream which I should use function
"fpfsync (Handle)", but as far as I found, there is no implementation
of DO_SYSCALL for mac. DO_SYSCALL is implemented only for BSD.
When my application crashes all files modified over TFileSt
12 matches
Mail list logo
