Re: [fpc-pascal] Parsing XML from MS SQL webservice using fpc
On Fri, 28 Aug 2009, Nataraj S Narayan wrote: Hi I am getting the XML using # curl -v -u pilot:pilot "http:///handheld?sql=select+*+from+branchdesc+for+xml+auto&root=clancor" Next step is to parse and put it into a Sqlite database. Is it possible to bypass curl and do fully using fcl-xml? You can use synapse, lnet or Indy to download the data, and then parse it with fcl-xml. Michael. regards Nataraj On Wed, Aug 26, 2009 at 6:13 PM, Nataraj S Narayan wrote: Hi The customer want it that way. May be don't like to expose Sql server to the world. ITC of wrong validation, browser shows:- ERROR: 401 Access Denied HResult: 0x80046000 Source: Microsoft SQL isapi extension Description: Access denied regards Nataraj On Wed, Aug 26, 2009 at 5:57 PM, Henry Vermaak wrote: 2009/8/26 Nataraj S Narayan : Hi The following URL gives me a XML output in any browser , after validating username and password:- http://"Some IP address"/handheld?sql=select+*+from+branchdesc+for+xml+auto&root=my-mssql-database This connects to a remote MS SQL server based web service , may be using MIcrosoft IIS server. Can i use "fcl-xml" package to send the query and then parse the xml output? Why don't you query the sql server directly? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Parsing XML from MS SQL webservice using fpc
Hi I am getting the XML using # curl -v -u pilot:pilot "http:///handheld?sql=select+*+from+branchdesc+for+xml+auto&root=clancor" Next step is to parse and put it into a Sqlite database. Is it possible to bypass curl and do fully using fcl-xml? regards Nataraj On Wed, Aug 26, 2009 at 6:13 PM, Nataraj S Narayan wrote: > Hi > > The customer want it that way. May be don't like to expose Sql server > to the world. > ITC of wrong validation, browser shows:- > > ERROR: 401 Access Denied > HResult: 0x80046000 > Source: Microsoft SQL isapi extension > Description: Access denied > > regards > > Nataraj > > On Wed, Aug 26, 2009 at 5:57 PM, Henry Vermaak wrote: >> 2009/8/26 Nataraj S Narayan : >>> Hi >>> >>> The following URL gives me a XML output in any browser , after >>> validating username and password:- >>> >>> http://"Some IP >>> address"/handheld?sql=select+*+from+branchdesc+for+xml+auto&root=my-mssql-database >>> >>> This connects to a remote MS SQL server based web service , may be >>> using MIcrosoft IIS server. >>> >>> Can i use "fcl-xml" package to send the query and then parse the xml output? >> >> Why don't you query the sql server directly? >> >> Henry >> ___ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-pascal >> > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc on Armel issues
Hi My problem still persists. Here are the details of 2 binaries - first compiled using fpc-arm and second qt4 for arm. The second one is working, 1. debian-armel:~# readelf -h firework ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x8f1c Start of program headers: 52 (bytes into file) Start of section headers: 260800 (bytes into file) Flags: 0x502, has entry point, Version5 EABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 34 Section header string table index: 31 2. debian-armel:~# readelf -h framebuffer ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x8874 Start of program headers: 52 (bytes into file) Start of section headers: 10272 (bytes into file) Flags: 0x502, has entry point, Version5 EABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 8 Size of section headers: 40 (bytes) Number of section headers: 27 Section header string table index: 26 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x8f1c Start of program headers: 52 (bytes into file) Start of section headers: 260800 (bytes into file) Flags: 0x502, has entry point, Version5 EABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 34 Section header string table index: 31 2. debian-armel:~#ldd firework /usr/bin/ldd: line 116: ./firework: No such file or directory debian-armel:~# ldd framebuffer libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40038000) libm.so.6 => /lib/libm.so.6 (0x40113000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401c) libc.so.6 => /lib/libc.so.6 (0x401d4000) /lib/ld-linux.so.3 (0x4000) On Tue, Aug 25, 2009 at 7:48 PM, Henry Vermaak wrote: > 2009/8/25 Nataraj S Narayan : >> Hi Henry >> >> Not any particular reason for that. Company policy was to get rid of >> Angtrom and go for Debian. >> >> Well seems debian-armel is also EABI 4. Would you suggest me a RFS with EABI >> 5? > > I'm just saying that you won't have these problems if you stick to the > same toolchain. There may still be issues with the fpc armel port, > but that's a different matter. > > Henry > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] WinCE: Detect if a PDA is connected to a LAN WI-FI peer-to-pear
Hi 1. Is it possible to detect if a PDA is connected (wi-fi) to a peer-to-peer LAN (by IP or Device name)? If yes, how? maybe by a ping? is there a programmatic ping method? 2.How to detect the IP of a PDA from an App running on the same PDA? In a peer-to-peer LAN, is the PDA IP static like for the workstations? Basically, what I'd like to do is to retrieve the IP of the PDA when the user on the PDA makes a change to a data file on the desktop server (via sockets) I want to store the IP of the PDA (if static) or its Device name (which I know I can retrieve from the PDA registry) if the IP keeps changing. If necessary, I need to see in a subsequent moment if the PDA is still connected to the LAN (with a ping or other method). Thanks for any help. -- View this message in context: http://www.nabble.com/WinCE%3A-Detect-if-a-PDA-is-connected-to-a-LAN-WI-FI-peer-to-pear-tp25179819p25179819.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
2009/8/27 Jonas Maebe : >> >> That was in the very first post of this thread: > > Maybe on another mailing list? Not here anyway. Nope, Mattias is right. He posted the results in the Lazarus mailing list, but when I moved the discussion from there to here, I quoted his results in my first posting. Here they are again. - Mattias test results are as follows: Under his Linux machine the above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds Under OS X the above program takes on his mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds - Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGui git not working?
2009/8/27 yu ping : > I ever download the fpGui source using git. > but now I can't connect the server. Yes, I posted a notice about it in the fpGUI newsgoups. SourceForge did some restructuring on there side. One of the affected systems was all Git repositories. No need to re-clone your Git repository. Simply edit the /.git/config file. Then change the git URL to the following address git://fpgui.git.sourceforge.net/gitroot/fpgui/fpgui Notice the extra "/fpgui" at the end. After this you should be able to do a 'git pull' again. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGui git not working?
2009/8/27 Henry Vermaak : > > I see the website still reports the old url. Thanks Henry, I'm updating the website now. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On 27 Aug 2009, at 19:08, Mattias Gaertner wrote: On Thu, 27 Aug 2009 18:57:58 +0200 Jonas Maebe wrote: Oh, now I see that the procedure was put below :) That it's quicker with cmem is reasonably logical: FPC's heap manager is not very good at reallocating memory. What reallocating memory do you mean? s1:=IntToStr(Paramcount+12345); s2:=IntToStr(Paramcount+23456); for i:=1 to 5 do begin s:=s1; s:=s2; end; I only change reference counters, don't I? You're right. I didn't see any timings for the command line app in your post though. That was in the very first post of this thread: Maybe on another mailing list? Not here anyway. Under my Linux machine the above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds Under OS X the above program takes on my mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds On my MacBook it's 12 seconds with or without cthreads (12.1 with 2.5.1, 12.8 with 2.2.4). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On Thu, 27 Aug 2009 18:57:58 +0200 Jonas Maebe wrote: > > On 27 Aug 2009, at 18:55, Jonas Maebe wrote: > > > Without saying what this command line application and this LCL > > application do exactly, it's kind of hard to understand this > > conclusion. > > > Oh, now I see that the procedure was put below :) That it's quicker > with cmem is reasonably logical: FPC's heap manager is not very good > at reallocating memory. What reallocating memory do you mean? s1:=IntToStr(Paramcount+12345); s2:=IntToStr(Paramcount+23456); for i:=1 to 5 do begin s:=s1; s:=s2; end; I only change reference counters, don't I? > I didn't see any timings for the command line app in your post > though. That was in the very first post of this thread: Under my Linux machine the above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds Under OS X the above program takes on my mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds > I guess the difference between the command line and LCL app > is simply due to alignment differences, causing different cache > behaviour. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On Thu, 27 Aug 2009 18:55:10 +0200 Jonas Maebe wrote: > > On 27 Aug 2009, at 18:48, Mattias Gaertner wrote: > > > On Thu, 27 Aug 2009 13:46:21 +0200 > > Mattias Gärtner wrote: > > > >> [...] > >> I would say, that using cthreads under Linux in an LCL app is ok. > >> I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't > >> know if cthreads has a performance penalty there. > > > > I did some tests on OS X and got some interesting results: > > > > An LCL application without cthreads: 15 seconds > > An LCL application with cthreads: 13 seconds > > An LCL application with cmem: 13 seconds > > > > This means LCL apps get faster with cthreads, while command line > > programs get slower. > > Without saying what this command line application and this LCL > application do exactly, it's kind of hard to understand this > conclusion. I already posted the code, so I guess you mean the libraries. How can I find out under OS X? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGui git not working?
Thanks 2009/8/28 Henry Vermaak > 2009/8/27 Henry Vermaak : > > 2009/8/27 yu ping : > >> I ever download the fpGui source using git. > >> but now I can't connect the server. > > > > This is not the fpgui mailing list. Graham posted a url change > > message 2 days ago to the fpgui mailing list. The url is now: > > It's a newsgroup, actually: > > http://opensoft.homeip.net/fpgui/#Newsgroups > > Henry > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- https://sites.google.com/site/pingyu211 https://sites.google.com/site/pingyu212 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On 27 Aug 2009, at 18:55, Jonas Maebe wrote: Without saying what this command line application and this LCL application do exactly, it's kind of hard to understand this conclusion. Oh, now I see that the procedure was put below :) That it's quicker with cmem is reasonably logical: FPC's heap manager is not very good at reallocating memory. I didn't see any timings for the command line app in your post though. I guess the difference between the command line and LCL app is simply due to alignment differences, causing different cache behaviour. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On 27 Aug 2009, at 18:48, Mattias Gaertner wrote: On Thu, 27 Aug 2009 13:46:21 +0200 Mattias Gärtner wrote: [...] I would say, that using cthreads under Linux in an LCL app is ok. I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't know if cthreads has a performance penalty there. I did some tests on OS X and got some interesting results: An LCL application without cthreads: 15 seconds An LCL application with cthreads: 13 seconds An LCL application with cmem: 13 seconds This means LCL apps get faster with cthreads, while command line programs get slower. Without saying what this command line application and this LCL application do exactly, it's kind of hard to understand this conclusion. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On Thu, 27 Aug 2009 13:46:21 +0200 Mattias Gärtner wrote: >[...] > I would say, that using cthreads under Linux in an LCL app is ok. > I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't > know if cthreads has a performance penalty there. I did some tests on OS X and got some interesting results: An LCL application without cthreads: 15 seconds An LCL application with cthreads: 13 seconds An LCL application with cmem: 13 seconds This means LCL apps get faster with cthreads, while command line programs get slower. Under Linux: no difference procedure TMainForm.FormCreate(Sender: TObject); var s1: String; s2: String; i: Integer; s: String; begin s1:=IntToStr(Paramcount+12345); s2:=IntToStr(Paramcount+23456); for i:=1 to 5 do begin s:=s1; s:=s2; end; end; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGui git not working?
2009/8/27 Henry Vermaak : > 2009/8/27 yu ping : >> I ever download the fpGui source using git. >> but now I can't connect the server. > > This is not the fpgui mailing list. Graham posted a url change > message 2 days ago to the fpgui mailing list. The url is now: It's a newsgroup, actually: http://opensoft.homeip.net/fpgui/#Newsgroups Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
En/na Marco van de Voort ha escrit: It makes it very hard to longterm succesfully deploy a simple linux binary over several systems. FWIW, yesterday I add to compile on a current system a 5 years old very simpe program (updated 2 years ago) with current lazarus/gtk2/fpc 2.2.4 to deploy on a 5 years old system (and that's nothing, sometimes I have to touch 15-20 years old systems) and it doesn't run (it claims it's missing some gtk2 function). Of course, I could reinstall those machines with a current distribution, but it'll take too much time for what is a simple modification to the program. Luckily it works if compiled with gtk1. This is to say that using cthreads by default (which, btw, my program uses) wouldn't make things that much worse. Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGui git not working?
2009/8/27 yu ping : > I ever download the fpGui source using git. > but now I can't connect the server. This is not the fpgui mailing list. Graham posted a url change message 2 days ago to the fpgui mailing list. The url is now: git://fpgui.git.sourceforge.net/gitroot/fpgui/fpgui I see the website still reports the old url. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpGui git not working?
I ever download the fpGui source using git. but now I can't connect the server. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
A much longer than expected discussion, but informative none the less. Thanks to all for explaining. And here one can see the difference. Static vs Dynamic executable. $ ldd bench1.cthreads linux-vdso.so.1 => (0x7fff3f5ff000) libdl.so.2 => /lib/libdl.so.2 (0x7f4b371b5000) libc.so.6 => /lib/libc.so.6 (0x7f4b36e43000) /lib64/ld-linux-x86-64.so.2 (0x7f4b373b9000) $ ldd bench1.no-cthreads not a dynamic executable $ ls -l -rwxr-xr-x 1 graemeg graemeg 693840 2009-08-27 14:11 bench1.cthreads -rwxr-xr-x 1 graemeg graemeg 607112 2009-08-27 14:11 bench1.no-cthreads Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
2009/8/27 Mattias Gärtner : > > Not me, but Michael said that. Of course, sorry for mis-quoting you. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Zitat von Henry Vermaak : 2009/8/27 Graeme Geldenhuys : Michael Van Canneyt wrote: Why is threading enabled by default under Windows and not under other platforms? Because it creates a dependency on the C library, which is not always wanted. For Lazarus programs, the dependency exists anyway, so it does not make a lot of sense to have the define. But surely that c library is available on all unix-type systems? To why is that dependency a bad thing? The linux threading support is part of glibc. See `man pthreads`. That's why Mattias says that including it by default in lazarus is o.k., since all the widgetsets depend on libc, anyway. Not me, but Michael said that. I would say, that using cthreads under Linux in an LCL app is ok. I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't know if cthreads has a performance penalty there. Threading on Windows works with Windows API functions. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Jonas Maebe schrieb: > > On 27 Aug 2009, at 12:49, Graeme Geldenhuys wrote: > >> Is this an issue, even if your program doesn't use any >> procedures/functions from the dynamically linked C library. For example, >> a console application that includes the cthreads unit (which dynamically >> links to C Library), but doesn't actually use the C Library or threads. >> Would such a console application not run on an 8 year old Linux distro? > > > It would not run *on* an 8-year old Linux distro regardless of whether > you use libc, because FPC nowadays uses Linux 2.4.x+ system calls. 2.4.0 was released in January 2001 and SuSE 7.1 in the same month with a 2.4.0 kernel or 2.2.18 ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On 27 Aug 2009, at 13:15, Marco van de Voort wrote: The init code touches errno No, it doesn't. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On 27 Aug 2009, at 13:04, Marco van de Voort wrote: OS X and FreeBSD have basically the same problem, however has some mitigating factors (they change mostly only with major versions, and have the ability to run older binaries using resp COMPAT and SDK system) The SDK's on Mac OS X are only for compiling, not for running. The way it's solved on Mac OS X is by almost never breaking backwards compatibility at the library level (they've haven't done it yet for libc since the launch of OS X 8 years ago, although that's obviously not that long a time ago), and if they do they include both the old and the new library or framework. Both libraries and frameworks have internal versioning information that enables automatically checking whether or not an application and a library are compatible. Standard library linking happens similar to on other Unix systems, with the filename being used to select the appropriate version. In case of frameworks, the framework bundle itself can contain multiple versions and the correct one is automatically selected when the application is launched. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
In our previous episode, Henry Vermaak said: > 2009/8/27 Michael Van Canneyt : > > > > Because I want a FPC program to depend only on the Linux kernel, not on the > > C library. > > > > There are FPC programs from 8 years back that still work with the current > > kernel. Try that with a program that depends on the C library. > > The only reason for this is the fact that the rtl is compiled into fpc > executables. If fpc had an rtl as a lib (like c), we would be in the > same boat. More or less. But FPC's rtl doesn't pretend to be an OS interface. That's also why e.g. Windows suffers less from this. Library linking issues are more isolated and the API is very static. (stuff is added, but not changed) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
In our previous episode, Graeme Geldenhuys said: > > There are FPC programs from 8 years back that still work with the current > > kernel. Try that with a program that depends on the C library. > > Sorry if this sounds dumb - it's late in the week. ;-) > Is this an issue, even if your program doesn't use any > procedures/functions from the dynamically linked C library. For example, > a console application that includes the cthreads unit (which dynamically > links to C Library), but doesn't actually use the C Library or threads. > Would such a console application not run on an 8 year old Linux distro? No. The init code touches errno, and that has changed several times due to the fact that that var became threadsafe. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Henry Vermaak schrieb: > 2009/8/27 Michael Van Canneyt : >> Because I want a FPC program to depend only on the Linux kernel, not on the >> C library. >> >> There are FPC programs from 8 years back that still work with the current >> kernel. Try that with a program that depends on the C library. > > The only reason for this is the fact that the rtl is compiled into fpc > executables. No, not really. A static (g)libc is often as well a problem because configurable options are taken from the host system and hard coded into the resulting libc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On 27 Aug 2009, at 12:49, Graeme Geldenhuys wrote: Is this an issue, even if your program doesn't use any procedures/functions from the dynamically linked C library. For example, a console application that includes the cthreads unit (which dynamically links to C Library), but doesn't actually use the C Library or threads. Would such a console application not run on an 8 year old Linux distro? It would not run *on* an 8-year old Linux distro regardless of whether you use libc, because FPC nowadays uses Linux 2.4.x+ system calls. What Michael was talking about was about running 8-year old programs on a current kernel. And that would probably work, although with some caveats. Programs that use the C library also require special startup code. This code is normally in crt1.o and shipped together with the C library, and is always linked statically into the program. FPC contains its own version of that code for Linux and *BSD, but slightly adapted. There are different versions for at least libc5, glibc 2.x and uclibc (and they are not interchangeable). The switchover from libc5 to glibc 2.x happened more than 8 years ago, so you'd probably be safe in this particular scenario. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
2009/8/27 Graeme Geldenhuys : > > I understand all this, but isn't libc available on all unix-type OSes. In my limited experience, I haven't come across a linux system without some form of a c library. Pretty much everything in gnu userland relies on it. > If so, then I don't understand why it (threading) must be optional in > FPC based applications. Not depending on libc is a good thing and keeps options open, especially for embedded development. E.g. you can try and write your own busybox style program in fpc, to make a 100% pascal userland :) Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
In our previous episode, Graeme Geldenhuys said: > >> Why is threading enabled by default under Windows and not under other > >> platforms? > > > > Because it creates a dependency on the C library, which > > is not always wanted. For Lazarus programs, the dependency exists > > anyway, so it does not make a lot of sense to have the define. > > But surely that c library is available on all unix-type systems? There is not one C library. There are several. And all these are separately versioned, and can also be configured differently. (removing legacy symbols, enabling alpha functionality). The problem is that Linux distro's seem to assume that all binaries are generated on the system they are used, and interpret the effective API of the system from the available headers. > To why is that dependency a bad thing? It makes it very hard to longterm succesfully deploy a simple linux binary over several systems. OS X and FreeBSD have basically the same problem, however has some mitigating factors (they change mostly only with major versions, and have the ability to run older binaries using resp COMPAT and SDK system) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Graeme Geldenhuys schrieb: > Michael Van Canneyt wrote: >> Because I want a FPC program to depend only on the Linux kernel, >> not on the C library. > > OK. > > >> There are FPC programs from 8 years back that still work with the current >> kernel. Try that with a program that depends on the C library. > > Sorry if this sounds dumb - it's late in the week. ;-) > Is this an issue, even if your program doesn't use any > procedures/functions from the dynamically linked C library. For example, > a console application that includes the cthreads unit (which dynamically > links to C Library), but doesn't actually use the C Library or threads. > Would such a console application not run on an 8 year old Linux distro? No, because using cthreads overrides internal dummy callbacks by procedures linking against libc thus libc is linked in. Further, units like classes or the heap manager use internally critical sections so you really depend on libc if you link cthreads. If you don't include cthreads these callbacks/hooks are simply empty with the side effect that things are faster. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
In our previous episode, Graeme Geldenhuys said:
> uses
> {$IFDEF UNIX}{$IFDEF UseCThreads}
> cthreads,
> {$ENDIF}{$ENDIF}
> Classes;
> ---
>
> Question 1:
> Is there an alternative implementation of multi-threading support for
> Unix-type systems -- other than the cthreads unit?
Not.
> Question 2:
> If not, then why do we have the extra "IFDEF UseCThreads" define in
> the uses clause?
In case you don't use threads and want to make a static binary.
> Why can't we just have the following...? By default Windows programs and
> OS/2 programmes have multi-threading support compiled in, why don't we
> do the same for Unix-type systems? I often get the "program not compiled
> with multi-threading support" error and have to constantly define the
> UseCThreads option.
Because the API model of Unix is totally different from Windows and OS/2.
I do think that if Lazarus has separate templates for "LCL app" and "general
app" that the ifdef could disappear from the LCL app, since that is never
static anyway.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
2009/8/27 Michael Van Canneyt : > > Because I want a FPC program to depend only on the Linux kernel, not on the > C library. > > There are FPC programs from 8 years back that still work with the current > kernel. Try that with a program that depends on the C library. The only reason for this is the fact that the rtl is compiled into fpc executables. If fpc had an rtl as a lib (like c), we would be in the same boat. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Michael Van Canneyt wrote: > > Because I want a FPC program to depend only on the Linux kernel, > not on the C library. OK. > There are FPC programs from 8 years back that still work with the current > kernel. Try that with a program that depends on the C library. Sorry if this sounds dumb - it's late in the week. ;-) Is this an issue, even if your program doesn't use any procedures/functions from the dynamically linked C library. For example, a console application that includes the cthreads unit (which dynamically links to C Library), but doesn't actually use the C Library or threads. Would such a console application not run on an 8 year old Linux distro? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Henry Vermaak wrote: > > The linux threading support is part of glibc. See `man pthreads`. > That's why Mattias says that including it by default in lazarus is > o.k., since all the widgetsets depend on libc, anyway. > > Threading on Windows works with Windows API functions. I understand all this, but isn't libc available on all unix-type OSes. If so, then I don't understand why it (threading) must be optional in FPC based applications. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On Thu, 27 Aug 2009, Graeme Geldenhuys wrote: Michael Van Canneyt wrote: Why is threading enabled by default under Windows and not under other platforms? Because it creates a dependency on the C library, which is not always wanted. For Lazarus programs, the dependency exists anyway, so it does not make a lot of sense to have the define. But surely that c library is available on all unix-type systems? To why is that dependency a bad thing? Because I want a FPC program to depend only on the Linux kernel, not on the C library. There are FPC programs from 8 years back that still work with the current kernel. Try that with a program that depends on the C library. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
2009/8/27 Graeme Geldenhuys : > Michael Van Canneyt wrote: >>> Why is threading enabled by default under Windows and not under other >>> platforms? >> >> Because it creates a dependency on the C library, which >> is not always wanted. For Lazarus programs, the dependency exists >> anyway, so it does not make a lot of sense to have the define. > > > But surely that c library is available on all unix-type systems? To why > is that dependency a bad thing? The linux threading support is part of glibc. See `man pthreads`. That's why Mattias says that including it by default in lazarus is o.k., since all the widgetsets depend on libc, anyway. Threading on Windows works with Windows API functions. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Michael Van Canneyt wrote: >> Why is threading enabled by default under Windows and not under other >> platforms? > > Because it creates a dependency on the C library, which > is not always wanted. For Lazarus programs, the dependency exists > anyway, so it does not make a lot of sense to have the define. But surely that c library is available on all unix-type systems? To why is that dependency a bad thing? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
On Thu, 27 Aug 2009, Graeme Geldenhuys wrote:
Hi,
I first asked this question in the Lazarus mailing list, but was told it
may be more appropriate here. When you create a new project in Lazarus,
the default uses clause in the *.lpr file looks as follows:
---
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes;
---
Question 1:
Is there an alternative implementation of multi-threading support for
Unix-type systems -- other than the cthreads unit?
No.
Question 2:
If not, then why do we have the extra "IFDEF UseCThreads" define in
the uses clause?
To be able to disable it ?
Mattias mentioned that when cthreads unit is included, all string access
needs critial sections which will slow down string access for any
unix-type OS.
Now because under Windows, threading support is on by default, does that
mean the same program will run faster under Linux than under Windows?
Why is threading enabled by default under Windows and not under other
platforms?
Because it creates a dependency on the C library, which
is not always wanted. For Lazarus programs, the dependency exists
anyway, so it does not make a lot of sense to have the define.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Why is cthreads unit not included by default
Hi,
I first asked this question in the Lazarus mailing list, but was told it
may be more appropriate here. When you create a new project in Lazarus,
the default uses clause in the *.lpr file looks as follows:
---
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes;
---
Question 1:
Is there an alternative implementation of multi-threading support for
Unix-type systems -- other than the cthreads unit?
Question 2:
If not, then why do we have the extra "IFDEF UseCThreads" define in
the uses clause?
Why can't we just have the following...? By default Windows programs and
OS/2 programmes have multi-threading support compiled in, why don't we
do the same for Unix-type systems? I often get the "program not compiled
with multi-threading support" error and have to constantly define the
UseCThreads option.
---
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes;
---
Mattias mentioned that when cthreads unit is included, all string access
needs critial sections which will slow down string access for any
unix-type OS.
Now because under Windows, threading support is on by default, does that
mean the same program will run faster under Linux than under Windows?
Why is threading enabled by default under Windows and not under other
platforms?
I asked Mattias for a sample project that will show the slowdown, so I
can see by what factor it is slower. He supplied the following program.
-
program bench1;
{$mode objfpc}{$H+}
uses
//cthreads,
//cmem,
classes, sysutils;
var
s1: String;
s2: String;
i: Integer;
s: String;
t: TThread;
begin
//t:=TThread.Create(true);
s1:=IntToStr(Paramcount+12345);
s2:=IntToStr(Paramcount+23456);
for i:=1 to 5 do begin
s:=s1;
s:=s2;
end;
end.
-
Mattias test results are as follows:
Under his Linux machine the above program takes about 7.5 seconds.
Uncomment the cthreads unit: 7.5 seconds
Under OS X the above program takes on his mac book about 15 seconds.
Uncomment the cthreads unit: 21 seconds
On my Linux system I have the following results:
// without cthreads in uses clause
$ time ./bench1
real0m9.971s
user0m9.969s
sys 0m0.004s
// with cthreads in uses clause - but no TThread usage.
$ time ./bench1
real0m9.973s
user0m9.973s
sys 0m0.000s
So on my system having the cthreads unit included by default will make
no difference at all. This is the point I'm trying to make.
Can anybody explain why we have to explicitly enable threading support
under unix-type OSes, but comes standard with Windows?
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
