Re: [fpc-pascal] Problems with ImageMagick Win64
On 04/28/2013 02:49 PM, Andrew Brunner wrote: I can't get ImageMagick unit to work under Windows XP 64. Also, I have confirmed that ImageMagick installed and the application does work. Can someone please edit change the unit code for Windows instead of Win32? The libraries are identical for x64 and 32. Thanks, ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to detect connection status of a socket
On 22 Apr 2013, at 15:10, Xiangrong Fang wrote: > > 1) fpsend() just pass data to the OS's socket layer without try to determine > if the connection is still alive, right? I suppose, but there exists an error code that might come in handy: ENotConn (see http://linux.die.net/man/2/send), which is returned by send(). > > 2) is it normal that in BLOCK mode, recv returns 0? i.e. if I receive a 0 > from fprecv(), I can say that the connection is closed by the other end (if > there is no detectable socketerror), right? > Yes, if recv() return 0, it mens the client disconnected. If it returns -1, errno will be set. From http://linux.die.net/man/2/recv (see `return value`): "These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown." Note that even in non-blocking mode, 0 means the socket is closed. If you received no data yet, you will get -1 as a return value and errno will be set to EAgain of EWouldBlock (see the link above). Does this help or am I completely talking besides the point? -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Problems with ImageMagick Win64
Current FPC/Trunk running on Win64 XP
I can't get ImageMagick unit to work under Windows XP 64.
I changed Win32 to Windows
{$ifdef Windows}
MagickExport = 'CORE_RL_magick_.dll';
WandExport = 'CORE_RL_wand_.dll';
{$else}
MagickExport = 'libMagickCore';
WandExport = 'libMagickWand'; // Previous ImageMagick versions used
'libWand'
{$endif}
CORE_RL_magick_.dll
CORE_RL_wand_.dll'
Apon running the app, libMagickWand.dll was not found.
Can someone please look into this?
Thanks,
--
Andrew Brunner
Aurawin LLC
15843 Garrison Circle
Austin, TX 78717
https://aurawin.com
Aurawin is a great new way to store, share, and explore all your content
featuring our innovative cloud social computing platform.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
On 28 Apr 13, at 21:03, Sven Barth wrote: . . > As a sidenote: I didn't know up to now that the prompt in the NT shell > can also be modified O.o . . Setting the PROMPT variable works for all DOS-like platforms (MS-DOS and compatibles, OS/2 and MS Windows NT+ and also replacement shells like those from JPSoft), although the set of supported metacodes varies slightly among them, of course (and the full set of possibilities also depends on other aspects like console features including ANSI positioning and colour commands, etc.). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
On 28.04.2013 21:03, Sven Barth wrote: Note 2: Maybe the PowerShell will have a bit different rules, I don't know... The PowerShell uses ` (back quote) as escape character... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
On 28.04.2013 13:31, Marco van de Voort wrote: In our previous episode, Bart said: the wrong path. So either 'make' is lying or FPC alters the path. In either case it is more a FPC issue than a Lazarus issue. The bug report should be moved to FPC. The compiler does not seem to have problems with constructs like: fpc c:\path\^-^\foo.pp @c:\path\^-^\^-^\foo.cfg at all (see bugreport for an example). Maybe the ^-as-an-escape is a shell-only convention. The compiler doesn't work through the shell. Make probably does. I took a look at Microsoft's documentation and indeed found something. Take a look here http://technet.microsoft.com/en-us/library/cc723564.aspx and look for "Figure 2.3: Simple command syntax". Below that are some bullets where the fourth mentions the reserved characters for the NT shell which includes "^" which is the escape character (unlike "\" in sh and C). So the carat needs to be escaped as "^^". As a sidenote: I didn't know up to now that the prompt in the NT shell can also be modified O.o Note 2: Maybe the PowerShell will have a bit different rules, I don't know... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Actually, I have a vintage IBM PC 5150, with a 4.77 MHz 8088 processor, so this isn't true, it's very testable actually :) However, the i8086 code generator still generates some 186/286+ instructions, so it doesn't work there yet, but I'm planning to fix this shortly. Here's a video of a few very simple Free Pascal compiled programs on a true 80186: OK, answering my own question then. A pure-8086 port could be valuable if it generated reliable code for something like vtprolog.pas, since this implements its own garbage collection relying on detailed knowledge of how Turbo Pascal manages its heap. Heap management is mostly a RTL feature. For high TP compatibility, things like calling conventions must also match. Yes, but in the specific case I gave the program extends the heap management. In practical terms it could be replaced with a mark/release arrangement, since when the program is trying to find a solution based on predefined rules it won't be extending them. But as it stands it's a good test of TP-compatibility. IOW 8086 codegeneration is not automatically full TP compatibility on the binary level. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
In our previous episode, Mark Morgan Lloyd said: > > Actually, I have a vintage IBM PC 5150, with a 4.77 MHz 8088 processor, > > so this isn't true, it's very testable actually :) However, the i8086 > > code generator still generates some 186/286+ instructions, so it doesn't > > work there yet, but I'm planning to fix this shortly. Here's a video of > > a few very simple Free Pascal compiled programs on a true 80186: > > OK, answering my own question then. A pure-8086 port could be valuable > if it generated reliable code for something like vtprolog.pas, since > this implements its own garbage collection relying on detailed knowledge > of how Turbo Pascal manages its heap. Heap management is mostly a RTL feature. For high TP compatibility, things like calling conventions must also match. IOW 8086 codegeneration is not automatically full TP compatibility on the binary level. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] Pascal compiler for embedded platforms
Hmmm I read through the web-page, one thing I could not find is support for real debugging (singlestepping, show registers) in ide, they only seem to provide log message capture. Without a real debugger it is for me not worth the download. I might of course be wrong, did you already test it and does it provide real debugging? Michael Am 28.04.13 15:16, schrieb greim: Hi, http://www.astrobe.com/default.htm Oberon on ARM. I think its worth to try it! Markus Greim Am 19.03.2013 08:46, schrieb Martin Schreiber: On Tuesday 19 March 2013 08:11:49 Justin Smyth wrote: Thanks, i am waiting to hear back regarding some suggest changes that were suggest in the debugging section that Michael Ring was working on a while ago, i want to write some code in lazarus for my ARM Cortex M3 and debug it in lazarus ( via gdb using gdb from openOCD) so i can see whats going on , just as a start because its going to take me a while to get my application running etc. Just in case you don't know, MSEide+MSEgui is an alternative to Lazarus especially made with development of embedded projects in mind: http://sourceforge.net/projects/mseide-msegui/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] Pascal compiler for embedded platforms
Hi, http://www.astrobe.com/default.htm Oberon on ARM. I think its worth to try it! Markus Greim Am 19.03.2013 08:46, schrieb Martin Schreiber: On Tuesday 19 March 2013 08:11:49 Justin Smyth wrote: Thanks, i am waiting to hear back regarding some suggest changes that were suggest in the debugging section that Michael Ring was working on a while ago, i want to write some code in lazarus for my ARM Cortex M3 and debug it in lazarus ( via gdb using gdb from openOCD) so i can see whats going on , just as a start because its going to take me a while to get my application running etc. Just in case you don't know, MSEide+MSEgui is an alternative to Lazarus especially made with development of embedded projects in mind: http://sourceforge.net/projects/mseide-msegui/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
Nikolay Nikolov wrote: So in practical terms, a strict 8086 port is probably untestable. But why would anybody want to when even embedded processors are based on a newer architecture? Actually, I have a vintage IBM PC 5150, with a 4.77 MHz 8088 processor, so this isn't true, it's very testable actually :) However, the i8086 code generator still generates some 186/286+ instructions, so it doesn't work there yet, but I'm planning to fix this shortly. Here's a video of a few very simple Free Pascal compiled programs on a true 80186: OK, answering my own question then. A pure-8086 port could be valuable if it generated reliable code for something like vtprolog.pas, since this implements its own garbage collection relying on detailed knowledge of how Turbo Pascal manages its heap. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
On 4/28/13, Bart wrote: > Someone should be brave enought to try and replicate/confirm the > described problem. Just did that, and indeed the error occurred. So, confirmed. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslasht
In our previous episode, Bart said: > But then the shell would make it \-\. > > Converting SomePath\^-^\SomePath into SomePath^-^\SomePath looks more like > C... Make could also be doing own substitutions, so is not a good testing platform to draw conclusions off. Note that I haven't tested that much, I just saw the hint about ^ being NT escape, and guessed the rest pretty much. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
On 4/28/13, Marco van de Voort wrote: > Maybe the ^-as-an-escape is a shell-only convention. The compiler doesn't > work through the shell. Make probably does. But then the shell would make it \-\. Converting SomePath\^-^\SomePath into SomePath^-^\SomePath looks more like C... Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
In our previous episode, Bart said: > > the wrong path. So either 'make' is lying or FPC alters the path. > > > > In either case it is more a FPC issue than a Lazarus issue. The bug > > report should be moved to FPC. > > The compiler does not seem to have problems with constructs like: > > fpc c:\path\^-^\foo.pp @c:\path\^-^\^-^\foo.cfg at all (see bugreport > for an example). Maybe the ^-as-an-escape is a shell-only convention. The compiler doesn't work through the shell. Make probably does. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
On 04/28/2013 12:00 PM, Mark Morgan Lloyd wrote: Bart wrote: On 4/27/13, Reinier Olislagers wrote: Noticed that an 8086 branch was merged to fpc trunk. Is it time to get out some 5.25" diskettes[1]? [1] Shame I dumped all the accompanying hardware long ago ;) Perhaps break out DOSBOX ;) I still have a portable (ahum, > 5 kg) IBM XT with 5.25" floppy disk. HD is appr. 10 MB (decaying...) Problem of course wil be to get the compiler on the floppy disks, and then hope my HD is large enough. (It cost about 10,000 Dfl (appr 4,500 € / $ 5000) at the time of purgase.) I've definitely got at least one system around older than a '386, but if it really is supposed to be an 8086 target it would have to be tested on an 8086/8088 because of extra opcodes that were added to the 186/286. I think I've got a system with 8086 or possibly V20, but it's non-PC and I don't know where its copy of DOS is (it usually ran CCP/M). I don't know how reliable a test something like Dosbox or Bochs would be, some of them vitualise the underlying hardware while others are sloppy about what opcodes they actually implement. So in practical terms, a strict 8086 port is probably untestable. But why would anybody want to when even embedded processors are based on a newer architecture? Actually, I have a vintage IBM PC 5150, with a 4.77 MHz 8088 processor, so this isn't true, it's very testable actually :) However, the i8086 code generator still generates some 186/286+ instructions, so it doesn't work there yet, but I'm planning to fix this shortly. Here's a video of a few very simple Free Pascal compiled programs on a true 80186: https://www.youtube.com/watch?v=wscin9RUiTU (sorry for the shaky camera) And here are the same programs, running on Charlie's (Karoly Balogh) Amiga 2000 with a A2286AT expansion card for PC emulation, which contains a real 286 CPU: http://charlie.amigaspirit.hu/screenshots/a2000/A2000-FPC-8086-01.png and up to -07.png Here's the 286 card: http://amiga.resource.cx/exp/a2286at Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows backslash
On 4/22/13, Mattias Gaertner wrote: > 'make' writes the right file name. Next thing is FPC and that uses > the wrong path. So either 'make' is lying or FPC alters the path. > > In either case it is more a FPC issue than a Lazarus issue. The bug > report should be moved to FPC. The compiler does not seem to have problems with constructs like: fpc c:\path\^-^\foo.pp @c:\path\^-^\^-^\foo.cfg at all (see bugreport for an example). (Maybe make is lying?) Does fpc have a switch to echo all commandline parameters (would be nice for this issue)? Someone should be brave enought to try and replicate/confirm the described problem. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
Bart wrote: On 4/27/13, Reinier Olislagers wrote: Noticed that an 8086 branch was merged to fpc trunk. Is it time to get out some 5.25" diskettes[1]? [1] Shame I dumped all the accompanying hardware long ago ;) Perhaps break out DOSBOX ;) I still have a portable (ahum, > 5 kg) IBM XT with 5.25" floppy disk. HD is appr. 10 MB (decaying...) Problem of course wil be to get the compiler on the floppy disks, and then hope my HD is large enough. (It cost about 10,000 Dfl (appr 4,500 € / $ 5000) at the time of purgase.) I've definitely got at least one system around older than a '386, but if it really is supposed to be an 8086 target it would have to be tested on an 8086/8088 because of extra opcodes that were added to the 186/286. I think I've got a system with 8086 or possibly V20, but it's non-PC and I don't know where its copy of DOS is (it usually ran CCP/M). I don't know how reliable a test something like Dosbox or Bochs would be, some of them vitualise the underlying hardware while others are sloppy about what opcodes they actually implement. So in practical terms, a strict 8086 port is probably untestable. But why would anybody want to when even embedded processors are based on a newer architecture? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
