Re: [fpc-devel] Parallel processing in the compiler
On 09/08/2010 09:58 PM, Hans-Peter Diettrich wrote: So my primary interest in a new back-end structure is more targeted at ease of development, than on really using multiple back-ends in one application. +1 -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Hi! Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :). Cheers, Willi P.S.: Way back in time, I did some investigation on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only). -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
On 2010-09-09 12:23, Willibald Krenn wrote: Hi! Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :). Cheers, Willi P.S.: Way back in time, I did some investigation on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only). Hi, I think you can start by reading http://wiki.freepascal.org/packages and http://wiki.freepascal.org/shared_library . Regards Žilvinas Ledas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
In our previous episode, Willibald Krenn said: Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. To my best knowledge: no. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :). Some resources you might want to have a look at: - Maybe not necessary if you know them already intimately, but I kept a bit of a brainstorm on packages here: http://wiki.freepascal.org/packages - a bugreport about creating shared libraries using the makefiles: http://bugs.freepascal.org/view.php?id=12492 with 45 comments with a lot of detail. P.S.: Way back in time, I did some investigation on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only). I don't know if this is necessary for packages, BUT: As far as I know FPC doesn't add the parameter name to the mangling, only the type. Moreover, the type is bare, iow not qualified with unitname. I don't know the status of the other details (like calling conventions). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
- Willibald Krenn willibald.kr...@gmx.at schreef: Hi! Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :). Cheers, Willi P.S.: Way back in time, I did some investigation on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only). aparantly you beat me to it, but I was planning on compiling a mail like this one later today (at home). Besides you (an me), is there anyone else interested in implementing this? My angle (besides from the obvious dynamic pluginsystem vs the lazarus/*nix FOSS way aka rebuild everything when you want something included) is that there are some additions to RTTI that need to be done as well regarding packages, units en the relationships with current RTTI and startup-initialization. I would be nice to know who wrote/compiled the packages page in the fpc wiki and to get in contact with ppl that want to discuss/implement delphi packages. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
In our previous episode, Dimitri Smits said: aparantly you beat me to it, but I was planning on compiling a mail like this one later today (at home). Besides you (an me), is there anyone else interested in implementing this? My angle (besides from the obvious dynamic pluginsystem vs the lazarus/*nix FOSS way Note that I don't hold library packages for Lazarus as very desirable. aka rebuild everything when you want something included) Note that I have never heard anybody complain about the quick lazarus startup time relative to Delphi. That is the flip side of dynamic packages !!! I would be nice to know who wrote/compiled the packages page in the fpc wiki and to get in contact with ppl that want to discuss/implement delphi packages. I did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Am 09.09.2010 13:27, schrieb Dimitri Smits: My angle (besides from the obvious dynamic pluginsystem This is why there is no work on a packages system for FPC: there are simply too much different versions around. While Delphi has at most one release per year, FPC/Lazarus has more or less every day a new version. A package compiled for FPC/Lazarus built from todays sources will mostly not work with a program compiled from yesterday sources. If you want a plugin system, you should create a defined API for this plugin system but not depend on the moving target of packages. The use of packages for FPC is simply much less than for Delphi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
This is why there is no work on a packages system for FPC: there are simply too much different versions around. While Delphi has at most one release per year, FPC/Lazarus has more or less every day a new version. Well, but not that much stable releases, I suppose. :) I am sure that Delphi has/had quite a few internal versions too... A package compiled for FPC/Lazarus built from todays sources will mostly not work with a program compiled from yesterday sources. Even if you divide up your code into packages (Delphi ones), you are not forced to compile with packages 'enabled'. Hence daily builds can stay perfectly static as is. However, you'd gain the option for stable releases to have modules. Said that, within open source, packages are probably less useful than in the commercial-closed source world. If you want a plugin system, you should create a defined API for this plugin system but not depend on the moving target of packages. I tried that once with Delphi/VCL (and mdi-child forms): It was horrible to maintain and utterly difficult to debug. Packages just let you use classes (forms etc.) from within dlls so much more easily. Besides, you can still do your own API on top of packages ;-) The use of packages for FPC is simply much less than for Delphi. This is probably true. However, from an end-user's perspective, I would not say that I do a fpc/lazarus re-build every day. I'd rather stick with some stable version and concentrate my own (application) code. But I guess, my main motivation on this is fun on hacking a compiler feature ;-) Cheers, Willi -- Achtung Sicherheitswarnung: GMX warnt vor Phishing-Attacken! http://portal.gmx.net/de/go/sicherheitspaket ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
On Thu, 9 Sep 2010, Willibald Krenn wrote: The use of packages for FPC is simply much less than for Delphi. This is probably true. However, from an end-user's perspective, I would not say that I do a fpc/lazarus re-build every day. I'd rather stick with some stable version and concentrate my own (application) code. But I guess, my main motivation on this is fun on hacking a compiler feature ;-) The best motivation we can imagine :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Am 09.09.2010 14:02, schrieb Willibald Krenn: This is why there is no work on a packages system for FPC: there are simply too much different versions around. While Delphi has at most one release per year, FPC/Lazarus has more or less every day a new version. Well, but not that much stable releases, I suppose. :) No. A package compiled for FPC/Lazarus built from todays sources will mostly not work with a program compiled from yesterday sources. Even if you divide up your code into packages (Delphi ones), you are not forced to compile with packages 'enabled'. Hence daily builds can stay perfectly static as is. True but building releases with optional dyn. has another disadvantage: they increase heavily the distribution size and people are already complaining now about download size. But I guess, my main motivation on this is fun on hacking a compiler feature ;-) That's a very good point :) However I fear implementing packages is one of the less fun features. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
I really am wanting something for my core objects so they can be loaded and unloaded at runtime. Recompiling the service application across different network nodes is costly, time and CPU intensive. On Sep 9, 2010, at 6:27 AM, Dimitri Smits smi...@telenet.be wrote: - Willibald Krenn willibald.kr...@gmx.at schreef: Hi! Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :). Cheers, Willi P.S.: Way back in time, I did some investigation on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only). aparantly you beat me to it, but I was planning on compiling a mail like this one later today (at home). Besides you (an me), is there anyone else interested in implementing this? My angle (besides from the obvious dynamic pluginsystem vs the lazarus/*nix FOSS way aka rebuild everything when you want something included) is that there are some additions to RTTI that need to be done as well regarding packages, units en the relationships with current RTTI and startup-initialization. I would be nice to know who wrote/compiled the packages page in the fpc wiki and to get in contact with ppl that want to discuss/implement delphi packages. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] PShortString
When dynamic strings are used all around, is the use of pointers to ShortString still recommended? (fmodule contains a lot of them) In many cases (almost all I found) the strings are duplicated when assigned, because the given dynamic strings disallow to simply copy the reference. IMO P[Short]Strings only were useful when the referenced string shall be changed later, with that change reflected automatically in all references. Since this seems not to occur anywhere, I'd suggest to replace or retype PShortString by [Ansi]String. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Marco van de Voort schrieb: Note that I have never heard anybody complain about the quick lazarus startup time relative to Delphi. That is the flip side of dynamic packages !!! Right, but that's no reason for not using packages somewhere else. Delphi packages have been invented as an improvement of DLLs, to make them type safe etc., and this idea can be used with shared libraries on any platform. IMO the implementation of Delphi packages in FPC depends on two things: the resources required for such an implementation, and the chance for closed-source libraries. When we want to disallow or even discourage closed-source FPC projects, I see no urgent need for implementing Delphi packages. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PShortString
Am 09.09.2010 15:52, schrieb Hans-Peter Diettrich: When dynamic strings are used all around, is the use of pointers to ShortString still recommended? (fmodule contains a lot of them) 1. Ancient code, keep in mind, most code not being back end code was written ~10 years ago. At this time we even could not depend on perfectly working ansistrings. 2. Ansistring create an explicit exception frame etc. which slows down things. Due to the explicit exception frame generation, I would propose not to change it but only if the length limitation is a problem. In many cases (almost all I found) the strings are duplicated when assigned, because the given dynamic strings disallow to simply copy the reference. IMO P[Short]Strings only were useful when the referenced string shall be changed later, with that change reflected automatically in all references. Since this seems not to occur anywhere, I'd suggest to replace or retype PShortString by [Ansi]String. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Am 09.09.2010 16:05, schrieb Hans-Peter Diettrich: IMO the implementation of Delphi packages in FPC depends on two things: the resources required for such an implementation, and the chance for closed-source libraries. When we want to disallow or even discourage closed-source FPC projects I think the modified LGPL clearly shows that we don't want discourage closed-source software. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PShortString
Hans-Peter Diettrich wrote: When dynamic strings are used all around, is the use of pointers to ShortString still recommended? (fmodule contains a lot of them) Whenever you care about performance, you'll quickly realize that dynamic strings are plain inappropriate. When it is also known that 255 character limit won't be exceeded, ShortString is nearly an ideal choice. In many cases (almost all I found) the strings are duplicated when assigned, because the given dynamic strings disallow to simply copy the reference. IMO P[Short]Strings only were useful when the referenced string shall be changed later, with that change reflected automatically in all references. Since this seems not to occur anywhere, I'd suggest to replace or retype PShortString by [Ansi]String. They provide fine-grained control over memory allocations, avoiding implicit try..finally blocks and memory allocations for temps. Copying still occurs, but with the highly optimized Move procedure it is pretty cheap. So please don't change such things just because something is used all around. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
In our previous episode, Hans-Peter Diettrich said: Note that I have never heard anybody complain about the quick lazarus startup time relative to Delphi. That is the flip side of dynamic packages !!! Right, but that's no reason for not using packages somewhere else. I was only talking about packages in Lazarus (designtime). I don't see a large benefit, and versioning an insurmountable problem. I think plugin uses for users are a perfectly fine application. Actually that is IMHO pretty muchthe only reason, since I'm no firm believer that in this day and age the possible filesize savings are still that important. (and even less so when this finally reaches production) Unfortunately, this (packages) is a feature that afaik requires heavy compiler and deep RTL work. Moreover the inner workings of the Delphi package are not very well documented (which is why I created the wikipage) IMO the implementation of Delphi packages in FPC depends on two things: the resources required for such an implementation, and the chance for closed-source libraries. When we want to disallow or even discourage closed-source FPC projects, I see no urgent need for implementing Delphi packages. I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs. ... Most notably since a EXE+packages is essentially just an EXE fragmented over multiple parts. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
IMO the implementation of Delphi packages in FPC depends on two things: the resources required for such an implementation, and the chance for closed-source libraries. When we want to disallow or even discourage closed-source FPC projects, I see no urgent need for implementing Delphi packages. I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs. ... Most notably since a EXE+packages is essentially just an EXE fragmented over multiple parts. E.g. for a closed source IDE packages are essentially. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
In our previous episode, Florian Klaempfl said: I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs. ... Most notably since a EXE+packages is essentially just an EXE fragmented over multiple parts. E.g. for a closed source IDE packages are essentially. Then you touch the Lazarus license (GPL), still not FPC's. Moreover, I already said I don't think binary design packages (proprietary or not) are very practical for Lazarus. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Am 09.09.2010 16:37, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs. ... Most notably since a EXE+packages is essentially just an EXE fragmented over multiple parts. E.g. for a closed source IDE packages are essentially. Then you touch the Lazarus license (GPL), still not FPC's. Moreover, I already said I don't think binary design packages (proprietary or not) are very practical for Lazarus. Not Lazarus but just some hypothetical 3rd party IDE. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Please do (at least) two separate projects: - Plugins (easy to use FPC-FPC DLLs / .so's with additional informations such as Delphi Runtime-Packages) - Unit collection (development packages with or without source code). I hate calling both the same name ;). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
Marco van de Voort schrieb: I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs. Licenses are of no concern here. How (what files) can somebody provide closed-source plug-ins (or the like), when their integration into some other application requires source code? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PShortString
Sergei Gorelkin schrieb: When dynamic strings are used all around, is the use of pointers to ShortString still recommended? (fmodule contains a lot of them) Whenever you care about performance, you'll quickly realize that dynamic strings are plain inappropriate. The concrete use of PShortString strings is inappropriate in your sense, because it results in allocation, copy and deallocation of temporary strings in the code, in many places. This behaviour gave birth to my question. They provide fine-grained control over memory allocations, avoiding implicit try..finally blocks and memory allocations for temps. Copying still occurs, but with the highly optimized Move procedure it is pretty cheap. So please don't change such things just because something is used all around. All that would no more be needed after a decent redesign. Or the existing code is inappropriate, and all the mentioned operations can be removed from the source code, without affecting the behaviour and result. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PShortString
Florian Klaempfl schrieb: 1. Ancient code, keep in mind, most code not being back end code was written ~10 years ago. At this time we even could not depend on perfectly working ansistrings. I'm talking about nowadays situation. 2. Ansistring create an explicit exception frame etc. which slows down things. Also when the strings are const parameters, as they are in this case? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
