Re: [fpc-pascal] FPC 3.0.0-rc1 release
Mark Morgan Lloyd wrote: Jonas Maebe wrote: Mark Morgan Lloyd wrote: I've already got both in the fpc.cfg file: # path to the gcclib -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.3 -Fl/usr/lib/arm-linux-gnueabi "make all" in the top level directory ignores your fpc.cfg (by design). [Slaps forehead] I'll be back. Thanks Jonas, that fixes it. To wrap this up and for the benefit of anybody getting here via Google: this is for a Raspeberry Pi with 2014-era Raspbian. Binaries from: http://sourceforge.net/projects/mseide-msegui/files/fpcarm/ Corresponding sources from http://svn.freepascal.org/svn/fpc/branches/fixes_3_0 using svn co Build command line: make NO_GDB=1 OPT='-FL/lib/ld-linux.so.3 -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.3 -Fl/usr/lib/arm-linux-gnueabi' all with OVERRIDEVERSIONCHECK=1 if necessary, and my preference is to also use -O- -gl -Xs- for ease of debugging. Install command line: sudo OPT='-FL/lib/ld-linux.so.3 -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.3 -Fl/usr/lib/arm-linux-gnueabi' make install Those -Fl and -FL options will probably need to be added to fpc.cfg for that specific version of Raspbian. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Jonas Maebe wrote: Mark Morgan Lloyd wrote: I've already got both in the fpc.cfg file: # path to the gcclib -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.3 -Fl/usr/lib/arm-linux-gnueabi "make all" in the top level directory ignores your fpc.cfg (by design). [Slaps forehead] I'll be 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Jonas Maebe wrote: Mark Morgan Lloyd wrote: /usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x88): undefined reference to `_fini' /usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x90): undefined reference to `_init' chmcmd.lpr(238,46) Error: Error while linking chmcmd.lpr(238,46) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted This is also related to the fact that you have an armhf system that uses the directory/file layout of an armel system. Pass -Fl/usr/lib/arm-linux-gnueabi to the compiler, as it is only looking in /usr/lib/arm-linux-gnueabihf for the crt*.o files (which contain those symbols). I've already got both in the fpc.cfg file: # path to the gcclib -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.3 -Fl/usr/lib/arm-linux-gnueabi where the system already has the symlink /usr/lib/gcc/arm-linux-gnueabi/4.6.3 -> 4.6 Doing a brute-force search for crt*.o: /usr/lib/arm-linux-gnueabi/crtn.o /usr/lib/arm-linux-gnueabi/crti.o /usr/lib/arm-linux-gnueabi/crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.6/crtbegin.o /usr/lib/gcc/arm-linux-gnueabi/4.6/crtbeginT.o /usr/lib/gcc/arm-linux-gnueabi/4.6/crtbeginS.o /usr/lib/gcc/arm-linux-gnueabi/4.6/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.6/crtendS.o /usr/local/lib/fpc/3.0.1/units/arm-linux/rtl-console/crt.o /usr/local/src/fpc/fixes_3_0/rtl/palmos/m68k/crt0.o I really do think that I need to get Raspbian upgraded, I know that there are problems with the one currently running. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Jonas Maebe wrote: On 30/08/15 17:36, Mark Morgan Lloyd wrote: [Requesting program interpreter: /lib/ld-linux.so.3] .. $ ls -l /lib/ld-linux.so.3 lrwxrwxrwx 1 root root 28 Oct 16 2014 /lib/ld-linux.so.3 -> arm-linux-gnueabi/ld-2.13.so $ ls -l /lib/arm-linux-gnueabi/ld-2.13.so -rwxr-xr-x 1 root root 122136 Oct 16 2014 /lib/arm-linux-gnueabi/ld-2.13.so You win that one, but I'm still a bit suspicious about what's in this Raspbian: it's almost a year old and seems a bit sensitive to attempted upgrades. The problem is that some old Debian (and hence Raspbian) versions used /lib/ld-linux.so.3 even on armhf, while newer ones (and other distributions) use /lib/ld-linux-armhf.so.3 . Their current release (2015-05-05) does appear to use ld-linux-armhf.so.3 You should be able to work around this problem using the -FL/lib/ld-linux.so.3 compiler option. Confirmed. Is that a setting which should have been created in fpc.cfg during installation (that bit failed, so I'm giving somebody a chance to tell me I should have checked things more carefully when I did it manually :-) See also http://stackoverflow.com/questions/20717838/gcc-arm-executable-no-such-file-orr-directory-wrong-dynamic-lib and the first answer to that question. Noted, but Google overlooked that one earlier although I was being fairly FPC-specific with the search. Almost there I think, but using a command like make OVERRIDEVERSIONCHECK=1 NO_GDB=1 OPT='-O- -gl -Xs- -FL/lib/ld-linux.so.3' all I get .. Linking chm/bin/arm-linux/chmcmd The installer encountered the following error: External command "/usr/local/src/fpc/fixes_3_0/compiler/ppcarm -Tlinux -FEchm/bin/arm-linux -FUchm/units/arm-linux/ -Fu/usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux/ -Fu/usr/local/src/fpc/fixes_3_0/packages/fcl-xml/units/arm-linux/ -Fu/usr/local/src/fpc/fixes_3_0/packages/fcl-base/units/arm-linux/ -Fu/usr/local/src/fpc/fixes_3_0/packages/fcl-res/units/arm-linux/ -Fu/usr/local/src/fpc/fixes_3_0/packages/rtl-objpas/units/arm-linux/ -Fu/usr/local/src/fpc/fixes_3_0/packages/iconvenc/units/arm-linux/ -Ur -Xs -O2 -n -Fu/usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux -V3.0.1 -O- -gl -Xs- -vt -FL/lib/ld-linux.so.3 -darm -dRELEASE -XX -CX -viq chm/src/chmcmd.lpr" failed with exit code 256. Console output: Target OS: Linux for ARMHF Compiling chm/src/chmcmd.lpr Assembling chmcmd make[2]: *** [smart] Error 1 make[1]: *** [packages_smart] Error 2 make: *** [build-stamp.arm-linux] Error 2 Linking chm/bin/arm-linux/chmcmd /usr/bin/ld: warning: chm/bin/arm-linux/link.res contains output sections; did you forget -T? /usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x88): undefined reference to `_fini' /usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x90): undefined reference to `_init' chmcmd.lpr(238,46) Error: Error while linking chmcmd.lpr(238,46) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[2]: Leaving directory `/usr/local/src/fpc/fixes_3_0/packages' .. I see discussion in the past suggesting that this was some residual eabihf issue, but nothing conclusive. Adding an explicit -dFPC_ARMHF doesn't help. If this doesn't have a blindingly obvious solution I'll redo with a newer Raspbian as soon as a colleague finds a spare SDCard. Alternatively, what's the quick-and-dirty way to exclude a single package under the new build regime? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Jonas Maebe wrote: On 30/08/15 15:35, Mark Morgan Lloyd wrote: .. [Requesting program interpreter: /lib/ld-linux-armhf.so.3] .. That file's missing, something's obviously badly wrong with the Rpi filesystem etc.: I strongly suspect that somebody did an incautious update/upgrade/dist-upgrade. What does readelf say about the program interpreter of the system binaries, such as "/bin/ls"? 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: 0xc3f8 Start of program headers: 52 (bytes into file) Start of section headers: 99312 (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: 9 Size of section headers: 40 (bytes) Number of section headers: 28 Section header string table index: 27 .. [Requesting program interpreter: /lib/ld-linux.so.3] .. $ ls -l /lib/ld-linux.so.3 lrwxrwxrwx 1 root root 28 Oct 16 2014 /lib/ld-linux.so.3 -> arm-linux-gnueabi/ld-2.13.so $ ls -l /lib/arm-linux-gnueabi/ld-2.13.so -rwxr-xr-x 1 root root 122136 Oct 16 2014 /lib/arm-linux-gnueabi/ld-2.13.so You win that one, but I'm still a bit suspicious about what's in this Raspbian: it's almost a year old and seems a bit sensitive to attempted upgrades. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Jonas Maebe wrote: On 29/08/15 17:57, Mark Morgan Lloyd wrote: ./fpmake compile --localunitdir=.. --os=linux --cpu=arm -o -Ur -o -Xs -o -O2 -o -n -o -Fu/usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux -o -V3.0.1 -o -O- -o -gl -o -Xs- -o -vt -o -darm -o -dRELEASE --compiler=/usr/local/src/fpc/fixes_3_0/compiler/ppcarm -bu -o -XX -o -CX make[2]: ./fpmake: Command not found make[2]: *** [smart] Error 127 make[2]: Leaving directory `/usr/local/src/fpc/fixes_3_0/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `/usr/local/src/fpc/fixes_3_0' make: *** [build-stamp.arm-linux] Error 2 /usr/local/src/fpc/fixes_3_0$ find . -name fpmake -ls 157069 4460 -rwxr-xr-x 1 markMLl staff 4565218 Aug 29 15:46 ./packages/fpmake /usr/local/src/fpc/fixes_3_0$ file ./packages/fpmake ./packages/fpmake: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped /usr/local/src/fpc/fixes_3_0$ ./packages/fpmake --help -bash: ./packages/fpmake: No such file or directory What does "readelf -aW ./packages/fpmake" print after "Requesting program interpreter:" ? And does that file exist? 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: 0x843c Start of program headers: 52 (bytes into file) Start of section headers: 3549332 (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: 7 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 27 .. [Requesting program interpreter: /lib/ld-linux-armhf.so.3] .. That file's missing, something's obviously badly wrong with the Rpi filesystem etc.: I strongly suspect that somebody did an incautious update/upgrade/dist-upgrade. Leave it with me, I'll be back. p.s. Currently looking at an x86 Android tablet, appears to have a significant amount of ARM code run by emulation. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Martin Schreiber wrote: On Saturday 29 August 2015 15:38:35 Mark Morgan Lloyd wrote: Martin, what would be really useful is knowing /exactly/ what sources you used to build your binary at http://sourceforge.net/projects/mseide-msegui/files/fpcarm/ " svn info Path: . Working Copy Root Path: /home/mse/packs/standard/svn/fp/arm/fixes_3_0 URL: http://svn.freepascal.org/svn/fpc/branches/fixes_3_0 Relative URL: ^/branches/fixes_3_0 Repository Root: http://svn.freepascal.org/svn/fpc Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2 Revision: 31324 Node Kind: directory Schedule: normal Last Changed Author: joost Last Changed Rev: 31297 Last Changed Date: 2015-08-06 22:26:00 +0200 (Thu, 06 Aug 2015) " Starting off with your binary on the system, i.e. with no 2.6.x, I have to use a generic fpc.cfg but apart from that things appear to work. Got sources from svn as above. Attempting to rebuild using a generic command line: make OVERRIDEVERSIONCHECK=1 NO_GDB=1 OPT='-O- -gl -Xs-' all when building fpmake objects about missing crti.o crtbegin.o crtend.o crtn.o. Add -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.3 -Fl/usr/lib/arm-linux-gnueabi Starting over, I get to Free Pascal Compiler version 3.0.1 [2015/08/29] for arm Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for ARMHF Compiling fpmake.pp fpmake.pp(16,3) Note: Local variable "T" is assigned but never used Assembling fpmake Linking fpmake /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 14595 lines compiled, 58.7 sec 1 note(s) issued ./fpmake compile --localunitdir=.. --os=linux --cpu=arm -o -Ur -o -Xs -o -O2 -o -n -o -Fu/usr/local/src/fpc/fixes_3_0/rtl/units/arm-linux -o -V3.0.1 -o -O- -o -gl -o -Xs- -o -vt -o -darm -o -dRELEASE --compiler=/usr/local/src/fpc/fixes_3_0/compiler/ppcarm -bu -o -XX -o -CX make[2]: ./fpmake: Command not found make[2]: *** [smart] Error 127 make[2]: Leaving directory `/usr/local/src/fpc/fixes_3_0/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `/usr/local/src/fpc/fixes_3_0' make: *** [build-stamp.arm-linux] Error 2 /usr/local/src/fpc/fixes_3_0$ find . -name fpmake -ls 157069 4460 -rwxr-xr-x 1 markMLl staff 4565218 Aug 29 15:46 ./packages/fpmake /usr/local/src/fpc/fixes_3_0$ file ./packages/fpmake ./packages/fpmake: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped /usr/local/src/fpc/fixes_3_0$ ./packages/fpmake --help -bash: ./packages/fpmake: No such file or directory I get stuck at the same point irrespective of any -dFPC_ARMHF etc. Now I'm quite sure it's me doing something silly... -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Jonas Maebe wrote: On 29/08/15 11:55, Martin Schreiber wrote: " make PP=/home/pi/fpc/3_0/eabihf/lib/fpc/3.0.1/ppcarm OVERRIDEVERSIONCHECK=1 all " in a fixes_3_0 checkout works for me. Note that Mark is building 3.0.0rc1, not fixes_3_0. Building an older revision with a compiler built from a newer revision is never supported (although in this very specific case, it might work since there are barely any differences between 3.0.0rc1 and the current fixes_3_0 branch). I'm under a bit of pressure to demonstrate that a Raspberry Pi is a "real computer", not just a target for a cross compiler (I've done plenty of that sort of thing in the past). Martin, what would be really useful is knowing /exactly/ what sources you used to build your binary at http://sourceforge.net/projects/mseide-msegui/files/fpcarm/ In any case: you should have to pass OPT="-dFPC_ARMHF" to get an armhf compiler (even if you already start with an armhf compiler). I haven't updated the compiler readme yet, but I've at least mentioned this in the mean time at http://wiki.freepascal.org/FPC_New_Features_3.0#Support_for_the_armhf_EABI Thanks, noted and aware. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Martin Schreiber wrote: On Wednesday 26 August 2015 20:14:09 Mark Morgan Lloyd wrote: Is there a native ARM version compatible with the Raspberry Pi? Here: http://sourceforge.net/projects/mseide-msegui/files/fpcarm/ Please run eabihf/lib/fpc/3.0.1/samplecfg in order to create a default configuration file. /usr/local/lib/fpc/3.0.1/samplecfg: fpcmkcfg: not found # ls /usr/local/lib/fpc/3.0.1 fpmkinst msg ppcarm samplecfg units # ls /usr/local/bin fpc fpc.d fpc-filter-vt mkarmins mkx86ins ppcarm ppcarm-3.0.1 ppudump ppufiles ppumove ..but appears OK with a standard fpc.cfg. Has problems rebuilding 3.0.0 rc1 from source: /bin/mv -f ppcarm ppc2 make 'FPC=/usr/local/src/fpc/fpcbuild-3.0.0-rc1/fpcsrc/compiler/ppc2' 'OLDFPC=/usr/local/src/fpc/fpcbuild-3.0.0-rc1/fpcsrc/compiler/ppc1' next CYCLELEVEL=3 An unhandled exception occurred at $00087480: EAccessViolation: Access violation $00087480 TMESSAGE__GET, line 445 of cmsgs.pas $00057754 MESSAGE, line 767 of verbose.pas $0004F574 COMPILE, line 370 of compiler.pas $8384 main, line 246 of pp.pas That happens several times until the make bombs. Original command line was make OVERRIDEVERSIONCHECK=1 NO_GDB=1 OPT='-V3.0.1 -dFPC_ARMHF -O- -gl -Xs-' 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Martin Schreiber wrote: On Wednesday 26 August 2015 20:14:09 Mark Morgan Lloyd wrote: Is there a native ARM version compatible with the Raspberry Pi? Here: http://sourceforge.net/projects/mseide-msegui/files/fpcarm/ Please run eabihf/lib/fpc/3.0.1/samplecfg in order to create a default configuration file. Cross development environment Linux X86 -> Raspberry Pi is here: http://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/crossfpc-i386_linux_eabihf_3_0_1.tar.gz/download How cross development looks in MSEide: http://mseide-msegui.sourceforge.net/pics/crossarm.png Thanks Martin, I'll look at that. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.0.0-rc1 release
Joost van der Sluis wrote: Hello We have placed the first release candidate of the Free Pascal Compiler version 3.0.0 on our ftp servers. You can help improve the upcoming 3.0.0 release by downloading and testing this release. If you want you can report what you have done here: http://wiki.freepascal.org/Testers_3.0.0 New features are listed at http://wiki.freepascal.org/FPC_New_Features_3.0 Changes that may break backwards compatibility are documented at http://wiki.freepascal.org/User_Changes_3.0.0 Issues with this release candidate that we already know of are listed in the wiki: http://wiki.freepascal.org/Issues_3.0.0 A preview of the 3.0.0 docs is available at http://www.freepascal.org/docs-html/3.0.0/ Downloads are available at: * ftp://freepascal.stack.nl/pub/fpc/beta/3.0.0-rc1 * ftp://gd.tuwien.ac.at/languages/pascal/fpc/beta/3.0.0-rc1 * ftp://ftp.freepascal.org/pub/fpc/beta/3.0.0-rc1 Is there a native ARM version compatible with the Raspberry Pi? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IS operator and library created objects
Michael Schnell wrote: On 08/20/2015 03:42 AM, Fabio Luis Girardi wrote: Everyone know some alternative (or more elegant)... AFAIK FPC does not support using objects (er even strings) cross a dynamic library interface. Unless you explicitly use the cmem library. However even then it's basically restricted to passing/returning strings as procedure parameters/results. Delphi has "Runtime Packages" for this. But those are not (yet) implemented in fpc (which would need to do that for all OSes) So you need to do "flat" library calls: no objects, no strings, ... -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Different idea
Michael Van Canneyt wrote: On Wed, 19 Aug 2015, Mark Morgan Lloyd wrote: Michael Schnell wrote: On 08/18/2015 10:03 PM, Chris Moody wrote: Having issues getting cross compiling to work, so here's another idea: What files would I need to move from Lazarus on my computer to the Pi, so it will be able to find all of the libraries? Or perhaps even better, how can I get the command Lazarus sends to FPC from my computer so I can issue it on the Pi? On a headless ARM system that hence can't run Lazarus, I completely did and tested the application on a Linux PC, with everything that is not available on the target (in that case among other stuff everything GUI related including timers) in a "simulation" unit that provides Stimuli and Debug outputs is appropriate classes. That can nicely be done in a completely Object oriented way using Events (callbacks), properties and functions. A (physically) headless system can run Lazarus etc. without any problems, provided that you can login using X11 (XDMCP), VNC, or SSH. Obviously appropriate underlying libraries are needed (gtk2 or whatever), but apart from that the only caveat is that building Lazarus or programs of any significant size tends to be memory-intensive- but generally within the scope of an Rpi. I use lazbuild succesfully on a machine without any X library installed. Works perfectly for automated final builds of website software. With the caveat that you need to run Lazarus at least once to get the paths etc. set up (i.e. settings stored in ~/.lazarus or as determined by -pcp). -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Different idea
Michael Schnell wrote: On 08/19/2015 10:11 AM, Mark Morgan Lloyd wrote: A (physically) headless system can run Lazarus etc. without any problems, provided that you can login using X11 (XDMCP), VNC, or SSH. Additionally you need a GUI Libray (QT or whatever) I do know that, but running an X server and a GUI Libray takes a lot of RAM Remember that the X server runs on your desktop system if you're using remote X11 (XDMCP etc.) or tunneling over SSH. The most demanding thing on the machine running Lazarus/Lazbuild is when it links. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Different idea
Michael Schnell wrote: On 08/18/2015 10:03 PM, Chris Moody wrote: Having issues getting cross compiling to work, so here's another idea: What files would I need to move from Lazarus on my computer to the Pi, so it will be able to find all of the libraries? Or perhaps even better, how can I get the command Lazarus sends to FPC from my computer so I can issue it on the Pi? On a headless ARM system that hence can't run Lazarus, I completely did and tested the application on a Linux PC, with everything that is not available on the target (in that case among other stuff everything GUI related including timers) in a "simulation" unit that provides Stimuli and Debug outputs is appropriate classes. That can nicely be done in a completely Object oriented way using Events (callbacks), properties and functions. A (physically) headless system can run Lazarus etc. without any problems, provided that you can login using X11 (XDMCP), VNC, or SSH. Obviously appropriate underlying libraries are needed (gtk2 or whatever), but apart from that the only caveat is that building Lazarus or programs of any significant size tends to be memory-intensive- but generally within the scope of an Rpi. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
Michael Schnell wrote: On 08/14/2015 04:38 PM, Mark Morgan Lloyd wrote: It seeds itself with "entropy" from the intervals between LAN packets, intervals between typed characters and so on. Unfortunately "Randomize" (in Linux in "System") just does randseed:=longint(Fptime(nil)); if it would use /dev/urandom, the rand() would be as unpredictable as /dev/urandom unless you fetch more more than some 2 Gig numbers But I suppose you can set randseed in user code, as well, if you want to. I agree, with the caveat that if you read /dev/urandom you can't be sure that there's enough accumulated entropy to give you a good seed, while if you read /dev/random it will block for an indeterminate time- neither of which are desirable behaviours in startup code. A compromise is for a program to wait until it knows it's generated enough entropy (LAN accesses or whatever), and at that point to reseed its random number generator, and that obviously suggests leaving the existing code unchanged. In the past, I've seen people who should have known better caught by Turbo Pascal's inadequate random number generator, and there's still people trying to undo some of the damage caused by RANDU. These days, there's very little excuse for anybody "skilled in the art" to not understand that the random number facility in most languages' default libraries is not crypto grade, and that it is barely adequate for academic-grade simulations. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
Michael Schnell wrote: On 08/14/2015 03:47 PM, Jonas Maebe wrote: My question is: is FPC built-in PRNG good enough as comparing to /dev/urandom? No PRNG is suited for that purpose, because every PRNG is by definition predictable and you need unpredictable numbers for IVs. How should /dev/urandom not be predictable (as any software random generator is) ? It seeds itself with "entropy" from the intervals between LAN packets, intervals between typed characters and so on. Decent Wifi hubs use hardware of some kind. Noise diode, entropy as discussed above, etc. Or they've got broken security, which probably describes the majority. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Android and Atom
I seem to have a tablet with Android 5.0 based on an Intel Atom CPU (Z3735F) here. I've got rather a lot of stuff on my plate so I'm putting off playing with this as long as I can, but can anybody comment on where FPC (and possibly Lazarus) are with this sort of device? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC's documentation license?
Jonas Maebe wrote: On 08 Aug 2015, at 10:04, Michael Van Canneyt wrote: I fundamentally do not believe in licenses. Not even free ones. Hence I specify none for the docs. The problem with this is that if you don't specify a license, the default in copyright law is that no one is allowed to do anything with your work without explicit permission from you (other than reading the HTML version on the web site, as publishing it like that is considered an implicit permission to read it). You can always use a public domain or CC0 license if you don't want to impose any conditions on anyone. Some sort of statement of ownership or permissive licence is desirable, in order to stop somebody appropriating documents etc., treating them as their own property, and slapping on strict redistribution notices to the detriment of the community. As a particular example, the firmware of the classic HP RPN calculators doesn't embed a copyright message, with the result that it appears that it is now free for distribution as a part of e.g. http://nonpareil.brouhaha.com/ which is generally accepted by everybody as good clean fun. However somebody else has started making changes to the firmware and now sells calculators in potential competition with HP http://www.swissmicros.com/ which makes a lot of people unhappy. If the project doesn't put a clear statement of ownership on everything, then there is a risk that somebody will put their own notice on things and claim that their files are the original and anything published by FPC/Lazarus is an unauthorised copy. Sorting things out would probably be messy and expensive. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: I think that the one thing I'd suggest to everybody is that it would be highly desirable if the dangling else fix were guaranteed to break Pascal syntax. As such end if; etc. might be a better choice If you start a different language, yes, the block system would be number one. Do away with oneline vs multiline blocks ambiguity in general. (and not just because of ELSE). Second would be a different procedure-block ending from just "end;" though the M2 way of end "procedurename" is unnecessary hard to maintain. end proc; or end function would be just fine. As usual that doesn't mean I want to micromanage. I don't have to end every block in a specific way. As usual, bounding the major problem (don't let an unterminated block spill over function bounderies) is enough. I came across an odd thing in a paper about ALGOL 60 the other day: "Any character between the symbol end and the first semicolon or end or else following this end is [comment] text." I've never ploughed through the original documents and presume it's in there somewhere, but it does seem like an attractive facility. If you want to merely extend pascal, my fav feature would be qualified vs unqualified import/export control I guesst. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
Marco van de Voort wrote: (don't forget to ask Martin about the language he is creating, I tried to plug some M2 features, maybe you can drive the message home :-) If I'm reading his wiki page properly, at least he's got the bit of M2 that matters- resolution of the dangling else problem- which had already been recognised as sufficiently important to be in ALGOL 68. I think that the one thing I'd suggest to everybody is that it would be highly desirable if the dangling else fix were guaranteed to break Pascal syntax. As such end if; etc. might be a better choice. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
Peter wrote: On 03/08/15 15:41, Gour wrote:> > I probably do not need full power of GTK2(3) or Qt toolkit, I would advise anyway against using LCL (Qt) on Linux at the moment.I understand its based on Qt4, and Qt4 is being dropped in favour ofQt5. At the very least, check how long your distribution will besupporting Qt4. http://perezmeyer.blogspot.co.uk/2014/11/early-announce-qt4-removal-in-jessie1.html I don't think you will get a complete GTK3 in the LCL either at themoment. Its 'alpha' status according to the wiki. That's going to be a problem. On x86 and x86-64 Jessie, my experience so far is that GTK2 doesn't work and that Qt is the only viable option. GOK what it's like on other platforms that might not have such a well-tested Qt 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
Gour wrote: Mark Morgan Lloyd writes: The first option would be a pure Pascal one, driving either a graphical or a text-based (curses etc.) UI. Here you mean fpGUI & MSEgui? No, more than anything I mean going directly to the relevant APIs. Using fpGUI etc. is a potentially-useful shortcut, particularly if their form designers are adequate. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
Graeme Geldenhuys wrote: On 2015-08-03 15:41, Gour wrote:> Is b)’s support for Mac via X11 good-enough or is b) more suitable, as I> read somewhere, for embedded platforms? As I mentioned in a private email, I have written commercial softwareusing fpGUI for the Mac. The client I worked for was not at all phasedby the fact that it used the X11 support included with OSX. Neither werethey bothered by the fact that it doesn't look 100% native (many ofApple's own software doesn't adhere to their own interface guidelines).My client's main concern was that the software is stable and that itworks by delivering the functionality they required - which it did. Having the same look and feel between OSX, Linux and Windows was also aplus for them, as it reduced the amount of staff training on the software. What about learning curve of each one? LCL and fpGUI has pretty much the same learning curve I think. Graeme, could you update us on the extent to which Lazarus or an equivalent IDE supports form design etc. for fpGUI these days? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] which GUI (noob)
Gour wrote: Hello, I’m new to FPC and researching about different GUI options available towrite open-source multi-platform desktop app using FPC… Based on what I’ve found there are mainly three options: a) Lazarus and LCL b) fpGUI c) MSEgui Afaict, a) support all three main OS-es - Linux, Mac & Windows byproviding native look’n’feel although, iirc, Cocoa supprt for Mac is notfinished yet. MSEgui works on Linux and Windows, while fpGUI works on all three OS-esbut on Mac support is done via X11 libs. Now, let me say that Linux (Debian) is my native platform which I useand will develop on it, but would like to provide versions for Mac &Windows. Does it automatically eliminates c) or there is plan to add support forMac? Is b)’s support for Mac via X11 good-enough or is b) more suitable, as Iread somewhere, for embedded platforms? What about learning curve of each one? I probably do not need full power of GTK2(3) or Qt toolkit, but needsome database support - app would use sqlite3 as storage backend. Another concern is that, afaics, both b) and c) are mostly one-manproject, while a) has much larger community behind. Any advice is helpful? The first option would be a pure Pascal one, driving either a graphical or a text-based (curses etc.) UI. However in practice I think you'll find that the majority in here who have any interest in GUI support use Lazarus. I tend to use the FPC+Lazarus combination on (Debian) Linux targeting x86 (including -64), SPARC, PPC and sometimes ARM, MIPS is also getting there slowly. Sometimes also x86 Windows and SPARC Solaris, and other people regularly target OSX etc. There is a bit of a problem in that all of us tend to test the less popular combinations somewhat sporadically, and at present some of these really do require careful choice of compiler version and- if using Lazarus- widget set. fpGUI and MSEgui definitely have their good points, they're lean and are only mean in self-defence :-) -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interactive command recognition & mapping to program functions & other 'cli' features as a unit
Lukasz Sokol wrote: On 31/07/15 16:41, Mark Morgan Lloyd wrote: Lukasz Sokol wrote: On 31/07/15 14:46, Mark Morgan Lloyd wrote: Lukasz Sokol wrote: Hi, I tried piecing something like in $topic together, intended as an 'interactive' command interpreter for my program. (which will in time grow an 'embedded' web server and intended to run as a (windows) service, but it's too early for that at the moment) Looking at your question another way, I suppose that you also have the issue of parsing a command as well as handling the data entry. I think that there's various possibilities here depending on what you're trying to handle: * A simple sequence of names/numbers. Supposedly this would do, parameters mostly are numbers (but when parsing through a TStringList everything is a string first anyway, so I can define some rules as to which parameter is what type) Parse the first word to an enumeration, feed that to a case. Leave options for terminating characters, case sensitivity and so on. * A unix-style command line, with leading options. Would be nice, however I don't need 'if' or explicitly defined looping instructions... No, I mean parsing of options starting - or -- together with their parameters. 'if' etc. are part of the shell, so are a distinct issue. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interactive command recognition & mapping to program functions & other 'cli' features as a unit
Lukasz Sokol wrote: On 31/07/15 14:46, Mark Morgan Lloyd wrote: Lukasz Sokol wrote: Hi, I tried piecing something like in $topic together, intended as an 'interactive' command interpreter for my program. (which will in time grow an 'embedded' web server and intended to run as a (windows) service, but it's too early for that at the moment) Looking at your question another way, I suppose that you also have the issue of parsing a command as well as handling the data entry. I think that there's various possibilities here depending on what you're trying to handle: * A simple sequence of names/numbers. * A unix-style command line, with leading options. * A sequence of email/HTTP headers. * XML. * Any of the above but with macro and/or numeric evaluation. I note in particular that PostgreSQL uses Flex and Bison, and if they'll parse (a fairly comprehensively extended) SQL I guess they'll parse about anything. Apart from that I've hacked something together for my own use based on Smalltalk (as an outer parser) with various evaluation possibilities (as an inner parser), this was intended as a way for programs to talk to each other and has its good points. I'm not sure whether getopts from the RTL provides a facility for you to feed it an arbitrary string for processing, but it would probably be a good place to start. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interactive command recognition & mapping to program functions & other 'cli' features as a unit
Lukasz Sokol wrote: Hi, I tried piecing something like in $topic together, intended as an 'interactive' command interpreter for my program. (which will in time grow an 'embedded' web server and intended to run as a (windows) service, but it's too early for that at the moment) (I hooked some events of a TMemo to my interpreter, which currently recognizes commands by a static map/array of record of string and function pointers; and passes the rest of command line to the called function as string, then the function is a shim/wrapper over the deeper program functions; the entire parameter sanitizing and conversion from string to what the 'deeper' function expects, is done in the 'wrapper' function layer, and so is the function output converted back to string and spat out to the TMemo. It's growing too complicated to maintain for the purpose, day by day, and has problems with some more interactive commands or tab completion... Is there something I could use for the purpose that is ready-made, tested, free and open source AND of course in FreePascal ? (I can share my changes back if I do any, can't open the entire application though) Any hints, Any keywords, any lmgtfy's are welcome :) This might be better in the Lazarus mailing list. I've knocked together a special-purpose terminal emulator, it's actually an IBM 2741 terminal which uses totally non-standard codes internally and I wanted something for APL, early ALGOL implementations and so on. This is obviously character-by-character, and I was just about able to get something working for TMemo, TRichMemo and TListBox. Somebody else mentioned TCmdBox (?) but I wasn't able to get it working adequately and in the end discarded most of my attempts, it might be worth looking at if you're trying to process lines rather than characters. I think this was discussed a few months ago, and consensus was that there wasn't an adequate terminal emulator component. See below. http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Xterm-konsole-etc-td4031905.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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Modems etc.
Lukasz Sokol wrote: On 24/07/15 12:12, Mark Morgan Lloyd wrote: It turns out that there's a more-or-less off-the-shelf solution in SpanDSP http://www.soft-switch.org/ which is one of the libraries that underlies IAXmodem. It provides a function to process a block of samples, hence a callback to simulate the Rx side of a UART; since it's C (rather than C++) it should be possible to mix it with FPC code. Cool, bookmarked ;) That also does G.711 and others. On unix, I think a soft modem should be accessible via the pty mechanism. But I think this still leaves us with a shortage of (Lazarus) components for writing general-purpose terminal emulators. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Basic Sockets in FreePascal
Coyo wrote: On Sun, 26 Jul 2015 15:47:52 + Mark Morgan Lloyd wrote: Michael Van Canneyt wrote: On Sun, 26 Jul 2015, Coyo wrote: I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it. This is not correct. Of course Free Pascal has native support for socket handling ? I will link the wiki articles later to demonstrate the difficulty of using sockets in FPC. However, I do appreciate the advice. How do you import a unit/library in FPC? Is there a .deb package or something that I install? Most of what you need comes as part of FPC. There's a very rough split between the Run-time Library (RTL) and Free Class Library (FCL), all you need is the uses statement. When compiling or distributing compiled FPC codebases that use external units or libraries in FPC, how do you go about doing that? I failed to find documentation illuminating how one goes about doing this. Any enlightenment would be greatly appreciated. Most of what you need comes as part of FPC. I dislike object oriented programming, it makes something that should be very simple, compact and portable to something more complex than it really has to be. But that's just a personal preference. Thankfully, FPC lets me use purely functional programming if I prefer to do so. Java and new Perl force object oriented programming down my throat, and is part of the reason I have a deep interest in FPC. I want to keep it stupid simple. I prefer, when possible, to avoid using external dependencies, and to keep all code in a single file. While I am not a supergenius coder or anything, I CAN appreciate elegantly-written code. Compact source code and compact binaries are something I can appreciate. Overuse or gratuitous use of external libraries and dependencies disturbs me. I'm afraid that you're going to have to get used to pulling in units from the RTL and FCL, and some of these mandate using OO. If it gives you problems then ask for help. I don't mean to be irritable, but I've heard "don't reinvent the wheel" far too many times, especially when defending centralized or dangerously homogenous networks and systems, rather than multiple implementations and diversity in network components and systems. I would very strongly recommend against trying to reimplement a complex protocol from scratch. You'll make the same mistakes that early implementers made, and your code will be vulnerable to the same attacks. One can argue over-reliance on a single implementation of a cryptographic library, namely OpenSSL, is actually a security RISK rather than a benefit. See: Heartbleed. ONLY OpenSSL-dependent applications, systems, and services were affected by that programming failure. Ditto. The IRC bot I have now uses a shell script to invoke it, and establishes the connection using netcat and standard input/output. I want to eliminate netcat from being a dependency. I can worry about TLS and whatnot later. If you're invoking netcat as an external program to handle your comms you're doing something very badly wrong. Netcat (and equivalents such as netpipes, i.e. hose/faucet) is great at what it does which is handling scripted socket access, but you really shouldn't be using it as part of custom code. I'm used to Perl, Python and Ruby, which all have systems of making using standard libraries trivial. C doesn't really have anything like that. I don't much like seeing that, but I suppose the assertion is justifiable since you usually need to specify both a .h file and the name of a library. For FPC, you only need a uses statement, the linker side is done automatically. I would greatly appreciate a definitive answer on how to go about using Synapse for things, since the wiki and docs I have found are either ancient, inconsistent, unclear, or incomplete. I would be happy to update the wiki, if you want me to. If there's something that's giving you trouble in the Wiki please give us a URL and tell us what the ambiguity or error is. The reason I want to have sockets internal to FPC instead of using an external tool such as netcat is because I want to use one of the core features of FPC, namely portability of code. FPC has incredible code portability. It is trivial to compile code for a huge selection of target platforms, and I would prefer my code to be as portable as possible, and rely on as few dependencies as possible. However, implementing an entire userspace TCP/IP protocol stack in FPC is something I am NOT ready to do at this time, especially for a simple IRC automaton. Maybe later... Do not even dream about trying to implement an IP stack from scratch. I've done that sort of thing for very specific purposes (e.g. a test program that's trying to work out whether it'
Re: [fpc-pascal] Basic Sockets in FreePascal
Michael Van Canneyt wrote: On Sun, 26 Jul 2015, Coyo wrote: I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it. This is not correct. Of course Free Pascal has native support for socket handling ? Knowing the URL of that wiki page would be useful, so that we can fix it if it really is broken. What version of FPC is the documentation for? I want to write an IRC bot in FreePascal, but I need the ability to both make outgoing connections to IRC servers or other bots of the same kind, as well as accept incoming connections from other bots. I'd prefer as straightforward TCP sockets support as I can get. Any advice would be greatly appreciated. Thank you in advance for your time and patience. Just use the sockets or ssockets units. The first is plain pascal and a straightforward interface as you encounter it in any C implementation, the second is using classes. Seconded, it's something I do on a regular basis when I have to do something with a non-standard protocol. However I think there's a couple of points worth considering. The first is that the Pascal /language/ doesn't have implicit support for sockets, you need to import an appropriate unit/library. That's going to be the case for almost all general-purpose languages, with the exception of things like Perl and Python which try to build in everything a programmer might need including the kitchen sink. The second is that for standard protocols like FTP and HTTP it might be better to use a third-party library to avoid reinventing the wheel when it comes to security etc., some of these- for example Synapse- are routinely used by almost everybody but aren't packaged with FPC because their developers prefer to stay independent. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Parsers and Unicode
Michael Van Canneyt wrote: On Fri, 24 Jul 2015, Mark Morgan Lloyd wrote: When writing something like a parser, does FPC have anything that exposes the properties of each Unicode codepoint? I'm thinking in particular of Unicode properties like BidiMirroring, which Perl6 uses to define bracketing characters. ftp://ftp.unicode.org/Public/UNIDATA/BidiMirroring.txt Yes it does. You can use the character or unicodedata units. But this is only available in trunk, and the upcoming 3.0 release. Thanks for that, and thanks also to whoever did the hard work :-) -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Parsers and Unicode
When writing something like a parser, does FPC have anything that exposes the properties of each Unicode codepoint? I'm thinking in particular of Unicode properties like BidiMirroring, which Perl6 uses to define bracketing characters. ftp://ftp.unicode.org/Public/UNIDATA/BidiMirroring.txt -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Modems etc.
Lukasz Sokol wrote: On 20/07/15 17:32, Mark Morgan Lloyd wrote: Lukasz Sokol wrote: It's been years since I had anything to do with DSP, unfortunately, but with the FFT running on the sliding 26-sample-long window, and a /reverse/ FFT to produce the 26-long sample from just having a byte or 2 written to an array, the kind of SIMD processing probably won't be very time consuming... and, operating on a fixed size array, would be of fixed-processing-time, which is usually handy. Thanks, noted. I must admit that I've never dabbled directly with FFT, but perhaps now is the time to start. I need to do a couple of test simulations first to demonstrate that working in the frequency domain is more promising than the time domain (I'm having to fight off the boss's suggestion that I simply time zero crossings). Just my £0.02p :) el es Worth more than you think http://www.bbc.co.uk/news/uk-england-berkshire-33586245 :-) :) Thinking about it some more, it could actually be true that FFT/DFT is overkill. For detection you need 4 specialized discrete band-pass (1 freq pass) filters, checking their output 'power' (side note : moving average can be used as detector on their outputs) and you can use them for sending too - just feed them white noise to the input :) there are some advantages to that which this email is too short to contain ;) It turns out that there's a more-or-less off-the-shelf solution in SpanDSP http://www.soft-switch.org/ which is one of the libraries that underlies IAXmodem. It provides a function to process a block of samples, hence a callback to simulate the Rx side of a UART; since it's C (rather than C++) it should be possible to mix it with FPC 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Modems etc.
Lukasz Sokol wrote: On 20/07/15 10:49, Mark Morgan Lloyd wrote: Lukasz Sokol wrote: Hi Mark, On 18/07/15 17:43, Mark Morgan Lloyd wrote: Has anybody used FPC to decode (and generate) FSK modem tones on a VOIP connection? Strictly V.21, don't need the complexity of QAM etc. i haven't ;) but it's interesting: are you just assembling/decoding the ulaw/alaw/choose$codec data into/from RTSP and sending/receiving through a SIP voice connection? How real-time does this need to be, to start with? Real-time enough to simulate a V.21 modem as the backend of a comms program running a proprietary telemetry protocol. I gather you have more data about this protocol to see where it can handle the 'processing time' of the far side receiver, and the rest can be just handled by playing 'recorded audio'. The protocol's no problem, but I need to handle the calls in realtime since processing several dozen a day offline would be... inconvenient. Before anybody criticises use of an obsolete modem type, I suggest they consider how long it takes to set up a V.21 call and transfer a few dozen bytes compared with the training time of something more sophisticated. Not criticizing anything ;) Leaving aside the call control for the moment, my current thoughts are to accumulate G.711 over UDP into a buffer ensuring this is a multiple of four samples, g711 can be ulaw or alaw IIRC (g711u g711a) ( not sure if this is relevant for you, but the codecs tend to have separate settings entities and even executables in any audio transcoding software, so I thought I bring this up, https://en.wikipedia.org/wiki/G.711 ) We've already got conventional modems working over G.711, and my understanding is that the selection between ulaw and alaw is basically a table lookup. (if g711 codec is transcoded to/from raw audio maintaining the 8kHz sampling rate, then don't you need 26 - 27 samples to fill up the mark/space slot for sending? Yes, with the length of each sample varying to try to keep the timing right. Still no great problem, particularly since what we send is rarely much more complex than a standard ack/nak. Receiving, you probably need to interpret your filter/fft output whether you have enough samples accumulated and levels of the frequency peaks detected, and act on that) FFT is probably overkill. Picking out the peaks is obviously one way of doing it, but the code would run more smoothly (i.e. fewer pipeline stalls) if as much as possible could be run with linear sequences of operations hence- if possible- rolling averages etc. use x86 MMX facilities to extract the mark/space frequencies, and something like a rolling average to measure which of those is dominant. The wikipedia page has some (pseudo)code on transcoding from g711 to audio sample(s), maybe it could help ? Doesn't seem very complicated ;) It's been years since I had anything to do with DSP, unfortunately, but with the FFT running on the sliding 26-sample-long window, and a /reverse/ FFT to produce the 26-long sample from just having a byte or 2 written to an array, the kind of SIMD processing probably won't be very time consuming... and, operating on a fixed size array, would be of fixed-processing-time, which is usually handy. Thanks, noted. I must admit that I've never dabbled directly with FFT, but perhaps now is the time to start. I need to do a couple of test simulations first to demonstrate that working in the frequency domain is more promising than the time domain (I'm having to fight off the boss's suggestion that I simply time zero crossings). Just my £0.02p :) el es Worth more than you think http://www.bbc.co.uk/news/uk-england-berkshire-33586245 :-) -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Modems etc.
Lukasz Sokol wrote: Hi Mark, On 18/07/15 17:43, Mark Morgan Lloyd wrote: Has anybody used FPC to decode (and generate) FSK modem tones on a VOIP connection? Strictly V.21, don't need the complexity of QAM etc. i haven't ;) but it's interesting: are you just assembling/decoding the ulaw/alaw/choose$codec data into/from RTSP and sending/receiving through a SIP voice connection? How real-time does this need to be, to start with? Real-time enough to simulate a V.21 modem as the backend of a comms program running a proprietary telemetry protocol. Before anybody criticises use of an obsolete modem type, I suggest they consider how long it takes to set up a V.21 call and transfer a few dozen bytes compared with the training time of something more sophisticated. Leaving aside the call control for the moment, my current thoughts are to accumulate G.711 over UDP into a buffer ensuring this is a multiple of four samples, use x86 MMX facilities to extract the mark/space frequencies, and something like a rolling average to measure which of those is dominant. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Modems etc.
Has anybody used FPC to decode (and generate) FSK modem tones on a VOIP connection? Strictly V.21, don't need the complexity of QAM 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Duplicate RTLs
Marco van de Voort wrote: In our previous episode, Adriaan van Os said: Marco van de Voort wrote: Also RTTI like class info (not used over typinfo unit) like IS, AS, .InheritsFrom? IOW Objecttype identity operations. Thanks for the info. I suggest to document this somewhere. But I am not (in my own code projects) using RTTI, class info, FPC memory allocation, reference counted types, exception catching or global variables. Which explains that I never got in trouble there. Note various to/from string and date types use locale info that is also duplicated. Basically everything that uses RTL state + anything that uses compiler generated tables. (there is two times RTL state and there can be two copies of those compiler tables). Plus if using the Lazarus IDE/LCL, you can have forms embedded in a DLL (or unix .so) rather than in the main program. It's possible to copy stuff between the two to e.g. merge menu structures: it takes work but isn't particularly painful. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC linking syntax error
patspiper wrote: On 21/06/15 14:58, Marco van de Voort wrote: In our previous episode, patspiper said: Compiling the following simple program (from fpc prog manual http://www.freepascal.org/docs-html/prog/progsu46.html#x53-520001.2.46) yields a linking syntax error: Is this a bug? Not of a general kind, since it works on most Linux distros. E.g. it works fine on my debian jessie 64-bit. So it must be something particular to your Linux installation or distribution. So best is to tell something about that installation. Ubuntu 11.04 32bit fpc 3.0.1 and 3.1.1 (not sure which rev but max 2 weeks old) ld version: GNU ld (GNU Binutils for Ubuntu) 2.21.0.20110327 Can you try with a different linker version? I've previously had problems with ld 2.21 on SPARC Solaris which apparently is acknowledged as a bad build, I was able to work round them to some extent by giving fpc an option like -k-T/some_path_here/ldscripts/elf32_sparc.x -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] loadlibrary() unsafe ?
fredvs wrote: @ Ewald and Mark => thanks for answer. ;-) Yep, i agree, the process is "exotic" but works so good. I have to agree too, following Martin Schreiber way: => export LD_PRELOAD=$LIBPORTAUDIO, before to run the executable works too. And is maybe safer. And do not need dynlibs in uses section. And no need to unloadlib(). So, in short, use loadlibrary() to pre-load a library works but better not use it ;-) The best way would be to first find out what package in the OS installs the symlink or files you need, and to document this as a prerequisite. The next-best way would be to investigate whether the wrapper can set LD_LIBRARY_PATH and export this to the loaded program. The next-next-best way would be LD_PRELOAD, since this potentially has path issues of its own. After that comes the way you first thought of :-) For problems like this, man ld.so is your friend. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] loadlibrary() unsafe ?
fredvs wrote:
- For [...], the eSpeak source produces a executable without static
espeak-library nor static portaudio-library included in executable.
So both espeak-library and portaudio-library must be installed in library
path of the system.
If libraries are not installed in library path of the system, a trick that
works is:
To do run the program =>
- first dynamic load portaudio with
loadlibrary('/the_path_you_want/libportaudio.so').
- then dynamic load libespeak with
loadlibrary('/the_path_you_want/libespeak.so').
- run the executable via TProcess (speak).
All is working like charms.
Now i heard that this trick is unsafe.
Why ?
I suspect that the point is that whatever reference counts that the OS
maintains for the library will be decremented if the outer program
terminates, at which point the demand-loaded code will be removed from
memory.
Before trying anything like this, I suggest that it would be worth
finding under what circumstances appropriate symlinks etc. are set 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finally, exceptions and so on.
Ewald wrote: On 05/14/2015 04:17 PM, Mark Morgan Lloyd wrote: So in effect, both an exit and a raise first execute the innermost finally, then look for procedure end or exception block repeating as necessary. Yes. These are the only cases where syntax needs to be unwound in this way. Well... There is also continue and break. The following program will also execute the Finally statements before exiting the loop: Thanks for that. Any others that occur to 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finally, exceptions and so on.
Ewald wrote: On 05/14/2015 12:08 PM, Mark Morgan Lloyd wrote: Is there a single place in the documentation where this sort of behaviour is described and prioritised, Your first fragment is documented on http://www.freepascal.org/docs-html/ref/refse103.html At the bottom of that page: `Note that an Exit statement enclosed by a try .. finally block, will still execute the finally block.` That's definitely the most useful page I've found, but the pertinent bit is "If, however, an exception occurs, the program flow is immediatly transferred from the point where the excepion was raised to the first statement of the Finally statements. [...] and then the exception will be automatically re-raised." (minor spelling mistakes in 2.6.4 17.3). So in effect, both an exit and a raise first execute the innermost finally, then look for procedure end or exception block repeating as necessary. These are the only cases where syntax needs to be unwound in this way. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finally, exceptions and so on.
Jonas Maebe wrote: On 14/05/15 13:18, Mark Morgan Lloyd wrote: Except that- as I understand it- when the reference count is decremented to oblivion, it will be destroyed by "magic" code in the context of the block it was created in. At which point exactly they will be destroyed is an implementation detail that is expressly undefined. Thanks very much for that Jonas. So I think it leaves the only "magic" being that exit always goes via the live finally blocks, or is there equivalent behaviour for raise? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finally, exceptions and so on.
Michael Van Canneyt wrote: On Thu, 14 May 2015, Mark Morgan Lloyd wrote: Starting off with this fragment begin // Start of procedure/function try ... if something then exit; ... finally ... end end; My understanding is that exit "magically" transfers control into the finally block before exiting the procedure. However to state the obvious, in this fragment begin // Start of procedure/function try ... if something then exit; ... except ... end end; control doesn't go via the except block. That is as designed. There is no exception, so no need to go in the exception. Yes, obviously. However I'm interested in the cases where (1) a try-finally is embedded in a try-except and (2) try-except is embedded in try-finally, and the order that exit and any potential equivalents disentangles things. Is there a single place in the documentation where this sort of behaviour is described and prioritised, taking into account interfaces etc.? http://www.freepascal.org/docs-html/ref/refse103.html#x214-22400017.3 What does 'taking into account interfaces' have to do with exceptions ? They are unrelated. Except that- as I understand it- when the reference count is decremented to oblivion, it will be destroyed by "magic" code in the context of the block it was created in. Same obviously applies to strings, dynamic arrays and so on. Are there any other cases where this sort of thing happens? I've got a horrible feeling that I'm not expressing my question well. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Finally, exceptions and so on.
Starting off with this fragment begin // Start of procedure/function try ... if something then exit; ... finally ... end end; My understanding is that exit "magically" transfers control into the finally block before exiting the procedure. However to state the obvious, in this fragment begin // Start of procedure/function try ... if something then exit; ... except ... end end; control doesn't go via the except block. Is there a single place in the documentation where this sort of behaviour is described and prioritised, taking into account interfaces 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CRTI.O and CRTN.O not found
Marco van de Voort wrote: In our previous episode, Anthony Walter said: A user on my forums sent me this message. I've experienced the problem as wee for quite some time. I was wondering if anyone has a universal fix for it yet since it seems to happen so frequently to many people? Basically the problem is that files that come with the system (read: distribution) are not detected. There are two common causes: 1. The user didn't install Linux properly, and didn't prepare the system for development. ( installing package "build-essentials" on Debian iirc) 2. The files are installed but not found. The line to check is the -Fl line in fpc.cfg. This can be a mistake in FPC packaging, or build-essentials being installed after FPC, thus the FPC package's detection being run while the files were not there yet. I've seen this on Solaris where the FPC installation script was broken, but otherwise the only time it happens is if I move an fpc.cfg file from one system to another where the underlying gcc etc. version is different. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Do the make commands have a way of listing the options and possible values for them?
Tomas Hajny wrote: On Tue, March 31, 2015 15:18, Jonas Maebe wrote: vfclists . wrote on Tue, 31 Mar 2015: The ./configure command used by a lot of unix programs can list the options and possible values for them. Note that ./configure can only do this if someone explicitly added information about all of those options to the help text of a particular configure script. Do the make commands for Lazarus and FPC have such an option? No, nobody has written such a help text for the FPC or Lazarus makefiles. There is some information in the documentation, but it hasn't been updated in a long time and is both incomplete and largely out of date. For completeness - "make help" is supported for at least both the fpcbuild and fpc Makefiles, but their content is limited to listing the Makefile targets (and even that it somewhat outdated these days) and it does not include any information about additional options modifying the overall behaviour. If anybody works on this please could they link to 24789 on Mantis which is sitting there unassigned. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] [No subject]
___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] getaddrinfo
Ewald wrote: On 03/20/2015 04:14 AM, MegaBrutal wrote: I also need some help with using the function, as it works very strangely on Linux, as it returns addrinfo structures, but the ai_addr member is always a null-pointer, which is theoretically impossible by the manual, in my understanding. As Mark suggested, perhaps a bug in the fpc implementation (fpc does not normally use lic for it's syscalls)? Try defining the function manually, using libc's equivalent and see if it produces the same result? The only context I've looked at that in was a server program which under some circumstances reported the address of an IP4 client formatted as IP6. It wouldn't be easy for me to get back into that at the moment, but I reported an ordering problem (Mantis 22605) and had my concerns partly allayed. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] getaddrinfo
Top-posting moved. Please don't. MegaBrutal wrote: 2015-03-20 4:14 GMT+01:00 MegaBrutal : Hi all, I'm working on an cross-platform application with DNS resolution with IPv6 support, but I can't really get around how should I handle IP version independent DNS resolution. After some searching, I see getaddrinfo might be a convenient solution, since it is implemented on multiple platforms, as it is POSIX-standard. Windows and Linux both have it. Which unit should I link on Windows and Linux to get getaddrinfo? On Linux, I managed to link it through cnetdb, though probably there is a better way. On Windows, I tried Windows, WinSock and WinSock2, but neither has it. I also need some help with using the function, as it works very strangely on Linux, as it returns addrinfo structures, but the ai_addr member is always a null-pointer, which is theoretically impossible by the manual, in my understanding. Though if you have a better idea for cross-platform and IP version independent network handling with Free Pascal, I'm all ears! > Hi, > > Can anyone help me with this? I don't know to what extent the core developers are using IP6, so there's always a possibility that there are undetected problems. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Portable coroutines
Michael Schnell wrote:
On 03/20/2015 11:09 PM, Mark Morgan Lloyd wrote:
Efficient implementation of coroutines requires CPU-specific code in
the RTL and possibly the compiler. However
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html suggests a
way that coroutines can be implemented in a portable fashion in C, how
can this be done in Object Pascal?
Lazarus seems to supports a similar concept by using events and
"Application.ProcessMessages". it might not be especially efficient,
though.
My tentative solution simplifies to the excerpt below, which I think is
reasonably efficient.
..
// Check that we're not trying to jump into exception blocks etc. Valid
// line numbers are known to be > 0, the assertion is CPU-specific.
if state.line > 0 then begin
SetJmp(sanity);
Assert(PtrUInt(state.env.sp) shr 1 xor PtrUInt(state.env.bp) =
PtrUInt(sanity.sp) shr 1 xor PtrUInt(sanity.bp),
'Bad stack frame at xfer to line ' +
IntToStr(state.line - 1));
LongJmp(state.env, state.line)
end;
if SetJmp(state.env) = 0 then begin
state.line := StrToInt( (*$I %LINE% *) );
exit('A')
end;
if SetJmp(state.env) = 0 then begin
..
Pity about the StrToInt(), which in principle could be resolved at
compilation time.
--
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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Portable coroutines
Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Efficient implementation of coroutines requires CPU-specific code in the
RTL and possibly the compiler. However
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html suggests a
way that coroutines can be implemented in a portable fashion in C, how
can this be done in Object Pascal?
Seems more an oddity than a system, but it relies heavily on preprocessor
and fallthrough case.
The preprocessor part can be done, just use whatever preprocessor
(maybe even cpp) and then haul the resulting code through fpc.
But there is no fallthrough case (and personally I think that is a good
thing)
Generally agreed. I'm not particularly bothered about the syntax,
although obviously having it fairly compact would be an advantage. I
don't think it's possible to use a case/goto arrangement since this
wouldn't be happy jumping into repeat or while loops, but it does look
as though it's possible to use LongJmp() (insomnia has its advantages):
program coroutines;
uses SysUtils;
typeTState= record
env: jmp_buf;
line: cardinal
end;
var state: TState;
once: boolean= false;
scratch: char;
function getchar(): char;
var sanity: jmp_buf;
begin
// Check that we're not trying to jump into exception blocks etc.
if state.line <> 0 then begin
SetJmp(sanity);
Assert(PtrUInt(state.env.sp) + PtrUInt(state.env.bp) =
PtrUInt(sanity.sp) + PtrUInt(sanity.bp),
'Bad SP or BP at xfer to line ' + IntToStr(state.line));
LongJmp(state.env, 1)
end;
SetJmp(state.env);
if state.line = 0 then begin
state.line := StrToInt( (*$I %LINE% *) );
exit('A')
end else
state.line := 0;
..
repeat
SetJmp(state.env);
if state.line = 0 then begin
state.line := StrToInt( (*$I %LINE% *) );
exit(#$ff)
end else
state.line := 0;
once := true
until once
end { getChar } ;
begin
FillByte(state, SizeOf(state), 0);
scratch := getChar();
while scratch <> #$ff do begin
WriteLn(scratch);
scratch := getChar()
end
end.
The sanity check at the start is obviously processor-specific, but it
doesn't use anything hidden and can at a pinch be omitted. It's
obviously excessively verbose, but it is comparatively regular and does
appear to handle at least some loop types properly.
--
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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Portable coroutines
rpzrpz...@gmail.com wrote: Maybe look at the coroutine implementation in Go (Golang). Maybe a better refrence. Maybe an optional switch in compiler so you are not required to have all CPU architectures working on day 1. Intel and ARM seem nice... The issue isn't the syntax, it's that proper implementation of coroutines means switching stacks which is highly architecture-specific; adding something like that to the RTL is a non-starter. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SVN Protocolo implementation
Antonio Sanguigni wrote: Hello, I would like to know if there is a OP implementation of SVN Protocol. I know there is a LazSvnPkg but it is basde on TProcess and communication with SVN bin. This would be my second chance so my question. I would prefer a OP implementation, even if very basic like import, commit and update. I wonder whether libsvn would do what you want. Google suggests that Dmitry Boyarintsev was looking at 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Portable coroutines
Efficient implementation of coroutines requires CPU-specific code in the RTL and possibly the compiler. However http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html suggests a way that coroutines can be implemented in a portable fashion in C, how can this be done in Object Pascal? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Michael Schnell wrote: On 03/20/2015 12:18 AM, Coyo Stormcaller wrote: With a Userspace TCP/IP stack, I can send strange traffic with a raw UDP port. In fact colleagues of mine once in Delphi implemented a TCP - like solution that uses UDP transfer to do secure, especially low overhead transfers via GPRS. So I understand that such User-space IP stack extensions might make sense in certain cases. But a User-Space "TCP/IP-Stack" implementation that sits on naked Ethernet does not seem to make any practical sense. It does if the objective is to experiment with variant protocols. Also remember that things like nmap already reimplement some parts of IP, so there's strong precedent. I don't know what language implementation would be best for the job. The problem is that it's convenient to be able to overlay e.g. an IP packet with a predefined type e.g. a record describing the header followed by an array encompassing the data, however the actual length of the data is unknown at compilation time which means that hardware-supported bounds checking is less than useful. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Coyo Stormcaller wrote: On 03/19/2015 04:25 AM, Mark Morgan Lloyd wrote: While it is possible to write a complete stack from scratch in any reasonably-complete programming language, and while this has been done for e.g. embedded systems (or by idiots such as myself for demonstration/testing purposes :-), in practice it's avoided on account of (a) the amount of well-tested code that it would attempt to supplant and (b) consideration of the difficulty of implementing all required services in a single program. My interest in Userspace TCP/IP stacks is mostly due to being able to make dramatic modifications to the stack itself without modifying the kernelmode stack, and the ability to route without touching system calls to the socket system. With a Userspace TCP/IP stack, I can send strange traffic with a raw UDP port. I'm developing a version of TCP/IP that uses 512-bit DHT hashes as addresses. When a packet is being routed to an unfamiliar destination IP, it uses Kademlia routing to reach the destination. The host itself has an internal router. All stacks in IPvCoyo have IP routing enabled. Only the first connection is routed in this inefficient way. Along the way, a bidirectional label-switching tunnel is constructed. Subsequent packets are switched rapidly. This is efficient enough that no hardware acceleration is needed. This system is based on CJDNS, but rather than stopping at an IPv6 address, it goes further, altering TCP/IP itself to have full 512-bit DHT hashes as endpoint identifiers. Obviously, applications need to support the socket system. That's where a userspace TCP/IP stack comes in. Applications can use pipes to send and receive traffic to another userspace application (the stack), or preferably, link to it as a dynamically-linked library and send and receive calls to that library. Maybe, if people like the system enough, it can be ported to hardware-accelerated kernelmode code. But for now, modifying a userspace TCP/IP stack seems like the most reasonable approach. If you're wondering why I want to re-design TCP/IP it's because of a dare. I won't lose! Interesting. I've seen at least one complete stack written in Pascal, although I can't remember what it was using as the low-level device: back in the DOS days when such things were common they'd usually have used Packet Driver. My partial implementations (embedded in test routines in a comms program) were on top of SLIP and PPP, my suggestion would be to start off with a simple conventional stack on top of SLIP and to test it against slirp running on Linux. IP etc. are basically fairly simple protocols. The complexity comes from all the options that can be applied at the IP level, and the RFCs that are piled on top of it. The real risk here, even for a research project, is the number of potential buffer overflows that you have to watch out for. It's tempting and comparatively simple to handle incoming messages using either pattern matching or overlaid records, but I think a more robust approach is to use state machines (Pascal doesn't, unfortunately, support coroutines). Things like unix kernels typically pass around messages as pointers, I'd avoid that and use bounds-checked arrays even if that meant that CPU time was wasted copying data around. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit - parallel test suite execution
Graeme Geldenhuys wrote: On 2015-03-19 08:10, Mark Morgan Lloyd wrote: In any event the output would need to be presented in a reproducible sequence. A good point, but thinking about it I don't think it would be that hard. The text output might be a bit more tricky, but not impossible. Blue-sky thought if there's to be /any/ modification. It would be useful to have something comparable with a Merkle tree here, so that there's a single overall fingerprint indicating that the entire run is OK (irrespective of the order of the tests), subsignatures indicating that the first and last halves are OK, 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Coyo Stormcaller wrote: On 03/19/2015 02:27 AM, Michael Van Canneyt wrote: If I may suggest, if you simply want to invoke a program with a socket as standard input, you can just use (x)inetd, it comes by default on all unix installations, and does just that: it is started by init, manages TCP/IP connections and spawns off a program to handle the connection with the socket handle as standard input/output. Why reinvent the wheel ? Synapse sounds interesting. an entire TCP/IP stack written in Object Pascal. It sounds like fun to play with, and I've actually been looking around for a userspace TCP/IP stack for a VPN project of mine. I wonder if I could comment on a couple of misapprehensions. The first one is that the bulk of the TCP/IP stack is in the operating system, Synapse (or equivalent) isn't simply talking to a naked Ethernet device, instead it's using a group of system calls broadly referred to as "Berkeley Sockets". While it is possible to write a complete stack from scratch in any reasonably-complete programming language, and while this has been done for e.g. embedded systems (or by idiots such as myself for demonstration/testing purposes :-), in practice it's avoided on account of (a) the amount of well-tested code that it would attempt to supplant and (b) consideration of the difficulty of implementing all required services in a single program. Second, Pascal, in common with most modern languages, doesn't have primitives or constructs dedicated to things like sockets. Its primitives are generally restricted to features which are fairly general-purpose, with everything else being added as procedures/functions or (in modern implementations) classes... in either case loaded from libraries decoupled from the language itself. It's interesting to compare this with some of the original ALGOL implementations or even with the original Turbo Pascal, which had a large number of keywords (e.g. to control file-open modes) which were defined as part of the language itself. Modern practice would be to make these into enumerations, which would be passed to a function as a parameter. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Coyo Stormcaller wrote: Despite documentation and manuals, I have not figured out how to use TCP sockets in Object Pascal, since there doesn't seem to be a primitive for it, or any easy way to instantiate sockets and manipulate incoming connections. So my approach to sockets is to do it externally. A Bash shell script invokes another script, such as Ruby for binding the socket. Upon recieving a socket connection, it invokes an Object Pascal command line program, passing it socket traffic as standard input. If you have to do it that way then I strongly suggest using the existing netpipes (hose and faucet) utilities. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit - parallel test suite execution
Graeme Geldenhuys wrote: As per good unit test guidelines, tests should be independent of each other and not rely on results from earlier tests. The perfect candidate for parallelism. So what about the idea of running x amount of test suites in parallel? It should at least give our multi-core CPU's something to do and maybe complete 2000+ tests in a shorter period. ;-) Thoughts? In any event the output would need to be presented in a reproducible sequence. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Google Code closing down
Jonas Maebe wrote: Hi, Please continue this discussion on fpc-other (and in the future, please also start these kinds of discussions there instead of here). Sorry Jonas, my fault for not responding to Graeme's posting in the Proper Place. At the same time I notice Michael Fuchs's quote that "A month later, the [Sourceforge] restrictions were relaxed so that individual projects could indicate whether or not their software should be blocked." I know that FPC has users in Cuba, do they still have problems downloading from Sourceforge? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Google Code closing down
Michael Van Canneyt wrote: On Sat, 14 Mar 2015, Mark Morgan Lloyd wrote: Graeme Geldenhuys wrote: If you haven't seen yet, Google announced that they will be closing down Google Code. My only concern is that some niche projects used it and that such code could be lost if not migrated to another service. So if you have the time and know of a project that needs migration, please do so. It is always sad to see open source code (no matter how old) simply lost. I was just about to start using it for something. Now I've got to start looking for an acceptable alternative- preferably one that operates by European rules rather than American ones. What do you mean by this ? How would these rules differ ? I wasn't aware that rules existed ? :) Google, Sourceforge and most if not all US-located services operate strictly according to US regulations and block access to Cuba, Iran and so on... it wouldn't surprise me if Russia is back on the shitlist before long. Irrespective of my feelings about those regimes, I'd be far happier to use a service that operated according to European laws and conventions. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Google Code closing down
Graeme Geldenhuys wrote: On 2015-03-14 10:39, Mark Morgan Lloyd wrote: looking for an acceptable alternative- preferably one that operates by European rules rather than American ones. Google Code was definitely based on American rules. I know. Anyway, have a look at GitLab - I just bought out Gitorious. They are based in the EU. [Sigh] I feel like I'm being pushed onto git rather than Subversion. I can really do without 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Google Code closing down
Graeme Geldenhuys wrote: If you haven't seen yet, Google announced that they will be closing down Google Code. My only concern is that some niche projects used it and that such code could be lost if not migrated to another service. So if you have the time and know of a project that needs migration, please do so. It is always sad to see open source code (no matter how old) simply lost. I was just about to start using it for something. Now I've got to start looking for an acceptable alternative- preferably one that operates by European rules rather than American ones. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGetTimeOfDay
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Are there any known issues with this sort of thing fpGetTimeOfDay (@TimeVal, nil) on various platforms? FPC 2.6.4 and 2.7.1 seem to be OK on x86, but on x64 (and FWIW SPARC, haven't tested others) it appears to be returning a fixed TimeVal plus a result of zero even if there are several seconds between calls. My FreeBSD manpage says: ... If tp or tzp is NULL, the associated time information will not be returned or set. The Linux manpage words it differently: If either tv or tz is NULL, the corresponding structure is not set or returned. (However, compilation warnings will result if tv is NULL.) The funny thing is that the snippet of code that I'm using was contributed by you, and that it works fine on multiple versions of x86 kernel. http://lists.freepascal.org/pipermail/fpc-pascal/2007-February/013356.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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fpGetTimeOfDay
Are there any known issues with this sort of thing fpGetTimeOfDay (@TimeVal, nil) on various platforms? FPC 2.6.4 and 2.7.1 seem to be OK on x86, but on x64 (and FWIW SPARC, haven't tested others) it appears to be returning a fixed TimeVal plus a result of zero even if there are several seconds between calls. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC embedded ?
Adriaan van Os wrote: Curious to know hands-on experience of list-members with FreePascal embedded. Arduino <http://arduino.cc/> looks quite attractive to me, but it's not Pascal. Any recommendations ? Raspberry Pi is a possibility, but my experience is that it has reliability problems which /might/ center on the removable SD card. BeagleBone Black has a lot going for it particularly if you can use its high-speed supplementary processors. Otherwise the MIPS Creator C120 http://store.imgtec.com/ look interesting, but I don't know whether anybody has FPC on it yet. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [Cross-post] Re: Free Pascal and Lazarus Nightly Builds
Lukasz Sokol wrote: On 03/03/15 17:47, Anthony Walter wrote: This is a public notice. Get Lazarus has switched from hosting arbitrary revisions to hosting setup programs from nightly builds. http://www.getlazarus.org/setup/ Going forward each night the current svn trunk sources of FPC and Lazarus will be updated and converted into a Windows installer, Linux, and Macintosh archives. The installer, setup scripts, application shortcuts, and website have now prominently inform users that they have installed or might be installing nightly build versions of FPC and Lazarus. As before any changes get Lazarus makes are hosted in a diff file distributed with each install. This information is also mirrored on github. Having had a look (as it's a wiki-idea-page-engine), I conclude that the automatic start of download only does not work any more by accident - somehow it doesn't go to ?download#linux when I visit it, but entering http://www.getlazarus.org/setup/?download#linux into URL field still does. Please consider removing the automatic click on the download link PERMANENTLY and SURELY. Going to relevant OS section IS OK. Forcing users to immediately decide whether to save or not, IS NOT. Out of curiosity, I've just taken a look at it on an "unexpected" platform (Linux SPARC). It did a creditable job, except that it appears to not make an initial check that FPC binaries are already installed :-) There might be additional problems if the FPC version has already been bumped to something non-approved (e.g. on MIPS it doesn't exist for <2.7.1). Also there's a problem with some combinations of FPC build where make "loses" the initial ppc binary, resulting in lots of messages along the lines of (this is from memory) "make cannot find the command -ijjhgjhgjhg". Apart from that, a valiant attempt :-) Just my 2d worth. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] InterLockedIncrement wrapping etc.
Looking at 2.7.1 for i386, InterLockedIncrement() appears to be take a signed 32-bit as its parameter but to increment as an unsigned and wrap to zero. Is this a reliable interpretation in the general case, or if I use it to e.g. count how many times a thread "spins" are there other cases that I need to take into account? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use sleep in thread
Michael Schnell wrote: On 02/28/2015 08:20 PM, Mark Morgan Lloyd wrote: Looking at http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden. ??? The Docs say "Normally you are required to override only 2 methods: the Create constructor, and the Execute method. " Yes, and the docs don't mark Suspended as deprecated, which is one of the reasons I was doing a general compare-and-contrast exercise. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use sleep in thread
Mattias Gaertner wrote: On Sat, 28 Feb 2015 19:20:49 + Mark Morgan Lloyd wrote: [...] Looking at http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden. That is nonsense. Unless you plan to create arbitrary threads. That paragraph needs to be fixed. It appears to have been a change put in by "Socke" on the 12th January this year. Does anybody know why he did 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] the unexplained 666
Mattias Gaertner wrote: constructor TFileStream.Create(const AFileName: string; Mode: Word); begin Create(AFileName,Mode,438); end; The octal value of 438 is &666, which is read/write permissions for other/group/owner. Why not write &666? Maybe some religious reasons? ;) Default radix for debugger variable display? Non-unix programmer not appreciating the "natural" way that the bits group? /Anything's/ better than starting an argument over mysticism and gullibility exhibited by certain communities. I find that Burroughs was using Octal in about 1960, which predates its popularisation by DEC etc. by some years. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use sleep in thread
Marco van de Voort wrote: In our previous episode, Xiangrong Fang said: BUT, that cannot be used to prioritize a thread. While you block a thread using rtlevent, it can only be unblocked from another thread. While you use sleep(), it still get time share of the CPU, only that it does nothing until sleep finishes, right? No, basically a sleeping thread is marked in the scheduler as "do not schedule for nn ticks". The thread doesn't run to evaluate if it should contiue. That is the scheduler/kernel's task. Looking at the TThread documentation, since Suspend and Resume are deprecated should Suspended be similarly annotated? Looking at http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden. Should this be in the documentation if it's a significant issue? Sorry about the niggles, I'm currently trying to track down a race condition. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Reading build-id
Does anybody have any example code for a program to read its own build-id (ELF note NT_GNU_BUILD_ID), if defined? Presumably this uses bfd.pas, which I notice is GPL rather than LGPL. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How do you build FPC?
Marco van de Voort wrote: In our previous episode, Jon Foster said: Is there documentation for compiling FPC? Am I just missing it somewhere? FPC seems incredibly flexible and I'd like to take advantage of it on some other platforms but so far it looks like that is reserved for a wizard elite somewhere and nobody is saying how to get there. Did you read the buildfaq mentioned on the more information page of FPC? http://www.freepascal.org/moreinfo.var It is somewhat outdated, but describes general principles and dependencies very well. If you update that, check the embedded URL: it's lost the ~ (tilde) so 404s. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How do you build FPC?
Jon Foster wrote: I'm using i386 32bit Linux for most of my development and currently using FPC 2.6.0. I'm trying to understand how to build FPC for various scenarios: Cross-compiling FPC for another architecture. Building FPC crosscompilers and related units so I can compile for them from my Linux machine. And building new FPC versions. There seems to be a massive lack of documentation about the FPC build process and many things I try get me know where. I'll do something like "make deb" and I get "/bin/cp: cannot stat `logs': No such file or directory ..." Or I do "make build OS_TARGET=win32 SMARTLINK=YES DEFAULTUNITS=YES NOGDB=1" and it builds a i386-linux RTL with i386-win32 packages!?!? I've tried building on I386 Linux, PPC Linux, PPC OSX, just to name the ones that I remember. I've tried simple builds of newer FPCs, cross compiling FPC, building crosscompilers and units. Building Debian packages. Not once have I ever been able to get it to do what I want. There is obviously a lot of pieces I'm missing from what I've dug up on the wiki, docs and included text files. Is there documentation for compiling FPC? Am I just missing it somewhere? FPC seems incredibly flexible and I'd like to take advantage of it on some other platforms but so far it looks like that is reserved for a wizard elite somewhere and nobody is saying how to get there. The document that is usually cited is http://www.stack.nl/~marcov/buildfaq.pdf which I think is still generally valid. I don't know whether this is the only URL, or if it's also hosted on the FreePascal site. In all cases the correct compiler to start with is the current one (i.e. at the time of writing v2.6.4), the makefiles generally check and enforce this and it is unwise to override it. Apart from that, and with the caveat that I am not a core developer and this is probably not an orthodox opinion or advice, for building natively on Linux (also Solaris, OS X etc.) I simply use something like make NOGDB=1 OPT='-O- -gl -Xs-' all That's a very conservative build, with minimal optimisation etc. so that if something goes wrong a backtrace can be had without having to rebuild. Alternatively see http://wiki.freepascal.org/fpcup To get the idea of how bootstrapping and cross compilers hang together, you might find http://wiki.freepascal.org/Native_MIPS_Systems useful. I tweaked that a few days ago since I think a couple of steps were in the wrong order. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] why fpc do not use a known return function value
misu kun wrote: Hi in this program test function has a known return value , and should be calculated in compile time , but fpc make it in real time !!! - program test; var c : int32; function test( p: int32): int32; inline; var i : int32; begin i := p; test := i+2+c+2+c+2+c; end; begin c:= test(128); end. The initial value of c is undefined. How do you expect the compiler to optimise it? In the more general case, my recollection is that C has simpler scoping rules, so there may be cases where it can optimise where a Pascal compiler would be more cautious. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compile vs native
Michael Schnell wrote: On 01/27/2015 10:27 PM, Ewald wrote: - Without the target system, the application cannot be tested .. This is true, only because remote debugging is not well supported. In fact I sometimes to programs to be run on a headless system (e.g. a NAS) Here you can't install Lazarus, because you don't have a GUI. A headless system can still map a GUI to a desktop computer using X, VNC, SSH 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compile vs native
Brian wrote: A question to those who must maintain a Linux version and a Windows versions application. Do you tend to cross-compile from Linux or do you compile native (with separate projects) on each OS (Linux and Windows)? Native where possible, but that's more habit than anything else. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] access violations on new ARM hardware
Björn Schreiber wrote: Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd: Since nobody else has suggested anything: is the new hardware susceptible to alignment errors in a way that the old hardware wasn't? The question is: how can we know? The ARM documentation says only "The processor supports unaligned accesses." Which is obviously a good start. Have you tried a later compiler? The problem is that we need the ppcarm.exe for Windows and there are no prebuilded snapshots available. Seems to me that we must offer some time to build it by ourself - never done before. I've done it for Linux and found it painless, but I know so little about CE that my opinion shouldn't be trusted. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] access violations on new ARM hardware
Björn Schreiber wrote: Hi *.*, we use an ARM based SOM for a device developed by us, the software is developed using Lazarus. Now we are testing a new version of the SOM and can't get our software to work. Old SOM: Samsung S5PV210 one Cortex-A8 (?) core Windows CE 6.0 R3 kernel New SOM: Freescale Vybrid dual core CPU one Cortex-A5 core one Cortex-M4 core Windows CE 6.0 R3 / Windows Compact 7 In order to gather some more information (even wince-stub isn't running on the device so we can't use GDB) we used a fresh install of FPC 2.6.4. A empty FPC program worked without any problems, even using the Windows function MessageBox() worked flawless. But if we included the unit SysUtils we got access violations right after the start - the same behaviour as our Lazarus application. By modifying the original source of SysUtils by some MessageBox() calls we tracked the first access violation down to the procedure GetFormatSettings, to be more precise to the first call of GetLocaleStr. If we removed the call to GetFormatSettings, the empty FPC program worked flawless. FPC was used with the following command line: fpc -Twince -Parm -FiC:\FPC\2.6.4\units\arm-wince\rtl\inc -O- test.pas Any ideas what goes wrong? Did we miss a compiler switch, perhaps? Since nobody else has suggested anything: is the new hardware susceptible to alignment errors in a way that the old hardware wasn't? Have you tried a later compiler? My recollection is that there were issues on SPARC that might have included alignment problems, and on that architecture I had to abandon 2.6.4 promptly and move onto trunk. I'm currently testing Lazarus trunk at about 47318 is OK with FPC 2.7.1 29398 on various CPUs running Linux, can't speak for CE. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux ACL
Henry Vermaak wrote: On Fri, Jan 23, 2015 at 11:37:05AM +0100, Koenraad Lelong wrote: Hi, I need to set ACL's on files on Linux. Is there something ready-made in fpc ? Or should I use a TProcess and execute a setfacl that way ? Easiest would be to create a binding for libacl. ACL is specified by POSIX, so there's nothing stopping fpc from implementing it natively, though. Would this require root access? As an aside, I've used capabilities to allow a program to listen to a low-numbered TCP port and found that setting it uid root was incompatible with GTK (Qt was fine). -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFileStream.Create and hidden files on Windows
Bart wrote: On 1/15/15, Michael Van Canneyt wrote: It seems strange that rewrite/reset handles it, because a quick search reveals that there is no handling of FILE_ATTRIBUTE_HIDDEN in the RTL. Reset handles it, rewrite not (access denied (GetLastOSError = 5)). TFileStream.Create with fmCreate also fails, but with GetLasOSError = 6 (invalid entry). Chances are I replaced some Resets with TFileStream.Create when saving the file in question. So, in the end it's all my own doing. Sorry for wasting your time. Although it also affects TInifile on Windows, which has made your comments interesting. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MIPS32 support
Graeme Geldenhuys wrote: Hi, Anybody know the status of MIPS32 support with Free Pascal? To be used on something like this board: http://shop.imgtec.com/uk/product/mips-creator-ci20/ When I last played with it on Qemu, it was able to compile itself (with all packages) but not build Lazarus. I don't know whether anybody from Imagination is lurking, but I was discussing FPC etc. with one of their directors a few months ago and he was fairly interested. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Michael Van Canneyt wrote: On Fri, 2 Jan 2015, Jonas Maebe wrote: in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. I will not argue about the linker and assembler, but I am not sure your libc argument is quite correct. It is about binary compatibility. If gnu C lib devs change the alignment of some struct, they just do it. All C programs can be recompiled, relinked, and that is it. It's not just that. Some of the GNU/C crowd make the confident assertion that a bug-free compiler /cannot/ generate code that breaks alignment, despite the fact that the majority whine if they can't pack their data structures exactly how they want. I'm trying to wean my colleagues off SPARC, I'm no longer convinced that the pain is worth it. Does anybody have any Debian/multiarch issues that they want to air? I seem to have caught the attention of one of the admins. -8<- > > Multiarch obviously introduces its own problems. Could you provide some examples? Multiarch seems unrelated to the portability of Debian. In fact I think it has a more positive impact on portability, since for less portable software you can workaround that by installing binaries from another architecture and running them directly where possible or use qemu-user to emulate them where not possible. ->8- -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Florian Klämpfl wrote: Am 02.01.2015 um 16:43 schrieb Jonas Maebe: On 02/01/15 15:59, Jeppe Græsdal Johansen wrote: Den 02-01-2015 kl. 15:07 skrev Jonas Maebe: After just having spent 2 days debugging an issue in fcl-res that could have been avoided by just using the assembler instead of by reimplementing object writers from scratch, I'm even more strengthened in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. I pretty much disagree on all points. Maybe it's nice if you sit on some popular flavour Linux, Our basic "manager" units are independent of Linux flavours and should not introduce any dependencies on a particular flavour or version of Linux. I still doubt that it is possible to build a glibc-linked linux binary like the compiler which runs on all linux flavours still being in support. Just look at the pain with the IDE on linux. Bottom line in the bug tracker and on the mailing lists: if the provided IDE binary does not work for you, just do not use it, we cannot help you (I know, in this case we could switch to an external gdb and get rid of glibc but this proves only the point). Noting that I asked about something related to this in fpc-devel the other day, I assure you that I feel your pain. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Benchmarks are odious, but...
At http://www.fourmilab.ch/fbench/fbench.html John Walker, formerly of Autodesk, rates FPC as one of the faster languages but remarks "To the best of my knowledge, none of the language implementations tested exploit the thread-level parallelism implemented in modern processors." Allowing that he used FPC 2.2.0, is optimisation etc. likely to have improved enough that somebody could usefully suggest he rerun the test? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of a partition
Rainer Stratmann wrote: On Thursday 18 December 2014 22:49:08 you wrote: On 12/18/14, Rainer Stratmann wrote: How to get the total size of an unmounted partition in Linux? Can you use the info at http://serverfault.com/questions/190685/whats-the-best-way-to-get-info-abou t-currently-unmounted-drives ? Just googled you question ;-) Thanks, it is may interesting. Better would be a syscall. I think this is a question that doesn't have a straightforward answer. For example, you refer to an "unmounted partition", but partitions aren't mounted: filesystems are mounted, and without knowing the type of filesystem you don't know how much overhead is associated. The canonical program that looks at partition sizes is fdisk, and painful experience has taught me that different fdisk implementations can return different results. Sometimes the differences are subtle, sometimes not. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] else and otherwise in a case statement
Ewald wrote: On 12/11/2014 11:13 PM, Howard Page-Clark wrote: On 11/12/2014 21:07, Mark Morgan Lloyd wrote: I've been doing a bulk replace of 'case..else' to 'case..otherwise' to eliminate possible ambiguities that have bitten me in the past, and have noticed something interesting under 2.6.4 on x86 Linux. How can "else" be ambiguous within a case statement? If one omits the trailing semicolon (the one that's commented), the else becomes ambiguous: Case Something of Value1: ; Value2: If Condition Then DoSomething (*;*) Else End; Yes, that's the one. When I raised it it was pointed out to me that the otherwise form was intended as a drop-in replacement to avoid 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] else and otherwise in a case statement
I've been doing a bulk replace of 'case..else' to 'case..otherwise' to
eliminate possible ambiguities that have bitten me in the past, and have
noticed something interesting under 2.6.4 on x86 Linux.
This is OK:
Ord('.'): case shiftState of
unshifted: mechCode := Corr_88_Period;
shifted:
else
end;
This is an error:
Ord('.'): case shiftState of
unshifted: mechCode := Corr_88_Period;
shifted:
otherwise
end;
I can fix it like this:
Ord('.'): case shiftState of
unshifted: mechCode := Corr_88_Period;
shifted: ;
otherwise
end;
But that grates since I was brought up on ; being a statement separator
rather than a terminator. Alternatively this is OK:
Ord('.'): case shiftState of
unshifted: mechCode := Corr_88_Period;
shifted:
end;
but I like having the regular code (in some cases there are active
otherwise clauses, and I spent enough time with Modula-2 to prefer
enumerating all possibilities).
Is this difference expected, and what is the best 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/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] mORMot
Discussion elsewhere has mentioned mORMot as a development framework. It claims to work with both Delphi and FPC: is anybody actively using it "in anger", so that I can pass the confirmation back to where I saw this mentioned? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Heap Management : sub-allocation ?
Brian wrote: Frederic Da Vitoria wrote> I think that Brian is asking if a memory leak could eat the system's> memory> irreversibly. IIUC in Windows, when the program is stopped, all it's> memory> is freed, even if the program leaked memory. I don't know about Linux, but> I'd be surprised if it weren't the same.> > -- > Frederic Da Vitoria> (davitof)> > Membre de l'April - « promouvoir et défendre le logiciel libre » -> http://www.april.org> > ___> fpc-pascal maillist - fpc-pascal@.freepascal http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Yes that is exactly what I was asking. For a high reliable system running24/7 my fear using Object Oriented code vs procedural code is exactly whatyou mentioned . If there is a serious leak , or even a small one for anextended period of time , it can take down the OS. I have seen this happenwith Sun OS and a 3rd party driver that leaked and caused the OS to crashafter an extended period of time. An operating system certainly /shouldn't/ crash if user processes allocate excessive memory. The overall system might thrash which would make it unresponsive to e.g. new SSH sessions, but that's hardly the same thing. I've got stuff here running 24/7 with uptime measured in months. Historically, the memory leaks weren't in application code but were in database backend stuff that managed its own heap, which made it very difficult to monitor. It's easy enough to code such that when you perform a complex activity which /should/ free all memory on completion you check that it does so. It's also easy enough to put something in your UI that reports how much is currently on the heap, and if you see that it's growing you can investigate in a development environment using e.g. HeapTrace. In extremis, it's usually possible to get a program to restart itself if something's obviously wrong. I don't know if it's still the case, but Apache used to limit the number of requests each process would handle to protect it from memory loss due to faulty CGI etc. If necessary, you can use a custom heap manager e.g. if you don't want it to expand beyond some preallocated size. In principle, you could code yourself multiple heaps each with custom procedures/functions, but while these might be useful for stuff that you're writing yourself you'll not be able to use them with the standard OO classes. I don't believe that there's an equivalent to mark/release in the standard heap managers, and from discussion elsewhere I don't believe it could be added in a compatible way. Some variant of Mark() that took a parameter suggesting how much memory could be allocated could be useful, but your focus should be on preventing leaks and runaway rather than constantly recovering from them. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TIniFile: how to save bool as string?
Reinier Olislagers wrote: On 03/10/2014 21:16, silvioprog wrote:> When I use the TIniFile to save my configurations, it saves the boolean> values as 0 and 1.> > Is there any way to save these values as string (true/false) instead> of integer (0/1)? If not, can I send a patch to implement that?! 1. Write your own wrapper?2. AFAIR, there already is a bug report+patch in the bug tracker onextending TInifiles. At least if it saves (and presumably expects) 0 and 1 it's protected from internationalisation issues e.g. if a template .ini is supplied with an app. I hacked a wrapper some while ago for my own use, which tries to preserve the form of the variable (i.e. if it's currently "True" then "False" is written, but if it's "yes" then "no" is written"). That's obviously massively problematic if multiple languages have to be supported. -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Reinier Olislagers wrote:
On 30/09/2014 22:05, Mark Morgan Lloyd wrote:
Marco van de Voort wrote:
In our previous episode, Sven Barth said:
It is indeed true that all units are initialized once the main code
Reinier: did you get as far as looking in Dynlibs for an error message
immediately after trying to connect to the database?
No, I didn't.
Assuming you've got >= 2.6.2, modify your code to look like this:
uses DynLibs;
..
WriteLn('Before TDBInterface.Create(): ', GetLoadErrorStr);
DBLayer:=TDBInterface.Create;
WriteLn('After TDBInterface.Create(): ', GetLoadErrorStr);
On Linux, I can see it calling the database connection stuff but then it
raises an exception because it can't find the named server etc. So at
least on Linux it's apparently transferring control into the
demand-loaded database stuff, since otherwise there wouldn't be the
messages as shown below. Whether it's appropriate and portable to do it
like that is a different issue.
I don't want to have to spend time changing your test code to suit
PostgreSQL or digging out names etc. for the limited number of Firebird
databases I've got set up, and I /really/ don't want to start fiddling
with Windows.
Before TDBInterface.Create():
An unhandled exception occurred at $B767EFEF :
EIBDatabaseError : : DoInternalConnect :
-Unable to complete network request to host "firebirdserver".
-Failed to locate host machine.
--
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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Sven Barth wrote: The only other alternative would be to add the RTL initialization code to each exported function. I don't consider this a viable alternative. Which is more or less what Reinier's working code did. I'd hate that to be an implicit default. Note: Dynamic packages won't have this problem, because: - for packages linked at compile time the initialization is run as part of the program initialization AFTER the OS has initialized the library (which doesn't do much in case of a package) - for packages loaded at runtime it's done as part of the LoadPackage call That's however only possible, because dynamic packages are very different from simple libraries (and stuffed with compiler magic). Is it possible for code in a unit to determine what sort of project it's part of, i.e. a standalone program, a library etc.? Could the RTL have a flag indicating that initialisation (or finalisation?) blocks were currently being run, and anything called should assume that facilities were restricted? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Marco van de Voort wrote: In our previous episode, Sven Barth said: It is indeed true that all units are initialized once the main code block of the library is called, but you are still inside the library initialization initiated by the OS and thus you are subject to its restrictions which in the case of Windows includes not to load any libraries there. So the obvious question might be if the unit initialization really belongs into the library initialization like that. Assuming that e.g. connecting to a database uses the Dynlibs unit, is there any way that this could recognise that it was being invoked from DLL/so initialisation code and raise a "don't try that here" exception? Reinier: did you get as far as looking in Dynlibs for an error message immediately after trying to connect to the database? -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Michael Van Canneyt wrote: However I'd precede that by a thought based on what Jose said. In your example, you're opening the database in the initialisation block of businesslayer.pas, which is invoked at an arbitrary position in the init sequence of the DLL/so. If that operation were moved instead to the initialisation block of testdbdll.lpr, which in the context of the DLL/so is analogous to a program's main block, it might work. No. this is not correct. For a library, this is analogous to initialization code of a unit, it's just the 'last' unit being initialized. Does the main program explicitly call the initialisation entry point of the (dynamically-loaded) library, or it this done by the OS? I was under the impression that the two were basically asynchronous and (as a particular example) both the program and the library would have distinct copies of the system unit with their own global variables etc. hence the memory manager problem. The memory manager problem is completely unrelated to this. DLL and calling program simply have different copies of the FPC memory manager. That is what needs to be solved with dynamic packages. Yes, agreed. Except that if cmem (or whatever) isn't being used there are two completely separate copies of the memory manager because... As far as I know, the initialization entry point is called automatically. But the compiler experts should confirm this. IIRC the behaviour changed as the support for libraries improved; ..(pending comment from compiler experts) there are completely separate trees of units in the main program and each dynamically-loaded library. The OS calls the initialisation block(s) for each library, and then finally calls the initialisation block for the main program. So in the context of one particular library, code in the main library initialisation block should have a similar standing to that in the main program initialisation block: everything else in that context (i.e. in the library or in the main program) has been initialised before it is called, and when it exits it goes back to the OS (possibly via finalisation blocks). -- 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Michael Van Canneyt wrote:
On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
On 29/09/2014 19:30, Reinier Olislagers wrote:
Re bug report: agreed. I'll raise it.
Jonas has already closed it, noting
"http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx
"***
The entry-point function should perform only simple initialization or
termination tasks. It must not call the LoadLibrary or LoadLibraryEx
function (or a function that calls these functions), because this may
create dependency loops in the DLL load order. This can result in a
DLL being used before the system has executed its initialization code.
***
"I.e., what you are doing is unsupported ("must not call the
LoadLibrary or LoadLibraryEx function"). I think that on most unix
platforms, trying to load libraries from other the init function of
other libraries is not supported either."
However I'd precede that by a thought based on what Jose said. In your
example, you're opening the database in the initialisation block of
businesslayer.pas, which is invoked at an arbitrary position in the
init sequence of the DLL/so. If that operation were moved instead to
the initialisation block of testdbdll.lpr, which in the context of the
DLL/so is analogous to a program's main block, it might work.
No. this is not correct. For a library, this is analogous to
initialization code of a unit, it's just the 'last' unit being initialized.
Does the main program explicitly call the initialisation entry point of
the (dynamically-loaded) library, or it this done by the OS? I was under
the impression that the two were basically asynchronous and (as a
particular example) both the program and the library would have distinct
copies of the system unit with their own global variables etc. hence the
memory manager 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/cgi-bin/mailman/listinfo/fpc-pascal
