Re: [fpc-devel] [PATCH] unix/serial.pp mods for darwin
Jonas Maebe wrote:
On 30 Sep 2008, at 17:06, Brad Campbell wrote:
These additions/changes make serial.pp work for me on MacOS X 10.4 and
10.5, both PPC and Intel.
Comments?
Do you also know why these changes are necessary? Adding special cases
from a particular platform without any comments (other than it works
now) is unlikely to work in the long term
Index: rtl/unix/serial.pp
===
--- rtl/unix/serial.pp (revision 11843)
+++ rtl/unix/serial.pp (working copy)
@@ -70,7 +70,14 @@
function SerOpen(const DeviceName: String): TSerialHandle;
begin
This is requires as MacOS will block on the open unless Carrier Detect is asserted. So you need to
open the port non-blocking and then clear the non-blocking flag. Found this in some apple sample
code on the apple dev site.
+ {$IFDEF DARWIN}
+ Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK);
+ { Remove the O_NONBLOCK }
+ If Result 0 then
+FpFCNTL(Result, F_SETFL, 0);
+ {$ELSE}
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY);
+ {$ENDIF}
end;
procedure SerClose(Handle: TSerialHandle);
@@ -127,7 +134,11 @@
tios.c_ispeed := tios.c_cflag;
tios.c_ospeed := tios.c_ispeed;
This is required as Darwin does not use enums for the baud rate, and simply use the whole numbers.
In this case some of the baud rates end up asserting weird flags in the control bits. Darwin uses
c_ispeed/c_ospeed rather than extract the baud rate from c_cflag.
+{$ifndef DARWIN}
tios.c_cflag := tios.c_cflag or CREAD or CLOCAL;
+{$else}
+ tios.c_cflag := CREAD or CLOCAL;
+{$endif}
case ByteSize of
5: tios.c_cflag := tios.c_cflag or CS5;
@@ -146,9 +157,10 @@
if RtsCtsFlowControl in Flags then
tios.c_cflag := tios.c_cflag or CRTSCTS;
This is actually only required on 10.5 on Intel, but it does not seem to hurt
on the other versions.
If left in place, this just blocks and stalls the program.
-
+{$IFNDEF DARWIN}
tcflush(Handle, TCIOFLUSH);
- tcsetattr(Handle, TCSANOW, tios)
+{$ENDIF}
+ tcsetattr(Handle, TCSANOW, tios);
end;
--
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] unix/serial.pp mods for darwin
On 01 Oct 2008, at 08:41, Brad Campbell wrote:
This is actually only required on 10.5 on Intel, but it does not
seem to hurt on the other versions.
If left in place, this just blocks and stalls the program.
-
+{$IFNDEF DARWIN}
tcflush(Handle, TCIOFLUSH);
- tcsetattr(Handle, TCSANOW, tios)
+{$ENDIF}
+ tcsetattr(Handle, TCSANOW, tios);
end;
How about using TCSADRAIN or TCSAFLUSH instead of TCSANOW? As far as
I can see, that should have the same effect as the tcflush(Handle,
TCIOFLUSH). Does that hang too?
Thanks a lot for the explanations. Once this is settled, I'll commit
your patch.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Howto hide Hint: Parameter yyy not used
On 29 Sep 2008, at 16:50, [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:49:29AM +0200, Jonas Maebe wrote: On 29 Sep 2008, at 11:41, Paul Ishenin wrote: Jonas Maebe ??: That's just a hack, and you have to regenerate the message file for every new FPC release. Ofcource, but what can we do simple fpc users ;) Submit a patch. The message handling code really isn't rocket science. It's pretty much all in compiler/verbose.pas In the attachment is a little patch. With cmdline option - vm05024,05025 you can suppress messages with idx 05024 and 05025. It's a good start, but this patch is not ready to be committed: a) it is limited to 10 suppressions b) people have to look up the error number in the message file first c) if you change the limitation in a), the code will become exponentially slower do to having to go over the entire suppression array every time a message has to be shown A better approach may be to add a method to TMessage (in the cmsg.pas unit) to clear the verbosity level (replace all verbosity indicators with '_'). And to add an option to the compiler to also show the message number when printing output (so people can use this to get the numbers of the messages they want to suppress). But I'am not sure if really realized msgtxt.inc rocket science :). That is why I do not change fpc help message in the patch. It is automatically generated from compiler/msg/errore.msg (a plain text file) when you make the compiler. So just a patch to compiler/msg/ errore.msg is fine. Thanks, Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] unix/serial.pp mods for darwin
On 01 Oct 2008, at 20:18, Jonas Maebe wrote:
On 01 Oct 2008, at 08:41, Brad Campbell wrote:
This is actually only required on 10.5 on Intel, but it does not
seem to hurt on the other versions.
If left in place, this just blocks and stalls the program.
-
+{$IFNDEF DARWIN}
tcflush(Handle, TCIOFLUSH);
- tcsetattr(Handle, TCSANOW, tios)
+{$ENDIF}
+ tcsetattr(Handle, TCSANOW, tios);
end;
How about using TCSADRAIN or TCSAFLUSH instead of TCSANOW? As far
as I can see, that should have the same effect as the
tcflush(Handle, TCIOFLUSH). Does that hang too?
I've found some other code for setting up a serial port on Darwin at
http://www.nabble.com/Patch-for-controlling-Pioneer-via-a-Mac-td6672642.html
The full code is at http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/server/drivers/mixed/p2os/p2os.cc?view=markup
(in method P2OS::Setup). Some observations:
* they use the cfsetispeed() and cfsetospeed() functions rather than
directly writing in the fields. This should probably also be done at
least for Darwin
* they also or the (CLOCAL | CREAD) flags into the c_flag field,
rather just overwriting it (I guess cfsetispeed()/cfsetospeed() will
make sure it's set appropriately)
* they also call tcflush() at the end
Since this project seems quite alive, I guess it works fine for them
on Mac OS X/Intel, so there may be something else going wrong that
requires you to clear the c_flags and remove the flush.
Jonas
They also flush before calling tcsetattr, and they do not appear to be
clearing term. c_cflag
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] String collating
Hi all,
can anybody please comment on the following?
Bellow is a simple function, returning M9,MD,P6.
function F: String;
begin
with TStringList.Create do
try
Sorted := True;
Add('P6');
Add('M9');
Add('MD');
Result := CommaText;
finally
Free;
end;
end;
It does so in a console program, but if invoked from within a GUI app,
the result is MD,M9,P6 (you can find the sources for both variants
in the attached archive) on my system (Ubuntu 8.04.1):
Linux mypc 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 GNU/Linux
LANG=cs_CZ.UTF-8
GDM_LANG=cs_CZ.UTF-8
FPC SVN revision 11845
Lazarus SVN revision 16831
I've traced the execution of TStringList.Add downto calling strcoll()
from libc (on rtl/unix/cwstring.pp line 578) which - to my surprise -
returns opposite signed results in the console and gui variants
for the same compare pair MD and M9. There is possibly some
difference in the initialization of an application which causes this
behaviour
and which also could be bound to my non English locale. Or it may be a
bug somewhere in the libc/RTL/LCL? (of course it may be also an error
between my seat and keyboard :-)
I was not yet able to find out if this is a bug at all or just the
intended string collating of a Czech locale.
Any feedback would be appreciated.
BFLM
question.tar.gz
Description: GNU Zip compressed data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] String collating (oops)
Hi all,
can anybody please comment on the following?
Bellow is a simple function, returning M9,MD,P6.
function F: String;
begin
with TStringList.Create do
try
Sorted := True;
Add('P6');
Add('M9');
Add('MD');
Result := CommaText;
finally
Free;
end;
end;
It does so in a console program, but if invoked from within a GUI app,
the result is MD,M9,P6 on my system (Ubuntu 8.04.1):
Linux mypc 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 GNU/Linux
LANG=cs_CZ.UTF-8
GDM_LANG=cs_CZ.UTF-8
FPC SVN revision 11845
Lazarus SVN revision 16831
I've traced the execution of TStringList.Add downto calling strcoll()
from libc (on rtl/unix/cwstring.pp line 578) which - to my surprise -
returns opposite signed results in the console and gui variants
for the same compare pair MD and M9. There is possibly some
difference in the initialization of an application which causes this
behaviour
and which also could be bound to my non English locale. Or it may be a
bug somewhere in the libc/RTL/LCL? (of course it may be also an error
between my seat and keyboard :-)
I was not yet able to find out if this is a bug at all or just the
intended string collating of a Czech locale.
Any feedback would be appreciated.
BFLM
PS: This is a resend of my previous post, now WITHOUT the attachment
as it (?) rendered the message unreadable. Sorry for any
inconvenience.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Strange things with the apache header files on Linux
On Linux (Ubuntu 8.04), latest SVN, in fpc/packages/httpd22/...
in httpd.inc inside request_rec:
{ body byte count, for easy access }
bytes_sent: apr_off_t;
{ Last modified time of the requested resource }
mtime: apr_time_t;
in apr.pas :
apr_off_t = Int64;
apr_int64_t = Int64;
in apr_time.inc :
apr_time_t = apr_int64_t;
Using an example apache module compiled with FPC/Lazarus (the
initialization part is executed when apache loads):
sizeof(apr_int64_t) gives 4
sizeof(apr_off_t) gives 4
sizeof(apr_time_t) gives 8
sizeof(request_rec.bytes_sent) gives 4
sizeof(request_rec.mtime) gives 8
Shouldn't all be 8 bytes? Or am I missing something?
And why apr_time_t is the correct 8 if the others are 4?
One of the reasons that the C compiled apache modules have 412 bytes
(correctly) in request_rec instead of the 384 bytes (incorrectly) in
the FPC compiled ones is that sizeof(apr_off_t) is 4 instead of 8.
This might be the reason that apache modules are not working on Linux
compiled with FPC/lazarus, unless I'm way off track...
Any thoughts?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange things with the apache header files on Linux
When copying the files from httpd22 dir to my project directory and
recompiling them with my project the record sizes are OK and same as the
C compiled apache module.
Yet, the apache module compiled with FPC/Lazarus is not working. The
hooked DefaultHandler function is never called, just an empty web page
is returned. Everything works under Windows, but not on Linux.
ABorka wrote:
On Linux (Ubuntu 8.04), latest SVN, in fpc/packages/httpd22/...
in httpd.inc inside request_rec:
{ body byte count, for easy access }
bytes_sent: apr_off_t;
{ Last modified time of the requested resource }
mtime: apr_time_t;
in apr.pas :
apr_off_t = Int64;
apr_int64_t = Int64;
in apr_time.inc :
apr_time_t = apr_int64_t;
Using an example apache module compiled with FPC/Lazarus (the
initialization part is executed when apache loads):
sizeof(apr_int64_t) gives 4
sizeof(apr_off_t) gives 4
sizeof(apr_time_t) gives 8
sizeof(request_rec.bytes_sent) gives 4
sizeof(request_rec.mtime) gives 8
Shouldn't all be 8 bytes? Or am I missing something?
And why apr_time_t is the correct 8 if the others are 4?
One of the reasons that the C compiled apache modules have 412 bytes
(correctly) in request_rec instead of the 384 bytes (incorrectly) in
the FPC compiled ones is that sizeof(apr_off_t) is 4 instead of 8.
This might be the reason that apache modules are not working on Linux
compiled with FPC/lazarus, unless I'm way off track...
Any thoughts?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
