Re: [fpc-pascal] Getting UTC time etc.
Mark Morgan Lloyd wrote: I know that this was discussed a couple of months ago, but I had difficulty working out what the consensus was. i)Is there an FPC function which will get the raw time from the RTC, which on unix systems will usually be UTC (specifically, without a DST correction)? Discussion was in March. How time flies. Reinier et al. suggested PascalTZ, but in the end I went for a simple function since I'm trying to avoid installing anything special and timezone info will be available from the backend database. (* This from FPC-Pascal mailing list, 13/02/07. Thanks, Marco. *) // function utc_now : TDateTime; var timeval: TTimeVal; timezone: PTimeZone; a: Double; begin TimeZone := nil; fpGetTimeOfDay (@TimeVal, TimeZone); // Convert to milliseconds a := (TimeVal.tv_sec * 1000.0) + (TimeVal.tv_usec / 1000.0); Result := (a / MSecsPerDay) + UnixDateDelta; end; ii)Are there functions to get "Unix seconds", "Borland seconds" and so on? Preferably without DST correction, or with the correction being extractable? DateTimeToUnix() from DateUtils. Anything else I can do without. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] GPL Lisence help
Dimitrios Chr. Ioannidis wrote: Hi all, first let me express my apologies for the off topic question. I'm having trouble to choose the correct gpl lisence for a new open source project that i'm starting. I want the project to be open source gpl'ed so it can be accepted in distro's like Debian. But, at the same time, because the structure is modular, i want the possibility, to be used by anyone in commercial applications. Can anyone give a hint and/or a suggestion ? Possibly multiple licenses: the license is determined by how somebody has got the code from you irrespective of whether he could have got it elsewhere. Alternatively, the basic framework is GPL but dynamically-linked extensions are proprietary. I suppose that the bigger question is: how does one find an affordable lawyer, well-versed in the laws covering the major jurisdictions? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Getting UTC time etc.
I know that this was discussed a couple of months ago, but I had difficulty working out what the consensus was. i) Is there an FPC function which will get the raw time from the RTC, which on unix systems will usually be UTC (specifically, without a DST correction)? ii) Are there functions to get "Unix seconds", "Borland seconds" and so on? Preferably without DST correction, or with the correction being extractable? I'm trying to work out a fairly large distributed system, and while the backend databases will generally be able to supply UTC I'd like to be able to get it from the client for status messages etc. before connection. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] POSIX capabilities library
Mark Morgan Lloyd wrote: Does FPC have an interface to the POSIX capabilities library, which I believe is libcap or possibly libcap-ng? I've hacked a partial interface to the API. If anybody else has to deal with this issue, note that Debian only provides libcap as a .so. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and IPv6, and BSD
ZAN DoYe wrote:
On 2012-07-23 21:51, Mark Morgan Lloyd wrote:
I'm trying to write a simple finger daemon, capable of both IP4 and
IP6. At present it's using an unprivileged socket so as to avoid
problems on unix platforms.
I appear to be having problems at the bind() call for IP6 (returns
-1), which I suspect is down to my incomplete understanding of the new
sockaddr_in6 structure. Has anybody done this successfully?
If you called fpBind, then check fpGetErrno to see what happened. If you
do called the bind function in libc. uses initc unit, and check the cerrno.
Thanks, the problem was entirely down to IP6 also binding IP4. I've
coded to leave this as an option.
As a subsidiary question: noting that a client has to be aware of this:
sockaddr_in6 = packed Record
{$ifdef SOCK_HAS_SINLEN} // as per RFC 2553
sin6_len: cuint8;
{$endif}
sin6_family : sa_family_t;
..
so that it initialises the sin6_len field if present (some BSD
variants?), does it see that conditional automatically if defined?
Otherwise how best to do it?
You don't worry about the sin6_len field.
`Even if the length field is present, we need never set it and need
never examine it, unless we are dealing with routing sockets. It is used
within the kernel by the routines that deal with socket address
structures from various protocol families.' --- UNP v1
Thanks very much for that, noted.
Remainder noted for reference.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] POSIX capabilities library
Does FPC have an interface to the POSIX capabilities library, which I believe is libcap or possibly libcap-ng? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and IPv6, and BSD
Mark Morgan Lloyd wrote:
I'm trying to write a simple finger daemon, capable of both IP4 and IP6.
At present it's using an unprivileged socket so as to avoid problems on
unix platforms.
I appear to be having problems at the bind() call for IP6 (returns -1),
which I suspect is down to my incomplete understanding of the new
sockaddr_in6 structure. Has anybody done this successfully?
On Linux >= 2.4.21 attempting to bind a v6 socket also binds the
corresponding v4. Appears to need
bindrc := 1;
fpsetsockopt(socket6, IPPROTO_IPV6, IPV6_V6ONLY, @bindrc,
SizeOf(bindRc));
to get them to work individually.
As a subsidiary question: noting that a client has to be aware of this:
sockaddr_in6 = packed Record
{$ifdef SOCK_HAS_SINLEN} // as per RFC 2553
sin6_len: cuint8;
{$endif}
sin6_family : sa_family_t;
..
so that it initialises the sin6_len field if present (some BSD
variants?), does it see that conditional automatically if defined?
Otherwise how best to do it?
Anybody?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC and IPv6, and BSD
I'm trying to write a simple finger daemon, capable of both IP4 and IP6.
At present it's using an unprivileged socket so as to avoid problems on
unix platforms.
I appear to be having problems at the bind() call for IP6 (returns -1),
which I suspect is down to my incomplete understanding of the new
sockaddr_in6 structure. Has anybody done this successfully?
As a subsidiary question: noting that a client has to be aware of this:
sockaddr_in6 = packed Record
{$ifdef SOCK_HAS_SINLEN} // as per RFC 2553
sin6_len: cuint8;
{$endif}
sin6_family : sa_family_t;
..
so that it initialises the sin6_len field if present (some BSD
variants?), does it see that conditional automatically if defined?
Otherwise how best to do it?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
Michael Van Canneyt wrote: On Sun, 22 Jul 2012, Mattias Gaertner wrote: On Wed, 18 Jul 2012 17:15:20 +0200 (CEST) michael.vancann...@wisa.be wrote: [...] I meant the SimpleIPC unit from the FCL: http://lazarus-ccr.sourceforge.net/docs/fcl/simpleipc/index.html Is there a simple two way IPC? It seems the '/tmp' directory is always used by simpleipc under unix. How can I change this directory? You can't, currently, but patches to customize this are definitely welcome. I had at least one extension in mind, where a user-specific directory would be used. If you'd like to pick through the stuff I wrote for myself you'd be welcome. There's quite a lot in there, in particular it uniquely-names and cleans up orphaned sockets... but I suspect that you'd throw your hands up in horror at my code since I'm sure that in a lot of places I've hardcoded stuff that by now exists in a standard library. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
waldo kitty wrote: FWIW: DOS does have and has had pipes... otherwise things like DIR | MORE would not work... maybe you mean named pipes? ;) Yes, I do. And I'm obviously aware that there are plenty of addons that graft named pipes (and mailslots etc.) onto DOS. i never used any of that... didn't need to AFAIK... just regular pipes worked fine for the times i needed them but yes, they a much different animals than named pipes... I used mailslots in a DOS (VB for DOS?) program, they're the API that underlies MS-style networking's NET SEND command. However I always think of named pipes, threads etc. as being primarily OS/2 v1 innovations, although some might have been introduced by the obscure Microsoft OS usually referred to as "European MS-DOS v4.0". for some reason i was thinking that unix and xenix had named pipes back then... either way, i'm out and apologize for the diversion ;) If you were using the very early MS networking for unix (mentioned in the Samba entry on Wp IIRC, but I think I've also got other references) then they probably had both. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
waldo kitty wrote: On 7/18/2012 08:48, Mark Morgan Lloyd wrote: I was reminded of this when somebody was asking about portable signalling APIs the other day, but I think it's also relevant to discussion of e.g. how to pass a keyword to a help viewer. I am obviously aware of the fact that FPC has an IPC unit which uses a temporary file, although I have always assumed that that was more to support targets like DOS that had absolutely no concept of pipes or sockets. But perhaps it really is the safest choice in all cases. FWIW: DOS does have and has had pipes... otherwise things like DIR | MORE would not work... maybe you mean named pipes? ;) Yes, I do. And I'm obviously aware that there are plenty of addons that graft named pipes (and mailslots etc.) onto DOS. However I always think of named pipes, threads etc. as being primarily OS/2 v1 innovations, although some might have been introduced by the obscure Microsoft OS usually referred to as "European MS-DOS v4.0". -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
Michael Van Canneyt wrote: I meant the SimpleIPC unit from the FCL: http://lazarus-ccr.sourceforge.net/docs/fcl/simpleipc/index.html Because I was exploring various unix-domain socket aspects including mtu, where they're put, how to recover if an inactive one's already there (e.g. gdb failure) and so on. And in particular I was exploring naming issues that were being fouled up by things like Mozilla, trying to find some balance between the name of the project (known at compilation time) and the name of the executable after this sort of thing had caused a lot of local hassle. So I think you've done better having something that is portable and is coded fairly elegantly, but I don't think that I've gratuitously reinvented the wheel. I never meant to imply that; I just hoped that by pointing you to some existing code, I could stop you from spending time on something which already exists. Of course, time spent learning APIs is never wasted :) I'll certainly take a close look at that if I come back to this problem- if nothing else to see whether it works in the context of a single process :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
michael.vancann...@wisa.be wrote: On Wed, 18 Jul 2012, Mark Morgan Lloyd wrote: michael.vancann...@wisa.be wrote: No need to apologize, I'm just curious where you got your info from. The implementation has been the same since day 1, which means your statement puzzles me. So instead of re-inventing the wheel, maybe have a closer look again at the standard IPC mechanisms. I will do, but I do note that http://lazarus-ccr.sourceforge.net/docs/rtl/ipc/index.html explicitly says that "It works only on the linux operating system". Where's the source- I can only see ./fpcsrc/rtl/unix/ipc.pp I meant the SimpleIPC unit from the FCL: http://lazarus-ccr.sourceforge.net/docs/fcl/simpleipc/index.html Because I was exploring various unix-domain socket aspects including mtu, where they're put, how to recover if an inactive one's already there (e.g. gdb failure) and so on. And in particular I was exploring naming issues that were being fouled up by things like Mozilla, trying to find some balance between the name of the project (known at compilation time) and the name of the executable after this sort of thing had caused a lot of local hassle. So I think you've done better having something that is portable and is coded fairly elegantly, but I don't think that I've gratuitously reinvented the wheel. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
OBones wrote: Mark Morgan Lloyd wrote: Basically, what I was trying to do was this. In the main thread: fIpcPipe:= CreateNamedPipe(PChar(fIpcName), PIPE_ACCESS_INBOUND, PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE, 1, 0, 0, 1000, NIL (* @sa *) ); That works. Fire up a background reader thread, and make sure that the main thread doesn't proceed... So you are not creating the "read" pipe in the context of the thread that actually reads from it? I'm not sure that this is actually supported, maybe you should try to create it in the context of the reading thread. I agree, but ever since threads were introduced (OS/2 v1 or perhaps even earlier) doctrine has had it that ownership (of memory, handles and so on) was by process while state (stack content and runability) was by thread. Other points noted, in particular that my problem might be that I can't distribute certain types of activity over threads rather than (as I initially assumed) that things had to be distributed over multiple processes. In any event, I can get away without having this working. If I do manage to hack it at some point I'll try to remember to report back. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
michael.vancann...@wisa.be wrote: No need to apologize, I'm just curious where you got your info from. The implementation has been the same since day 1, which means your statement puzzles me. So instead of re-inventing the wheel, maybe have a closer look again at the standard IPC mechanisms. I will do, but I do note that http://lazarus-ccr.sourceforge.net/docs/rtl/ipc/index.html explicitly says that "It works only on the linux operating system". Where's the source- I can only see ./fpcsrc/rtl/unix/ipc.pp -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
OBones wrote:
Mark Morgan Lloyd wrote:
A couple of weeks ago, out of curiosity rather than necessity, I
started looking at whether the library could be ported to Windows
using MS-style named pipes. However I seem to have hit a snag since it
appears that Windows can't both create a named pipe (for reading) and
open the same named pipe (for writing) in the same process, something
that gives unix sockets no problems at all.
Could you show us some code here?
And what return values do you get?
I'm asking because I have distinct memories of doing just that a while
back without any issue.
I've certainly done it to communicate between separate processes, but
the difference in the current case is that the first time the program is
loaded I'm enqueueing its own parameters rather than passing them via an
in-memory "shortcut"... works fine in unix and seemed like a good idea
at the time :-) It's strange though just how many people on
StackOverflow etc. say things like "using a named pipe to communicate
inside a single process is utterly pointless", it's almost as though
they're parroting some doctrine the origin of which is now lost.
Basically, what I was trying to do was this. In the main thread:
fIpcPipe:= CreateNamedPipe(PChar(fIpcName), PIPE_ACCESS_INBOUND,
PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE,
1, 0, 0, 1000, NIL (* @sa *) );
That works. Fire up a background reader thread, and make sure that the
main thread doesn't proceed...
fThread:= TSphinxThread.Create(false);
while fThread.fSyncParam = DEADBEEF DO (* Until thread has called
ConnectNamedPipe() *)
Sleep(10);
fThread.Suspend
..until after the Execute in the reader thread has done:
fSyncParam := ''; (* Let main process see that
we've started *)
{$ifndef UNIX }
IF NOT ConnectNamedPipe(Phix.Pipe, NIL) THEN
EXIT;
{$endif UNIX }
WHILE NOT Terminated DO BEGIN
I'm keenly aware of the deprecated status of calling Suspend from
outside the thread, but what I'm showing there is just one attempt from
many.
Finally, once the main thread is confident that the background reader
has got to the point of being connected to the named pipe:
sendPipe:= CreateFile(PChar(fIpcName), GENERIC_WRITE,
FILE_SHARE_WRITE + FILE_SHARE_READ,
NIL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, 0);
IF sendPipe = INVALID_HANDLE_VALUE THEN BEGIN
fSlaveInitErrorNum:= GetLastError; (* 230: bad pipe. 231: pipe
busy.*)
That invariably fails with an error 231, at which point after quite a
lot of tinkering and comparison against my older code I gave up.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
michael.vancann...@wisa.be wrote: On Wed, 18 Jul 2012, Mark Morgan Lloyd wrote: I was reminded of this when somebody was asking about portable signalling APIs the other day, but I think it's also relevant to discussion of e.g. how to pass a keyword to a help viewer. I am obviously aware of the fact that FPC has an IPC unit which uses a temporary file, although I have always assumed that that was more to support targets like DOS that had absolutely no concept of pipes or sockets. But perhaps it really is the safest choice in all cases. In which unit did you find this ? The IPC unit in FPC uses a unix socket on unix, and on windows a Windows window handle to copy data. I believe I'm thinking of TSimpleIPC etc. My apologies if I've got this wrong, or if what I read was outdated "Ignorance of the law is no defense"). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Inter-process communication, a cautionary tale
I was reminded of this when somebody was asking about portable signalling APIs the other day, but I think it's also relevant to discussion of e.g. how to pass a keyword to a help viewer. I am obviously aware of the fact that FPC has an IPC unit which uses a temporary file, although I have always assumed that that was more to support targets like DOS that had absolutely no concept of pipes or sockets. But perhaps it really is the safest choice in all cases. A couple of years ago I wrote an experimental library that used a unix-domain socket to ensure that only a single copy of a program was running, and to pass a command line from any subsequent copy to the original. In general, it worked well; and unlike TCP etc. it was inherently protected from external interference. A couple of weeks ago, out of curiosity rather than necessity, I started looking at whether the library could be ported to Windows using MS-style named pipes. However I seem to have hit a snag since it appears that Windows can't both create a named pipe (for reading) and open the same named pipe (for writing) in the same process, something that gives unix sockets no problems at all. I'm not particularly looking for sympathy, and I'm not really expecting anybody to point out that I've overlooked something obvious (although suggestions would, of course, be appreciated). I'm simply outlining this as an illustration that the complex semantics of the Windows API can, at times, bite. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Mark Morgan Lloyd wrote: Sven Barth wrote: Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem. This problem no longer exists in 2.7.1 (21919 + Reinier's solarisdbtrunk2.diff). Then it might be good if you report this in Mantis together with Reinier's patch so that it isn't forgotten. I'll do that, but first I'm working through another odd issue to determine whether it's down to Lazarus on Solaris or is a recently-introduced problem in 2.7.1 targeting SPARC. Submitted as 22459. There are other database problems affecting SPARC on both Solaris and Linux, I don't know yet what other architectures are affected and suspect it's something to do with Lazarus components or resource handling so will raise it elsewhere. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Sven Barth wrote: Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem. This problem no longer exists in 2.7.1 (21919 + Reinier's solarisdbtrunk2.diff). Then it might be good if you report this in Mantis together with Reinier's patch so that it isn't forgotten. I'll do that, but first I'm working through another odd issue to determine whether it's down to Lazarus on Solaris or is a recently-introduced problem in 2.7.1 targeting SPARC. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Ludo Brands wrote: We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry). I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)? No, the value is read from the server and depends on how the server was compiled. Run 'show integer_datetimes;' in psql or whatever client you are using to see the value. Pqconnection has detected that it is 'on' on your server. You can check with above command to see if the server agrees with that. With integer_datetimes on the datetime is returned as an int64 with the number of microseconds since 2000-01-01 00:00:00 UTC, hence the dbl^ := pint64(buffer)^/100; Dbl is a Pdouble, so the alignment problem could indeed come from there. The buffer returned by the driver is correct because just before you have pint64(buffer)^ := BEtoN(pint64(CurrBuff)^); CurrBuff being the pointer returned. Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem. This problem no longer exists in 2.7.1 (21919 + Reinier's solarisdbtrunk2.diff). However, I've got an "unknown fieldtype" which I'll investigate and if necessary raise separately. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : Database problem on Solaris SPARC
Reinier Olislagers wrote:
On 16-7-2012 18:41, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
Whoopsie, error in the patch: this:
- merged
P.SourcePath.Add('src/sqldb/sqlite', SqldbConnectionOSes);
P.SourcePath.Add('src/sqldb/sqlite', SqliteOSes);
into
P.SourcePath.Add('src/sqldb/sqlite', SqldbConnectionOSes+SqliteOSes);
for clarity on who gets sqlite
wasn't true... I had mixed some very similar but different paths.
New patches attached.
FPC trunk compiles for me with this patch (x86) on Windows.
In Solaris/SPARC,
..
Assembling oracleconnection
Compiling ./fcl-db/src/sqldb/postgres/pqconnection.pp
Writing Resource String Table file: pqconnection.rst
Assembling pqconnection
Compiling ./fcl-db/src/sqldb/postgres/pqeventmonitor.pp
Writing Resource String Table file: pqeventmonitor.rst
Assembling pqeventmonitor
Compiling ./fcl-db/src/sqldb/mssql/mssqlconn.pp
mssqlconn.pp(43,3) Fatal: Can't find unit dblib used by mssqlconn
Fatal: Compilation aborted
gmake[2]: *** [all] Error 1
gmake[2]: Leaving directory
`/export/home/local-src/fpc/fpcbuild-2.7.1/fpcsrc/packages'
gmake[1]: *** [packages_all] Error 2
gmake[1]: Leaving directory
`/export/home/local-src/fpc/fpcbuild-2.7.1/fpcsrc'
gmake: *** [build-stamp.sparc-solaris] Error 2
Have I missed any stages out: applied patch successfully, make
distclean, make all?
Blast, I'm sorry... missed the dblib unit that is required for FreeTDS...:
which requires adding solaris: from
DBLibOSes = [linux,freebsd,netbsd,openbsd,win32,win64,haiku];
to
DBLibOSes =
[linux,freebsd,netbsd,openbsd,solaris,win32,win64,haiku];
Going to have a look at Oracle and mysql units as well then.
Mysql: looked at packages\mysql; no idea what if anything to change there.
Oracle packages\oracle\fpmake.pp shows
P.OSes := AllUnixOSes+AllWindowsOSes-[qnx];
which sounds reasonable, so no changes
Likewise for packages\ODBC
Likewise for packages\ibase (Interbase/Firebird)
Likewise for packages\postgres
Likewise for packages\sqlite
Updated patch attached
Hope this one does the trick...
Please don't apologise: I very much appreciate the effort :-)
That compiles and installs OK. Currently working on Lazarus... bigide
compiles and runs OK. Deo volente, I'll get back onto testing the
program that was having trouble with PostgreSQL in the morning, after
that it will be at least a few days before I've got Borg-NG talking to
its backends.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : Database problem on Solaris SPARC
Reinier Olislagers wrote:
Whoopsie, error in the patch: this:
- merged
P.SourcePath.Add('src/sqldb/sqlite', SqldbConnectionOSes);
P.SourcePath.Add('src/sqldb/sqlite', SqliteOSes);
into
P.SourcePath.Add('src/sqldb/sqlite', SqldbConnectionOSes+SqliteOSes);
for clarity on who gets sqlite
wasn't true... I had mixed some very similar but different paths.
New patches attached.
FPC trunk compiles for me with this patch (x86) on Windows.
In Solaris/SPARC,
..
Assembling oracleconnection
Compiling ./fcl-db/src/sqldb/postgres/pqconnection.pp
Writing Resource String Table file: pqconnection.rst
Assembling pqconnection
Compiling ./fcl-db/src/sqldb/postgres/pqeventmonitor.pp
Writing Resource String Table file: pqeventmonitor.rst
Assembling pqeventmonitor
Compiling ./fcl-db/src/sqldb/mssql/mssqlconn.pp
mssqlconn.pp(43,3) Fatal: Can't find unit dblib used by mssqlconn
Fatal: Compilation aborted
gmake[2]: *** [all] Error 1
gmake[2]: Leaving directory
`/export/home/local-src/fpc/fpcbuild-2.7.1/fpcsrc/packages'
gmake[1]: *** [packages_all] Error 2
gmake[1]: Leaving directory
`/export/home/local-src/fpc/fpcbuild-2.7.1/fpcsrc'
gmake: *** [build-stamp.sparc-solaris] Error 2
Have I missed any stages out: applied patch successfully, make
distclean, make all?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
michael.vancann...@wisa.be wrote:
On Mon, 16 Jul 2012, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
[Nod], understood. Hit a slight snag here with trunk FPC + trunk
Lazarus:
Target OS: Solaris for SPARC
Compiling sqldblaz.pas
Compiling registersqldb.pas
registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by
registersqldb
Fatal: Compilation aborted
make[2]: *** [sqldblaz.ppu] Error 1
make[2]: Leaving directory
`/export/home/local-share/lazarus-trunk/components/sqldb'
make[1]: *** [bigide] Error 2
make[1]: Leaving directory
`/export/home/local-share/lazarus-trunk/components'
make: *** [bigidecomponents] Error 2
-bash-3.00$ svn up
At revision 37922.
Anybody got any quick suggestions? "all" builds OK but I presume I
need "bigide" because I've used the TQuery etc. on the form.
Still getting this at FPC 21919 and Laz 37954: can anybody recommend a
quick hack as a workaround, or do I Mantis it?
I don't think Firebird works on Solaris or SPARC cpus, so it makes no sense
to compile in firebird support on that platform.
Remove the ibconnection unit or put it in an {$IFNDEF SOLARIS}. (or should
that be SUNOS ?)
You'll have to remove TIBConnection from the registercomponents call as
well.
If that works, we'll put it in the sources in SVN.
I think I see the problem: it looks as though somebody has left
TIBConnection registration right at the end in (Lazarus's)
RegisterUnitSQLdb without any conditional around it, possibly to avoid
working out the commas :-)
It might be easiest if somebody could get the unit back into FPC- I can
check it compiles immediately, and should be able to run it in anger
within a couple of weeks.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : Database problem on Solaris SPARC
michael.vancann...@wisa.be wrote: On a side note: My quoted paragraph doesn't mention FreeBSD, but I have successfully ran Firebird Server & clients under FreeBSD 9.0 on x86, and there are FreeBSD downloads on the Firebird website for 2.1.x and older. So just because the latest version doesn't contain a download for a specific OS+CPU, doesn't make it "not supported". Firebird rocks! :) That means we should compile & distribute IBase and ibconnection in FPC, because I think currently they are not. On a Solaris SPARC system, looking at /usr/local/lib/fpc, -bash-3.00$ find . -name ibconnection.ppu |sort ./2.4.2/units/sparc-solaris/fcl-db/ibconnection.ppu ./2.4.4/units/sparc-solaris/fcl-db/ibconnection.ppu ./2.6.0/units/sparc-solaris/fcl-db/ibconnection.ppu i.e. it's in 2.6.1 but isn't being built in 2.7.1 (trunk). I'm assuming that I need the latter because of code generator fixes that I know were applied. It would certainly be useful for me to have the /client/ stuff on as many platforms as possible, since I'm starting to look at a large distributed project which will primarily be using PostgreSQL as its backend but I also want the option of Firebird for "leaf" systems. Obviously the availability of the Firebird /server/ stuff is a completely different issue. I'd neither be surprised nor particularly sorry if that turned out to be x86-only. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Mark Morgan Lloyd wrote: [Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus: Target OS: Solaris for SPARC Compiling sqldblaz.pas Compiling registersqldb.pas registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by registersqldb Fatal: Compilation aborted make[2]: *** [sqldblaz.ppu] Error 1 make[2]: Leaving directory `/export/home/local-share/lazarus-trunk/components/sqldb' make[1]: *** [bigide] Error 2 make[1]: Leaving directory `/export/home/local-share/lazarus-trunk/components' make: *** [bigidecomponents] Error 2 -bash-3.00$ svn up At revision 37922. Anybody got any quick suggestions? "all" builds OK but I presume I need "bigide" because I've used the TQuery etc. on the form. Still getting this at FPC 21919 and Laz 37954: can anybody recommend a quick hack as a workaround, or do I Mantis it? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Ludo Brands wrote: We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry). I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)? No, the value is read from the server and depends on how the server was compiled. Run 'show integer_datetimes;' in psql or whatever client you are using to see the value. Pqconnection has detected that it is 'on' on your server. You can check with above command to see if the server agrees with that. Agreed, returns 'on'. With integer_datetimes on the datetime is returned as an int64 with the number of microseconds since 2000-01-01 00:00:00 UTC, hence the dbl^ := pint64(buffer)^/100; Dbl is a Pdouble, so the alignment problem could indeed come from there. The buffer returned by the driver is correct because just before you have pint64(buffer)^ := BEtoN(pint64(CurrBuff)^); CurrBuff being the pointer returned. Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem. [Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus: Target OS: Solaris for SPARC Compiling sqldblaz.pas Compiling registersqldb.pas registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by registersqldb Fatal: Compilation aborted make[2]: *** [sqldblaz.ppu] Error 1 make[2]: Leaving directory `/export/home/local-share/lazarus-trunk/components/sqldb' make[1]: *** [bigide] Error 2 make[1]: Leaving directory `/export/home/local-share/lazarus-trunk/components' make: *** [bigidecomponents] Error 2 -bash-3.00$ svn up At revision 37922. Anybody got any quick suggestions? "all" builds OK but I presume I need "bigide" because I've used the TQuery etc. on the form. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database problem on Solaris SPARC
Jonas Maebe wrote: Thomas Schatzl wrote on Thu, 12 Jul 2012: On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---) We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry). I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Thomas Schatzl wrote: Hi, On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: Ludo Brands wrote: Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a consistent error Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---) Although it's OK on Linux. However that pint64() could be relevant. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Ludo Brands wrote: I've found a problem when a (well-tested) program that connects to a PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux SPARC is OK. I appreciate that this is a minority platform, but would I be less unpopular reporting it against 2.6.0 or testing it against 2.7.1 first? Problem appears to be in pqconnection.pp and I can see that it's recently been worked on. AFAIK non of the recent changes in pqconnection.pp would affect solaris (alignment or other). So if the program compiled with 2.6.0 works fine on linux sparc and fails on solaris sparc I would suspect more the PostgreSQL client libraries. Are those the same versions? What problems are you experiencing? As background, program gets information from a table on a PostgreSQL server using 2x query objects in a thread. The current info is then copied to foreground LCL components using synchronise. I don't think any of this is relevant since it works reliably on Linux on all other architectures available to me, doesn't work on Windows for unrelated reasons (named pipe issue). Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a consistent error Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Current language: auto; currently pascal (gdb) bt #0 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLO #1 0x004b58c8 in TCUSTOMSQLQUERY__LOADFIELD (FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=false, this=0xf #2 0x004ef414 in TCUSTOMBUFDATASET__LOADBUFFER (BUFFER=0xfa5f00bc '', this=0xfceb96c0) at bufdataset.pas:1781 #3 0x004eeaec in TCUSTOMBUFDATASET__GETNEXTPACKET (this=0xfceb96c0) at bufdataset.pas:1665 #4 0x004edf4c in TCUSTOMBUFDATASET__GETRECORD (BUFFER=0xfa5f04a0 '', GETMODE=GMNEXT, DOCHECK=true, this=0xf #5 0x004c8278 in TDATASET__GETNEXTRECORD (this=0xfceb96c0) at dataset.inc:770 #6 0x004c8438 in TDATASET__GETNEXTRECORDS (this=0xfceb96c0) at dataset.inc:799 #7 0x004c9744 in TDATASET__RECALCBUFLISTSIZE (this=0xfceb96c0) at dataset.inc:1154 #8 0x004c6e14 in TDATASET__DOINTERNALOPEN (this=0xfceb96c0) at dataset.inc:411 #9 0x004c8cb0 in TDATASET__OPENCURSOR (INFOQUERY=false, this=0xfceb96c0) at dataset.inc:962 #10 0x004c92fc in TDATASET__SETACTIVE (VALUE=true, this=0xfceb96c0) at dataset.inc:1087 Those lines are truncated since I've C&Ped from a disconnected ssh session. Appears to be this on 2.6.0: dbl := pointer(buffer); if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; // 803 which I think is this on 2.7.1 although I've not tested yet: dbl := pointer(buffer); if FIntegerDatetimes then dbl^ := BEtoN(pint64(CurrBuff)^) / 100 // 856 else Also I've not tested recently on ARM Linux, but since SPARC Linux is OK it's unlikely to be a straight alignment error. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Database problem on Solaris SPARC
I've found a problem when a (well-tested) program that connects to a PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux SPARC is OK. I appreciate that this is a minority platform, but would I be less unpopular reporting it against 2.6.0 or testing it against 2.7.1 first? Problem appears to be in pqconnection.pp and I can see that it's recently been worked on. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] BUG:flush the serial in FPC2.6.0
kc87654321 wrote: I am trying to flush the serial incom on Linux with no success. So far I have: serial.pp in fpc 2.6.0 is SerFlush, which calls fpfsync, intended to discard input data, no work. it is patch as 0018946 but for fpc 2.4.2 no 2.6.0 http://free-pascal-general.1045716.n5.nabble.com/Unix-serial-port-handling-td3413763.html#a3415365 That patch should be good all the way to 2.7.1- I'm using it here as routine. SerFlush() was discussed in the list a few months ago, and the consensus was that it was probably inappropriate which is why I've marked it as deprecated. Try SerFlushInput() which goes straight to the operating system. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SIGTERM and thread
jmbottu wrote: Hello, I wrote a handler to intercept the SIGTERM signal and execute some processing before terminating the program. It works fine. But when i add the cthreads unit in the uses clause, the application seems to do a shutdown after the end of the handler function, and the processing before terminating the program can no longer run. What's in the handler? I usually just use it to set a variable, since the CPU context at the time of the signal is unclear (i.e. might not be safe to perform a GUI op, don't know which thread was running at the time, might already be inside a non-reentrant function, and so on). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How can a project determine if it's using cmem?
Mark Morgan Lloyd wrote: Tomas Hajny wrote: On Wed, July 4, 2012 11:32, Mark Morgan Lloyd wrote: When building a shared library, I'm putting a (function that returns a) magic number into both the library and the calling program. This returns an integer, and allows the program and library to check their exposed APIs without risk. How can code in the library test whether it is using cmem, so that it can tell the caller that it's safe to call functions that move strings and objects around? It's obviously trivial to rely on a compile-time conditional, but can this be done in a way that doesn't rely on this? First of all, you can easily check whether the default memory manager is used by calling IsMemoryManagerSet. Obviously, this doesn't tell whether the custom memory manager is cmem or something else (e.g. TraceManager from HeapTrace). However, you could possibly try to check the distance between the individual MemoryManager methods retrieved using GetMemoryManager - while that is not bulletproof by any means, it provides at least some indication. Finally, if there are certain major changes to features provided by individual memory managers (like some operation being safe or not), adding some TMemoryManager method allowing to provide this information may be the best solution for the future. Thanks Tomas (and Ludo). Under the circumstances I think IsMemoryManagerSet is probably an adequate solution, since the real risk is that somebody messes about with the start of the main unit (or with the project settings) without appreciating that the cmem import is crucial to operation elsewhere in the program (or, analogously, that a shared library will crash when some functions are called). Having something- e.g. an exported string- in cmem would be a partial solution, but would have to be checked in the main unit. With any solution, I think that testing that cmem was the first import could be a challenge. I've added a feature request as http://mantis.freepascal.org/view.php?id=22386 but am being told "First of all, you are wrong in thinking that using Cmem is a prerequisite to being able to use longstrings etc. as parameters and results..." Obviously I accept that there might be other suitable memory managers, but cmem is the one normally referred to. Far be it from me to argue with those more experienced than I, but the suggestion I'm trying to make is that it would be desirable if each module (i.e. every shared library plus the main program) could confirm that it's in a state where it can share e.g. longstrings, objects etc. with others. In common usage, that implies that cmem is not only imported, but is imported /first/. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] StackTop and StackBottom are bogus in a Win32/64 Dll
OBones wrote: Hello all, I'm writing Dlls here and am also doing low level analysis of the stack and its content. To do that, I use the StackTop and StackBottom global variables which used to work fine in an exe file. Problem is, when in a DLL, StackTop is always zero and StackBottom is the exact opposite of StackLength. I thus looked as to where this might come from, and discovered that it comes from the fact that StackTop is only ever calculated from within Exe_entry which obviously is not called for a DLL. Is anyone else seeing this? I've not got into that level of detail, but I've noted that in Linux (and possibly Solaris) you have to turn off stack checking when generating a shared library (otherwise when the main program calls into the library it's unhappy) but not in the main program (i.e. the library can call into the main program and is always happy) which I think is consistent with what you're saying. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How can a project determine if it's using cmem?
Tomas Hajny wrote: On Wed, July 4, 2012 11:32, Mark Morgan Lloyd wrote: When building a shared library, I'm putting a (function that returns a) magic number into both the library and the calling program. This returns an integer, and allows the program and library to check their exposed APIs without risk. How can code in the library test whether it is using cmem, so that it can tell the caller that it's safe to call functions that move strings and objects around? It's obviously trivial to rely on a compile-time conditional, but can this be done in a way that doesn't rely on this? First of all, you can easily check whether the default memory manager is used by calling IsMemoryManagerSet. Obviously, this doesn't tell whether the custom memory manager is cmem or something else (e.g. TraceManager from HeapTrace). However, you could possibly try to check the distance between the individual MemoryManager methods retrieved using GetMemoryManager - while that is not bulletproof by any means, it provides at least some indication. Finally, if there are certain major changes to features provided by individual memory managers (like some operation being safe or not), adding some TMemoryManager method allowing to provide this information may be the best solution for the future. Thanks Tomas (and Ludo). Under the circumstances I think IsMemoryManagerSet is probably an adequate solution, since the real risk is that somebody messes about with the start of the main unit (or with the project settings) without appreciating that the cmem import is crucial to operation elsewhere in the program (or, analogously, that a shared library will crash when some functions are called). Having something- e.g. an exported string- in cmem would be a partial solution, but would have to be checked in the main unit. With any solution, I think that testing that cmem was the first import could be a challenge. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How can a project determine if it's using cmem?
When building a shared library, I'm putting a (function that returns a)
magic number into both the library and the calling program. This returns
an integer, and allows the program and library to check their exposed
APIs without risk.
How can code in the library test whether it is using cmem, so that it
can tell the caller that it's safe to call functions that move strings
and objects around? It's obviously trivial to rely on a compile-time
conditional, but can this be done in a way that doesn't rely on this?
If I define USE_CMEM in the project and then in the main unit have
uses
{$ifdef USE_CMEM }
cmem, {$ifdef USE_HEAPTRC } HeapTrc, {$endif } ...
{$endif }
then this always errors
{$if not defined(cmem) }
{$error Not using cmem }
{$endif }
and this fails to compile saying the . is illegal
{$if not defined(cmem.malloc) }
{$error Not using cmem }
{$endif }
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Apologies for my poor threading. Sven said: > Unix based systems might be a different topic altogether. I've no > experience regarding cross module excetions on *nix, so I can't > comment whether it works or not... > Summa summarum: don't let exceptions travel past the DLL boundary. One > might be able to fix it on Windows, but *nix maybe not so much... Forcing an integer divide-by-zero error in a routine in a .so on i386 Linux, with an exception handler in the main program, I get a floating point error reported in the shell session. So it's definitely not trapped, and might be mis-reported. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Mark Morgan Lloyd wrote: >> Can such an alternative entry point in the main unit be called by >> a shared library, i.e. either resolved at load time or with the main >> binary reopened like a library? Or is the only way to pass a main- >> program entry point to a shared library by using it as a parameter >> to a procedure? > I can't tell you for *nix systems as I'm not experienced enough > regarding their dynamic linkers, Superficial testing suggests that if the code in a .so (Linux, i386) tries to call an "extra" entry point exported from the main program, that a run-time (libdl) load of the library will fail. I'll keep on tinkering with this, I've not yet retrieved the exact error message and I'm interested in seeing what happens if the .so itself tries to use libdl to reopen the main program. Short answer: works on Linux, but at run- (not load-time) only. Longer answer: if a .so has an explicit dependency on the main program, i.e. a procedure marked extern, an attempt to load it using dlopen(...RTLDLAZY) will fail (return zero as a handle). The error message refers to an entry point of the form library_proc_types rather than program_proc_types, and I've not managed to override that using extern or extern/name in a way that makes everything happy. Using LoadLibrary() -> dlopen() inside the .so, passing an *empty* string representing the main program, appears to allow exported entry points to be accessed (i.e. a shared library can access a procedure in the main program in exactly the same way that a main program can access a procedure in a shared library). One thing that would be useful would be if DynLibs had a "get last error" function. I've implemented this myself for Linux and Windows and find it indispensable. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
>> Can such an alternative entry point in the main unit be called by >> a shared library, i.e. either resolved at load time or with the main >> binary reopened like a library? Or is the only way to pass a main- >> program entry point to a shared library by using it as a parameter >> to a procedure? > I can't tell you for *nix systems as I'm not experienced enough > regarding their dynamic linkers, Superficial testing suggests that if the code in a .so (Linux, i386) tries to call an "extra" entry point exported from the main program, that a run-time (libdl) load of the library will fail. I'll keep on tinkering with this, I've not yet retrieved the exact error message and I'm interested in seeing what happens if the .so itself tries to use libdl to reopen the main program. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Apologies for my lousy message threading, but some are vanishing in the spamtrap. >> OK, so to emphasise that: library B's data will be common, >> irrespective of the location of the calling routine. Does this >> apply if the load is being done at runtime, i.e. the program is >> using dl (or whatever) to load A and B, and A also uses dl to >> load B? > > It does not matter whether the library is loaded at program start > or at runtime. It's always the same mechanism with the exception > that in the first case your main function has not yet been called > (which normally doesn't matter either). Just being cautious :-) One final question if I may: noting Ludo's example elsewhere: > In the project.lpr add the following code: > > Procedure qt_startup_hook;export; > Begin > End; > > Exports qt_startup_hook; Can such an alternative entry point in the main unit be called by a shared library, i.e. either resolved at load time or with the main binary reopened like a library? Or is the only way to pass a main-program entry point to a shared library by using it as a parameter to a procedure? I've used such things in a Windows-style .exe so a loader/binder would know how to generate absolute code for an embedded system, but have never tried exploiting it with a "real" OS. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Mark Morgan Lloyd wrote: I'm currently tinkering with shared libraries, using cmem, mainly on Linux. In one case the main-program code is multithreaded, but so far I'm not moving data between threads inside the library. Am I correct in believing that unit-level variables in a shared library might end up being shared between multiple instances of the library, or are they guaranteed to be distinct? If my belief is correct, I presume that I could get around this by using threadvars. But in this case, how would I best implement a variable that I wanted to be common across related threads (e.g. to track the number of a particular object being allocated/deallocated), but distinct across program invocations (i.e. two programs using the same shared library wouldn't clash)? The discussion of libraries in ch16 of the Language reference guide is rather quiet on the semantics. > > A programs memory always belongs to itself (exceptions through mmap or > kernel related thing excluded) and libraries are loaded into the > program's memory. Their code sections might only exist once if the OS > detects that it had already loaded the library somewhere, but it's > data sections and also the memory it allocates during its lifetime > belong to the program's memory. Thanks Sven. So to summarise: code might be shared, but this generally won't be relevant since it should be read-only. Data- local or global- won't be shared. > This means for you: normal global variables in your library are not > shared with other "instances" of this library (note: if a program > loads library A and B and library A also loads B then there is only > one "instance" of the library and its data). They are shared by all > threads that use this library though. Having variables shared between > different "instances" of a library is a different topic altogether. OK, so to emphasise that: library B's data will be common, irrespective of the location of the calling routine. Does this apply if the load is being done at runtime, i.e. the program is using dl (or whatever) to load A and B, and A also uses dl to load B? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Shared libraries and threadvars
I'm currently tinkering with shared libraries, using cmem, mainly on Linux. In one case the main-program code is multithreaded, but so far I'm not moving data between threads inside the library. Am I correct in believing that unit-level variables in a shared library might end up being shared between multiple instances of the library, or are they guaranteed to be distinct? If my belief is correct, I presume that I could get around this by using threadvars. But in this case, how would I best implement a variable that I wanted to be common across related threads (e.g. to track the number of a particular object being allocated/deallocated), but distinct across program invocations (i.e. two programs using the same shared library wouldn't clash)? The discussion of libraries in ch16 of the Language reference guide is rather quiet on the semantics. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings and objects crossing dll boundaries
kyan wrote: Hello all, A couple of questions regarding handling of strings, dynamic arrays and objects -especially exceptions- when writing programs that use shared libraries (.dll, .so). This seems to be a hot topic at the moment. In Delphi we have the option of either using packages to ensure that there is only one instance of the memory allocator or use ShareMem.pas that installs a memory allocator that can handle memory allocations across libraries. Given that in FPC/Lazarus there are no "packages" in the Delphi sense what is the equivalent of ShareMem.pas? Is it cmem.pp? Yes. A reference to cmem should appear as the first entry in the uses statement of earliest-executed unit, i.e. assuming Lazarus this is the .lpr file. If using heaptrc this has to be put as the next entry, FPC's -gh won't work, but I don't know to what extent having heaptrc in both the main program and the library is workable (and various people are currently mentioning heaptrc problems possibly caused by inadvertent optimisation). Regarding objects, in Delphi an object cannot safely cross dll boundaries because separate class record(s) for it exist in each executable file. OK, actually it can if one is certain that the class records compiled in each executable are identical. Agreed. However I'd suggest better terminology would be something like "cannot safely be referenced across", simply saying "crossing" is too evocative of "crossing a 64K boundary" for us old-timers :-) Having said that, I'm successfully referencing (non-short) strings across the divide, doing a deep-copy of TMenuItems from a form designed in the shared library (which is there purely as a placeholder for menu entries, and executing click events associated with menu items (which work because they get a sender when invoked). I'm moving onto more complex stuff shortly /but/ due to design requirements will be handling this by passing parseable text commands, i.e. the backend can tell the frontend to change the UI state (without full knowledge of the current state) and the frontend can tell the backend to change state (with the same limitation). But if an exception crosses dll boundaries then you are in trouble, because the operator "is" does not work due to the class pointer that points to another Exception class record than the one known by the handling executable. Generally agreed. The best way to solve this is to put the class Exception at least inside a package that all executables use so at least "is" will work for Exception. Is there a way to handle this problem in FPC that does not have packages? Not knowing, can't say. Looking at the larger picture, I don't know how one best debugs operation as control is transferred from the main program into the shared library, bearing in mind that this might be important since the library might have all the tricky code. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing open array
Koenraad Lelong wrote:
Hi,
Im trying to access an open array but I get a runtime error. I googled a
bit, and found some suggestions, but for me they don't work.
It's actually a port of some C-library I want to use on a STM32-processor.
This is my test-code :
program LCDtest1;
type
TArray = array of byte;
var
nCols : cardinal;
nRows : cardinal;
nBytes : cardinal;
pFont : ^TArray;
{$include fonts.inc}
begin
// get pointer to the beginning of the selected font table
pFont:=@FONT6x8;
writeln('0');
setlength(pFont^,8); <-- here it crashes
I didn't have the setlength at first, then it crashed at the first
access of the array (ncols:=...).
The include file contains this (only partly shown) :
originally :
const
FONT6x8 : array[0..96] of array[0..7] of byte = (
Assuming that in your current implementation FONT6x8 is a table at an
absolute location in memory... I don't think you can do that, since a
dynamic array (which I think is what you're trying to use) is nowt but a
descriptor block which contains a pointer into the heap. Try something like
typeTFONT6x8= array[0..96] of array[0..7] of byte;
PFONT6x8= ^TFONT6x8;
var fontTable: PFONT6x8;
Force your absolute address into fontTable, then dereference to get at
the content.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Default value for an open array
kyan wrote:
However, given a declaration of that form, is it possible to define a
default parameter of [] so that OutputWriteF('Test, no params\n') is
valid?
Not for open arrays, but you can write an overloaded version without
the open array argument that calls the version with the open array
parameter passing an empty array, or an array initialised with
whatever "default" values you want:
Thanks, good point and adequate workaround.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Default value for an open array
It's previously been pointed out to me that a declaration such as
procedure OutputWriteF(const str: widestring; values: array of
const; fg: TColor= clBlack; bg: TColor= clDefault);
can't be rewritten
type owfArray: array of const;
procedure OutputWriteF(const str: widestring; values: owfArray; fg:
TColor= clBlack; bg: TColor= clDefault);
since this would make the parameter into a dynamic rather than an open
array. I'm entirely happy to accept that now that I understand it.
However, given a declaration of that form, is it possible to define a
default parameter of [] so that OutputWriteF('Test, no params\n') is
valid?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Parameters to Format()
Michael Van Canneyt wrote: On Fri, 25 May 2012, Mark Morgan Lloyd wrote: How should I put this? procedure TUnyokedFrontendForm.OutputWriteF(const str: widestring; values: array of variant; fg: TColor= clBlack; bg: TColor= clDefault); var scratch: widestring; begin scratch := Format(str, values); As above, I get unyokedfrontendcode.pas(354,32) Error: Incompatible type for arg no. 2: Got "Open Array Of Variant", expected "Array Of Const" I was caught by this one years ago, and at the time the Delphi developers I was in contact with had no easy solution. That's because there is no easy solution. Format uses a different array type, they are not variants. You'll have to convert the arrays. Roughly translated: "look at the documentation and use the right parameter type" :-) Thanks, now working. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Parameters to Format()
How should I put this? procedure TUnyokedFrontendForm.OutputWriteF(const str: widestring; values: array of variant; fg: TColor= clBlack; bg: TColor= clDefault); var scratch: widestring; begin scratch := Format(str, values); As above, I get unyokedfrontendcode.pas(354,32) Error: Incompatible type for arg no. 2: Got "Open Array Of Variant", expected "Array Of Const" I was caught by this one years ago, and at the time the Delphi developers I was in contact with had no easy solution. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: 2.6.0 for Solaris? And other questions [one resolved]
microc...@zoho.com wrote: On Tue, 22 May 2012 10:29:28 +0200 Sven Barth wrote: This might be, because you compiled it without a libgdb which in turn is the one who links dynamically to libc. Most FPC applications (if they don't use threads or a WideString manager) don't require libc and thus don't need to link to it (which AFAIK is also the case for the IDE if it doesn't link to libgdb). That's a good explanation, thank you. I would like to have the debugger support. That will require that you can find a precompiled libgdb- preferably a version that's already supported by the options in gdbint.pp. Or build one from source (which I've done on several systems). I've just checked my SPARC Solaris 10 and I've not gone to the trouble: fp was built without gdblib. I'm planning to go through the build again a few times for various reasons including I want to get a current copy on Solaris SPARC. I didn't get (all) the units built and there are some other minor annoyances in the way it worked out (no symlink from fpc to the ppcx module) and if it doesn't go like you said I'll post back to the list. You normally have to set up the ppc symlink manually, irrespective or platform. I usually use two stages, e.g. ppcsparc -> ppcsparc-2.4.4 and ppcsparc-2.4.4 -> /usr/local/lib/fpc/2.4.4/ppcsparc, and in cases where I'm e.g. running Lazarus I tell it to use the "one in the middle" i.e. ppcsparc-2.4.4. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Linux sound (especially MIDI) programming: ALSA?
Mark Morgan Lloyd wrote: leledumbo wrote: http://sourceforge.net/projects/fpalsa/ http://sourceforge.net/projects/humus/ Thanks for those. Also http://perso.wanadoo.es/plcl/alsapas/alsapas-en.html so as I thought there appears to be (at least) two sets of ALSA bindings: fpalsa and alsapas. Noted HuMuS, but that appears to be for PortAudio. However using that as a seed I get to http://breakoutbox.de/pascal/pascal.html#PortAudio which claims to include PortMidi support- this is supposedly cross-platform but requires an additional library which might not be available on all distreaux. Also MIDI is very much the "poor cousin" and operating support is patchy, so since I've got ALSA working I'm reluctant to risk breaking anything. Since running on anything other than Linux is not a significant priority, I think I'll probably start off with by doing a comparison of fpalsa and alsapas, and writing code that will support either if possible. If I could also code to support PortMidi that would be a bonus, but by no means essential: I'm trying to knock together a MIDI transposer for my own use, and testbed some techniques for another project. To wrap this up, alsapas is a translation of the ALSA headers etc. as of v0.9.7, and fpalsa is similar but corresponds to the slightly later v1.0.24. They have a slightly different style in that alsapas uses variable parameters while fpalsa uses pointers to be a bit closer to the original (and possibly to allow null parameters); alsapas is attractive in that it's got useful examples. As far as MIDI is concerned, alsapas still works but there's a handful of parameters named "out" that are no longer compatible with FPC, I've followed the author's convention and renamed those to _out; basic operation appears OK on Debian "Squeeze" x86 with a 3.2 kernel. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Parsing parameters inside an interpreter
luciano de souza wrote:
Hello all,
I trying to build a very small interpreter. I can type commands like:
$ add "Luciano de Souza" luchya...@gmail.com
Somewhere in my code, I can have something like:
procedure parse(commandline: string; var params: array of string);
In this case, the commandline has the format: "add %s %s". So I would obtain:
parse('add "Luciano de Souza" luchya...@gmail.com', params);
After this command, the parameter would have the following values:
params[0] := 'add';
params[1] := 'Luciano de Souza';
params[2] := 'luchya...@gmail.com';
My question is: there is a way to do it easily using a standard class
of Freepascal?
I'd suggest that this depends on two things: the first is whether input
is guaranteed to be on a single line, if it is (or if multiple lines
could be merged) then you could use something like the standard regular
expression unit.
The second is the complexity of your quoting and escaping, and also
whether you want to handle Unicode. If you only allow (say) " and
restrict it to a single depth, or if you could do an initial rewrite to
change nested quotes into something innocuous such as #$ff, then things
are comparatively simple.
In other cases use something like recursive descent, or investigate
(p)yacc, (p)lex etc.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC and (minimal) telnet
I'm using the ltelnet unit to good effect in a special-purpose terminal emulator which doesn't merit e.g. Synapse, although since it's not part of the the fcl I'm having to build it specially. I find that if I try to use it to connect to the Hercules mainframe emulator it fails since the terminal type subcommand is not supported. If anybody else is using it (or if Ales is reading this) I'd be interested in any suggestions as to how best to add this facility (i.e. hardcoded internally, subcommands passed to a callback, etc.). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: 2.6.0 for Solaris?
microc...@zoho.com wrote: On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote: On Thu, May 10, 2012 13:22, microcode wrote: Sun makes awfully nice boxes and Solaris is a very nice development platform. I hope the guys will keep FPC going on Solaris. There are many Solaris 10 on Sun fans. FPC support of individual platforms depends on availability of volunteers interested and capable of supporting these platforms. FPC can target really many platforms nowadays, but this increasing number cannot be supported with constant number of developers. Someone from the Sun fans has to step in, otherwise the support cannot be guaranteed in the long term. Yeah, that's obvious. I'm sure anybody who was capable would help. All I can offer at this point is development systems but that doesn't seem to be the problem. How much platform dependent code is there? I would think if the main product works on i386 or AMD64 for example then there isn't much to do except build on the other targets? Is it a matter of not having developers for the specific platform or not having anybody to build it for a specific platform? You might find the fpc-devel mailing list interesting, although I think that everybody would admit that there is a shortage of documentation for the entrails of the compiler. You might also find looking at the fpcsrc/compiler and fpcsrc/rtl trees in the source interesting, noting in particular the way that the latter at least /attempts/ to separate OS- and CPU-specific code. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: 2.6.0 for Solaris? And other questions
Sven Barth wrote: Am 09.05.2012 20:19, schrieb microc...@zoho.com: There are no binaries provided by my distribution. It's Slackware! But the question was, was it really necessary to use such a recent glibc? It's a matter of what the libc version happens to be on the system that was used to build libgdb, which is simply someone's personal machine. Ok, but if that is what happened I would expect a lot of people not to be able to run fp except maybe Fedora 16 or Gentoo users who always have the latest stuff. I guess I am wrong though or you would already know about it. Maybe it would be better to build on a non-bleeding edge system so people with older distros and pieces could still run everything? I very seldom upgrade but maybe everybody else does. I try to find a good working setup and then don't change it much. That's kind of why I was asking about 2.6.0 since it is the current release. I was planning on staying on that until I had a really good reason not to. The text mode IDE "fp" is not used that much on Unix based systems thus such problems regarding to recent/old libraries are not detected that easily. On other systems like OS/2 (where "fp" is used more often) and Windows there aren't such dependency problems. Most users use a graphical IDE like Lazarus: http://www.lazarus.freepascal.org/ I agree. I harboured illusions at one point about being able to work out how fp was put together and tracking down some of the issues (mostly related to debugging, i.e. libgdb) but in practice I've gone with the flow and started using Lazarus. Having said which, I think I've got fp running on all the systems here (with the possible exception of Solaris 8), and I've got libgdb running with all of those (with the exception of ARM Linux). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: 2.6.0 for Solaris? And other questions
microc...@zoho.com wrote: I screwed up the quoting here, sorry. Jeff didn't write all below, I think some of it was Mark. On Wed, 09 May 2012 18:01:43 -0400 Jeff Wormsley wrote: And what, pray, is wrong with Slackware? :-) Nothing :-) Once you Slack you never go back! Most of the SPARC systems around here are Debian (plus one each of Solaris 8 and 10), but I've got Slackware 12 IIRC on an E4500 since the Debian installer wouldn't work. Good machine for testing multithreaded stuff on account of the number of CPUs. Hah! I didn't even think of that. I've been thinking it would be nice to have a SPARC port of Slackware but it hasn't been maintained. How many sockets do you have on your E4500? 12, i.e. space for an I/O card and internal discs for booting. I prefer the SS1000 architecture, where each of the eight cards is identical so you can have 16x CPUs plus full I/O... in addition being a Xerox PARC design it has a certain pedigree ;-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: 2.6.0 for Solaris?
microc...@zoho.com wrote: On Wed, 09 May 2012 18:18:59 + Mark Morgan Lloyd wrote: My main role is being a thorn in the side of the core developers when something stops working :-) However I've previously offered to host a (not very fast) system here for compilation etc., and the offer stands. What SPARC box(es) do you have? I may be able to host Solaris development systems if needed although the SPARC stuff would have to be scheduled since I cannot leave them on all the time because of the huge noise and heat factor. The Intel box is on most of the time. I've got a range here: mostly U60 running "in anger", a U80, E4500, U10s, a U1, plus some museum pieces I can't find an OS for. I'm also one of very few people who've got an SS1000E running Linux SMP, but that's not a recent distro and because of library versions (**) I'm not sure what if any version of FPC I could get running on it. ** When a program is built, the (Linux) linker puts the actual filenames of the .so files it expects to find in the binary- not the names of any symlinks. That means that once you've built a binary using standard parameters, that binary /requires/ the same collection of .so versions that was on the development system... I managed to get around that to backport FPC from Solaris 10 to 8 but in general I think it's better to start off with a version that runs and work forwards. I wholeheartedly agree that power, and in the Summer heat, is a massive problem. There's only so much we can afford, and even with substantial air conditioning things can get pretty unpleasant in my workroom and the adjacent machineroom. That's why I'm only able to offer U10s as always-up systems, Vincent used one of those for Lazarus two or three years ago and I've tried to test both FPC and Lazarus on Linux and Solaris fairly regularly since. His point was that Slackware has a far more limited range of binaries and libraries than do more popular distreaux such as Debian/Ubuntu, but it has its uses. Right you are. Anyway, the particular glibc version was probably selected by the ld linker when compiling the binaries on the builder's machine. I'll check 2.7.1 on SPARC Solaris 8, 10 and Slackware 12 over the next few days. I don't anticipate any problems, and in the interest of getting the OP (who hasn't provided us with a more genteel handle) going I could mail or FTP him tarballs as appropriate. If 2.6.0 is ok for Linux that is good enough for me as far as Slackware goes. I may try to rebuild against my glibc or just forget about it on Linux and concentrate on Solaris since I prefer to work on Solaris anyway. I appreciate your offer for packages but since you or somebody else has already pointed me to the buildfaq, I'll try this on my own and when I get stuck I'll email the list again. Thanks again for all the help. You might find it useful to go to the Mantis bug tracker and look at the SPARC-related bugs I've reported- use "View Issues", expand "Search", select "Mark Morgan Lloyd" from "Reporter" then "Use Filter". You might in particular need http://mantis.freepascal.org/view.php?id=18271 when getting your initial FPC binary installed on Solaris 10. When you get to compiling, you might find it necessary to use a command line like this: make NOGDB=1 OPT='-O- -gl' What that does is tell it to not try to use the optional libgdb in the fp text-mode IDE, and it disables optimisation in the compiler binary (/not/ the compiler's ability to apply optimisation) so that if something goes wrong you can get a useful backtrace. On Debian, you'll need [checks] build-essential, gdb, libgpmg1-dev, and some combination of libncurses5-dev and libncursesw5-dev. If you get as far as building Lazarus use trunk (on SPARC) and treat libgtk2.0-dev and possibly libqt4pas-dev as prerequisites, if those aren't available (e.g. on Slackware) I suggest we continue on the Lazarus mailing list. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Re: 2.6.0 for Solaris?
Ludo Brands wrote: Your question, as given unambiguously in the subject line, relates to 2.6.0. I'm telling you, equally unambiguously, that you don't want to do that. You might need to start off with an older binary to get yourself going, or you might be able to get hold of a binary for 2.6.0, but having done that, in the case of SPARC, you want to get onto 2.7.1 rather than relying on 2.6.0's correctness. I have no particular need for 2.6.0, I just normally try to get the stable release of whatever new thing I decide to try out and I understood from the website 2.6.0 is the one I should use. You are, of course, free to ignore my advice. In any case, 2.6.0 is needed now to build 2.7.1. Just rebuild 2.7.1 from today on Solaris 10 Intel and it failed miserably with 2.4.4. That worked a few months ago and the 2.7.1 then build doesn't build todays 2.7.1 neither. Only 2.6.0 builds 2.7.1 correctly. But I fully agree: don't do more on Solaris with 2.6.0 than building 2.7.1. One thing I would stress for the OP's benefit: SPARC 2.6.0 was entirely able to build itself and Lazarus. It's only when I tried mixing database access and some heavy floating-point astronomical calculations that the problems became apparent. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: 2.6.0 for Solaris?
microc...@zoho.com wrote: On Wed, 09 May 2012 16:10:06 + Mark Morgan Lloyd wrote: There is a directory for Solaris SPARC but it is empty. Is it possible to get 2.6.0 for Solaris SPARC? Thanks again. I've got a copy that I've built and run here, but I started off with an earlier version and had to jump through a few hoops to get it installed. I strongly recommend using 2.6 as an interim release on SPARC, since there were code-generation bugs that weren't fixed until a few months ago- the fixes are in 2.7.1 but haven't been backported. I am not sure I understood your message. 2.6.0 SPARC isn't available for download, but you suggest it as an interim release because of fixes in an upcoming release that probably won't be backported. So I guess you mean even if I could get 2.6.0 built I should realize when 2.7.something comes out that's the version I should use? If so, no problem. I will go over the buildfaq suggested earlier and see what I can do, possibly with the 2.7.1 you mentioned. Your question, as given unambiguously in the subject line, relates to 2.6.0. I'm telling you, equally unambiguously, that you don't want to do that. You might need to start off with an older binary to get yourself going, or you might be able to get hold of a binary for 2.6.0, but having done that, in the case of SPARC, you want to get onto 2.7.1 rather than relying on 2.6.0's correctness. I have no particular need for 2.6.0, I just normally try to get the stable release of whatever new thing I decide to try out and I understood from the website 2.6.0 is the one I should use. You are, of course, free to ignore my advice. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Subject: Re: 2.6.0 for Solaris? And other questions
Tomas Hajny wrote: On Wed, May 9, 2012 18:26, microc...@zoho.com wrote: From: "Tomas Hajny" Do you guys plan on releasing the 2.6.0 version on Solaris and is there a timeframe? Do you plan on continuing to support Solaris? I would be interested in running both the Intel and SPARC versions if they come available. I'm not the right one to answer this question but I believe that this depends mainly on availability of a maintainer for this operating system. You may try building the compiler (and RTL) for that platform and it may work well for you, but you may encounter some issues. I didn't find a list of maintainers on the home page and I don't know how Free Pascal development is organized. Hopefully the maintainer will speak up and in the meantime I will look at the build guide you mentioned further on. My point was that there has been no official / dedicated maintainer for that platform within the core team recently which is the reason why there are no official builds for Solaris for version 2.6.0. Mark Morgan Lloyd who already responded to your e-mail probably has the most experience with these targets at the moment. My main role is being a thorn in the side of the core developers when something stops working :-) However I've previously offered to host a (not very fast) system here for compilation etc., and the offer stands. Another question is on 2.6.0 on Linux. I cannot run the fp ide because I have glibc 2.9. The error message I get says fp: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by fp) That is really a recent version! Even the latest Slackware from 1 year ago only has glibc 2.13. Is this really needed or can it be built against my version of glibc? It should be possible to build against your version of glibc, but you'll probably have to do it yourself (or use FPC binaries provided by your distribution). There are no binaries provided by my distribution. It's Slackware! But the question was, was it really necessary to use such a recent glibc? I'm not sure what's the supposed meaning of "It's Slackware!" in your e-mail. We do not actively track which Linux distributions support FPC directly. His point was that Slackware has a far more limited range of binaries and libraries than do more popular distreaux such as Debian/Ubuntu, but it has its uses. Anyway, the particular glibc version was probably selected by the ld linker when compiling the binaries on the builder's machine. I'll check 2.7.1 on SPARC Solaris 8, 10 and Slackware 12 over the next few days. I don't anticipate any problems, and in the interest of getting the OP (who hasn't provided us with a more genteel handle) going I could mail or FTP him tarballs as appropriate. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Subject: Re: 2.6.0 for Solaris? And other questions
microc...@zoho.com wrote: There are no binaries provided by my distribution. It's Slackware! But the question was, was it really necessary to use such a recent glibc? And what, pray, is wrong with Slackware? :-) Most of the SPARC systems around here are Debian (plus one each of Solaris 8 and 10), but I've got Slackware 12 IIRC on an E4500 since the Debian installer wouldn't work. Good machine for testing multithreaded stuff on account of the number of CPUs. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] 2.6.0 for Solaris?
microc...@zoho.com wrote: On Wed, 9 May 2012 17:19:59 +0200 "Ludo Brands" wrote: Hi, I was looking to try FPC but I saw the latest release isn't available for Solaris, only 2.4something. Do you guys plan on releasing the new version on Solaris? Do you intend to keep supporting Solaris? 2.6.0 is available for intel from ftp://ftp.freepascal.org/pub/fpc/dist/2.6.0/i386-solaris/fpc-2.6.0.i386-sola ris.tar.gz and ftp://ftp.freepascal.org/pub/fpc/dist/2.6.0/x86_64-solaris/fpc-2.6.0.x86_64- solaris.tar.gz Ludo There is a directory for Solaris SPARC but it is empty. Is it possible to get 2.6.0 for Solaris SPARC? Thanks again. I've got a copy that I've built and run here, but I started off with an earlier version and had to jump through a few hoops to get it installed. I strongly recommend using 2.6 as an interim release on SPARC, since there were code-generation bugs that weren't fixed until a few months ago- the fixes are in 2.7.1 but haven't been backported. Having said that, 2.7.1 plus the trunk version of Lazarus work fine together for basic projects (there's things I don't routinely test, like database access). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Linux sound (especially MIDI) programming: ALSA?
leledumbo wrote: http://sourceforge.net/projects/fpalsa/ http://sourceforge.net/projects/humus/ Thanks for those. Also http://perso.wanadoo.es/plcl/alsapas/alsapas-en.html so as I thought there appears to be (at least) two sets of ALSA bindings: fpalsa and alsapas. Noted HuMuS, but that appears to be for PortAudio. However using that as a seed I get to http://breakoutbox.de/pascal/pascal.html#PortAudio which claims to include PortMidi support- this is supposedly cross-platform but requires an additional library which might not be available on all distreaux. Also MIDI is very much the "poor cousin" and operating support is patchy, so since I've got ALSA working I'm reluctant to risk breaking anything. Since running on anything other than Linux is not a significant priority, I think I'll probably start off with by doing a comparison of fpalsa and alsapas, and writing code that will support either if possible. If I could also code to support PortMidi that would be a bonus, but by no means essential: I'm trying to knock together a MIDI transposer for my own use, and testbed some techniques for another project. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linux sound (especially MIDI) programming: ALSA?
Wimpie Nortje wrote: On 2012/05/06 05:49 PM, Mark Morgan Lloyd wrote: Wimpie Nortje wrote: I have used ALSA to record sound. It was some time ago, I think on Kubuntu 10.04 or so. I can send you some code I used but I have no idea whether it will work under newer Linux's Thanks, but since it's specifically MIDI I'm interested in it might not be relevant. Can you remember which Pascal interface to the ALSA libraries you were using? I think I've seen two, but I've not yet checked to see whether they were actually minor variants of the same thing. The readme file says: ALSAPAS (ALSA library for Pascal) Version 0.9.7, September 2003. Copyright (c) 2002-2003, Pedro Lopez-Cabanillas Hence http://perso.wanadoo.es/plcl/alsapas/alsapas-en.html -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linux sound (especially MIDI) programming: ALSA?
Wimpie Nortje wrote: I have used ALSA to record sound. It was some time ago, I think on Kubuntu 10.04 or so. I can send you some code I used but I have no idea whether it will work under newer Linux's Thanks, but since it's specifically MIDI I'm interested in it might not be relevant. Can you remember which Pascal interface to the ALSA libraries you were using? I think I've seen two, but I've not yet checked to see whether they were actually minor variants of the same thing. On 2012/05/06 10:09 AM, Mark Morgan Lloyd wrote: Has anybody used FPC to control ALSA on Linux? I need to filter a MIDI stream in real time, and handle transposition etc. If anybody knows of useful resources I'd appreciate any hints. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linux sound (especially MIDI) programming: ALSA?
Has anybody used FPC to control ALSA on Linux? I need to filter a MIDI stream in real time, and handle transposition etc. If anybody knows of useful resources I'd appreciate any hints. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reversing bit-order of byte
Koenraad Lelong wrote: Hi, I'm porting a driver, originally written in C, for an LCD to be used with an embedded arm-processor (STM32). The original driver uses SPI, my driver will use a USART in synchronous mode because the STM32 has no SPI for 9-bit. Unfortunately, the bit-order is reversed between SPI and USART transmission. Does anyone knows an efficient way to reverse bit-order of a byte for the arm-processor ? I'm going to look into the assembly language of the arm-processor, but maybe someone knows this immediately. For old processors like 8085 or Z80 I know how to do this, but arm-assembler is new to me. I think I'd use a lookup table (making sure it's cacheable), particularly since what you're doing is going to be called frequently and you're likely to have much more than 64K memory. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Jonas Maebe wrote: On 29 Apr 2012, at 14:23, Jorge Aldo G. de F. Junior wrote: What would be usefull is to move the loads of code stored in sysutils/runtime into a dll/so. That's mainly useful if the external API of the RTL will ever stabilize, which is certainly not the case today. Otherwise you create a dynamic library hell. I had to download somebody's archive viewer a few weeks ago: first there was his binary, then there were his custom DLLs, then there was the MS runtime. I think it came to about 100Mb in total, which made the equivalent written using Lazarus look pretty good- once we'd thrashed out some smartlinking issues. However there's a definite acceptance problem: in the past I've talked to people who insisted in programming in C "because the customer might be bothered about what language we use". Since ABIs (i.e. calling conventions etc.) have settled down a lot since those days it should, in theory, no longer be an issue: but I suspect that many old prejudices remain. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Testing existence of a file at compilation time
Is it possible to test for the existence of a file, directory or package
at compilation time, i.e. {$if exists() or similar?
The specific scenario I'm looking at is where I want to publish a couple
of projects on Berlios, and the functionality will differ depending on
whether a particular (Lazarus) package is available: as an example,
character-by-character (not syntax-defined) colouring which I don't
think I can do in any standard text-output controls. If at compilation
time it was possible to detect that a package was available, it would
then be possible to enable the code that at runtime created a graphical
component from that package without any intervention on the part of the
user building the app.
I've just checked the 2.6.0 manuals: where are things like {$if
declared() defined?
I note that the FPC documentation pointed to at
http://wiki.lazarus.freepascal.org/Lazarus_Documentation#Free_Pascal_Compiler_Documentation
is still 2.2.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sending break on (Windows) serial comms
Mark Morgan Lloyd wrote: Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Marco, I see you had a StackOverflow question on this a year or so ago. Did you ever get anywhere with it in practice? It was an idea to lower the overhead and improve the reliability of our serial protocol. (because of the out of band information is guaranteed unique and can't happen in the datastream) But if you can't insert the break cleanly into the character stream, it is useless for protocol purposes I guess. And it was not worth centering the rest of the application around it. I did't have any confidence in the solutions presented (just reset the connection and pauze) because both the pauze is not reliable in length on preemptive systems like Windows, and the damage to the FIFOs is a problem, since that would negate the size advantages. I never pursued it further. OK. I'll start off with the standard API, with an explicit check that the output has drained by default, and a mSec parameter (which will get rounded up to something gross on unix). I'm still hoping that at some point the units and test code will be bundled in place of the existing unix-only serial.pp. I've added it, but it's best avoided except for the classic use of getting a remote system's attention. On Linux the only working parameter is zero indicating a break of around 250 mSec, on Solaris it doesn't work at all, and on Windows I've not found a way of preventing a break from trashing anything that's sitting in the Tx buffer. Modified library appended to issue 18946 in Mantis. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sending break on (Windows) serial comms
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Marco, I see you had a StackOverflow question on this a year or so ago. Did you ever get anywhere with it in practice? It was an idea to lower the overhead and improve the reliability of our serial protocol. (because of the out of band information is guaranteed unique and can't happen in the datastream) But if you can't insert the break cleanly into the character stream, it is useless for protocol purposes I guess. And it was not worth centering the rest of the application around it. I did't have any confidence in the solutions presented (just reset the connection and pauze) because both the pauze is not reliable in length on preemptive systems like Windows, and the damage to the FIFOs is a problem, since that would negate the size advantages. I never pursued it further. OK. I'll start off with the standard API, with an explicit check that the output has drained by default, and a mSec parameter (which will get rounded up to something gross on unix). I'm still hoping that at some point the units and test code will be bundled in place of the existing unix-only serial.pp. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Sending break on (Windows) serial comms
Marco, I see you had a StackOverflow question on this a year or so ago. Did you ever get anywhere with it in practice? I'm about to hack a SerBreak() into my re-implementation of serial.pp, and since I have dedicated HP comms test gear here I could check that it was interleaving with dataflow correctly. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Open vs dynamic arrays
Michael Van Canneyt wrote: On Sun, 22 Apr 2012, Mark Morgan Lloyd wrote: cobines wrote: 2012/4/22 Mark Morgan Lloyd : but I'm not sure why that works when it didn't earlier (i.e. before I'd started using array of const). You said you used DbgArray= array of integer then I assume this declaration? procedure ClrDebug(const panels: DbgArray); If so the parameter is a dynamic array not open array and you cannot call it with constant array: var arr: DbgArray; begin ClrDebug([DbgKey, DbgCode1, DbgTx]); //Won't work SetLength(arr, ...); arr[0] := ... ... ClrDebug(arr);// This works end; This on the other hand is an open array parameter: procedure ClrDebug(const panels: array of integer); Thanks, succinct. So if I understand this correctly it's one of the very rare cases where one has to write out the type of a parameter in full, rather than using an earlier declaration. It results in different declarations. type DbgArray = array of integer; procedure ClrDebug(const panels: DbgArray); Defines a procedure that accepts a dynamic array of type DbgArray. You cannot have "constant dynamic arrays", as they are managed on the heap and reference counted. On the other hand procedure ClrDebug(const panels: array of integer); Defines a procedure that accepts an open array: an array of integers, but without length. It accepts types as type SmallArray = array[1..100] of integer; LargeArray = array[1..1] of integer; And a constant array (and a dynamic array, if I'm correct) as well. I'll see if I can add something about it in the docs. Hopefully Google will pick this up as a guide for the perplexed :-) So if I understand things correctly, the important point here is that while it is good practice to do e.g. type dbgArray3= array[0..2] of integer; procedure clrDebug3(da: dbgArray3); rather than procedure clrDebug3(da: array[0..2] of integer); you quite simply can't do that when there isn't an explicit index range since your attempt to define an open array is interpreted as a dynamic array. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Open vs dynamic arrays
cobines wrote: 2012/4/22 Mark Morgan Lloyd : but I'm not sure why that works when it didn't earlier (i.e. before I'd started using array of const). You said you used DbgArray= array of integer then I assume this declaration? procedure ClrDebug(const panels: DbgArray); If so the parameter is a dynamic array not open array and you cannot call it with constant array: var arr: DbgArray; begin ClrDebug([DbgKey, DbgCode1, DbgTx]); //Won't work SetLength(arr, ...); arr[0] := ... ... ClrDebug(arr);// This works end; This on the other hand is an open array parameter: procedure ClrDebug(const panels: array of integer); Thanks, succinct. So if I understand this correctly it's one of the very rare cases where one has to write out the type of a parameter in full, rather than using an earlier declaration. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Open vs dynamic arrays
cobines wrote: ClrDebug(panels[i]) calls itself again and not procedure ClrDebug(panel: integer)... So stack overflow happens. If you need it only for integers then declare it as: procedure ClrDebug(const panels: array of integer) Thanks. Making sure it couldn't recurse fixes half the problem, reverting to array of integer fixes the other but I'm not sure why that works when it didn't earlier (i.e. before I'd started using array of const). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Open vs dynamic arrays
I know this is an area of some confusion, and the more explanations I
read the more I'm confused.
I've got a procedure like this
procedure ClrDebug(const panels: array of const);
var i: integer;
begin
for i := 0 to Length(panels) - 1 do
ClrDebug(panels[i])
end { ClrDebug } ;
procedure ClrDebug(panel: integer)...
I want to call it like this
ClrDebug([DbgKey, DbgCode1, DbgTx]);
Or anything similar. My original declaration used had a type DbgArray=
array of integer but that upset the compiler at the call point, the
code above throws an exception every time the procedure's called.
What, please, is the correct syntax to use in this sort of case?
FPC 2.6.0 on Linux x86.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling from and to memory
OBones wrote: Mattias Gaertner wrote: Maybe you can create a ramdisk. Thank you for your answer. I have thought about that, but this would create deployment problems as there is no default ramdisk driver under Windows. Might be worth considering should performance become a really big issue. This is what heavyweight database servers use solid state drives for. In any event, I think it's worth remembering that pipes etc. will always go through the operating system, so there's a limit to how much you can slim things. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Resolving a local hostnames to an IP address
Ludo Brands wrote: Bear in mind that files of that type are very much optional on Windows, a sop to those who demanded them in order to implement things like innd so they could claim it was as good as Unix. My experience is that the nameserver addresses are available from the Windows registry if configured statically, I suspect- but I've not checked and aren't going to- that that sort of thing will be copied into the registry if it arrives using DHCP. The synapse library has in synamisc.pas function GetDNS: string; which returns all DNS servers known on the system (windows or unix). It uses on windows the GetNetworkParams api function from IPHlpAPI.lib and, if not succesfull, tries the windows registry. I'd have used Synapse if this were a program of any significance. However as it is it's purely a demo, and in case any of the target audience tries to recompile it I've specifically avoided anything non-standard (I'm using FPC's ltelnet, but since that isn't in the search paths by default I've copied it into my own source). A later version might use something like cmdline in order to support coloured text, but I'll probably make that optional so that the base configuration will still compile. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resolving a local hostnames to an IP address
waldo kitty wrote: [...] not sure about that on windows... i just did a search in this w2k box... because it is different than my previous w98 box... the hosts file is found in %systemdir%/drivers/etc where on w98 it was found in %systemdir%... there is no resolv* found anywhere in my OS base directory... i also have this machine configured for pseudo-static IP assignment via DHCP so all address, gateway and DNS settings come from my DHCP server which just happens to be my main firewall box... that box is specifically configured to set a DNS suffix of my internal LAN domain TLD for all lookups with one or less dots in the name ie: foo and foo. both return the same IP... foo. returns just the name as given with the IP and foo (without the dot) returns the name with the domain suffix added and the same IP as foo. returns... Bear in mind that files of that type are very much optional on Windows, a sop to those who demanded them in order to implement things like innd so they could claim it was as good as Unix. My experience is that the nameserver addresses are available from the Windows registry if configured statically, I suspect- but I've not checked and aren't going to- that that sort of thing will be copied into the registry if it arrives using DHCP. [...] does this make sense and/or help any at all? it may be that some portion of your problem comes from a partially configured DNS setup on the client end of things (ie: the default domain suffix to add) but it may also extend to the DNS server as well if it is not configured to return proper responses for these lookups... in the past, i have seen local lookups traversing to the WAN and lookups being attempted out there that should never have left the LAN... there are many thousands of networks that erroneously do this which leads to the leaking of internal machine names and possibly roles (determined by the name)... No. The issue is solely that resolve.pas doesn't refer to the searchpath (no criticism intended), this is explicitly noted in fcl-net's readme file. For unqualified lookups on unix you need to use cnetdb, i.e. go via libc, or parse resolv.conf in application code. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting big-endian signed 16bits values to fpc integer
Jonas Maebe wrote:
On 16 Apr 2012, at 00:38, Giuliano Colla wrote:
I'm dealing with a large number of data coming from an external device.
They are big-endian 16 bits signed numbers, which must be converted to integer
and to real to perform calculations.
Besides the obvious solutions of treating them as isolated bytes, multipying by
256 the highest, adding the lower, and oring wit $, or whatever
sizeof(Integer) suggests if the result is bigger than 32767, is there a more
efficient and elegant way to achieve the result?
Call BEtoN() on them (Big Endian to Native byte order). Note that this routine is
overloaded for all integer sizes > 1, and that FPC extends the size of any number
< 32/64 bits (depending on the architecture) to 32/64 bits when performing almost
any operation on it. It's therefore probably the safest to call it as
BEtoN(smallint(value)) to ensure that the correct overload is selected.
I asked this a few weeks ago in the context of doing endianness-changes
in-place in a data structure, and Martin (I think) suggested overloading
the := operator.
I did however find that one has to be extremely careful inside the
custom operator, I ended up using Move() rather than an assignment to
the result since it was tending to go recursive- some way of inhibiting
all automatic type conversions would be useful.
(* This type represents a little-endian word, irrespective of the
platform. It *)
(* is of known size (16 bits, tested by assertion) but is not directly
*)
(* compatible with any other type.
*)
//
typeWordLE= packed record b0, b1: byte; end;
(* Assign a little-endian word to an (unsigned) integer, with
appropriate *)
(* conversion.
*)
//
operator := (wle: WordLE): word;
begin
..
Type TAWSHeader=packed Record
ThisSize: WordLE;
PrevSize: WordLE;
Flags:Byte;
Rsvd: Byte;
End;
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resolving a local hostnames to an IP address
waldo kitty wrote: On 4/13/2012 04:54, Mark Morgan Lloyd wrote: If I use THostResolver.NameLookup I find that it can convert a fully-qualified name but not one where the domain is omitted, can you explain this a bit more, please? the reason i ask is because some code wants at least one dot separator... example: foo.bar -- .bar is the TLD and foo is the hostname foo.bar. -- the last dot says this is the end, do not look to other domains so... foo -- may result in other domains being automatically looked up by stuffing known TLDs after it ie: foo.com, foo.net, foo.org... *BUT* foo. -- says there is no more domains to look at... so effectively one is looking for only the LAN name which should be easily served up by the LAN DNS server or the HOSTS file... some systems need the trailing dot and others do not... i've seen this problem for years and it seems to be limited to some OS' to a certain extent... That issue IME is specifically at the server, i.e. you've got to be careful with your DNS zone files. Cf the cricket book. I've not checked what the RFCs have to say about trailing dots at the client or in the client protocol, IMO strictly they're an error. I notice that the README specifically says that resolv.conf isn't fully parsed. in the above, i'm speaking purely from a network admin/tech/specialist POV... i work with a FOS firewall product and this is quite a common problem IF what i'm thinking it is is correct... sadly i've not (yet!) the coding knowledge in this area to be able to be more specific or of more help :? the main point is that many do not know about the use of the trailing dot to denote that there are no other domains to append in an attempt to locate the given hostname... clarification: foo.bar -- foo is the hostname, bar is the TLD... foo.bar.com -- foo is the hostname, bar is a SLD, and com is a TLD... foo.-- says look up "foo" only... foo.bar -- says look up "foo.bar" first and maybe other TLDs behind... foo.bar.-- says look up "foo.bar" and don't look up more than that... i hope this makes sense and is of some assistance... The point is that I was knocking together a demo terminal emulator (using non-standard coding etc.) that communicates using telnet, and I'd copied over the ltelnet library that requires (a string containing) an IP address as its parameter. Communicating with localhost worked, but rather late in the day I discovered that I was unable to set up a connection with named servers (i.e. DNS lookups were failing). This applies to Linux, I've not checked the Windows situation (there are other things that might not work such as keycodes, so porting isn't very high on my list). Connecting to pye-dev-07 failed, but its IP address (192.168.1.22) was OK. Qualifying the name manually so that it read pye-dev-07.telemetry.co.uk worked, but trying to get the domain name using GetDomainName didn't. The unix /etc/resolv.conf file (normally on each client) has a line for search paths, which are suffixes to be applied to a name if it doesn't immediately match. The libc lookup implementation, wrapped in cnetdb, uses this, while resolve.pas doesn't. The file can also specify a domain although this is rarely used, it might be that this is what GetDomainName refers to. I've ended up using a hybrid approach: first well-known names such as localhost and lo, then THostResolver, then cnetdb, with the possible fallback of parsing resolv.conf for cases where libc isn't available. If I look at porting to Windows I'll probably have to consult the registry in lieu of resolv.conf. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resolving a local hostnames to an IP address
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: a particular development system but if it happens to me it might happen to others. In short, how best should I work around this? Have a look at unit cnetdb.pp in fcl-net package. Thanks Marco, now working. I see I've used that elsewhere in the past... I rather loathe those return structures :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Resolving a local hostnames to an IP address
I need to resolve a hostname to an IP address, to pass to a minimal telnet implementation that expects that as its parameter. The reason that I'm not using something "industrial grade" like Synapse is that I'm trying to restrict myself to standard libraries so that I can ship sources to people who have no FPC experience, making the program both useful and a good demonstration of the development tools. If I use THostResolver.NameLookup I find that it can convert a fully-qualified name but not one where the domain is omitted, I notice that the README specifically says that resolv.conf isn't fully parsed. Unfortunately I find (2.6 on Debian "Squeeze") that GetDomainName returns nothing useful- I've not yet investigated whether that's down to a particular development system but if it happens to me it might happen to others. In short, how best should I work around this? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text matching for configuration files etc.
Mark Morgan Lloyd wrote: I know that there are algorithms which given a text fragment will find the "best fit" from a number of candidates, based on how many substrings have to be deleted or changed. Is there anything like this in the standard FPC library, and if not does anybody have one or a URL? Application is a configuration file handler, where parameters describe things like keyboard layout, and I want to include some latitude so that a user doesn't have to get it exactly right if editing by hand. > Maybe you mean something like Soundex: > http://lazarus-ccr.sourceforge.net/docs/rtl/strutils/soundex.html > > I myself would make a GUI for the configuration file and give all > valid choices in comboboxes and radiogroups etc. > > Juha Soundex had occurred to me, but it's very much oriented towards (American) surnames: encode the start of the name followed by a digest of the remainder. > I think this sounds more like "edit distance", but I am not sure why > it would be needed for a config file. > > Thank you, >Noah silva That was the term I was looking for, I see there's a Wp entry and I haven't even blown the dust off Knuth yet :-) Basically, I've got descriptions of golfballs like BCD, 88 character Correspondence, 96 character Correspondence, 88 character + APL and (if I get enough interest from the target audience) I want to be able to provide users the option of applying tweaks that might exceed what's provided by the GUI. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Text matching for configuration files etc.
I know that there are algorithms which given a text fragment will find the "best fit" from a number of candidates, based on how many substrings have to be deleted or changed. Is there anything like this in the standard FPC library, and if not does anybody have one or a URL? Application is a configuration file handler, where parameters describe things like keyboard layout, and I want to include some latitude so that a user doesn't have to get it exactly right if editing by hand. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Custom assignment operators
A few weeks ago somebody (Martin?) suggested I got round an endianness issue by doing this: typeWordLE= packed record b0, b1: byte; end; operator := (wle: WordLE): word; begin .. It works well, except that attempting to use an assignment inside the operator definition immediately recurses: I've fixed this by using Move(), with operand sizes check by assertion. Is it possible to tell the compiler that, for a code fragment like this, it is under no circumstances to attempt any implicit type conversions? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SysUtils.GetEnvironmentVariable
Marcos Douglas wrote: On Thu, Mar 29, 2012 at 5:42 AM, Mark Morgan Lloyd wrote: Marcos Douglas wrote: I know that I have to define the environment variable before or after starting the application or IDE. As I said, works in WinXP... but I had a little problem with a client using Win7 so, I talked about this on lazarus-br list and asked to somebody do the test on Win7 and they said the test did not work so, I wrote here. I think the absolutely crucial thing here is to ask what the relationship between the session in which the shell/environment variable was defined, and the FPC program. Nothing. If the variable is set and the program is run from the same prompt, provided that it's not messed up by extra spaces or by e.g. an interposed command.com, then it should work. No. The variable is set using a install program or Windows. In any other case it might work, and it's entirely reasonable to assume that the extent to which variables are passed between running processes will vary wildly with OS version. I suggest the *first* thing to do is to confirm that the variable has stuck by using the set command. After that try running the Pascal program. No command set is used. The variable has been created in the Windows System Variables. In simple English: if you enter the set command, do you see the variable? If not, it's an OS or installer problem. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SysUtils.GetEnvironmentVariable
Marcos Douglas wrote: I know that I have to define the environment variable before or after starting the application or IDE. As I said, works in WinXP... but I had a little problem with a client using Win7 so, I talked about this on lazarus-br list and asked to somebody do the test on Win7 and they said the test did not work so, I wrote here. I think the absolutely crucial thing here is to ask what the relationship between the session in which the shell/environment variable was defined, and the FPC program. If the variable is set and the program is run from the same prompt, provided that it's not messed up by extra spaces or by e.g. an interposed command.com, then it should work. In any other case it might work, and it's entirely reasonable to assume that the extent to which variables are passed between running processes will vary wildly with OS version. I suggest the *first* thing to do is to confirm that the variable has stuck by using the set command. After that try running the Pascal program. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems with broken (or unclear) download urls for fpc-solaris
Adrian Maier wrote: On Wed, Mar 28, 2012 at 10:45, Mark Morgan Lloyd wrote: Adrian Maier wrote: Hello, I wanted to download the latest freepascal for Sparc Solaris . Issue 1: Opened the http://www.freepascal.org/download.var, clicked on the "SPARC Solaris" link. It opened the page for selecting the mirror. Clicked on Sourceforge , which lead to : http://sourceforge.net/projects/freepascal/files/ The problem here is that this page doesn't seem to contain any Solaris stuff . Issue 2: I went back to the mirror selection, and clicked on ftp.freepascal.org . This link is ok , but it contains the 2.4.2 sparc solaris FPC . This is not consistent with the main download page (http://www.freepascal.org/download.var) , which implies that 2.6.0 is available for the entire list of platforms and operating systems (which includes the SPARC solaris ... ). Perhaps it's worth taking a look at the download page , so that it presents in a clearer way which FPC version is available for each platform ? For example create a separate section for the less-supported platforms.The way it is now, it implies that 2.6 is available for all the platforms - which is unfortunately false. I currently have ssh access to some Sparc Solaris servers. Does it involve a lot of work to create the solaris builds ? I don't know to what extent anybody is routinely producing Solaris/SPARC releases. I try to test the compiler on v10 (and to a limited extent on v8) on a fairly regular basis, but I started off with [checks] 2.4.2, had to do a bit of hacking to get it installed (see http://mantis.freepascal.org/view.php?id=18271) and then compiled newer versions from there. The server is a SunOS 5.10 . Uname -a : SunOS bebrxsu005 5.10 Generic_147440-07 sun4u sparc SUNW,SPARC-Enterprise Solaris I'll try to find some time for installing the 2.4.2 and building the 2.6. Thanks for the link : the comments will be useful in case i encounter problems . If you get stuck having a copy of my fpc.cfg might help. Email me in the address in my sig (below), I'll be at my desk intermittently. In practical terms, you might need to be on 2.7 since there are a couple of code generation bugs that weren't backported to 2.6- this affects both Solaris and Linux. Lazarus 0.9.30-fixed should compile and run on v10 now that some alignment patches have been incorporated. I am hoping that 2.6 would be enough (not targetting lazarus) . Compiling a development version would be painful because there is no way to directly access the svn server ... But you should still be able to get a snapshot of the development version. However you might find you have to work in a progression: 2.4.2 (possibly via 2.4.4) to 2.6.0 to 2.7.1. The issues are in floating point and variant handling, you'll see them on Mantis if you look for SPARC. In all cases, you need the freeware gas, gld, gmake and probably gtar etc., and need to be careful with your paths. The server has the GNU make and tar . But the as and ld are not GNU. And i have no admin rights : so i can install software only in the home dir. I'd have thought that would have been OK, once you'd got paths set up. If you have problems use the compiler's -vt switch, since this will give you a blow-by-blow account of what's being looked for: gmake NOGDB=1 OPT='-O- -gl -vt' all Note that there are some things that I haven't tested. For example, on various Linux targets I've got a (Lazarus) app that uses PostgreSQL's listen/notify with a lot of pointer checks etc... I've never looked at that on either Solaris or Windows (which isn't where I want to go today). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems with broken (or unclear) download urls for fpc-solaris
Adrian Maier wrote: Hello, I wanted to download the latest freepascal for Sparc Solaris . Issue 1: Opened the http://www.freepascal.org/download.var, clicked on the "SPARC Solaris" link. It opened the page for selecting the mirror. Clicked on Sourceforge , which lead to : http://sourceforge.net/projects/freepascal/files/ The problem here is that this page doesn't seem to contain any Solaris stuff . Issue 2: I went back to the mirror selection, and clicked on ftp.freepascal.org . This link is ok , but it contains the 2.4.2 sparc solaris FPC . This is not consistent with the main download page (http://www.freepascal.org/download.var) , which implies that 2.6.0 is available for the entire list of platforms and operating systems (which includes the SPARC solaris ... ). Perhaps it's worth taking a look at the download page , so that it presents in a clearer way which FPC version is available for each platform ? For example create a separate section for the less-supported platforms.The way it is now, it implies that 2.6 is available for all the platforms - which is unfortunately false. I currently have ssh access to some Sparc Solaris servers. Does it involve a lot of work to create the solaris builds ? I don't know to what extent anybody is routinely producing Solaris/SPARC releases. I try to test the compiler on v10 (and to a limited extent on v8) on a fairly regular basis, but I started off with [checks] 2.4.2, had to do a bit of hacking to get it installed (see http://mantis.freepascal.org/view.php?id=18271) and then compiled newer versions from there. In practical terms, you might need to be on 2.7 since there are a couple of code generation bugs that weren't backported to 2.6- this affects both Solaris and Linux. Lazarus 0.9.30-fixed should compile and run on v10 now that some alignment patches have been incorporated. In all cases, you need the freeware gas, gld, gmake and probably gtar etc., and need to be careful with your paths. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] [No subject]
___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] [No subject]
___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Burn a CD
Marcos Douglas wrote: On Wed, Mar 14, 2012 at 7:42 AM, Leonardo M. Ramé wrote: If you think in the future your app must work in another OSes, maybe a better solution is to use cdrecord, it has everything you need (CD, DVD, BluRay) . Here's the Win32 version http://www.student.tugraz.at/thomas.plank/ We run it using TProcess, then parse the results and show them on screen. Interesting. Could you give an example how do you use it, please? You do not translated the headers, just use the binaries, rigth? cdrecord is generally well-regarded in terms of the number of different drives etc. it supports, but I've always found (on Linux) that it needs a bit of nursing when scanning and selecting available devices. Also there are issues with e.g. Debian forking the project and applying patches which weren't approved by the original author. Frankly, I think that I'd settle for building a .iso image, and rely on the user having his own software which is known to be compatible with his hardware. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] status of MIPS port
Jorge Aldo G. de F. Junior wrote: Whats the status of the MIPS port ? I am currently working on a project called "OpenTik", wich aims at replacing mikrotik's routeros with a completely opensource alternative. Originally i wanted to use FreeBSD on ARM but theres no freepascal compiler for this. I switched to a Linux based system as the base, and freepascal to write a couple of complex components (like the console wich is way more powerfull than the mikrotik's original one). I am working on the captive portal system now, wich will be nicely integrated into the current (working already) xmlconsole. Later i plan to write a mac server using freepascal and libpcap and finally a winbox replacement called openbox. Current source code is here : http://code.google.com/p/opentik/ it implements a complete programming language on its own, besides a template system and a configuration management tool all integrated into a single system called xmlconsole (because it uses xml files to store config). My question is : Whats the status of Freepascal on the MIPS (both LE and BE) ? I ask this bacause MIPS is the single most used processor in the low end/low cost access point market and it would be quite nicey to have opentik running on those. It's work-in-progress. There's a port of 2.0.0 with limited functionality (i.e. only part of the RTL was compiled), that's currently being merged into trunk but I've not heard anything from the people looking at it over the last few days. There was relevant discussion in this ML at end-Jan/start-Feb, also see http://wiki.lazarus.freepascal.org/Native_MIPS_Systems which I knocked together when I started looking at it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Advanced Records
Sven Barth wrote: Am 09.03.2012 23:26, schrieb Mark Morgan Lloyd: Martin wrote: On 09/03/2012 21:26, Mark Morgan Lloyd wrote: but is there any way to define something like an endianness-correcting type, i.e.: Type TAWSHeader=Record ThisSize: WordLE; .. where by the time ThisSize is accessed any disparity has been corrected? Not sure if this will be of any use. but you can always define an assignment incompatible type WordLE = record data: Word; end; and define all required overloaded operators I think that could be of a lot of use, but I'll need to tinker :-) Noted your example, but apart from that is there any concise way to define a type such as WordLE with the explicit restriction that it requires an explicit definition of assignment operators (i.e. is never subject to implicit casts or type conversions)? Can this be done such that WordLE has a predefined size even if the assignment has to go via code? You could play around with a construct like the following: type generic TMyLEType = record Data: T; class operator := (aRight: TMyLEType): TMyLEType; class operator := (aRight: TMyLEType): T; end; TWordLE = specialize TMyLEType; TLongWordLE = specialize TMyLEType; // ... class operator TMyLEType.:= (aRight: TMyLEType): TMyLEType; begin Result.Data := aRight.Data end; class operator TMyLEType.:= (aRight: TMyLEType): T; begin // convert the value to the correct endianess here // you might want to use SizeOf(T) for a determination of the // correct size of T, so you can swap correctly end; Thanks. Thinking about it, Martin's example probably fits my criteria of conciseness etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Advanced Records
Martin wrote: On 09/03/2012 21:26, Mark Morgan Lloyd wrote: but is there any way to define something like an endianness-correcting type, i.e.: Type TAWSHeader=Record ThisSize: WordLE; .. where by the time ThisSize is accessed any disparity has been corrected? Not sure if this will be of any use. but you can always define an assignment incompatible type WordLE = record data: Word; end; and define all required overloaded operators I think that could be of a lot of use, but I'll need to tinker :-) Noted your example, but apart from that is there any concise way to define a type such as WordLE with the explicit restriction that it requires an explicit definition of assignment operators (i.e. is never subject to implicit casts or type conversions)? Can this be done such that WordLE has a predefined size even if the assignment has to go via code? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Advanced Records
Jonas Maebe wrote:
On 09 Mar 2012, at 22:26, Mark Morgan Lloyd wrote:
Thanks Jonas, I don't think I need to do it but I thought it was a fair
question: better safe than sorry.
OK, so hopefully I can get away with another. I'm looking at a program written
in Delphi, which reads a file containing the image of an IBM mainframe tape.
This has a record:
Type TAWSHeader=Record
ThisSize: Word;
..
If you want a record to have a predictable layout, always either
a) use {$packrecords c} if it's a translation of a C struct, or
b) declare it as "packed"
In other cases, you can (and will) have problems across different platforms or
even compiler versions.
Thanks Jonas, noted (although I invariably put lots of Assert(SizeOf()=)
in initialization). It's actually pretty simple stuff, but derives from
a card IBM designed which had a mainframe (big-endian) processor on it
but plugged into an MCA (little-endian) system.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Advanced Records
Jonas Maebe wrote: On 09 Mar 2012, at 21:38, Mark Morgan Lloyd wrote: Can an Advanced Record, i.e. a record which as well as having fields has at least one embedded function, be safely used as a cast or type transfer overlaying unstructured bytes? Yes. Thanks Jonas, I don't think I need to do it but I thought it was a fair question: better safe than sorry. OK, so hopefully I can get away with another. I'm looking at a program written in Delphi, which reads a file containing the image of an IBM mainframe tape. This has a record: Type TAWSHeader=Record ThisSize: Word; .. ThisSize is defined as being in Intel-style little-endian format, so I'm going to have problems if compiling the program for SPARC or (hypothetically) zSeries which are big-endian. If I understand things correctly I can do this: Type TAWSHeader=Record ThisSizeLE: Word; function ThisSize: Word; .. but is there any way to define something like an endianness-correcting type, i.e.: Type TAWSHeader=Record ThisSize: WordLE; .. where by the time ThisSize is accessed any disparity has been corrected? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC Advanced Records
Can an Advanced Record, i.e. a record which as well as having fields has at least one embedded function, be safely used as a cast or type transfer overlaying unstructured bytes? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Trim(): incompatibility with Delphi
Flávio Etrusco wrote:
On Mon, Mar 5, 2012 at 11:36 PM, leledumbo wrote:
Fpc Trim(): Trim whitespace from the ends of a string.
Where did you get that? The documentation
(http://www.freepascal.org/docs-html/rtl/sysutils/trim.html) doesn't say
so...
And a simple test confirms the docs (FPC 2.6):
ShowMessage(Trim('test ') + Trim (' !'));
More to the point, putting in control characters instead of spaces:
program trimtest;
uses SysUtils;
begin
WriteLn(Trim('test' + #$0d + #$0a) + Trim (#$0d + #$0a + '!'))
end.
test!
Unless there's some weird locale-specific problem.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
