[fpc-devel] Re: [lazarus] Why TSemaphore not implemented for Win32?
Hello, i do fully agree with you. Implementing Semaphores is very important. So i hope someone will implement this. regards Felipe Monteiro de Carvalho schreef: On 10/30/07, 12 12 <[EMAIL PROTECTED]> wrote: Why TSemaphore not implemented for Win32? AFAIK TSemaphore is just an alias to different semaphore names on different unixes. So it would never work on Win32 by definition. but CreateSemaphore present in Delphi! No it's not. It's a Windows API. It's not directly connected to Delphi. Nevertheless, I for one, am interrested in having a cross-platform semaphores solution. I find them quite useful, specially after having the theory at the university. What do others think about how such functionality could be implemented? We could write a procedural interface with some functions like CreateSemaphore, OpenSemaphore, CloseSemaphore, etc. Also the 2 classical operations P and V (I don't remember the descriptive names for them) And TSemaphore could be the handle passed by such functions, or a new type could be created to avoid confusion. Ah, by the way, I am moving this discussion to fpc-devel, since it's more appropriate here. thanks, ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Solaris X86
My company bought an amazing Sun Ultra 40 M2 Workstation, with two Opteron processors and Solaris 10 installed. This machine will be used as a demo server for a third party java app we sell, but since we'll be porting some Delphi services to Linux and FreeBsd, I want to test them also in Solaris X86. Does anybody compiled FPC for Solaris X86? 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
[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
Re: [fpc-devel] Solaris X86
On 03 Nov 2007, at 15:58, Leonardo M. RamX wrote: My company bought an amazing Sun Ultra 40 M2 Workstation, with two Opteron processors and Solaris 10 installed. This machine will be used as a demo server for a third party java app we sell, but since we'll be porting some Delphi services to Linux and FreeBsd, I want to test them also in Solaris X86. Does anybody compiled FPC for Solaris X86? I doubt it, since we have no Solaris/x86 rtl. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TClientDataset (was: Dnamic packages support)
On Sat, 3 Nov 2007, Joost van der Sluis wrote: > 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? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. > Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
