Re: [fpc-devel] Dnamic packages support
L schrieb: Freepascal, C, etc. 'Compile using packages' does not make the plugin system language independent and portable too. I'm not sure if for example delphi packages would ever dynamically load into an fpc executable. You can't even use packages across different versions of the same compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
I think packages could be used to use Free Pascal object-oriented libraries in other languages. With packages it's possible to build LCL, for example, into a DLL, create a procedural wrapper around it, and then use in any language, like is done for the Qt bindings. I'm not saying I would do it, but packages would make this task much easier. I may do it one day, if I see myself in a situation where I must use another language for a GUI project, well, then maybe at least I can do some bindings for LCL and keep using it =) thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Hi Lars, The key point is exporting the api from the executable rather than the dll. Many people don't understand this basic concept nor know it is possible, nor understand why it works and how it works. I, too, in fact don't understand this. care to give a short explanation ? I do know about FP/GNU ABI-problems, but that does not seem to be the major port of the problem. LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is no longer in active development That is a really bad :-( . What is LazarusRB ? Is there still something usable and some documentation on LazarusRB and/or Plugger ? since I am very busy with web programming and consulting, and documenting Powtils project which takes most of my time. P.S.: I did file a bug report regarding the in deed not functional CGI-project feature in Lazarus. I don't suppose that you are involved in that but maybe it would be a good idea to synchronize this with parts of what Powtils provides. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Hi The key point is exporting the api from the executable rather than the dll. Many people don't understand this basic concept nor know it is possible, nor understand why it works and how it works. LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is no longer in active development since I am very busy with web programming and consulting, and documenting Powtils project which takes most of my time. L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Michael Schnell, Firmware-Entwicklung LUMINO Licht Elektronik GmbH, Germany, Europark Fichtenhain A8, D-47807 Krefeld Geschäftsführung: Dipl.-Ing. Karl Heinz Ronkholz, Dipl.-Betriebswirt Mario Fullert, Dipl.-Ing. Rolf Aengenendt www.lumino.de, fon: +49 (2151) 8196-172, fax: +49 (2151) 8196-272 Handelsregister HRB 1682 Amtsgericht Krefeld ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Hi Lars, The key point is exporting the api from the executable rather than the dll. Many people don't understand this basic concept nor know it is possible, nor understand why it works and how it works. I, too, in fact don't understand this. care to give a short explanation ? I do know about FP/GNU ABI-problems, but that does not seem to be the major port of the problem. Executables can export functions and procedures just like a library can. For delphi/fpc programs.. where most people design their software inside one gigantic executable.. you already have an API stored in the exe. Taking all the code out of the exe and putting it inside DLL's takes time. When you export some procedures from the exe, you already have all that infrastructure in the exe that you can use instantly. No taking code out from the exe and putting it in dll's required. Of course putting it into dll's is not a big deal if you have compiler support that does all this automatically with the 'compile using packages' checkbox. Exporting from the exe offers you the ability to quickly make an API for language independent plugins that can work with Digital Mars D, Freepascal, C, etc. 'Compile using packages' does not make the plugin system language independent and portable too. I'm not sure if for example delphi packages would ever dynamically load into an fpc executable. Whereas plugger ones would. So since your executable already contains lots of code in it.. And since turning an existing big Exe into DLL's is a big pain (without compiler support), you can make use of the 'export from exe' trick that people don't know about. People think dll's are what we can export things from. Not only dll's but also exe's. This is the key to two way communication between the dll and the exe, rather than one way communication. LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is no longer in active development That is a really bad :-( . What is LazarusRB ? Is there still something usable and some documentation on LazarusRB and/or Plugger ? Not really, just some old videos and screenshots. The problem for me is simply lack of time :-( since I am very busy with web programming and consulting, and documenting Powtils project which takes most of my time. P.S.: I did file a bug report regarding the in deed not functional CGI-project feature in Lazarus. I don't suppose that you are involved in that but maybe it would be a good idea to synchronize this with parts of what Powtils provides. They have something called 'ezcgi' and 'cgimodule' which I guess you have checked out? But yes, more project integration is needed.. when I get fpcweb.exe working it will work with any IDE such as lazarus/mseide but even more integration is needed than just a http compiler. Things like a menu item to open a powtils template/project is needed, and much more. There are many lazarus users using Powtils and I had hoped one of them would create some template for the 'file-new..' dialog. Amir wrote a lazarus plugin I think for O-PSP development once: https://opensvn.csie.org/pspcgi/LazarusPlugin/ L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, If using packages is the way to go to make installing visual components in Lazarus, IMHO it's essential to use them there ASAP. It would be really nice to have a predefined way to do/deploy plugins (that should not depend on compiler versions and maybe should be doable in C, too). Maybe something supporting those could be worth some thoughts, too. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Mon, 05 Nov 2007 12:08:31 +0100 Michael Schnell [EMAIL PROTECTED] wrote: Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, If using packages is the way to go to make installing visual components in Lazarus, IMHO it's essential to use them there ASAP. It would be really nice to have a predefined way to do/deploy plugins (that should not depend on compiler versions and maybe should be doable in C, too). Maybe something supporting those could be worth some thoughts, too. If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. I don't intend to doing that right now. But one of the most commonly used and supposedly complex and well defined plugin systems open to 3rd party providers is Steinberg (Cubase) plugins for MIDI/Audio applets. - the plugin API defines MIDI I/O, Audio I/O, GUI and supposedly some more weird stuff like copy protection dongles - there are working hosts and plugins for Windows, Linux and Mac - there are hundreds of companies providing those plugins (many freeware products) - there are hosts by several companies. Besides Steinberg products there is NI Core and even a hardware system (that runs on Linux) - I read about projects writing those plugins successfully with free Pascal So this _is_ a good example of an OS and language independent plugin API. Maybe it's a good idea to provide something compatible. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. I don't intend to doing that right now. But one of the most commonly used and supposedly complex and well defined plugin systems open to 3rd party providers is Steinberg (Cubase) plugins for MIDI/Audio applets. - the plugin API defines MIDI I/O, Audio I/O, GUI and supposedly some more weird stuff like copy protection dongles - there are working hosts and plugins for Windows, Linux and Mac - there are hundreds of companies providing those plugins (many freeware products) - there are hosts by several companies. Besides Steinberg products there is NI Core and even a hardware system (that runs on Linux) - I read about projects writing those plugins successfully with free Pascal So this _is_ a good example of an OS and language independent plugin API. Maybe it's a good idea to provide something compatible. The key point is exporting the api from the executable rather than the dll. Many people don't understand this basic concept nor know it is possible, nor understand why it works and how it works. LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is no longer in active development since I am very busy with web programming and consulting, and documenting Powtils project which takes most of my time. L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Daniël Mantione wrote: Op Sat, 3 Nov 2007, schreef Marco van de Voort: Florian Klaempfl schrieb: Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. Probably, but is that really the problem with packages? Packages are a part of Delphi compat, and have been explicitely on the 2.x roadmap for years. And now we cancel it because the linux install installs the demoes in the wrong place, if not manually fixed? As far as I am concerned, nothing is against the implementation of packages as long as it is non-intrusive to FPC users and FPC developers. Putting something on the roadmap does not automatically mean it gets implemented, fore major features there has to be someone who has an interrest in that feature before it get implemented. Until now, it hasn't been the case. Daniël Please,do not mess fpc with packages , implement only those parts required for creating and maintaining packages by Lazarus team.Here packages are useful. Better is to implement native debugger library for fpc programs instead of using gdb which may be fine under linux but crashes too often here under windows. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Dnamic packages support
Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? Leonardo M. Ramé http://leonardorame.blogspot.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages are IMHO a pre-requisite for any good plugin system. It allows you to enable/disable certain features of a program based on the particular system you install the package on, without having to recompile your complete application for this particular system. Lazarus is an IDE and therefore recompilation is IMHO an acceptable solution, since the person using it is a developer (even so, this would be too much asked for most devels in my company) but the same cannot be said for most end-user applications, OSS or not. For example, I don't think we can expect an end user to recompile XMMS if he decides to use ogg vorbis files instead of .mp3... Apart from the recompilation issue, packages allow you to have type-safety in plugins. A normal dll does not offer this (which is why techniques such as COM are used on Windows). I could not build my day-time job application if packages did not exist... So I do think packages are really a must; I lack the skill to implement them in the compiler, but will be glad to assist in any design issues or even creating any RTL code that you would need, if this is the problem for you. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages are IMHO a pre-requisite for any good plugin system. The reason is that the library construction requires you to write down your binary interface, and therefore design it properly. If the interfacing between application and plugin is automatic, it can also change automatically without you knowing. I believe such a system is only useable in contolled environments. If plug-ins are to be developed by a third party, runtime-packages aren't a feasible mechanism. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages have major drawbacks - DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. - speed of programs decreases by ~10% because each global variable access gets indirect (like pic) - major blow up of installer size Packages are IMHO a pre-requisite for any good plugin system. It allows you to enable/disable certain features of a program based on the particular system you install the package on, without having to recompile your complete application for this particular system. Then it's the task of a programmer to design a proper plugin interface. A plugin interface based on packages (in the delphi sense) requires that the main program and the plugin use exactly the same compiler and rtl. Lazarus is an IDE and therefore recompilation is IMHO an acceptable solution, since the person using it is a developer (even so, this would be too much asked for most devels in my company) but the same cannot be said for most end-user applications, OSS or not. For example, I don't think we can expect an end user to recompile XMMS if he decides to use ogg vorbis files instead of .mp3... Apart from the recompilation issue, packages allow you to have type-safety in plugins. A normal dll does not offer this (which is why techniques such as COM are used on Windows). I could not build my day-time job application if packages did not exist... So I do think packages are really a must; I lack the skill to implement them in the compiler, but will be glad to assist in any design issues or even creating any RTL code that you would need, if this is the problem for you. I see only a real use of packages if one doesn't want to distribute the source of the IDE like Delphi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages are IMHO a pre-requisite for any good plugin system. The reason is that the library construction requires you to write down your binary interface, and therefore design it properly. If the interfacing between application and plugin is automatic, it can also change automatically without you knowing. I believe such a system is only useable in contolled environments. If plug-ins are to be developed by a third party, runtime-packages aren't a feasible mechanism. Of course, if only if it ties you down to the specifics of a language. But that is not different between OSS or not OSS either. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Daniël Mantione schrieb: Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages are IMHO a pre-requisite for any good plugin system. The reason is that the library construction requires you to write down your binary interface, and therefore design it properly. If the interfacing between application and plugin is automatic, it can also change automatically without you knowing. I believe such a system is only useable in contolled environments. If plug-ins are to be developed by a third party, runtime-packages aren't a feasible mechanism. Exactly. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Daniël Mantione wrote: Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages are IMHO a pre-requisite for any good plugin system. The reason is that the library construction requires you to write down your binary interface, and therefore design it properly. If the interfacing between application and plugin is automatic, it can also change automatically without you knowing. I believe such a system is only useable in contolled environments. If plug-ins are to be developed by a third party, runtime-packages aren't a feasible mechanism. Indeed. It is exactly because I wish to control the plugins that I require packages. The single identifier space is a huge advantage, which make it almost automatic. If you don't have packages, then you must revert to COM interfaces, refcounted stuff, explicitly sharing memory managers to be able to use ansistrings properly etc. Packages solve all problems in 1 fell swoop. There is only 1 disadvantage to packages, this is the versioning of the base packages, which is IMHO very controllable. All other things are advantages. In my opinion, Packages are the second best thing Borland did for RAD. If I remember the shit we had with VB and its OCXes, DLLs and whatnot. No thanks... Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages have major drawbacks - DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages I don't see this as a problem. We release only once a year. - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. - speed of programs decreases by ~10% because each global variable access gets indirect (like pic) This is so. - major blow up of installer size I fail to see this ? Packages are IMHO a pre-requisite for any good plugin system. It allows you to enable/disable certain features of a program based on the particular system you install the package on, without having to recompile your complete application for this particular system. Then it's the task of a programmer to design a proper plugin interface. A plugin interface based on packages (in the delphi sense) requires that the main program and the plugin use exactly the same compiler and rtl. Yes, of course. I don't see this as a problem, but as a plus, since you control the environment. I'm not talking about some audio decoding/encoding mechanism, that is for babies. I'm talking about hundreds of possible interfaces, highly interdependent. If I had to design a proper plugin interface for my application at work, I would end up simply re-implementing packages, the interface would be HUGE, and would dwarf the implementation code. Lazarus is an IDE and therefore recompilation is IMHO an acceptable solution, since the person using it is a developer (even so, this would be too much asked for most devels in my company) but the same cannot be said for most end-user applications, OSS or not. For example, I don't think we can expect an end user to recompile XMMS if he decides to use ogg vorbis files instead of .mp3... Apart from the recompilation issue, packages allow you to have type-safety in plugins. A normal dll does not offer this (which is why techniques such as COM are used on Windows). I could not build my day-time job application if packages did not exist... So I do think packages are really a must; I lack the skill to implement them in the compiler, but will be glad to assist in any design issues or even creating any RTL code that you would need, if this is the problem for you. I see only a real use of packages if one doesn't want to distribute the source of the IDE like Delphi. Or, like I said, third party programs for which recompiling by the end user is not an option. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Dani?l Mantione wrote: ... In my opinion, Packages are the second best thing Borland did for RAD. If I remember the shit we had with VB and its OCXes, DLLs and whatnot. ... I agree. I also want to remind that it is not just about the use for us. The devels will create a package system on C level in no time. It is something else for people that don't know all implementation details of Pascal/Delphi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages have major drawbacks - DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages I don't see this as a problem. We release only once a year. Well, twice a year, but there are also snapshots, people compile there code themself etc. Each time you compile and install fpc it will fill your windows dir or /usr/local/lib with another 50 MB of dlls :) - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. Only because dll's/so's are probably being counted shared. - speed of programs decreases by ~10% because each global variable access gets indirect (like pic) This is so. - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? Packages are IMHO a pre-requisite for any good plugin system. It allows you to enable/disable certain features of a program based on the particular system you install the package on, without having to recompile your complete application for this particular system. Then it's the task of a programmer to design a proper plugin interface. A plugin interface based on packages (in the delphi sense) requires that the main program and the plugin use exactly the same compiler and rtl. Yes, of course. I don't see this as a problem, but as a plus, since you control the environment. I'm not talking about some audio decoding/encoding mechanism, that is for babies. I'm talking about hundreds of possible interfaces, highly interdependent. If I had to design a proper plugin interface for my application at work, I would end up simply re-implementing packages, the interface would be HUGE, and would dwarf the implementation code. Well, but this is mainly abusing packages ;) Lazarus is an IDE and therefore recompilation is IMHO an acceptable solution, since the person using it is a developer (even so, this would be too much asked for most devels in my company) but the same cannot be said for most end-user applications, OSS or not. For example, I don't think we can expect an end user to recompile XMMS if he decides to use ogg vorbis files instead of .mp3... Apart from the recompilation issue, packages allow you to have type-safety in plugins. A normal dll does not offer this (which is why techniques such as COM are used on Windows). I could not build my day-time job application if packages did not exist... So I do think packages are really a must; I lack the skill to implement them in the compiler, but will be glad to assist in any design issues or even creating any RTL code that you would need, if this is the problem for you. I see only a real use of packages if one doesn't want to distribute the source of the IDE like Delphi. Or, like I said, third party programs for which recompiling by the end user is not an option. Michael. ___ 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] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. The memory footprint can only be lower if multiple applications are in memory that can use the same packages. Even then, there will only be savings if the amount of code that can be smartlinked is small. Example: Let's say an LCL package is 10MB. 2 applications are 2MB when smartlinked, and 100kb when linked against the package. (The heap can be ignored in this discussion because its memory usage does not differ depending on packages being used.) Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB= 4MB Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages have major drawbacks - DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages I don't see this as a problem. We release only once a year. Well, twice a year, but there are also snapshots, people compile there code themself etc. Each time you compile and install fpc it will fill your windows dir or /usr/local/lib with another 50 MB of dlls :) Snapshots are of course not suitable; We don't support them in the first place. I also don't use development builds or Betas of Borland, although I could. I have 1 set of BPLs on my system. Works excellent. And for an application that needs to change compiler version - something that happened on my day-time job once in 8 years, this is not a problem. - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. Only because dll's/so's are probably being counted shared. No, because they have a single memory area. - speed of programs decreases by ~10% because each global variable access gets indirect (like pic) This is so. - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? The package system will solve this nicely, because we'll only distribute sources anyway. By the end of this year, I hope that you'll be convinced of that :-) If I had to design a proper plugin interface for my application at work, I would end up simply re-implementing packages, the interface would be HUGE, and would dwarf the implementation code. Well, but this is mainly abusing packages ;) On the contrary, it is using them for what they were designed to accomplish. Make no mistake: I am not the only one using them like that. Beside my own articles about it, there have been several description of such systems in e.g. Toolbox. Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, but you should also be open to the idea that there are areas where they are simply a very good thing, making development much easier. Not everyone is a seasoned compiler developer like we are, and packages make it possible for less-educated developers to participate in more complicated architectures, because they don't have to worry about creating interfaces, ref counting, setting memory managers and whatnot. I cannot even begin to explain to some of my collegae what an interface is, they even barely understand classes. And because of Delphi's RAD approach and the use of packages, they don't have to... Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Michael Van Canneyt schrieb: Hm. I don't see what OSS or not OSS has to do with it ? Packages have major drawbacks - DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages I don't see this as a problem. We release only once a year. Well, twice a year, but there are also snapshots, people compile there code themself etc. Each time you compile and install fpc it will fill your windows dir or /usr/local/lib with another 50 MB of dlls :) Yes. And if my 500GB disk will be filled up with snapshots in 500GB/50MB=1 days, I'm sure in 27 years, the same HD will be a lot cheaper. Aside from the fact it makes sense to routinely install compatible versions. Keep release + 1 snapshot just like with the compiler. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. Only because dll's/so's are probably being counted shared. To be honest, all this diskspace/memory stuff is totally uninteresting. Packages are about dividing the Pascal program up in blocks, with parts being compilable AFTER the main program, without a lot of additional demands (or need for control) on the interfaces between the packages. Don't get too worked up about plugin architectures in the AutoCAD sense. In practice it is way simpler, like only shipping one BPL to a custom if he @([EMAIL PROTECTED] paid for it. This means you can have one main binary, in which a hand full of acquisition BPLs register themselves. - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. If I had to design a proper plugin interface for my application at work, I would end up simply re-implementing packages, the interface would be HUGE, and would dwarf the implementation code. Well, but this is mainly abusing packages ;) No it is not. If the interface is not a focus of your design, it is a waste of time to spell it out, and keep the packages independant programs. Most notably since that fails miserably on Linux atm, since RTL duplication isn't handled very well. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Daniël Mantione wrote: Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. The memory footprint can only be lower if multiple applications are in memory that can use the same packages. You forget something, see below. Even then, there will only be savings if the amount of code that can be smartlinked is small. Example: Let's say an LCL package is 10MB. 2 applications are 2MB when smartlinked, and 100kb when linked against the package. (The heap can be ignored in this discussion because its memory usage does not differ depending on packages being used.) This is wrong for plugins, see below. Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB= 4MB First of all, we would be stupid to create a single LCL package. We should divide it into various packages grouping units according to functionality. Even Borland realized this eventually. Secondly, your quoted sizes are simply bogus; This is not a valid argument for a discussion. But that is beside the point. I agree with you that for a single app, using packages is a bad thing for memory usage. No discussion there. But the gain is not there. The gain I mentioned comes when using plugins. With DLLs plugins, each DLL will of necessity have a lot of common code, loaded into memory with each plugin. With packages, all code is in memory only once. Then, you are only considering code size. This is not enough. I am also considering heap size. With DLLs, each DLL will of necessity have a lot of common data structures in memory, copied in each plugin. You would be surprised at the size of this. For a system with 100ds of interfaces, this can become a big amount. Using packages for plugins, the code will be there only once, and the common data structures in memory will be there only once. This is the gain I was talking about. It exists only for a plugin system, and when compared to a plugin system based on DLLs. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: Even then, there will only be savings if the amount of code that can be smartlinked is small. Example: Let's say an LCL package is 10MB. 2 applications are 2MB when smartlinked, and 100kb when linked against the package. (The heap can be ignored in this discussion because its memory usage does not differ depending on packages being used.) Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB= 4MB _ADDRESS_ space use. Memory use depends on actual usage, since the pages of memory mapped DLLs will only be loaded on access. (and afaik linux does it similarly) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Marco van de Voort schrieb: - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. Who will maintain this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Sat, 3 Nov 2007, Florian Klaempfl wrote: Leonardo M. Ramé schrieb: Reading a post in public.mseide-msegui.talk, the mseide discussion list, I found this: Florian has committed the beginning of dynamic packages support. With Dynamic Packages you mean a platform independent way of implementing something similar to .Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow across all libraries without problems? If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it. Hm. I don't see what OSS or not OSS has to do with it ? Packages have major drawbacks - DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages I don't see this as a problem. We release only once a year. Well, twice a year, but there are also snapshots, people compile there code themself etc. Each time you compile and install fpc it will fill your windows dir or /usr/local/lib with another 50 MB of dlls :) Snapshots are of course not suitable; We don't support them in the first place. I also don't use development builds or Betas of Borland, although I could. I have 1 set of BPLs on my system. Works excellent. Because you use only one delphi version. And for an application that needs to change compiler version - something that happened on my day-time job once in 8 years, this is not a problem. - memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs. Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that. Only because dll's/so's are probably being counted shared. No, because they have a single memory area. ? - speed of programs decreases by ~10% because each global variable access gets indirect (like pic) This is so. - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? The package system will solve this nicely, because we'll only distribute sources anyway. By the end of this year, I hope that you'll be convinced of that :-) I fear somehow the deploying and maintainance of packages because of the reasons mentioned: size, versioning, different code generation etc. If I had to design a proper plugin interface for my application at work, I would end up simply re-implementing packages, the interface would be HUGE, and would dwarf the implementation code. Well, but this is mainly abusing packages ;) On the contrary, it is using them for what they were designed to accomplish. Make no mistake: I am not the only one using them like that. Beside my own articles about it, there have been several description of such systems in e.g. Toolbox. Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, but you should also be open to the idea that there are areas where they are simply a very good thing, making development much easier. Not everyone is a seasoned compiler developer like we are, and packages make it possible for less-educated developers to participate in more complicated architectures, because they don't have to worry about creating interfaces, ref counting, setting memory managers and whatnot. I cannot even begin to explain to some of my collegae what an interface is, they even barely understand classes. And because of Delphi's RAD approach and the use of packages, they don't have to... Packages and the missing TClientDataset are the only 2 remaining things See irc ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Sat, 3 Nov 2007, Marco van de Voort wrote: To be honest, all this diskspace/memory stuff is totally uninteresting. Packages are about dividing the Pascal program up in blocks, with parts being compilable AFTER the main program, without a lot of additional demands (or need for control) on the interfaces between the packages. Don't get too worked up about plugin architectures in the AutoCAD sense. In practice it is way simpler, like only shipping one BPL to a custom if he @([EMAIL PROTECTED] paid for it. This means you can have one main binary, in which a hand full of acquisition BPLs register themselves. This is actually more or less what I would have liked to get through, yes. Thanks Marco :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Marco van de Voort schrieb: - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. Who will maintain this? The person that will otherwise have to explain to newbies how to pass as string to a dll. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Marco van de Voort schrieb: Marco van de Voort schrieb: - major blow up of installer size I fail to see this ? Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. Who will maintain this? The person that will otherwise have to explain to newbies how to pass as string to a dll. Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Michael Van Canneyt schreef: On Sat, 3 Nov 2007, Marco van de Voort wrote: Don't get too worked up about plugin architectures in the AutoCAD sense. In practice it is way simpler, like only shipping one BPL to a custom if he @([EMAIL PROTECTED] paid for it. This means you can have one main binary, in which a hand full of acquisition BPLs register themselves. This is actually more or less what I would have liked to get through, yes. Thanks Marco :-) So, it is actually commercially driven and therefore not a thing you look for in a OSS environment ;-) Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Marco van de Voort: Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: Even then, there will only be savings if the amount of code that can be smartlinked is small. Example: Let's say an LCL package is 10MB. 2 applications are 2MB when smartlinked, and 100kb when linked against the package. (The heap can be ignored in this discussion because its memory usage does not differ depending on packages being used.) Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB= 4MB _ADDRESS_ space use. Memory use depends on actual usage, since the pages of memory mapped DLLs will only be loaded on access. (and afaik linux does it similarly) True, but does that change this calculation? I.e. if 75% of the code is in memory, the calculation still results in the same conclusion. Or is there, according to you, a reason why smartlinked programs have higher loading percentages than dynamically linked programs? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Michael Van Canneyt schreef: On Sat, 3 Nov 2007, Marco van de Voort wrote: Don't get too worked up about plugin architectures in the AutoCAD sense. In practice it is way simpler, like only shipping one BPL to a custom if he @([EMAIL PROTECTED] paid for it. This means you can have one main binary, in which a hand full of acquisition BPLs register themselves. This is actually more or less what I would have liked to get through, yes. Thanks Marco :-) So, it is actually commercially driven and therefore not a thing you look for in a OSS environment ;-) No. It is time driven. And we don't code everything in plain C in OSS either. So why limit ourselves to that with library interfaces? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Marco van de Voort: Op Sat, 3 Nov 2007, schreef Michael Van Canneyt: Even then, there will only be savings if the amount of code that can be smartlinked is small. Example: Let's say an LCL package is 10MB. 2 applications are 2MB when smartlinked, and 100kb when linked against the package. (The heap can be ignored in this discussion because its memory usage does not differ depending on packages being used.) Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB= 4MB _ADDRESS_ space use. Memory use depends on actual usage, since the pages of memory mapped DLLs will only be loaded on access. (and afaik linux does it similarly) True, but does that change this calculation? I.e. if 75% of the code is in memory, the calculation still results in the same conclusion. If the percentage is the same yes, but since the packages one has a higher percentage of unused code, the unused pages percentage will also be higher. Or is there, according to you, a reason why smartlinked programs have higher loading percentages than dynamically linked programs? Yes. They contain code that is more or less likely to have a chance to be really used. The bloat in the packages scenario doesn't. And such a LCL bpl would be roughly have the TEXT symbols of each component in order, and an bunch of unused components would lead to unused pages. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
[ Charset ISO-8859-1 unsupported, converting... ] Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. Who will maintain this? The person that will otherwise have to explain to newbies how to pass as string to a dll. Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Marco van de Voort schrieb: [ Charset ISO-8859-1 unsupported, converting... ] Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. Who will maintain this? The person that will otherwise have to explain to newbies how to pass as string to a dll. Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Florian Klaempfl schrieb: Marco van de Voort schrieb: [ Charset ISO-8859-1 unsupported, converting... ] Because we've to deliever also the fpl's? If it really is that of a problem, you only deliver them using a optional package. Who will maintain this? The person that will otherwise have to explain to newbies how to pass as string to a dll. Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? Or do you only miss some features in sqldb? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Florian Klaempfl schrieb: Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. Probably, but is that really the problem with packages? Packages are a part of Delphi compat, and have been explicitely on the 2.x roadmap for years. And now we cancel it because the linux install installs the demoes in the wrong place, if not manually fixed? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Marco van de Voort schrieb: Florian Klaempfl schrieb: Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. Probably, but is that really the problem with packages? I said: packages blow up download sizes you said: make it an optional downloadable package I say: we are even not able to maintain the current downloads and keep them bug free Packages are a part of Delphi compat, and have been explicitely on the 2.x roadmap for years. And now we cancel it because the linux install installs the demoes in the wrong place, if not manually fixed? ___ 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] Dnamic packages support
Op Sat, 3 Nov 2007, schreef Marco van de Voort: Florian Klaempfl schrieb: Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. Probably, but is that really the problem with packages? Packages are a part of Delphi compat, and have been explicitely on the 2.x roadmap for years. And now we cancel it because the linux install installs the demoes in the wrong place, if not manually fixed? As far as I am concerned, nothing is against the implementation of packages as long as it is non-intrusive to FPC users and FPC developers. Putting something on the roadmap does not automatically mean it gets implemented, fore major features there has to be someone who has an interrest in that feature before it get implemented. Until now, it hasn't been the case. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
