Hi,
I would like to ask politely for some elaboration about the closing comment on
this bug report: http://www.freepascal.org/mantis/view.php?id=5940
It was opened one year ago, when I was testing the FPC release 2.0.0, but the
situation didn't change too much in all this time.
I know that it
On Saturday 26 February 2005 12:38, Florian Klaempfl wrote:
> > On Saturday 26 February 2005 12:02, I wrote:
> >>On current CVS (FPC-1.9.9) there is a dependency between classes unit and
> >>cthreads. Any program using the classes unit requires to use also
> >> cthreads or it fails with a runtime e
On Saturday 26 February 2005 12:02, I wrote:
> On current CVS (FPC-1.9.9) there is a dependency between classes unit and
> cthreads. Any program using the classes unit requires to use also cthreads
> or it fails with a runtime error. This happens to the utilities fpcmake and
> fpdoc.
This is not e
Hi,
On current CVS (FPC-1.9.9) there is a dependency between classes unit and
cthreads. Any program using the classes unit requires to use also cthreads or
it fails with a runtime error. This happens to the utilities fpcmake and
fpdoc.
$ ./fpdoc
This binary has no thread support compiled in.
On Monday 17 January 2005 10:37, Johannes Berg wrote:
> On So, 2005-01-16 at 23:36 +0100, Pedro Lopez-Cabanillas wrote:
> > The attached program works well under Linux when compiled with Kylix3. It
> > counts from 1 to 10 and ends. FPC compiles it, but doesn't work (loops
>
On Monday 17 January 2005 14:42, Vincent Snijders wrote:
> Micha Nelissen took a look at it and said:
> > Does it work, if you remove the call to sleep, just before
> > CheckSynchronize? Or change it to sleep(1) and observe it prints 1 2 3 4
> > every second.
No. It doesn't work even if you remove
Hi,
The attached program works well under Linux when compiled with Kylix3. It
counts from 1 to 10 and ends. FPC compiles it, but doesn't work (loops
forever). Seems that CheckSynchronize doesn't work (or perhaps
TThread.Synchronize?).
Another issue: CheckSynchronize has in Kylix3 an optional
Peter Vreman wrote:
> > Peter Vreman wrote:
> > [...]
> >
> >> > This is bad coding imho and works in Delphi only "by accident" because
> >> > Delphi uses register calling conventions. Or are I'am wrong and sort
> >> > expects a local procedure?
> >>
> >> The compiler should give an error. It is ba
Peter Vreman wrote:
[...]
> > This is bad coding imho and works in Delphi only "by accident" because
> > Delphi uses register calling conventions. Or are I'am wrong and sort
> > expects a local procedure?
>
> The compiler should give an error. It is bad coding and only a
> "undocumented feature" of
Hi,
The attached program compiles and works fine under Kylix 3, and also compiles
under fpc 1.9, but bombs with this message:
An unhandled exception occurred at 0x0807F0B5 :
EAccessViolation : Access violation
0x0807F0B5
It happens on TObjectList.Sort when the argument is a local nested funct
[EMAIL PROTECTED] wrote:
> On Sat, 15 Nov 2003, KJK::Hyperion wrote:
> > At 12.27 15/11/2003, you wrote:
> > >All you need to do is send the STOP signal to the thread.
> >
> > This is a common misunderstanding. I quote from IEEE 1003.1:
> >
> > "[...]
> >
> > Note that pthread_kill() only causes th
Johannes Berg wrote:
> Probably not complete, but an overview of what I have in mind -- read
> the notes in the file.
Can you include also a patch for rtl/objpas/classes/classesh.inc ?
Regards,
Pedro
--
ALSA Library Bindings for Pascal
http://alsapas.alturl.com
__
Hi,
Does the example program threads.pp (doc/examples/fcl/threads.pp) work for
anybody under Linux?
It aborts for me as soon as the first thread is created, printing "Killed".
Regards,
Pedro
--
ALSA Library Bindings for Pascal
http://alsapas.alturl.com
__
Marco van de Voort wote:
> And that is no problem. FPC should take the best (fastest) path. Even
>
> Kylix gives it as warning already:
> > test5.pp(10) Warning: FOR-Loop variable 'i' may be undefined after loop
> > test5.pp(12)
I agree that FPC behavior is right here. But Borland compilers are do
Hi,
The following program behaves different in Kylix3 and FPC 1.9.
program test5;
{$IFDEF FPC}
{$MODE DELPHI}
{$ENDIF}
var
i: Integer;
begin
for i:=1 to 1 do WriteLn(i);
WriteLn(i, ' <===');
end.
$ fpc test5
Hint: End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 1.9
Hi again,
I've installed the FPC 1.9.0 binary rpm from sourceforge, but seems that there
is not a source package for this version there. I guess that i can download
the sources from CVS, but surely they have changed since the rpm has been
created, and I need the sources for Lazarus.
The file n
Marco van de Voort wrote:
> > open("/etc/timezone", O_RDONLY) = 3
>
> This is the culprit. People that have this file don't have the problem.
> If this one goes wrong, the errno value remains there, and the next
> decision that bases itself on linuxerror goes wrong.
Confirmed. Removing /et
Marco van de Voort wrote:
> - Do an strace, and see if there is a function that fails.
Everything seems OK.
$ strace pipetest
execve("/home/plc/Pascal/test1.9/pipetest", ["pipetest"], [/* 63 vars */]) = 0
sigaction(SIGFPE, {0x805a9d4, [], 0}, {SIG_DFL}, 0x40054d58) = 0
sigaction(SIGSEGV, {0x805a9
Jeff Pohlmeyer wrote:
> Could someone else please try this with the Linux 1.9.0 compiler,
> and let me know the results ?
>
>
> program pipetest;
> uses errors, unix;
> var
> pipi, pipo: text;
> begin
> AssignPipe(pipi, pipo);
> perror('AssignPipe', LinuxError);
> end.
I've tried it, with fp
Hi all,
The following test program doesn't compile under FPC 1.9.0, but it does and
works under Kylix 3. I didn't try other Delphi incarnations.
The compiler says:
$ fpc test3
Hint: End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 1.9.0 [2003/11/05] for i386
Copyright (c) 19
20 matches
Mail list logo