Re: [fpc-devel] for-in-index loop
Paul Ishenin schrieb: 29.01.13, 17:23, Hans-Peter Diettrich пишет: Paul Ishenin schrieb: At least it's more fun to implement something very new, instead of working on incomplete parts (loadable libraries, targets) which had been delayed due to problems. The same situation in Lazarus and in many open source projects BTW. Where are your patches for loadable libraries and new targets? Where are the bugs to fix? I don't know. I thought you know that since you wrote about them. I wrote about FPC developers, and incomplete implementations. The ability to read an ToDo file doesn't require any knowledge about the matter, nor the ability to provide patches. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fixes 2.6.1 fails to install under Win32
On 01/30/13 02:22, Michalis Kamburelis wrote: Do not use a final backslash, like make install INSTALL_PREFIX=c:\fpc\2.6.1 Ah, that did the trick. Thank you for your help. Side Note: That also highlights how fragile the build system is, but that is another issue. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
On 01/28/2013 08:03 PM, waldo kitty wrote: i'm trying to make sure i'm following along here because i'm also using synapse for a project... Do you know where to find the Synapse Powers ? I do hope (and feel) they are interested in helping to make this work and fix potential problems in the Synapse code. This is why I upgraded to the most recent svn sources of Synapse (and found that it obviously is not yet tested on ARM: it does not compiled without a (simple) modification). Here are my latest finding: - I set the ConnectTimeout property and I set the other timeouts by calling SetTimeout. - As described my project does perform two complete HTTP communications with the target successfully. - With the third access, the connect does work even without a timeout and a retry performed by my software (Synapse Status log: 7 = HR_CanWrite / 5 = HR_Connect). - then it does 11 = HR_WriteCount is shown, supposedly indicating my write request. and 13 = HR_Error seems shows that a timeout error on that Write occurred. - my latest log shows that the timeout occurs after more than 15 Minutes (see below). - my software does a retry and the same happens again. Now the extended Timeout is one problem, but the primary problem is why this write HTTP access does not work, while the previous two accesses do work fine. How do we proceed ? Thanks, -Michael 29-1-13 23:00:133: 29-1-13 23:00:130:192.168.71.252:80 29-1-13 23:00:131:192.168.71.252:80 29-1-13 23:00:132:IPv4 29-1-13 23:00:137: 29-1-13 23:00:135:192.168.71.252:80 29-1-13 23:16:3711:5616 29-1-13 23:16:3713:110,Connection timed out 29-1-13 23:16:376: 29-1-13 23:16:3710:5663 29-1-13 23:16:373: 29-1-13 23:16:370:192.168.71.252:80 29-1-13 23:16:371:192.168.71.252:80 29-1-13 23:16:372:IPv4 29-1-13 23:16:377: 29-1-13 23:16:375:192.168.71.252:80 29-1-13 23:33:1211:5382 29-1-13 23:33:1213:110,Connection timed out 29-1-13 23:33:126: 29-1-13 23:33:1210:5638 29-1-13 23:33:123: 29-1-13 23:33:120:192.168.71.252:80 29-1-13 23:33:121:192.168.71.252:80 29-1-13 23:33:122:IPv4 29-1-13 23:33:127: 29-1-13 23:33:125:192.168.71.252:80 29-1-13 23:48:4711:4095 29-1-13 23:48:4713:110,Connection timed out 29-1-13 23:48:476: 29-1-13 23:48:4710:498 29-1-13 23:48:473: 29-1-13 23:48:470:192.168.71.252:80 29-1-13 23:48:471:192.168.71.252:80 29-1-13 23:48:472:IPv4 29-1-13 23:48:477: 29-1-13 23:48:475:192.168.71.252:80 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
On Wed, January 30, 2013 10:04, Michael Schnell wrote: On 01/28/2013 08:03 PM, waldo kitty wrote: i'm trying to make sure i'm following along here because i'm also using synapse for a project... Do you know where to find the Synapse Powers ? I do hope (and feel) they are interested in helping to make this work and fix potential problems in the Synapse code. . . The dedicated support list for Synapse might be a better place for potential issues related to Synapse return codes on certain platforms - see the link Support on Synapse pages. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
On 01/30/2013 12:12 PM, Tomas Hajny wrote: The dedicated support list for Synapse might be a better place for potential issues related to Synapse Did so, Hoping to see both of you over there... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Weird output from fpGetErrNo
Hello, I was just writing a little mmapped (that's two `m`'s -- no typo ;-) ) file stream and thought to do it properly just in case I might fork(). So I thought to give some advise about memory: madvise(daBuffer, FileSize, MADV_DONTFORK); Now if I check the result value and, if 0, print the detailed error code using: ErrorCode:= fpGetErrNo(); WriteMsg(strError(ErrorCode)); I get the most ambiguous results (ENOTTY, ENOENT, which are not even documented as being possible error comditions after this call). After some research I decided to try implement fpGetErrNo myself using (straight from errno.h -- using linux 3.7.4 running x86_64 hardware): Function __errno_location: pcint; cdecl; external 'c' name '__errno_location'; Function fpGetErrNo: cint; Begin Result:= __errno_location()^; End; And this gave me the expected results (Out of memory, Success, ...). So, did I discover a bug or do I miss something? Just for the record: `daBuffer` is just mmapped in the line preceding this one, there is no error there, it contains the right data, `Filesize` is obtained through stat(), so no issue there either. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
In our previous episode, Ewald said: I was just writing a little mmapped (that's two `m`'s -- no typo ;-) ) file stream and thought to do it properly just in case I might fork(). So I thought to give some advise about memory: Why not simply use fpgetcerrnp in unit initc? I get the most ambiguous results (ENOTTY, ENOENT, which are not even documented as being possible error comditions after this call). What do you see if you strace the resulting binary? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
On 1/30/2013 04:04, Michael Schnell wrote: On 01/28/2013 08:03 PM, waldo kitty wrote: i'm trying to make sure i'm following along here because i'm also using synapse for a project... Do you know where to find the Synapse Powers ? no, sorry, i do not... i haven't seen them in the synapse list, either... I do hope (and feel) they are interested in helping to make this work and fix potential problems in the Synapse code. as do i and others ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
Once upon a time, on 01/30/2013 08:17 PM to be precise, Marco van de Voort said: In our previous episode, Ewald said: I was just writing a little mmapped (that's two `m`'s -- no typo ;-) ) file stream and thought to do it properly just in case I might fork(). So I thought to give some advise about memory: Why not simply use fpgetcerrnp in unit initc? I didn't know it existed. I get the most ambiguous results (ENOTTY, ENOENT, which are not even documented as being possible error comditions after this call). What do you see if you strace the resulting binary? When explicitely triggering an error: (madvise(0, 4096)) madvise(0, 4096, 0xa /* MADV_??? */)= -1 ENOMEM (Cannot allocate memory) And when using madvise() correctly: madvise(0x7f5352248000, 31160801, 0xa /* MADV_??? */) = 0 Native fpGetErrNo gives ENOENT / ENOTTY respectively, while my little experiment gives me ENOMEM / 0 (success) respectively. fpgetcerrno from initc gives me the correct results as well; and by looking at the code I see it implements it by using `__errno_location` under linux, so no surprise there. So, what's supposed to be the difference between fpgetcerrno and fpgeterrno (multithreading? [*])? [*] Maybe not important, but this is a rather heavily multi-threaded application. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
In our previous episode, Ewald said: fpgetcerrno from initc gives me the correct results as well; and by looking at the code I see it implements it by using `__errno_location` under linux, so no surprise there. Well, the surprise is that initc worked, and yours not. From a quick glance I believe it to be correct too. So, what's supposed to be the difference between fpgetcerrno and fpgeterrno (multithreading? [*])? Platform dependent. They can be the same. FPC does its own kernel calls on some platforms, and the result is then stored in fperrno. fpcerrno is always linking to libc's errno. On platforms where FPC uses libc to acces the kernel, errno=cerrno. [*] Maybe not important, but this is a rather heavily multi-threaded application. Both are threadsafe, even if you use the pseudo variable variant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
On 30 Jan 2013, at 21:52, Marco van de Voort wrote: In our previous episode, Ewald said: fpgetcerrno from initc gives me the correct results as well; and by looking at the code I see it implements it by using `__errno_location` under linux, so no surprise there. Well, the surprise is that initc worked, and yours not. From a quick glance I believe it to be correct too. I believe there is a bit of confusion: my little experiment and the fpgetcerrno both boil down to exactly the same code (both using __errno_location under linux). The reason I wrote it is that I didn't know it was already implemented this way in initc. Both functions obviously work. The function that seemingly doesn't work is the native fpGetErrNo (with native I mean the function that is available in unit baseunix without any modification). So, what's supposed to be the difference between fpgetcerrno and fpgeterrno (multithreading? [*])? Platform dependent. They can be the same. FPC does its own kernel calls on some platforms, and the result is then stored in fperrno. That's handy, so it would be advisory to use fperrno as much as possible then. fpcerrno is always linking to libc's errno. On platforms where FPC uses libc to acces the kernel, errno=cerrno. Thus on linux fpc does its own kernel access then, since errno cerrno? So, on this linux, after calling a syscall which I defined as `external 'c'` (like the madvise in the original post) it makes no sense to call fpGetErrno, and instead I should call fpgetCerrno to get sensible results? If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. What bothers me is: what (and why) created the contition? (I know it is not some garbage data in the variable, since it changes over time to another error: ENOTTY -- ENOENT) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
In our previous episode, Ewald said: Well, the surprise is that initc worked, and yours not. From a quick glance I believe it to be correct too. I believe there is a bit of confusion: Ok, cler. The function that seemingly doesn't work is the native fpGetErrNo (with native I mean the function that is available in unit baseunix without any modification). That only works for routines that call the FPC syscall.do_syscall function directly or indirectly. Just like cerrno works for functions that call libc functions directly or indirectly. That's handy, so it would be advisory to use fperrno as much as possible then. Use fperrno for FPC predeclared functions. That works. fpcerrno is always linking to libc's errno. On platforms where FPC uses libc to acces the kernel, errno=cerrno. Thus on linux fpc does its own kernel access then, since errno cerrno? Yes. Free/Open/NetBSD too. The other *nixes (Haiku,Solaris, Darwin/OSX) fall in the other category. So, on this linux, after calling a syscall which I defined as `external 'c'` Not a syscall, but a libc call. Even though it might call a syscall internally. On most *nixes, the kernel returns the error result in some register. The wrapper code is responsible for properly storing the error result in some variable (and nowdays, preferably in a threadsafe manner) So libc syscll wrapper code stores in the c errno, and routines that call the FPC internal syscall wrapper store it in the RTL errno variable. (like the madvise in the original post) it makes no sense to call fpGetErrno, and instead I should call fpgetCerrno to get sensible results? Correct. Or write madvise out as a true syscall, calling syscall.do_syscall (if there is any). Not all libc calls are direct syscalls. If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. All errno's are not cleared in any way, but should be checked _only_ if a function returns a value that indicates so (usually -1 but sometimes null) What bothers me is: what (and why) created the contition? You can't know. Any library call might call several other functions that update errno internally. Schematically, it could be like this: function somelibccall(aparam:integer):cint; begin if aparam=0 then exit(somefunc(aparam)) else begin if aparam10 then begin errno:=einval; exit(-1); end; result:=somefunc2(aparam); if result=-1 then begin result:=somefunc3(aparam+1); if (result=-1) and (errno=einsomething) then seterrno(einsomethingelse); end; end; All three somefuncs might write errno, and somelibccall simply passes the result of those calls on (and leaves their error unmodified, except in the last case). Moreover, it can write errno from nowwhere. In such cases it is impossible to tell what of these cases happened from the result of somelibccall and errno. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
On Wed, January 30, 2013 23:18, Ewald wrote: On 30 Jan 2013, at 21:52, Marco van de Voort wrote: In our previous episode, Ewald said: . . fpcerrno is always linking to libc's errno. On platforms where FPC uses libc to acces the kernel, errno=cerrno. Thus on linux fpc does its own kernel access then, since errno cerrno? So, on this linux, after calling a syscall which I defined as `external 'c'` (like the madvise in the original post) it makes no sense to call fpGetErrno, and instead I should call fpgetCerrno to get sensible results? Correct. If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. What bothers me is: what (and why) created the contition? (I know it is not some garbage data in the variable, since it changes over time to another error: ENOTTY -- ENOENT) I don't think you need to worry too much. It's perfectly normal that certain functions used within RTL, etc., may end up in a failure code. Sometimes there's no other way for testing certain things than simply trying them and checking the result afterwards (and this may happen within the RTL and RTL itself needs to evaluate what should be cinsidered an error and what not). This is one of disadvantages of this way (one common function for checking the last error) of returning error codes, BTW - if API functions return detailed error code directly, no such leftovers may happen. Obviously, there are some advantages too. ;-) Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
