Re: [fpc-devel] for-in-index loop
On 01/25/2013 09:39 PM, Alexander Klenin wrote: I disagree with the statement that generics are easy to add. I ANSI C1 I use macros to do what might be done with Generics. (In fact I'm not really sure that Syntax-based Generics Pascal are more handy (supposedly they are when debugging) ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 28.01.2013 10:18, schrieb Michael Schnell: On 01/25/2013 09:39 PM, Alexander Klenin wrote: I disagree with the statement that generics are easy to add. I ANSI C1 I use macros to do what might be done with Generics. (In fact I'm not really sure that Syntax-based Generics Pascal are more handy (supposedly they are when debugging) ) I've written a macro based list type for a C based project in university... I'm definitely in favor of a real generic syntax like it's implemented in FPC. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Synapse hangs in ARM-Linux
Hi, (Any Synapse experts around :-) ? ) With the great help from Thomas (who taught me to understand how the Linker works and that it's error messages are not what I supposed them to be) I have been able to compile and partly run my Snapse-based project - that already runs fine on Windows and PC-Linux - on my QBAP NAS device. It can receive and send E-Mails via POP3 and SMTP just fine and does access a HTTP server (the controller of a Central Heating attached to the local Ethernet) via HTTP. The problem is, that the HTTP access to the embedded Web Server in the Heating Controller rather often results in a timeout. (Supposedly the small CPU in the controller is too busy with other stuff and just drops the Socket open request instead of answering.) For the Windows and PC Linux versions of my project this is no problem at all. When I get any error message from Synapse, I simply do a retry. I found I never need more than just another try to make it work decently. (Supposedly any Browser does this under the hood without the user noticing it.) But when using the same Pascal code for my project and Synapse (the RTL and FCL libraries are from the svn for the PC, but from the TAR-distribution for ARM) on the ARM Box, the project infinitely hangs when this situation is hit. Usually several HTTP requests do work and it hangs with the next one. Synapse (or whatever is called by same) It hangs in state 5 (HR_Connect) and obviously never returns to my user code. When it hangs, even CTRL-C does not have any effect and I need to use kill from another console session. I tried to reproduce this with a more simple project, just accessing a non-existing IP address, but I found that while on Windows here Synapse issues a time out (after some seconds, exactly like when the Heating Controller fails to answer), when compiling for Linux (PC and ARM) the error message is HR_Error: 113,No route to host and is issued immediately and thus not involves a timeout (and no hanging on ARM). So I'm out of luck, as I would need to install debugging tools (Lazarus locally, Remote debugging with Lazarus) or learn to work with gdb on fpc projects) and try to find problems in code that is not created by myself. This does not sound like easy to do. Any suggestions on how to proceed ? Thanks -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
Al 28/01/13 11:47, En/na Michael Schnell ha escrit: (Supposedly any Browser does this under the hood without the user noticing it.) I don't think so. Anyway, it can be that your problem is too long a connection timeout (which is system dependent). There was a patch a while ago to synapse to add a ConnectionTimeout, but I don't know if it's included in the current version. Bye -- Luca ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Catch a signal
Hi Linux fans, I'd like to catch a signal sent to a Linux program. Here: http://www.freepascal.org/docs-html/rtl/oldlinux/signal.html I see: Install signal handler (deprecated) ... This call has the same functionality as the *SigAction* call. So I tried to do this: http://www.freepascal.org/docs-html/rtl/oldlinux/sigaction.html It does not compile, as the unit oldlinux is not compiled in the normal Lazarus svn installation. So I tried to add the directory of oldlinux.pp to the project options (no problem). This now asks for adding multiple more directories with inc files (no problem either) But finally the project gets linker errors, as lineinfo is not provided. Trying to add this seemingly results in recompiling the complete rtl, which I of course don't want to do. So: Hot to catch a signal ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Catch a signal
On Mon, Jan 28, 2013 at 12:20:30PM +0100, Michael Schnell wrote: So: Hot to catch a signal ? Use FpSig* in unit BaseUnix. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Catch a signal
Am 28.01.2013 12:20, schrieb Michael Schnell: Hi Linux fans, I'd like to catch a signal sent to a Linux program. Here: http://www.freepascal.org/docs-html/rtl/oldlinux/signal.html I see: Install signal handler (deprecated) ... This call has the same functionality as the *SigAction* call. So I tried to do this: http://www.freepascal.org/docs-html/rtl/oldlinux/sigaction.html It does not compile, as the unit oldlinux is not compiled in the normal Lazarus svn installation. So I tried to add the directory of oldlinux.pp to the project options (no problem). This now asks for adding multiple more directories with inc files (no problem either) But finally the project gets linker errors, as lineinfo is not provided. Trying to add this seemingly results in recompiling the complete rtl, which I of course don't want to do. So: Hot to catch a signal ? What does the name old imply to you? Nevertheless: The functionality of SigAction is provided by FpSigAction in the unit BaseUnix. For documentation and an example look here: http://www.freepascal.org/docs-html/rtl/baseunix/fpsigaction.html Regards, Sven ___ 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 12:18 PM, Luca Olivetti wrote: Anyway, it can be that your problem is too long a connection timeout (which is system dependent). This would be hours, then. But maybe it is that way on that system. There was a patch a while ago to synapse to add a ConnectionTimeout, but I don't know if it's included in the current version. Bye I'll take a look. In the svn - version in blksock.pas there is a property ConnectionTimeout: Integer read FConnectionTimeout write FConnectionTimeout; Is this what you suggest ? I'll try to set it, as soon as I have access to the box again. Thanks, -Michael ___ 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 Mon, January 28, 2013 11:47, Michael Schnell wrote: . . I tried to reproduce this with a more simple project, just accessing a non-existing IP address, but I found that while on Windows here Synapse issues a time out (after some seconds, exactly like when the Heating Controller fails to answer), when compiling for Linux (PC and ARM) the error message is HR_Error: 113,No route to host and is issued immediately and thus not involves a timeout (and no hanging on ARM). . . While I don't know how to fix your problem, this no route to host should be possible to solve (whether it helps you in reproducing and fixing your issue is another question). What is the IP address and netmask of your device and what is the (non-existing) IP address which you try to access? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Catch a signal
On 01/28/2013 12:24 PM, Sven Barth wrote: What does the name old imply to you? I did not want to ask before having tried on my own ;-) . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freebsd 9.1 -liconv not found
On 01/27/13 15:35, Leonardo M. Ramé wrote: Pass -Fl/usr/local/lib in OPT= Thanks Marco, that did the trick!. I had a similar problem for X11 apps recently. I simply modified my ~/.fpc.cfg file and specified -Fl/usr/local/lib inside there. Solved my problem without too much fuss, and no need to modify compiler parameters per project. 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
[fpc-devel] FreeBSD ports maintainer for FPC?
Hi, Who is the FreeBSD ports maintainer for FPC? There are some grammar errors in the pkg-message.in (final instructions after a make) file. I thought I would notify the ports maintainer of that. 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] Freebsd 9.1 -liconv not found
In our previous episode, Graeme Geldenhuys said: Pass -Fl/usr/local/lib in OPT= Thanks Marco, that did the trick!. I had a similar problem for X11 apps recently. I simply modified my ~/.fpc.cfg file and specified -Fl/usr/local/lib inside there. Solved my problem without too much fuss, and no need to modify compiler parameters per project. The TAR installer and afaik the port should add this line to the config already, so if your installation derives from that, it should be already done. But building fpc ignores (.)fpc.cfg, so it is not a solution anyway for the reported problem. ___ 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 12:27 PM, Tomas Hajny wrote: While I don't know how to fix your problem, this no route to host should be possible to solve (whether it helps you in reproducing and fixing your issue is another question). What is the IP address and netmask of your device and what is the (non-existing) IP address which you try to access? I used the same source code for all compiles (Windows, PC Linux and ARM-Linux), and I tried to use an IP-Address within the local network (192.168.71.XXX) . I'll take another look ASAP. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreeBSD ports maintainer for FPC?
In our previous episode, Graeme Geldenhuys said: Who is the FreeBSD ports maintainer for FPC? There are some grammar errors in the pkg-message.in (final instructions after a make) file. I thought I would notify the ports maintainer of that. There is a MAINTAINER field in every ports makefile? acm@ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
Al 28/01/13 12:26, En/na Michael Schnell ha escrit: On 01/28/2013 12:18 PM, Luca Olivetti wrote: Anyway, it can be that your problem is too long a connection timeout (which is system dependent). This would be hours, then. But maybe it is that way on that system. Well, then it's not it. The default connection timeout should be 20 seconds. There was a patch a while ago to synapse to add a ConnectionTimeout, but I don't know if it's included in the current version. Bye I'll take a look. In the svn - version in blksock.pas there is a property ConnectionTimeout: Integer read FConnectionTimeout write FConnectionTimeout; Is this what you suggest ? Yes, that's it. Bye -- Luca ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Catch a signal
In our previous episode, Michael Schnell said: Here: http://www.freepascal.org/docs-html/rtl/oldlinux/signal.html I see: Install signal handler (deprecated) ... This call has the same functionality as the *SigAction* call. So I tried to do this: http://www.freepascal.org/docs-html/rtl/oldlinux/sigaction.html It does not compile, as the unit oldlinux is not compiled in the normal Lazarus svn installation. Or any normal installation since it has been deprecated since 2004. See baseunix.fpsigaction or baseunix.fpsignal. People stubbornly trying to use it anyway is exactly the reason why it isn't compiled by default anymore. And in 2.6.2 unit libc will trigger a deprecated warning for exactly the same reason. ___ 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 12:49 PM, Luca Olivetti wrote: Well, then it's not it. The default connection timeout should be 20 seconds. This is a slightly propriety Linux distribution by QNAP. So we can't be sure... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Catch a signal
On 01/28/2013 12:51 PM, Marco van de Voort wrote: People stubbornly trying to use it anyway is exactly the reason why it isn't compiled by default anymore. Obviously and as it should be ! It was just a documentation problem and silly me not taking old for depreciated. Thanks again, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
Al 28/01/13 12:49, En/na Luca Olivetti ha escrit: Al 28/01/13 12:26, En/na Michael Schnell ha escrit: On 01/28/2013 12:18 PM, Luca Olivetti wrote: Anyway, it can be that your problem is too long a connection timeout (which is system dependent). This would be hours, then. But maybe it is that way on that system. Well, then it's not it. The default connection timeout should be 20 seconds. or around 3 minutes, I'm not really sure, but certainly not hours. Bye -- Luca ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freebsd 9.1 -liconv not found
On 01/28/13 11:45, Marco van de Voort wrote: The TAR installer and afaik the port should add this line to the config already, I installed the stable FPC from the TAR installer, then installed the fixes version from the repository. All done as a normal user, not root. But building fpc ignores (.)fpc.cfg, so it is not a solution anyway for the reported problem. Thanks for correcting me, my mistake. Re-reading the original post, I see he mentions compiling FPC itself. My message referred to compiling my applications. 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] FreeBSD ports maintainer for FPC?
On 01/28/13 11:49, Marco van de Voort wrote: There is a MAINTAINER field in every ports makefile? acm@ Ah got it, thanks Marco. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 08:07, Michael Van Canneyt wrote: Delphi 7 object pascal could be learned very easily. Nowadays with all the features added you go, try and explain pascal to someone. Say it is 'nice and readable'. +1 Generics, for-in loops, anonymous methods, classes defined inside classes etc... I have and see no need for them, and they simply complicate the beautiful Object Pascal language (at least from the D7 days). Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Synapse hangs in ARM-Linux
In fact I feel that no Route is the more appropriate Error message. When trying to access a not known local IP, the system should issue an ARP request that will time out much faster than the Connect Timeout. After this a no Route Error should be generated by the system. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 08:07, Michael Van Canneyt wrote: If he wants to help, Alexander Klenin had better put his students to useful tasks. There are plenty to choose from. He said maybe he'd look after fcl-stl. The silence since was deafening. He said he needed a arbitrary precision math library: Well, get started ! Both should be perfectly within grasp of a student. If he has students, let them work on that. +1 To add to that list... a native Free Pascal Debugger. I'm already working on this in my [very limited] spare time. Progress is slow, but progress is being made. The debugger is based on reading the DWARF debug information that FPC generates. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 17:17, Alexander Klenin wrote: Using indicies is against all principles of iterators. I am not sure what princilpes you are talking about, The theory. Read any Design Patterns book or technical papers. but accessing the key of the current element is required quite often On the contrary. You should be interested in the current element, not the index value it represents. ALL my iterators in all my application code don't use or need the index value. I simply ask for the Next or Previous object or value. This also hides the implementation details of the container object, thus the container can change its internal implementation, and my Iterator code in my applications will still continue to function without change. 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] for-in-index loop
28.01.13, 20:33, Graeme Geldenhuys пишет: On 01/25/13 08:07, Michael Van Canneyt wrote: Delphi 7 object pascal could be learned very easily. Nowadays with all the features added you go, try and explain pascal to someone. Say it is 'nice and readable'. +1 Generics, for-in loops, anonymous methods, classes defined inside classes etc... I have and see no need for them, and they simply complicate the beautiful Object Pascal language (at least from the D7 days). Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. I used for-in loop many times in my applications simple because it reduce the code and therefore makes it more readable. I also used types inside classes - this is a great feature. I don't need to polute global namespace with internal types. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. I use avanced record syntax because it makes code more understandable. I scarry to use generics but that simple because they have many bugs. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Mon, 28 Jan 2013, Paul Ishenin wrote: 28.01.13, 20:33, Graeme Geldenhuys пишет: On 01/25/13 08:07, Michael Van Canneyt wrote: Delphi 7 object pascal could be learned very easily. Nowadays with all the features added you go, try and explain pascal to someone. Say it is 'nice and readable'. +1 Generics, for-in loops, anonymous methods, classes defined inside classes etc... I have and see no need for them, and they simply complicate the beautiful Object Pascal language (at least from the D7 days). Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. tatata, you should always understand everything :) I used for-in loop many times in my applications simple because it reduce the code and therefore makes it more readable. I also used types inside classes - this is a great feature. I don't need to polute global namespace with internal types. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. I use avanced record syntax because it makes code more understandable. It offers nothing that objects didn't already have. Just trying to say that this is one of these things where Delphi could simply have re-instated the TP-style objects. The compiler compiled them anyway already. There was no need to burden records with methods in an attempt to make them 'object-like'. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
In our previous episode, Michael Van Canneyt said: I use avanced record syntax because it makes code more understandable. It offers nothing that objects didn't already have. Just trying to say that this is one of these things where Delphi could simply have re-instated the TP-style objects. The compiler compiled them anyway already. There was no need to burden records with methods in an attempt to make them 'object-like'. I think it works the other way around, creating room to deprecate TP objects in time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Mon, 28 Jan 2013 21:02:23 +0800 Paul Ishenin paul.ishe...@gmail.com wrote: 28.01.13, 20:33, Graeme Geldenhuys пишет: On 01/25/13 08:07, Michael Van Canneyt wrote: Delphi 7 object pascal could be learned very easily. Nowadays with all the features added you go, try and explain pascal to someone. Say it is 'nice and readable'. +1 Generics, for-in loops, anonymous methods, classes defined inside classes etc... I have and see no need for them, and they simply complicate the beautiful Object Pascal language (at least from the D7 days). Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. You are free to not use a feature, but you must understand all when using third party code. And the new features are neither easy to understand nor to remember. I used for-in loop many times in my applications simple because it reduce the code and therefore makes it more readable. True. But it adds quite a lot of stuff and a simple loop can become much slower. I also used types inside classes - this is a great feature. I don't need to polute global namespace with internal types. True. What about nested classes? I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Correct me if I'm wrong, but all the alternatives in javascript have some drawbacks, you don't write big programs in javascript and the anonymous methods easily confuse the javascript debuggers. I use avanced record syntax because it makes code more understandable. This feature made records more consistent with objects and classes, so I would say they indeed made Pascal easier to understand. I scarry to use generics but that simple because they have many bugs. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/28/13 13:20, Michael Van Canneyt wrote: tatata, you should always understand everything :) :-) Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. Yup. I have also seen sample Delphi code where they used Generics. It was on the Code of Horror website if I remember correctly. It was ridiculously complex, unreadable, and probably a nightmare to debug. I regard simplicity and readability very high in my code. It makes working in a team so much easier too. That is what the Pascal language was all about. I use avanced record syntax because it makes code more understandable. It offers nothing that objects didn't already have. Yeah, what was that all about... advanced records. They are nothing more than the Objects introduced in Turbo Pascal days - and then Embarcadero has the audacity to call it a new language feature. LOL. BTW: I still find it useful using Objects instead of Classes in some places in my code. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 21:20, Michael Van Canneyt wrote: Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. tatata, you should always understand everything :) Very weak argument :) In your work you use system APIs and other frameworks which are made in C, C++ or assembler. I believe you don't understand everything and if you don't - you use the reference if needed. The same way with pascal - if you don't want to learn new features then use libraries as black boxes but if you need then use a reference. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. It is a readability horror when for injecting a small piece of code as anonymouse method in place where it is needed you *must* declare a new named method (which will no be used anywhere else) few screens up or down. It offers nothing that objects didn't already have. It offers understandable memory layout without VMT. Just trying to say that this is one of these things where Delphi could simply have re-instated the TP-style objects. The compiler compiled them anyway already. There was no need to burden records with methods in an attempt to make them 'object-like'. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 21:27, Mattias Gaertner пишет: You are free to not use a feature, but you must understand all when using third party code. And the new features are neither easy to understand nor to remember. Already replied to Michael. You don't need to understand third-party code the same way as you don't need to understand API sources. For winapi and cocoa you don't even have the sources to understand something. True. But it adds quite a lot of stuff and a simple loop can become much slower. True. Classes adds quite a lot of stuff and simple procedures can become much slower. Let's don't use them. I also used types inside classes - this is a great feature. I don't need to polute global namespace with internal types. True. What about nested classes? Class is just one of the types pascal have. If for some reason you need to use internal class - use it. But in my practive I mostly need some enumerations. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Correct me if I'm wrong, but all the alternatives in javascript have some drawbacks, you don't write big programs in javascript and the anonymous methods easily confuse the javascript debuggers. You can use named methods too wihout drawbacks. Of course one of the benefits of anonymouse methods is javascript is access to local variables. And I don't notice that chrome debugger is confused much by them. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Mon, 28 Jan 2013, Paul Ishenin wrote: 28.01.13, 21:20, Michael Van Canneyt wrote: Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. tatata, you should always understand everything :) Very weak argument :) In your work you use system APIs and other frameworks which are made in C, C++ or assembler. I believe you don't understand everything and if you don't - you use the reference if needed. The same way with pascal - if you don't want to learn new features then use libraries as black boxes but if you need then use a reference. I can understand the argument for libraries, but not for the programming language itself. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. It is a readability horror when for injecting a small piece of code as anonymouse method in place where it is needed you *must* declare a new named method (which will no be used anywhere else) few screens up or down. Absolutely. You have local procedures for exactly this reason. That is what Pascal stands for. I use Anonymous methods in Javascript too, but in the majority of cases I end up naming them anyway. So I do not think the use case justifies the mutilation. It offers nothing that objects didn't already have. It offers understandable memory layout without VMT. That could have been solved with a simple novmt' keyword just like the existing 'packed'. There, I could have saved Embarcadero lots of valuable time with that :-) Enough bickering; it is useless. We will not agree, no matter how many arguments are presented: simply because the arguments are of a metaphysical/human/whatever nature, and not technical. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 21:51, Michael Van Canneyt пишет: Enough bickering; it is useless. We will not agree, no matter how many arguments are presented: simply because the arguments are of a metaphysical/human/whatever nature, and not technical. Agreed. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 28.01.2013 14:02, schrieb Paul Ishenin: I scarry to use generics but that simple because they have many bugs. I'm working on them :( Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 28.01.2013 14:39, schrieb Paul Ishenin: I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. It is a readability horror when for injecting a small piece of code as anonymouse method in place where it is needed you *must* declare a new named method (which will no be used anywhere else) few screens up or down. I agree here. Also think about e.g. Synchronize. You must create a parameterless method + fields for each method you want to execute in the main thread. Here I definitely prefer anonymous methods. And an also important aspect of them is that they can capture variable state from outside it's body. You can't do the exact same with nested procedures... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Am 28.01.2013 14:48, schrieb Paul Ishenin: 28.01.13, 21:27, Mattias Gaertner пишет: You are free to not use a feature, but you must understand all when using third party code. And the new features are neither easy to understand nor to remember. Already replied to Michael. You don't need to understand third-party code the same way as you don't need to understand API sources. For winapi and cocoa you don't even have the sources to understand something. For WinAPI: Wine/ReactOS For Cocoa: GNUStep :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin paul.ishe...@gmail.com wrote: I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. It is a readability horror when for injecting a small piece of code as anonymouse method in place where it is needed you *must* declare a new named method (which will no be used anywhere else) few screens up or down. Note that readability troubles of anonymous functions in Pascal are largely due to unfortunate syntax. In a parallel thread, I have offered some suggestions to make them much more readable. It offers nothing that objects didn't already have. It offers understandable memory layout without VMT. Oops... so, FPC object type always creates VMT -- even if there is no virtual methods? -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 28 Jan 2013, at 18:00, Alexander Klenin wrote:
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin paul.ishe...@gmail.com wrote:
It offers nothing that objects didn't already have.
It offers understandable memory layout without VMT.
Oops... so, FPC object type always creates VMT -- even if there is
no virtual methods?
Not always, but there are other conditions when a VMT is generated for objects,
just like in Delphi/TP: when a constructor or destructor exists. In general,
I'd also strongly recommend to treat them as opaque types, especially because
this VMT may be inserted in the middle of the object, and be subject to special
alignment requirements because of the target (regardless of the current
{$packrecords x} or packed setting).
Jonas___
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/28/2013 05:47, Michael Schnell wrote:
I tried to reproduce this with a more simple project, just accessing a
non-existing IP address, but I found that while on Windows here Synapse issues a
time out (after some seconds, exactly like when the Heating Controller fails to
answer), when compiling for Linux (PC and ARM) the error message is HR_Error:
113,No route to host and is issued immediately and thus not involves a timeout
(and no hanging on ARM).
i'm trying to make sure i'm following along here because i'm also using synapse
for a project...
using a slightly modified testhttp (that came with synapse, attached) and
attempting to connect via http to a non-existant IP in my network, i get a 0
result code, empty result string and Connection reset by peer string on my
winwhatever box but that may be due to a firewall proxy that is injected into
all http streams on that winwhatever system... on my os/2 eCS2 box, i get 500
result code, empty result string and Connection refused string... however, if
i try using a non-existent hostname, both return 500 result code, empty result
string and Host not found string...
i would suggest that trying to use a non-existent IP or host is not the way you
want to go to test this... the results are not going to be what you should be
getting from the heating controller connection when it fails...
your No route to host actually sounds plausible if there is, in fact, no route
to the IP you have chosen... that also sounds like there's no default routing
gateway defined for networking traffic headed out of the local network... when i
test trying to access a non-existent IP outside my local network, my winwhatever
box reports Connection reset by peer (as above) and my OS/2 eCS2 box reports
Connection timed out...
suffice it to say that synapse's error codes are not always they seem to be,
unfortunately... run testhttp and you'll see what i mean... i'm pretty sure
there are other result codes and strings that i've not been told about or
discovered yet... oh, and yes, this testhttp will use ssl libraries if they
exist so you can test against https as well as http ;)
EG:
testhttp http://google.com/
301 Moved Permanently
ssl_openssl OpenSSL 0.9.8o 01 Jun 2010
HTTP/1.0 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Mon, 28 Jan 2013 19:00:49 GMT
Expires: Wed, 27 Feb 2013 19:00:49 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Connection: Keep-Alive
testhttp https://google.com/
301 Moved Permanently
ssl_openssl OpenSSL 0.9.8o 01 Jun 2010
HTTP/1.0 301 Moved Permanently
Location: https://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Mon, 28 Jan 2013 19:01:35 GMT
Expires: Wed, 27 Feb 2013 19:01:35 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 220
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Connection: Keep-Alive
{$MODE DELPHI}
Program testhttp;
uses
httpsend, classes, ssl_openssl;
var
HTTP: THTTPSend;
l: tstringlist;
begin
HTTP := THTTPSend.Create;
l := TStringList.create;
try
if not HTTP.HTTPMethod('GET', Paramstr(1)) then
begin
writeln('ERROR');
writeln(Http.Resultcode,' ',Http.Resultstring,'');
writeln('',Http.Sock.SSL.LibName,' ',Http.Sock.SSL.LibVersion,'');
writeln('',Http.Sock.GetErrorDescEx,'');
writeln('',Http.Sock.LastErrorDesc,'');
writeln('',Http.Sock.SSL.LastErrorDesc,'');
end
else
begin
writeln(Http.Resultcode, ' ', Http.Resultstring);
writeln('',Http.Sock.SSL.LibName,' ',Http.Sock.SSL.LibVersion,'');
writeln('',Http.Sock.GetErrorDescEx,'');
writeln('',Http.Sock.LastErrorDesc,'');
writeln('',Http.Sock.SSL.LastErrorDesc,'');
writeln;
writeln(Http.headers.text);
writeln;
l.loadfromstream(Http.Document);
//writeln(l.text);
end;
finally
HTTP.Free;
l.free;
end;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Paul Ishenin schrieb: 28.01.13, 21:20, Michael Van Canneyt wrote: Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. tatata, you should always understand everything :) Very weak argument :) In your work you use system APIs and other frameworks which are made in C, C++ or assembler. I believe you don't understand everything and if you don't - you use the reference if needed. The same way with pascal - if you don't want to learn new features then use libraries as black boxes but if you need then use a reference. As a strong argument: you *must* understand everything when you want to read other people's code, which use the new language features :-( IMO most of the new features had been added *only* for .NET compatibility. But since Delphi.NET is dead, I see no need to introduce them into FPC, where .NET never was on topic. But I understand that the compiler developers need something to put their hands on, so that the new language features come in at the right time. The Delphi developers had a goal (.NET) and limited time, while the FPC developers have time and look out for new goals. 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. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: Support for new type tuple v0.1
On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Consider these examples: var x, y, z: Integer; pt: TPoint; ... (x, y) // record a, b: Integer; end; (x, (y))// record a, b: Integer; end; (x, (y, z))// record a, b: Integer; end; (x, TPoint(y, z)) // record a: Integer; b: TPoint; end; (TPoint(x, y), TPoint(y, z)) // record a, b: TPoint; end; (TPoint(x, y), pt) // record a, b: TPoint; end; (TPoint(x, y), Tuple(pt)) // record a: TPoint; b, c: Integer; end; I don't see the correspondence between the left and right sides, sorry. I also dont see whether the left sides are tuple constructors or deconstructors, what's the intended effect... Right side contains examples of records which would be compatible with the tuples on the left -- for both construction and deconstruction. True, functional programming is certainly the largest modern paradigm still lacking from FPC. What's modern? I've learned about functional programming in 1970 - did all the following languages miss something important? Current consensus in the field of programming languages design is that they did -- which is why FP features are added to just eny language you look at, from C++ to PHP :) Why do you expect any difference between A[Tuple(APos1)] := 1.0; and A[APos1] := 1.0; ? The compiler will have to create the same code for both notations, or use the same RTL subroutine for doing the job. The idea is that second case will require a manually-written operator[], while the first one will work automatically. NACK. How comes that the compiler should break a tuple into a list of indices, but not an array? In detail when the tuple contains such an array? Well, that was the idea, auto- breaking a tuple but not an array, so by converting array to tuple programmer can control it. Note again that I did not mean tuple to be a type, so what I suggested is a convention, which might be adopted by some library for real-time, embedded or other low-level usage where exceptions add too much overhead: res, error := SomeFunction(params); where types of result and error will be chosen as appropriate for each function. The advantages over usual res := SomeFunction(params, error) being: 1) Easier to read, once reader knows the convention 2) Ignoring error is more prominent: res, nil := SomeFunction(params); 3) Since the result is actually a record, functions may still be chained, while ignoring errors: SomeFunction1(SomeFinction2(params).res); The latter looks like breaking tuple rules, by acessing a tuple element by name. The record becomes a tuple only by either explicit conversion, or deconstructing assignment. This means more writing, and the typical use of error codes becomes much more complicated IMO: if f(x, res) then ... has to be rewritten as res, error := f(x); //or: (res,error) := f(x);? if error then ... That depends on the type or err That's why I wonder about yet another syntax proposal. Your proposal *requires* that a record/tuple type *is* used for the result, where otherwise the subroutine could return the result in an CPU or FPU register, ready for immediate further use. There is no reason why a record can not be returned in a register. Actually, there is perhaps even greater chance for that compared to out parameter, which is usually implemented as pointer. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
29.01.2013 9:51, Hans-Peter Diettrich wrote: As a strong argument: you *must* understand everything when you want to read other people's code, which use the new language features :-( Only if you want this. And if you want a new feature will not stop you. Your brains learn something every day anyway. And I believe that the majority of features which you touch below are easy to learn and understand. At least it must be much easier to learn and understand than code from fpc\rtl\i386 which nobody complains about. IMO most of the new features had been added *only* for .NET compatibility. But since Delphi.NET is dead, I see no need to introduce them into FPC, where .NET never was on topic. But I understand that the compiler developers need something to put their hands on, so that the new language features come in at the right time. The Delphi developers had a goal (.NET) and limited time, while the FPC developers have time and look out for new goals. 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? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
