Re: [fpc-devel] Delphi anonymous methods
05.03.13, 15:57, Michael Van Canneyt wrote: With such an attitude you should remove objfpc (and perhaps all non-delphi modes) alltogether, and rename Free Pascal to Free Delphi. The situation with FPC and Delphi is very like to what had happened with browsers. Every had it own vision of CSS, JS and HTML. Currently then finally understood that these dirrences are bad. So if I could I would organaize some forum between Delphi and FPC developers where all new features before been implemented had been discussed first and if accepted nobody could implement it different. I tried to contact with some delphi team members on their forum on twitter and on some blogs but without result. Regards FPC, I would indeed remove FPC mode. Those who need it can use FPC 2.6. I would also minimize the difference between objfpc and delphi modes. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 07:56, schrieb Paul Ishenin: 05.03.13, 14:10, Sven Barth wrote: ObjFPC mode is not compatible with mode Delphi, because of conscious decisions. Think for example about the "@" for procedure variable assignments here or the use of symbolic operator names for overload declarations, instead of words like Delphi did it. And generics are a further example. And I would left (if needed) only those minimal differences. Or even tried to reduce (removed own generics implementation and left only Delphi compatible). In any case I would not add more incompatibilities. Many times the main point to have incompatibilites was: "We implemented it earlier". But regards generics how we implemeneted it earlier? Even now they have some bugs/missing features. And in 2009 when Delphi announced them they had much more (you know of course). That was more a prototype of generics. But inspite of that we did not drop our own implementation. Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner variant of the (Object) Pascal language (and Michael wrote), and if that means higher maintenance burden, so be it. Somewhen in the future we should do a rewrite of the parser anyway and then we can learn from the problems we faced currently and implement it in a way that we can easily extend the language with different implementations (just like was done for the backend). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, 5 Mar 2013, Paul Ishenin wrote: 05.03.13, 15:57, Michael Van Canneyt wrote: With such an attitude you should remove objfpc (and perhaps all non-delphi modes) alltogether, and rename Free Pascal to Free Delphi. The situation with FPC and Delphi is very like to what had happened with browsers. Every had it own vision of CSS, JS and HTML. Currently then finally understood that these dirrences are bad. You piched a wrong comparison. They are still different in all browsers. Each browser has its own extensions of these "standards" as any web developer will tell you. There is some common ground (and even this is sometimes interpreted differently), but that is it. So if I could I would organaize some forum between Delphi and FPC developers where all new features before been implemented had been discussed first and if accepted nobody could implement it different. I tried to contact with some delphi team members on their forum on twitter and on some blogs but without result. I do not believe they will ever do this. Why would they want to ? They (think that they) rule the Pascal community. They do not care a fig for Lazarus/FPC. And that is why we have objfpc mode. Delphi mode is 'Object pascal according to Embarcadero' ObjFPC mode is 'Object Pascal according to Free Pascal' There is nothing wrong with having ObjFPC mode, and the bigger the differences are, the better. The only thing it costs you is some extra cases in parsing, so no maintenance whatsoever. The rest of the compiler remains the same, as the functionality is equal. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, 5 Mar 2013, Sven Barth wrote: Am 05.03.2013 07:56, schrieb Paul Ishenin: 05.03.13, 14:10, Sven Barth wrote: ObjFPC mode is not compatible with mode Delphi, because of conscious decisions. Think for example about the "@" for procedure variable assignments here or the use of symbolic operator names for overload declarations, instead of words like Delphi did it. And generics are a further example. And I would left (if needed) only those minimal differences. Or even tried to reduce (removed own generics implementation and left only Delphi compatible). In any case I would not add more incompatibilities. Many times the main point to have incompatibilites was: "We implemented it earlier". But regards generics how we implemeneted it earlier? Even now they have some bugs/missing features. And in 2009 when Delphi announced them they had much more (you know of course). That was more a prototype of generics. But inspite of that we did not drop our own implementation. Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner variant of the (Object) Pascal language (and Michael wrote), and if that means higher maintenance burden, so be it. Somewhen in the future we should do a rewrite of the parser anyway and then we can learn from the problems we faced currently and implement it in a way that we can easily extend the language with different implementations (just like was done for the backend). +1 Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 16:30, Sven Barth wrote: Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because Sven, relax - FPC is not your own project and not mine. We can't simple commit or revert what we want. not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. Yes, it is hard to parse but anyway you need to implement it. So this argument if false. And regards backward compatibility - it is not too much places to fix: some in FPC itself and some in Lazarus components. Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner variant of the (Object) Pascal language (and Michael wrote), and if that means higher maintenance burden, so be it. That cleaner variants split pascal for nothing - to make 3-5 developers happy. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, 5 Mar 2013, Paul Ishenin wrote: 05.03.13, 16:30, Sven Barth wrote: Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because Sven, relax - FPC is not your own project and not mine. We can't simple commit or revert what we want. Of course we can, if you violate a basic rule: do not undo other peoples work. not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. Yes, it is hard to parse but anyway you need to implement it. So this argument if false. And regards backward compatibility - it is not too much places to fix: some in FPC itself and some in Lazarus components. Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner variant of the (Object) Pascal language (and Michael wrote), and if that means higher maintenance burden, so be it. That cleaner variants split pascal for nothing - to make 3-5 developers happy. It does not split. It offers people the choice. This is the basis of open source: Having a choice. You may think that Delphi is the best thing since sliced bread, but not everyone thinks so. There are several people on the list that do not like what Delphi is doing to the pascal language. The way Embarcadero treats the Pascal Language I am more and more going to this camp. More so with every release of Delphi. You must live with this fact, as I must live with your love of Delphi. We do not deny you your work on Delphi mode. We expect you not to deny us our work on objfpc mode. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 09:59, schrieb Paul Ishenin: Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because Sven, relax - FPC is not your own project and not mine. We can't simple commit or revert what we want. I'm sorry that it sounded a bit harsh, but I consider the topics backwards compatibility and clean language design very serious. And parsing Delphi's syntax is everything, but not clean... not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. Yes, it is hard to parse but anyway you need to implement it. So this argument if false. And regards backward compatibility - it is not too much places to fix: some in FPC itself and some in Lazarus components. Just for your information: I will implement generic methods will full requirement for "generic" and "specialize" in mode ObjFPC (and no, you can't change my opinion on that). And regarding backwards compatibility: we are not only talking about FPC and Lazarus. There are enough people around that use FPC's generic syntax and that alone is reason enough to keep it. Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner variant of the (Object) Pascal language (and Michael wrote), and if that means higher maintenance burden, so be it. That cleaner variants split pascal for nothing - to make 3-5 developers happy. There seem to be enough persons that use mode ObjFPC and its generics and seem to be happy about it. Especially those that don't care about Delphi compatibility. Also it seems that those that like to develop in Delphi are the only ones complaining... or do you hear from any MacPas developer that mode ObjFPC does not support "return", "c" or "$ifc"? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 10:12, schrieb Michael Van Canneyt: There are several people on the list that do not like what Delphi is doing to the pascal language. The way Embarcadero treats the Pascal Language I am more and more going to this camp. More so with every release of Delphi. As this thread clearly shows... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 20:33, Howard Page-Clark wrote: > > You can simulate this in FPC as well as TP by using a local typed > constant. e.g. > > function GetValue: integer; > const value: integer = 0; > begin >Inc(value); >Result:= value; > end; I've seen this before, and always been baffled by this. How can you increment a "constant"? If you can, it is then a variable, no? 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] Delphi anonymous methods
On Tue, 5 Mar 2013, Graeme Geldenhuys wrote: On 2013-03-04 20:33, Howard Page-Clark wrote: You can simulate this in FPC as well as TP by using a local typed constant. e.g. function GetValue: integer; const value: integer = 0; begin Inc(value); Result:= value; end; I've seen this before, and always been baffled by this. How can you increment a "constant"? If you can, it is then a variable, no? A leftover from the TP days. A typed constant acts as an initialized variable. You can disable this construct with: http://www.freepascal.org/docs-html/prog/progsu42.html Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 10:20, schrieb Graeme Geldenhuys: On 2013-03-04 20:33, Howard Page-Clark wrote: You can simulate this in FPC as well as TP by using a local typed constant. e.g. function GetValue: integer; const value: integer = 0; begin Inc(value); Result:= value; end; I've seen this before, and always been baffled by this. How can you increment a "constant"? If you can, it is then a variable, no? In Turbo Pascal these typed constants were used as the poor man's visibility managment. You basically had a global variable that only that function (and nested ones) can access. In Delphi the $J switch was introduced which is disabled by default, which means that typed constants are not writeable. You can nevertheless switch it on. Note: The important point here is that it is a typed constant. And there typed constants and variables are technically the same (both are located in the initalized read/write area of the executable file), while true constants are either inserted directly into the code (ordinals, floating point values) or are located in a read only area of the executable (strings) [if the format does not support a readonly area they are located in the read/write one as well though]. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 17:14, Sven Barth wrote: Just for your information: I will implement generic methods will full requirement for "generic" and "specialize" in mode ObjFPC (and no, you can't change my opinion on that). Yes, I didn't expect my mails will suddenly change your opinion. And even if they would change there are enough fpc team members who will protected objfpc generics :) I only hope to stop duplicate implementation of other delphi features. And regarding backwards compatibility: we are not only talking about FPC and Lazarus. There are enough people around that use FPC's generic syntax and that alone is reason enough to keep it. Enough - how much? 50 or 100 projects? What will be needed to make them work with dephi syntax? Remove word generic and specialize? Especially those that don't care about Delphi compatibility. Also it seems that those that like to develop in Delphi are the only ones complaining... Think about component and applications developers who need to care about FPC and Delphi. Less incompatibilities FPC will have more 3rd party components and applications it will get. I remember author of Total Commander who had failed to port his project to FPC + Laz because of many incompatilities in both projects. I remember Fib+ developer who stoped his effort to port component to FPC after some found incompatibilities. There is nothing good in incompatibilities. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 10:41, schrieb Paul Ishenin: 05.03.13, 17:14, Sven Barth wrote: Just for your information: I will implement generic methods will full requirement for "generic" and "specialize" in mode ObjFPC (and no, you can't change my opinion on that). Yes, I didn't expect my mails will suddenly change your opinion. And even if they would change there are enough fpc team members who will protected objfpc generics :) I only hope to stop duplicate implementation of other delphi features. I won't remove your hope, but I'll also not do anything to fulfill it :P And regarding backwards compatibility: we are not only talking about FPC and Lazarus. There are enough people around that use FPC's generic syntax and that alone is reason enough to keep it. Enough - how much? 50 or 100 projects? What will be needed to make them work with dephi syntax? Remove word generic and specialize? Once we support generic functions/procedures (which Delphi does not support) it will be more :) Especially those that don't care about Delphi compatibility. Also it seems that those that like to develop in Delphi are the only ones complaining... Think about component and applications developers who need to care about FPC and Delphi. Less incompatibilities FPC will have more 3rd party components and applications it will get. For exactly this purpose we have the mode Delphi. And if something is not working there it's either a missing feature, a bug or something that we just plain refuse to support... (e.g. in Delphi you can have one set element multiple times in the same set constructor: [objectdef, objectdef, objectdef]) I remember author of Total Commander who had failed to port his project to FPC + Laz because of many incompatilities in both projects. And some differences are by design. Think about resource string handling here. We might provide the LoadResString function/callback, but it's just a dummy, because FPC's resource strings work differently. The same for Lazarus: some differences are by design, because Lazarus is not fixed to the Windows platform (as a Lazarus developer you should know this). I remember Fib+ developer who stoped his effort to port component to FPC after some found incompatibilities. There is nothing good in incompatibilities. As already wrote by Michael and me: it's not the purpose of mode ObjFPC to provide compatibility. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-05 09:12, Michael Van Canneyt wrote: > You may think that Delphi is the best thing since sliced bread, > but not everyone thinks so. > > There are several people on the list that do not like what Delphi is doing to > the pascal language. +1000 I think Embarcadero is butchering the Object Pascal language. Stealing ideas (and worse, the syntax) from other languages verbatim. They don't put any thought in there language design like Borland did. For that reason, I love FPC and the objfpc mode. ALL my products are developer only in objfpc mode. The syntax is much cleaner and true to Pascal. 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] Delphi anonymous methods
05.03.13, 17:12, Michael Van Canneyt wrote: Of course we can, if you violate a basic rule: do not undo other peoples work. Can you imagine me or anybody other in FPC team who do so without total agreement? It does not split. It offers people the choice. Again we see one thing from different sides. For me this is not a benefit but defect requires elimination. This is the basis of open source: Having a choice. Yes, but I'd love to see this choise not inside 1 project. We do not deny you your work on Delphi mode. We expect you not to deny us our work on objfpc mode. Okay. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 05.03.2013 10:41, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. In theory you can do it already. Compile each unit with "-Ur" (release unit) and the compiler will not attempt to recompile such a unit and prefer to fail. And then you do a compilation run for each unit. Good luck though for circular dependencies (the legal ones). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, 5 Mar 2013, Paul Ishenin wrote:
Think about component and applications developers who need to care about FPC
and Delphi. Less incompatibilities FPC will have more 3rd party components
and applications it will get.
For this, mode delphi exists.
I remember author of Total Commander who had failed to port his project to
FPC + Laz because of many incompatilities in both projects.
I remember Fib+ developer who stoped his effort to port component to FPC
after some found incompatibilities.
There is nothing good in incompatibilities.
There is no incompatibility. There is choice.
People who wish to port Delphi code should use {$mode delphi}.
And from what I see, people that come from Delphi automatically use $mode delphi.
Good, that is what it is for.
I fully agree with you that Delphi mode should try and be as Delphi compatible
as possible.
All that is being argued is that there must be the choice to have another mode where people
that do not care or agree with Delphi, can implement things the way they think it should be done.
FPC is as old as Delphi.
I think that gives us the right of speech and the right to voice our own opinion.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 10:53, schrieb Graeme Geldenhuys: On 2013-03-05 09:12, Michael Van Canneyt wrote: You may think that Delphi is the best thing since sliced bread, but not everyone thinks so. There are several people on the list that do not like what Delphi is doing to the pascal language. +1000 I think Embarcadero is butchering the Object Pascal language. Stealing ideas (and worse, the syntax) from other languages verbatim. They don't put any thought in there language design like Borland did. For that reason, I love FPC and the objfpc mode. ALL my products are developer only in objfpc mode. The syntax is much cleaner and true to Pascal. @Paul: see? :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: > Sven Barth wrote: > >Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: > >> > >>But on the other hand, if an application programmer could > >>disable FPC's unit handling and use make -j instead, choosing > >>to pay the price of difficult maintenance, it might defuse the > >>criticism coming from certain quarters. > >> > >Make can not figure out the dependencies between units by itself > >as it would need to parse them. > > That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, 5 Mar 2013, Paul Ishenin wrote: 05.03.13, 17:12, Michael Van Canneyt wrote: Of course we can, if you violate a basic rule: do not undo other peoples work. Can you imagine me or anybody other in FPC team who do so without total agreement? I hope not :) It does not split. It offers people the choice. Again we see one thing from different sides. For me this is not a benefit but defect requires elimination. This is your right. This is the basis of open source: Having a choice. Yes, but I'd love to see this choise not inside 1 project. Since it is not your project to begin with, you'll have to learn to live with this choice. Like I have to live with your implementations. Live and let live. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] STOP OVER QUOTING PLEASE
Hi, I find it extremely hard to follow conversations in this mailing list lately. Everybody seems to disregard simple netiquette guidelines here. For example: I can't read a message thread any more by just using my up/down arrow keys [jumping from one reply to the next]. I have to constantly scroll 50+ lines of quoted text [often 4-6 levels keep quotes], just to get to a 2-4 line reply! Please, please, please... trim your quotes to just the relevant lines. It takes but a second to do, so will not slow you down. I know I'm not the list moderator, but try and respect some basic netiquette, and make it easier for everybody to read messages here. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 05.03.2013 10:58, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. As this is something we (as in the FPC developers) don't need: patches are welcome. [or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ] Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, Mar 05, 2013 at 10:12:04AM +0100, Michael Van Canneyt wrote: > You may think that Delphi is the best thing since sliced bread, > but not everyone thinks so. And with the attitude of, e.g. Boian, we see that it's simply too hard to please hard-core delphi fanboys. They're all "take" and no "give". I look forward to the day when the fpc developers will realise that playing eternal catch-up is never going to work. > There are several people on the list that do not like what Delphi is doing to > the pascal language. The way Embarcadero treats the Pascal Language > I am more and more going to this camp. More so with every release of > Delphi. Much kudos to Sven for really trying to keep the language sane. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Henry Vermaak wrote: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. Possibly augmented by timestamp-based validity checking. Yes, but I didn't want to muddy the water by suggesting too many things at once :-) Seriously: if FPC's putting too much internal work into sorting out dependencies and somebody is prepared to write his code for an alternative build system, then give him enough rope. But it would obviously shine a harsh light on the compiler if this turned out not to be the major bottleneck. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, 5 Mar 2013, Sven Barth wrote: Am 05.03.2013 10:58, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. As this is something we (as in the FPC developers) don't need: patches are welcome. [or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ] There is a new tool "pas2fpm.pp" which can easily be adapted to do this. It already calculates the dependencies, but outputs them in fpmake form. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 17:55, Sven Barth wrote: @Paul: see? :) I see you, Graeme, Michael and probably some more 5-6 developers. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 11:05:22AM +0100, Sven Barth wrote: > Am 05.03.2013 10:58, schrieb Henry Vermaak: > >On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: > >>Sven Barth wrote: > >>>Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: > But on the other hand, if an application programmer could > disable FPC's unit handling and use make -j instead, choosing > to pay the price of difficult maintenance, it might defuse the > criticism coming from certain quarters. > > >>>Make can not figure out the dependencies between units by itself > >>>as it would need to parse them. > >>That's for the user to do, if he thinks he can do a better job than FPC. > >Or implement an option that spits out the dependencies for make, so that > >the user doesn't have to do this. > As this is something we (as in the FPC developers) don't need: > patches are welcome. I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then? I'm not ordering anyone to implement features, I'm exploring solutions to the depressing fact that my c projects compile quicker than my fpc projects (simply because my build system can launch parallel jobs). I don't think that turning fpc into a multi-threaded compiler is a sane thing to do. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Michael Van Canneyt hat am 5. März 2013 um 11:09 geschrieben: > > > On Tue, 5 Mar 2013, Sven Barth wrote: > > > Am 05.03.2013 10:58, schrieb Henry Vermaak: > >> On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: > >>> Sven Barth wrote: > Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: > > But on the other hand, if an application programmer could > > disable FPC's unit handling and use make -j instead, choosing > > to pay the price of difficult maintenance, it might defuse the > > criticism coming from certain quarters. > > > Make can not figure out the dependencies between units by itself > as it would need to parse them. > >>> That's for the user to do, if he thinks he can do a better job than FPC. > >> Or implement an option that spits out the dependencies for make, so that > >> the user doesn't have to do this. > > As this is something we (as in the FPC developers) don't need: patches are > > welcome. > > > > [or you could try whether the ppdep tool still works: > > http://www.freepascal.org/tools/ppdep.var ] > > There is a new tool "pas2fpm.pp" which can easily be adapted to do this. > It already calculates the dependencies, but outputs them in fpmake form. Is this correct: You need the tool pas2fpm to feed the tool fpmake to feed the tool fpc to feed linker, lazres Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 11:09:39AM +0100, Michael Van Canneyt wrote: > > There is a new tool "pas2fpm.pp" which can easily be adapted to do this. > It already calculates the dependencies, but outputs them in fpmake form. Ah, I remember that fpmake can build with multiple threads, so perhaps this is a better solution than to do it with make. I'll investigate. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, 5 Mar 2013, Mattias Gaertner wrote: Michael Van Canneyt hat am 5. März 2013 um 11:09 geschrieben: On Tue, 5 Mar 2013, Sven Barth wrote: Am 05.03.2013 10:58, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. As this is something we (as in the FPC developers) don't need: patches are welcome. [or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ] There is a new tool "pas2fpm.pp" which can easily be adapted to do this. It already calculates the dependencies, but outputs them in fpmake form. Is this correct: You need the tool pas2fpm to feed the tool fpmake to feed the tool fpc to feed linker, lazres You don't need anything. You can create fpmake.pp yourself. pas2fpm makes it easier for you. Just like "configure" and "autoconf" make it easier to create Makefiles if you use C. But because pas2fpm parses your units to do its job, it can go wrong, even on legal code. So using it should be optional. You could try and integrate all in 1 tool (like in an IDE as lazarus). fpmake was set up so it can be integrated completely in lazarus if you want it. Same for fppkg. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Paul Ishenin wrote: I remember author of Total Commander who had failed to port his project to FPC + Laz because of many incompatilities in both projects. IMHO, you are not right. the 64-bit version seems to be written in FPC/Lazarus: The string "FPC 2.5.1 [2011/12/03] for x86_64 - Win64" can be found in the binary. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 11:05, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 10:12:04AM +0100, Michael Van Canneyt wrote: You may think that Delphi is the best thing since sliced bread, but not everyone thinks so. And with the attitude of, e.g. Boian, we see that it's simply too hard to please hard-core delphi fanboys. They're all "take" and no "give". I look forward to the day when the fpc developers will realise that playing eternal catch-up is never going to work. Somehow I hope we reach this day sooner than later... There are several people on the list that do not like what Delphi is doing to the pascal language. The way Embarcadero treats the Pascal Language I am more and more going to this camp. More so with every release of Delphi. Much kudos to Sven for really trying to keep the language sane. Thanks, I try my best :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > IMHO a threading clusterfsck is preferable to a forking clusterfck :-) > > My gut feeling would be that the complexity and potential bugs/races > don't make up for the speed, but maybe a threaded compiler gains a lot > more than I imagine. Are there any multi-threaded compilers around for > comparison? Not the normal free ones. But that is not really a metric, but none of them were designed for modular languages, stronger, they don't even use features like precompiled headers that commercial ones already have for a long time. Note that strictly only the part of make *must* be multithreaded, the compilation of a compilation unit is basically the current single threaded compiler running in its own thread. So the parts that decide which compilation unit must be loaded, and parts of the unit loader. I think the problem is more doing it in a non-trivial production compiler, than the principle itself. > > This means you need to manually specify in the build system which > > compilation unit depends on which headers. And this is also why in C/C++ > > inline functions are in the header, so that this model is persistent, since > > most builds are not full, but incremental. > > As you probably know, you can use -MD and variants with gcc, which > outputs dependency files for make, that you then include in the > Makefile. No, but I did know other tools for that yes. Compiler output is better of course. > If you add, e.g. -MMD to the CFLAGS, these dependencies are > generated as a side effect of the compilation process, so it's not a > separate step. As a result, partial builds work really well, and can be > parallelized as usual. No manual work involved. Maybe that works for FPC too. But FPC can currently compile units multiple times afaik. (to detangle circular references), FPC afaik also registers some preprocessor state, and compiles on change. So basically make is meant for a different execution model IMHO, and it shouldn't be made a cornerstone. It is only a stopgap till we have something that fits with the unit system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > >>But on the other hand, if an application programmer could > > >>disable FPC's unit handling and use make -j instead, choosing > > >>to pay the price of difficult maintenance, it might defuse the > > >>criticism coming from certain quarters. > > >> > > >Make can not figure out the dependencies between units by itself > > >as it would need to parse them. > > > > That's for the user to do, if he thinks he can do a better job than FPC. > > Or implement an option that spits out the dependencies for make, so that > the user doesn't have to do this. That does't work, since in FPC an unit is an interface AND an implementation. And inline functions are in the implementation, not the interface. The only way is to simply toss the modular system (units) out, and work with $i, declare functions as externals in headers, let the compiler spit out dependencies. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-05 10:31, Henry Vermaak wrote: > > Ah, I remember that fpmake can build with multiple threads, so perhaps > this is a better solution than to do it with make. I'll investigate. I've got that option enabled by default for building FPC 2.7.1 and it does shave off a few seconds. I'm also trying to use fpmake for other "hourly build server" tasks, where I need to do clean compiles of various independent packages first, then build the test suite that pulls everything together. eg: building Synapse, FBLib, tiOPF, EpikTimer, fpGUI etc in parallel. Then somehow wait until they are all done, then build the test suite which uses all those packages. I still haven't figure this process out yet. If you have hints or suggestion on this, it would be greatly appreciated [maybe follow-up in a new message thread in fpc-pascal] 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] Delphi anonymous methods
In our previous episode, Sven Barth said: > > when Delphi announced them they had much more (you know of course). > > That was more a prototype of generics. But inspite of that we did not > > drop our own implementation. > Just to say one thing clear: I will NOT drop FPC's generic > implementation and I'll revert every commit that tries to do so, because > not only do we have to keep backwards compatibility, but the Delphi > syntax is a nightmare to parse. But you need to anyway because of mode delphi, so what is the point? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, Mar 5, 2013 at 9:10 PM, Paul Ishenin wrote: > 05.03.13, 17:55, Sven Barth wrote: > > I see you, Graeme, Michael and probably some more 5-6 developers. > The level of Delphi compatibility vs. syntax quality is, as always in engineering, a matter of compromise and cost/benefit analysis. For example, and trying to return to the topic of this thread, I think "embedded" anonymous functions should be implemented for both Delphi and ObjFPC mode -- even if there will be better alternatives in ObjFPC. This way, at least in one direction compatibility will be preserved, while people preferring "pure Pascal" style will still be able to ignore Delphi syntax in their FPC-only projects. On the other hand, default closure behavior should perhaps be implemented differently. There are three choices for anonymous function without additional annotations: 1) No closure 2) By-reference closure 3) By-value closure Delphi currently implements (2) which is inconsistent with nested functions and introduces a subtle and unexpected performance drop. I suggest (1) in ObjFPC mode, but (2) in Delphi mode, with additional modeswitch, as usual. This is why I propose the following plan: 1) Implement Delphi-like anonymous functions syntax, without closures 2) Implement Delphi-like by-reference closures 3) Implement ObjFPC-specific named closures with explicit by-value/by reference options 4) Implement ObjFPC-specific shortened syntax Discussion of ObjFPC extension may continue while the implementation of (1) and (2) is in progress. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, Mar 5, 2013 at 10:24 PM, Marco van de Voort wrote: >> Just to say one thing clear: I will NOT drop FPC's generic >> implementation and I'll revert every commit that tries to do so, because >> not only do we have to keep backwards compatibility, but the Delphi >> syntax is a nightmare to parse. > > But you need to anyway because of mode delphi, so what is the point? It is hard to parse for humans as well as for the compiler. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
In our previous episode, Alexander Klenin said: > >> not only do we have to keep backwards compatibility, but the Delphi > >> syntax is a nightmare to parse. > > > > But you need to anyway because of mode delphi, so what is the point? > > It is hard to parse for humans as well as for the compiler. That's a matter of taste. I'm not sb who in general favours terse notation, but I don't really see the benefit of the FPC syntax for humans. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 10:25, schrieb Michael Van Canneyt: I've seen this before, and always been baffled by this. How can you increment a "constant"? If you can, it is then a variable, no? A leftover from the TP days. A typed constant acts as an initialized variable. You can disable this construct with: http://www.freepascal.org/docs-html/prog/progsu42.html This should be the default in ObjFpc mode. Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 11:44:37AM +0100, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > >>But on the other hand, if an application programmer could > > > >>disable FPC's unit handling and use make -j instead, choosing > > > >>to pay the price of difficult maintenance, it might defuse the > > > >>criticism coming from certain quarters. > > > >> > > > >Make can not figure out the dependencies between units by itself > > > >as it would need to parse them. > > > > > > That's for the user to do, if he thinks he can do a better job than FPC. > > > > Or implement an option that spits out the dependencies for make, so that > > the user doesn't have to do this. > > That does't work, since in FPC an unit is an interface AND an > implementation. And inline functions are in the implementation, not the > interface. > > The only way is to simply toss the modular system (units) out, and work with > $i, declare functions as externals in headers, let the compiler spit out > dependencies. OK, I'll drop this line of enquiry then :) Thanks for the information (and the patience). Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Henry Vermaak schrieb: I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then? Yes and no. It would mean to create kind of header files for the Pascal units, usable to compile the units independently. No problem at a first glance, the Interface is the equivalent of an C header file, and the Uses lists are equivalent to further #includes. One of the remaining problems are the lost unit qualifiers, so that external references in the object files cannot be safely resolved. But in fact above is what FPC already does! When it encounters a Uses list, it loads the according PPU or, if not available or outdated, compiles the requested unit. Thus the PPU files already *are* the equivalent of the C header files. Plus the bonus that every "header" has to be loaded only once, not for every single module to be compiled by an C compiler. The problem IMO is the long list of units waiting for their dependencies loaded, before the first unit can be compiled at all (top-down). More efficient were bottom-up compilation, starting with the units with only few dependencies, so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Pass compiler options to generics [was Delphi anonymous methods]
On 2013-03-05 12:37, Sven Barth wrote: Thanks, I try my best :) I know you do. And, since generics has also been mentioned in this thread, here is something I'd like to table/mention (or, rather, use you as a sounding board, if I may). Sometimes writing generic routines that are truly generic is hard since the types it needs to handle can be tough to genericise (strings, ordinals, objects etc. are not always treatable in generic routines in the same way). The solution to this might be to write different generic routines for each offending type but this means duplication plenty of code in the process which in turn defeates quite a bit of the purpose of having generics. This brings me to wonder if it would be possible to pass some constant (or set of constants, or something similar) to generic routine such that this/these option(s) would be treated as compiles options within the implementation of the generic routine. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Unicode String Manager on darwin
With the fpc 2.7.1 trunk, the following simple program does not work
under darwin unless I also include the unit cwstring:
program project1;
{$mode objfpc}{$H+}
uses sysutils;// also needs the unit cwstring to work under
darwin
function toupper(const s: WideString): WideString;
begin
result := WideUpperCase(s);
end;
begin
writeln(toupper('hello world'));
end.
---
Is this the intended behavior?
Upon running the program above I get the error:
This binary has no unicodestrings support compiled in.
Recompile the application with a unicodestrings-manager in the program
uses clause.
An unhandled exception occurred at $0001EECB:
ENoWideStringSupport: SIGQUIT signal received.
$0001EECB GENERICUNICODECASE, line 2181 of
/Users/lou/fpc/fpc/rtl/darwin/../bsd/system.pp
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 11:10, schrieb Paul Ishenin: @Paul: see? :) I see you, Graeme, Michael and probably some more 5-6 developers. That is the problem with mailing lists. Not everybody sends a mail, just saying "+1 from me too". And so it could be "probably some more 500-600 developers". And btw: actual Delphi vs. ObjFPc -> +1 for ObjFpc from me ;) Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > That does't work, since in FPC an unit is an interface AND an > > implementation. And inline functions are in the implementation, not the > > interface. > > > > The only way is to simply toss the modular system (units) out, and work with > > $i, declare functions as externals in headers, let the compiler spit out > > dependencies. > > OK, I'll drop this line of enquiry then :) Thanks for the information > (and the patience). No problem at all, writing it down helped me see things more clearly too. I before never thought about the incremental build aspect. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, Mar 5, 2013 at 7:10 AM, Paul Ishenin wrote: > 05.03.13, 17:55, Sven Barth wrote: > >> @Paul: see? :) > > > I see you, Graeme, Michael and probably some more 5-6 developers. So now we have 7! ;-) I want to keep the language sane too. Regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode String Manager on darwin
Am 03.03.2013 22:23, schrieb Louis Salkind:
With the fpc 2.7.1 trunk, the following simple program does not work
under darwin unless I also include the unit cwstring:
program project1;
{$mode objfpc}{$H+}
uses sysutils;// also needs the unit cwstring to work
under darwin
function toupper(const s: WideString): WideString;
begin
result := WideUpperCase(s);
end;
begin
writeln(toupper('hello world'));
end.
---
Is this the intended behavior?
Yes, this is intended behavior on Unix based systems, because this will
cause the code to link to the C library (though one can debate whether
this makes any difference on Mac OS X, where we link to the C library
anyway...).
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 12:44, schrieb Michael Fuchs: Am 05.03.2013 10:25, schrieb Michael Van Canneyt: I've seen this before, and always been baffled by this. How can you increment a "constant"? If you can, it is then a variable, no? A leftover from the TP days. A typed constant acts as an initialized variable. You can disable this construct with: http://www.freepascal.org/docs-html/prog/progsu42.html This should be the default in ObjFpc mode. Two words: backwards compatibility. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 12:29, schrieb Alexander Klenin: This is why I propose the following plan: 1) Implement Delphi-like anonymous functions syntax, without closures 2) Implement Delphi-like by-reference closures 3) Implement ObjFPC-specific named closures with explicit by-value/by reference options 4) Implement ObjFPC-specific shortened syntax Discussion of ObjFPC extension may continue while the implementation of (1) and (2) is in progress. I basically agree. Though for now anonymous functions should be either bound to mode Delphi or at least a modeswitch (enabled by default in mode Delphi and disabled everywhere else). [or maybe we should add such newer extensions to mode DelphiUnicode?] The type "reference to ..." should be available in either mode though (independantly of anonymous functions). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 12:24, schrieb Marco van de Voort: In our previous episode, Sven Barth said: when Delphi announced them they had much more (you know of course). That was more a prototype of generics. But inspite of that we did not drop our own implementation. Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. But you need to anyway because of mode delphi, so what is the point? Because in mode Delphi the following will not work for quite some time (because it is so damn hard to parse): === example begin === SomeVar := SomeFunc - SomeType.SomeMethod * SomeOtherType.SomeMethod; === example end === while this will be much easier to implement: === example begin === SomeVar := specialize SomeFunc - specialize SomeType.SomeMethod * specialize SomeOtherType.specialize SomeMethod; === example end === (though "specialize SomeType" and "specialize SomeOtherType" are more likely to stay in type sections for now...) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth wrote: > > SomeVar := SomeFunc - SomeType.SomeMethod * > SomeOtherType.SomeMethod; > > === example end === > > while this will be much easier to implement: > > === example begin === > > SomeVar := specialize SomeFunc - specialize > SomeType.SomeMethod * specialize > SomeOtherType.specialize SomeMethod; > > === example end === > > (though "specialize SomeType" and "specialize > SomeOtherType" are more likely to stay in type sections for > now...) > BTW, does anybody know why on earth the "sane" objFPC syntax still have those angle brackets instead of normal round ones? -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 14:23, schrieb Alexander Klenin: On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth wrote: SomeVar := SomeFunc - SomeType.SomeMethod * SomeOtherType.SomeMethod; === example end === while this will be much easier to implement: === example begin === SomeVar := specialize SomeFunc - specialize SomeType.SomeMethod * specialize SomeOtherType.specialize SomeMethod; === example end === (though "specialize SomeType" and "specialize SomeOtherType" are more likely to stay in type sections for now...) BTW, does anybody know why on earth the "sane" objFPC syntax still have those angle brackets instead of normal round ones? I don't know why the one who first implemented them chose them, but now the reason is backwards compatibility. Please note that I wouldn't have choosen round brackets either (potential conflicts with type casting) but more something like this: === snippet begin === specialize SomeType with (Something) === snippet end === Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Sven Barth hat am 5. März 2013 um 14:27 geschrieben: >[...] > Please note that I wouldn't have choosen round brackets either > (potential conflicts with type casting) ? Can you give an example? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth wrote: > I don't know why the one who first implemented them chose them, but now the > reason is backwards compatibility. > > Please note that I wouldn't have choosen round brackets either (potential > conflicts with type casting) Is not "specialize" keyword there to prevent exactly this? > specialize SomeType with (Something) I would like to propose a modification to one of the principles we brought up in this thread: "prefer keywords to punctuation ... but not to the point of becoming COBOL" :) -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 14:50, schrieb Alexander Klenin: On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth wrote: I don't know why the one who first implemented them chose them, but now the reason is backwards compatibility. Please note that I wouldn't have choosen round brackets either (potential conflicts with type casting) Is not "specialize" keyword there to prevent exactly this? Right... I forgot :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 14:41, schrieb Mattias Gaertner: Sven Barth hat am 5. März 2013 um 14:27 geschrieben: [...] Please note that I wouldn't have choosen round brackets either (potential conflicts with type casting) ? Can you give an example? Forget what I wrote... As I've written in my mail to Alexander, I've forgotten that we have the "specialize" as an introductory keyword. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 03/05/2013 05:34 AM, waldo kitty wrote:
It is as I thought about closures before. But this is useless without
capturing
of variables by value. During creation of anonymous method you *can
not bind any
values* to it. Anonymous method have only references to captured
variables.
Pascal don't allows to create static variables inside function like
in c-like
languages. So you also not able to create unique static variable
which available
only to one instance of same anonymous method. Even if implementation
will
create many separate objects for one anonymous function then all
instances will
be equivalent. Because all instances will refer to same data.
i'm trying to understand what you mean by
> Pascal don't allows to create static variables inside function like
in c-like
> languages.
i've done something that i think is what you speak of but it was in
Borland's Turbo Pascal... at least TP6... i don't remember how we did
it though and can't find any sample code in my library :(
what happened is that the value did not get cleared between
invocations of the routine and subsequent executions could use the
value already stored... this breaks, of course, if the memory area for
the routine is cleared first...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Word "static" is mistake here, sorry. It should be "local" variable instead.
As it was said in this thread: closure is a way to create object (no
mean named closure or anonymous). Closure is a routine with all
variables which it accesses (or "captures" in terminology of Delphi or
C++). So closure is routine + captured data. I expected that Delphi will
create one object for one closure.
In example below I was expecting to see creation of 10 different
objects. But Delphi creates only 1 object. I was surprised.
=== example
for i := 1 to 10 begin
arr[i] := procedure begin
...
end;
===
All arr[i] have same value(same reference).
Actually Delphi creates object(called FrameObject in Delphi's docs) for
closure otherwise it will not work. But Delphi creates this object not
for every closure but only for procedure where closure defined. This
details described in pdf file which I attached in first message of
thread. Also Sven created good comments which describes how Delphi
implements closures and how capturing by value should work
http://lists.freepascal.org/lists/fpc-devel/2013-March/031588.html.
My confused comment can be reformulated: Delphi doesn't create object
for each closure because there is no need to do it. But why many other
languages should create object for each closure but Delphi need not ?
Because Pascal allows to declare local variables only in beginning of
routine. But many c-like languages allows to declare local variables in
middle of routine. I will describe on example.
Imagine that you want to create many similar objects in loop like this:
=== example
type TWriter = class
data: Integer;
constructor Create(i: Integer);
procedure Execute;
end;
constructor TWriter.Create(i: Integer); begin data := i; end;
procedure TWriter.Execute; begin Writeln(data); end;
var i: Integer;
arr: array[1..10] of TWriter;
begin
for i := 1 to 10 do
arr[i] := TWriter.Create(i);
for i := 1 to 10 do
arr[i].Execute;
end.
===
=== output
1 2 3 4 5 6 7 8 9 10
===
If someone will try to make same trick using Delphi's anonymous
methods(Delphi's implementation of closures) he may try to do this
=== wrong
for i := 1 to 10 do
procArr[i] := procedure begin
Writeln(i);
end;
for j := 1 to 10 do
procArr[j]();
===
=== output
11 11 11 11 11 11 11 11 11 11
===
Why? Because all procedures from procArr captured variable 'i' by
reference. They access same variable. So this is a problem to simply
create "private" data for closure. But you can do it like this:
=== right
function Factory(data: Integer): TProc;
begin
Result := procedure begin
Writeln(data);
end;
end;
...
for i := 1 to 10 do
procArr[i] := Factory(i);
for j := 1 to 10 do
procArr[j]();
===
=== output
1 2 3 4 5 6 7 8 9 10
===
Just as expected.
Now about local variables and why in other languages simple creation of
"private" variable for closure is not a problem.
=== perl
for (my $i = 0; $i < 10; ++$i) {
{
my $stored = $i;
$f[$i] = sub { printf $stored }
}
}
for (my $j = 0; $j < 10; ++$j) {
$f[$j]();
}
===
=== output
0123456789
===
This is works because:
- each loop iteration creates new variable $stored
- closure captures $stored
- variable $stored is accessible only in it's declaring block { .. }
; at end of loop iteration only closure will save link to it.
So Perl have to create new object for each closure because each closure
may contains private d
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 21:00, Marcos Douglas пишет: So now we have 7! ;-) I want to keep the language sane too. I wrote not about sane/insane. Delphi adds features to pascal the way they want - this is reality. We can't do anything with this. If they add a feature not the sane way we can't undo their feature. From that moment language become so - with this feature. Whether we want or no. Sooner or later we will have to deal with this feature exactly as Delphi developers see it. What I was against is to add the second implementation for already existent language feature. But after mail of Michael I already look at this more tolerant now. So please let's stop this endless dispute about nothing. We have different vision and this is good after all. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Am 05.03.2013 11:10, schrieb Paul Ishenin: 05.03.13, 17:55, Sven Barth wrote: @Paul: see? :) I see you, Graeme, Michael and probably some more 5-6 developers. Even if those are the only ones, from the beginning, FPC tried to support all niches. And if someone maintaines a certain niche, the niche will be continued to be support. Actually, I think FPC lives from niches and developers working on niches. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, Mar 5, 2013 at 11:46 AM, Paul Ishenin wrote: > 05.03.13, 21:00, Marcos Douglas пишет: > >> So now we have 7! ;-) >> I want to keep the language sane too. > > > I wrote not about sane/insane. Delphi adds features to pascal the way they > want - this is reality. We can't do anything with this. If they add a > feature not the sane way we can't undo their feature. From that moment > language become so - with this feature. Whether we want or no. Sooner or > later we will have to deal with this feature exactly as Delphi developers > see it. But if something isn't good enough, why spend time to codify this? > What I was against is to add the second implementation for already existent > language feature. Why follow the Delphi even knowing that is the wrong way to implement something? > But after mail of Michael I already look at this more tolerant now. So > please let's stop this endless dispute about nothing. We have different > vision and this is good after all. Ok. Best regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 3/4/2013 15:33, Howard Page-Clark wrote: On 04/03/13 6:34, waldo kitty wrote: i'm trying to understand what you mean by > Pascal don't allows to create static variables inside function > like in c-like languages. i've done something that i think is what you speak of but it was in Borland's Turbo Pascal... at least TP6... i don't remember how we did it though and can't find any sample code in my library :( You can simulate this in FPC as well as TP by using a local typed constant. e.g. function GetValue: integer; const value: integer = 0; begin Inc(value); Result:= value; end; Successive calls to GetValue() will return 1, 2, 3 etc. yes, that is exactly what i was thinking of... i just could not find any sample code in my library... as noted, i have used it and it sounds similar to what the OP is looking to do... one thing i used to use it for was counting the number of time that a routine was called during the course of execution... other times i used it were in relation to recursion IIRC... NOTE: i've never done this with strings but i would guess it would work, too... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pass compiler options to generics [was Delphi anonymous methods]
On Tue, Mar 5, 2013 at 11:13 PM, ListMember wrote: > This brings me to wonder if it would be possible to pass some constant (or > set of constants, or something similar) to generic routine such that > this/these option(s) would be treated as compiles options within the > implementation of the generic routine. Ugh, that is definitely not the right solution. Some alternatives: 1) Make sure "is" and "as" work with generic types -- maybe they already are? 2) Since currently the specialization has to be named anyway, write non-generic versions for "inconvenient" types, and use inheritance to factor out common code. 3) Implement partial specialization, in C++ style -- fundamental solution, but perhaps an overkill in the light of the above. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 3/5/2013 04:20, Graeme Geldenhuys wrote: On 2013-03-04 20:33, Howard Page-Clark wrote: You can simulate this in FPC as well as TP by using a local typed constant. e.g. function GetValue: integer; const value: integer = 0; begin Inc(value); Result:= value; end; I've seen this before, and always been baffled by this. How can you increment a "constant"? If you can, it is then a variable, no? yep... i also call all named storage items variables even if they are constants... what else do you call them in a generic sense? ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Agree :-) . A native Linux version is planned. It will be however done with either Lazarus or Delphi if its Linux version becomes available next year, or our own non Pascal compiler in the next couple of years if that one gets ready. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 11:51 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods A pity. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 3/5/2013 05:50, Graeme Geldenhuys wrote: I'm also trying to use fpmake for other "hourly build server" tasks, where I need to do clean compiles of various independent packages first, then build the test suite that pulls everything together. eg: building Synapse, FBLib, tiOPF, EpikTimer, fpGUI etc in parallel. Then somehow wait until they are all done, then build the test suite which uses all those packages. I still haven't figure this process out yet. If you have hints or suggestion on this, it would be greatly appreciated [maybe follow-up in a new message thread in fpc-pascal] on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages... one is created when the section is entered into and another when the section is successfully compiled... it is mostly all C stuff and uses make... it is all pretty much FM to me as i only start it and wait for it to reach my modules and see if they compile or fail... if they fail, i (w)hack at them some more... the breadcrumbs allow the compilation environment to pick up where it left off instead of spending two hours recompiling everything again up to the point of failure... maybe this can give you some ideas? FWIW: the above breadcrumb system that i speak of is in the development version of an open source firewall product that i work with ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies. == Disk I/O is a huge low-down to avoid on any price (like databases do with their indexing). Today me tested building LINUX kernel 3.8.0 on 8*SMT=16 CPU system (Corei7 2G) + 32G DDR3 + 175(wr)/350(rd)MB/s RAID1. And this monster outperformed another cheap E8400 + 4G machine by only 2 times and most probably because the cheap machine was non-RAIDed. And because Core i* arch can't have proper DMA. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
"make -j 16 deb-pkg" vs "make -j 2 deb-pkg", sure :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Hi Henry, Interesting that you consider me a Delphi fanboy :-D . I don't like it much, but I surely love the anonymous methods :-D . I love the C++11 implementation of anonymous methods more however, but I hate the lack of extensive RTTI in C++ (and FPC). I am hard to please, and no fan of any specific language. I hate them, and love them equally with only one exception, well maybe 2. I highly dislike Java, and I hate Scheme! :-D . And BTW: I hate my products too, so that is why I keep working to improve them all the time :-D, they are never good enough for me! I am equal opportunity hater! With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Henry Vermaak Sent: Tuesday, March 05, 2013 2:05 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods And with the attitude of, e.g. Boian, we see that it's simply too hard to please hard-core delphi fanboys. They're all "take" and no "give". I look forward to the day when the fpc developers will realise that playing eternal catch-up is never going to work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Ivanko B wrote: so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies. == Disk I/O is a huge low-down to avoid on any price (like databases do with their indexing). Today me tested building LINUX kernel 3.8.0 on 8*SMT=16 CPU system (Corei7 2G) + 32G DDR3 + 175(wr)/350(rd)MB/s RAID1. And this monster outperformed another cheap E8400 + 4G machine by only 2 times and most probably because the cheap machine was non-RAIDed. And because Core i* arch can't have proper DMA. I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. make -j has a dramatic effect on an SMP system, particularly if it can find groups of jobs without too much interdependence. If there's a lot of shared input files etc., then my experience is that it tends to level out at around -j 8 since it's extremely difficult to improve the cache architecture beyond that point. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Hmm... you are running on the assumptions that humans are parsers. I for one do analyze the logic not the sequence, maybe because I usually write code for parallel execution. Humans do not think and follow code as computers, and often code that is easy to parse is difficult to follow by human IMHO. Otherwise we all would have been writing in Assembler ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Alexander Klenin Sent: Tuesday, March 05, 2013 3:30 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods It is hard to parse for humans as well as for the compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. Well... I put that into question. I don't have a 256 core system, but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a bit of compute power. Compiling kernel 3.3.2: [root@node016 linux-3.3.2]# time make -j 64 ... real1m54.823s user77m14.178s sys 11m32.109s To minutes to build a kernel is still fast though :) Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-05 15:24, Marcos Douglas wrote: > > Why follow the Delphi even knowing that is the wrong way to implement > something? Because like the FPC team have said a million times to me because they follow Delphi blindly, and WILL do everything to stay "delphi compatible". Good thing is, most of these are kept in the 'delphi' compiler mode. The 'objfpc' mode normally get some more pascal love. 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] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-05 17:09, waldo kitty wrote: > > on another system i work with, we use disk-based breadcrumb semaphore files > for > the different stages and parts of those stages... Thanks for you input. It sounds similar to what I was planning. Simply create an empty file in /tmp when each independent package is compiled successfully. Another process keeps checking /tmp for all the 0 byte files in expects. If they all exist, then build the test suite. Once that is complete, remove all the 0 byte files, and run the test suite. Now the question is, how good is fpmake? Will it can do something like that, or must I build my own system using scripts or console apps etc. 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] Comparison FPC 2.6.2 - Delphi 7
On 05.03.2013 20:58, Graeme Geldenhuys wrote: On 2013-03-05 17:09, waldo kitty wrote: on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages... Thanks for you input. It sounds similar to what I was planning. Simply create an empty file in /tmp when each independent package is compiled successfully. Another process keeps checking /tmp for all the 0 byte files in expects. If they all exist, then build the test suite. Once that is complete, remove all the 0 byte files, and run the test suite. Now the question is, how good is fpmake? Will it can do something like that, or must I build my own system using scripts or console apps etc. I didn't yet experiment that much with fpmake, but considering that fpmake.pas files are just plain Pascal programs... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.7.1 segfault in writestr?
On 15 Feb 2013, at 23:38, Martin wrote: > > RTL build with OPT="-gl -gw -godwarfsets -O-1" > compiler build with OPT="-gl -O3 -Or -CpPENTIUMM -OpPENTIUMM" > Lazarus -WC -gh -Criot -gw2 -godwarfsets -O-1 -gt > > The following line crashes with SigSegV >writestr(BaseConf, AType,':', > ' IMode=', dbgs(AIndentMode), ' IMax=', AIndentFirstLineMax, ' > IExtra=', AIndentFirstLineExtra, > ' CMode=', ACommentMode, ' CMatch=', AMatchMode, ' CLine=', > AMatchLine, > ' M=''', AMatch, ''' R=''', APrefix, ''' CIndent=', ACommentIndent >); > > > Stepping through the disassembler it happens in a cass to > 0046E95B e8e03efaff call 0x412840 As mentioned before: please post a compilable example that demonstrates the problem. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Failed to compile ios-headers from fpc's trunk
On 16 Feb 2013, at 15:18, Joost van der Sluis wrote: > When I try to parse & compile the ios-headers as supplied in cocoaint/utils, > I get the following error: > > NSEnumerator.inc(18,18) Fatal: Syntax error, ";" expected but "identifier > __UNSAFE_UNRETAINEDPTR" found > > The offending code is: > function countByEnumeratingWithState_objects_count(state: > NSFastEnumerationStatePtr; buffer: id __unsafe_unretained; len: NSUInteger): > NSUInteger; > > Apparently the parser does not handle the __unsafe_unretained identifier > properly. I used fpc-trunk and the ios 5.1 sdk. "As packages/cocoaint/utils/Make iPhone Headers.txt" mentions, that conversion script + patches only supports the iOS 3.2 SDK. For newer iOS SDK support, see http://objectivepascal.com/parser/index.html At one point these may be integrated in FPC's svn. The person who creates the parser scripts even has svn access, but he doesn't use it often unfortunately. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote: > > > Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: > > >I've not had an opportunity to try this, but my understanding is > >that on a Sun E10K with something like 256 400MHz processors the > >Linux kernel built in around 20 seconds. I've had it build in > >about 3 minutes on a system with 16x 80MHz processors, but that > >was in the days of kernel 2.2 and there was probably less than > >half today's number of files involved. > > Well... I put that into question. I don't have a 256 core system, > but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a > bit of compute power. Compiling kernel 3.3.2: > > [root@node016 linux-3.3.2]# time make -j 64 > > ... > > real1m54.823s > user77m14.178s > sys 11m32.109s Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04 Mar 2013, at 13:38, Daniël Mantione wrote: > 2. Layered code generation > > The split of the code generation in a high-level and low-level layer, means > that for every node that is processed, first the high-level virtual method is > called, which in turn calls the lower level virtual method. Thus you have an > addition virtual method call for evey node processed. > > The low level code generator, which is still mostly CPU independent, again > calls virtual methods from the abstract assembler layer to generate the > actual opcodes. > > The abstract assembler in turn, has again to worry about multiple assemblers > which can emit the final object file. Note that the release compilers are compiled with WPO and those optimizations change most of those virtual calls into static calls. Not all of them, but e.g. the entire code generator (both high and low level) does get devirtualized for most platforms (except for ARM, because it contains multiple low level code generators). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On Tue, Mar 05, 2013 at 09:56:21AM -0800, Boian Mitov wrote: > Hi Henry, > > Interesting that you consider me a Delphi fanboy :-D . > I don't like it much, but I surely love the anonymous methods :-D . > I love the C++11 implementation of anonymous methods more however, > but I hate the lack of extensive RTTI in C++ (and FPC). > I am hard to please, and no fan of any specific language. I hate > them, and love them equally with only one exception, well maybe 2. I > highly dislike Java, and I hate Scheme! :-D . > And BTW: I hate my products too, so that is why I keep working to > improve them all the time :-D, they are never good enough for me! I > am equal opportunity hater! You sure have a lot of smiley faces for a person so full of hate :) In all seriousness, what were you thinking when you used all the latest features of a language that's closed source? I can understand that it makes your code better (arguably, perhaps), but you've locked yourself into the Delphi world now, and it's unlikely that freepascal will ever satisfy you if you chase after the latest features, since it will take too long to implement and stabilise. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
I equally love and hate the tools (spare Scheme and Java) :-D . So hence the smiling faces. I needed the performance boos and speed of development they are giving me. The development before that was way too slow :-( . I have increased the productivity multiple times by doing that. I also did more insane things to do that, like writing my own Design time API on top of the Delphi one. This virtually eliminated the need to develop design time editors, as I do it with just adding few attributes now. Second, I am financing the development of our own proprietary development language, and in few years may port everything to it. I also have the option to pay some developers to add the necessary features to FPC if it comes to that :-D . So I am not short on options :-P . I am insane, but not "that" insane :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Henry Vermaak Sent: Tuesday, March 05, 2013 2:20 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods You sure have a lot of smiley faces for a person so full of hate :) In all seriousness, what were you thinking when you used all the latest features of a language that's closed source? I can understand that it makes your code better (arguably, perhaps), but you've locked yourself into the Delphi world now, and it's unlikely that freepascal will ever satisfy you if you chase after the latest features, since it will take too long to implement and stabilise. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
I have observed a lot of Delphi developers who have written code that needs or depends on the features like anonymous methods, generics, RTTI give up porting to FPC because it proved too difficult, but then it turns out those libraries could greatly enhance FPC usage. So I think this bullet must be bitten once to enable those libraries to be ported over, by FPC achieving parity or syntax compatibility in that area. Once that is done the FPC development team should make it clear where they don't agree with Embarcadero's approach, so developers who want to port to FPC don't depend on any funny stuff Embarcadero might concoct in the future. It may even turn out that in the future Delphi will be the one that has to follow FPCs lead or accommodate it, if this issue is successfully resolved, just as Microsoft has had to accommodate Linux. The more developers can accomplish with FPC and Linux the less relevant the restrictive and proprietary Windows and Mac environments become and that is what FPC devs should keep in sight. -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Henry Vermaak wrote: On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote: Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. Well... I put that into question. I don't have a 256 core system, but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a bit of compute power. Compiling kernel 3.3.2: [root@node016 linux-3.3.2]# time make -j 64 ... real1m54.823s user77m14.178s sys 11m32.109s Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config? Noting that for this test to be valid you obviously have to start from e.g. make clean and might usefully consider a reboot to make sure that all caches are empty. My point however was that a kernel build parallelises to very good effect, even where each processor is "implausibly slow" by today's standards. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
