Re: [fpc-devel] Delphi-like Packages, Plan
Op 2010-10-03 18:56, Matt Emson het geskryf: File.fppl Or File.fplib ?? Why force a backward facing legacy on the an OS that does not have such a restriction? Even NT4 supported longer file extensions. :-) I must agree with you 100%! So many still use *.cfg or *.txt etc... for a long time now I have used *.config or *.text without problems. The 8.3 naming convention is so DOS and Microsoft specific! So 80's. OS/2, Linux etc has had long filename support longer that I care to remember, so why not use it. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Am 04.10.2010 02:43, schrieb Willibald Krenn: Yes, they probably do. For the beginning (and with generics in mind) it's probably easier if they do. don't forget inline as well, not just generics. Yep. (For inlined methods/functions we could - theoretically - provide a 'non-inlined' version in the binary package) For generics: the token stream is already included in the PPUs (learned by looking at DoDi's ppudump patches ^^) For inline: If I remember correctly inlined methods/functions/procedures are always available as non-inlined methods as well. It's up to the compiler to deside whether it inlines it or not. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
In our previous episode, Willibald Krenn said: I don't like the Delph all-or-nothing philosophy here. I'd prefer to specify the packages, that shall be loaded at runtime, while all other You can always load packages at runtime.. That is, after the RTL supports that of course. Runtime loading of loading is quite a different process from startup loading, and only used for plugin system (where the baseclass is statically linked, and the plugins implement the baseclasses). Dynamic loading for enormous amounts of symbols might be costly (since they are resolved with a call per symbol, instead of by one call to the system, as during startup). The KDE suites startup speed problems have shown that very complicated dynloading schemes are not desirable. The RTL is always loaded on startup btw. packages can be linked into the executable. This would allow to use an minimal set of external modules, which are shared by the exe and the really self-contained packages. What you probably(?) could do is to link all basic packages into the executable but still export all symbols, so that when the shared object is loaded it finds all necessary entry points. Problem is that that leads to a dependancy circle (pkg-exe-pkg). Maybe not a blocker problem, but more a complication. However, at the moment I don't see why this is better than shipping all necessary ppl files. BTW: I realize that ppl might be a bad TLA - since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
In our previous episode, Dimitri Smits said: for enormous amounts of symbols might be costly (since they are resolved with a call per symbol, instead of by one call to the system, as during startup). only the symbols that are used are imported in the dyn-loaded package. And it exports all publicly available types/procs/consts/vars. No, also the amounts needed from e.g. LCL to FCL and RTL packages. And those have high granularity (and the program-LCL might also be quite high) The KDE suites startup speed problems have shown that very complicated dynloading schemes are not desirable. The RTL is always loaded on startup btw. to say even more, when you run with runtime packages, it's units are initialized first (before any other units/bpl's/the main exe). I think this discussion should first define some terms wrt building with packages vs safeloadpackage. Dynamic is a too vague term. I was mostly thinking Hans-Peter meant doing loadpackage() under the hood. I think that is, if viable at all, an extreme specialty which shouldn't be considered at all in the first run. In later mails I got the impression he didn't mean that, but normal static-dynamic linking. (importlib static, code dynamic in dll/bpl) Problem is that that leads to a dependancy circle (pkg-exe-pkg). Maybe not a blocker problem, but more a complication. when you use packages, it requires some discipline, that is right. Consider following scenario: pkg1: your plugin-base classes, requires RTL package exe: imports pkg1 as a runtime package requirement, statically binds the gui components in lcl/vcl since it was not defined as a runtime package link requirement pkg2: a plugin for runtime loading, requires RTL package and VCL/LCL package what would be result when you want to import this at runtime through a loadlibrary call? ((safe)loadpackage?) I would suspect that you then have duplicate units-error. Compiler cannot defend against it due to the runtime information vs compile-time information. Correct. Since LCL might hold state, it violates the rule that the whole of the packages system may hold only one instance of a certain unit state (its variables, but also VMT tables, see wiki) Just to show that packages bring their own set of problems and pitfalls. But definately not all is bad ;-) This is all known, and described in the wiki afaik. since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. that is why versionnrs are included: RTL70.BPL (Delphi 7) vs RTL150.BPL (Delphi XE aka 2011) That's the first order defence yes, to allow multiple installs. But the packages system should be safeguarded against any kind of tampering, based on CRCs or other .ppu version items. Since with the openess and snapshot generation of FPC/Lazarus, even two builds from different periods with the same number will usually be incompatible. (CRCs of the interface of the relevant ppus I think, as currently is done with ppu's too) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
On 04/10/2010 09:46, Dimitri Smits wrote: nope, D7 does this too. (maybe even D5, but cannot verify) Yes, Delphi 5+ does this. It might even work in 3 or 4, I haven't tried it. Packages were horribly buggy in 3 from what I remember and I only used 4 briefly as 5 came out rapidly after we'd started using it and then I moved to a company that was a Borland partner and we had all the latest kit there. M ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
In our previous episode, Dimitri Smits said: The same effect could be achieved by a separation of packages into (Lazarus-type) static libraries, and packages *designed* for dynamic loading (plug-ins...). Delphi compiler does this as well. One caveat in this discussion is for instance: when you build with runtime packages vclXXX.bpl, db*.bpl; even though you didn't specify them, all packages your bpls depend on are loaded runtime only as well. (rtlXXX.bpl for instance) the reason is simply: there can only be one instance loaded of EVERY unit you use in your program (or that is included in some bpl). (this is all in the http://wiki.freepascal.org/packages ovewview) It is therefore simple to say in delphi that you want to build with rtlXXX.bpl only, but still have the vclXXX.dcp statically linked into your executable when you use a TForm and include the Forms unit somewhere in your code. But that will be smartlinked, so that can still be a netto win for small apps. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Op 2010-10-04 01:51, Dimitri Smits het geskryf: fpc-trunc to compile and create a specific bin folder. as far as I've gathered is that you need to do a make clean all and then copy all the resulting exe's to somewhere (find and retrieve yourself strategy). But No, simply specify INSTALL_PREFIX=path_goes_here on the install command line, after you did a 'make clean all'. It will install FPC to you chosen path. No need to manually copy exe's and *.ppu files out. Here is the script I use to compile Trunk and install it to my preferred directory location. -[ start-trunk64.sh ]-- #!/bin/bash COMPILER=/opt/fpc-2.4.3/x86_64-linux/bin/ppcx64 make clean make all FPC=$COMPILER make install INSTALL_PREFIX=/opt/fpc-2.5.1/x86_64-linux/ FPC=$COMPILER - Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
In our previous episode, Willibald Krenn said: Yes, they probably do. For the beginning (and with generics in mind) it's probably easier if they do. don't forget inline as well, not just generics. Yep. (For inlined methods/functions we could - theoretically - provide a 'non-inlined' version in the binary package) inlined functions for cross-unit use are already in the .ppu why change that? (and the .ppu becomes part of the .dcp). I don't think there changes so much wrt to this because packages always fall over unit borders. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Am 04.10.2010 12:35, schrieb Matt Emson: On 04/10/2010 10:56, Sven Barth wrote: So I personally would prefer *.ppl (for Pascal Package Library) on every platform supporting packages. Scenario - I'm using someother Pascal compiler (GNU/Delphi/Virtual/etc) so I can use the PPL's from Free Pascal with them? After all, they *are* Pascal Package Library files?! No matter how infrequently, this *will* happen at some point. I'd say, pick another more descriptive extension now, save your - [collective] - selves reiterating the same disclaimer every time someone asks this question. The assumption that Free Pascal is the only Pascal that will ever exist in a usable form going forward is probably subjective, but it's not a reliable constant. Then let's pick *.fppl (Free Pascal Package Library). I don't mind what extension we use as long as it is not *.bpl ^^ Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Sent from my iPhone On 4 Oct 2010, at 04:35, Hans-Peter Diettrich drdiettri...@aol.com wrote: Dimitri Smits schrieb: It is therefore simple to say in delphi that you want to build with rtlXXX.bpl only, but still have the vclXXX.dcp statically linked into your executable when you use a TForm and include the Forms unit somewhere in your code. This sounds like a post-D7 feature? No, Delphi 5 onwards allowed the developer to choose which BPL's are linked statically and which are dynamic. We used to link the RTL and VCL but have our BPL's external. I forget the reasoning, but it worked. M___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
- Marco van de Voort mar...@stack.nl schreef: In our previous episode, Willibald Krenn said: I don't like the Delph all-or-nothing philosophy here. I'd prefer to specify the packages, that shall be loaded at runtime, while all other You can always load packages at runtime.. That is, after the RTL supports that of course. Runtime loading of loading is quite a different process from startup loading, and only used for plugin system (where the baseclass is statically linked, and the plugins implement the baseclasses). Dynamic loading for enormous amounts of symbols might be costly (since they are resolved with a call per symbol, instead of by one call to the system, as during startup). only the symbols that are used are imported in the dyn-loaded package. And it exports all publicly available types/procs/consts/vars. The KDE suites startup speed problems have shown that very complicated dynloading schemes are not desirable. The RTL is always loaded on startup btw. to say even more, when you run with runtime packages, it's units are initialized first (before any other units/bpl's/the main exe). packages can be linked into the executable. This would allow to use an minimal set of external modules, which are shared by the exe and the really self-contained packages. What you probably(?) could do is to link all basic packages into the executable but still export all symbols, so that when the shared object is loaded it finds all necessary entry points. Problem is that that leads to a dependancy circle (pkg-exe-pkg). Maybe not a blocker problem, but more a complication. when you use packages, it requires some discipline, that is right. Consider following scenario: pkg1: your plugin-base classes, requires RTL package exe: imports pkg1 as a runtime package requirement, statically binds the gui components in lcl/vcl since it was not defined as a runtime package link requirement pkg2: a plugin for runtime loading, requires RTL package and VCL/LCL package what would be result when you want to import this at runtime through a loadlibrary call? I would suspect that you then have duplicate units-error. Compiler cannot defend against it due to the runtime information vs compile-time information. Just to show that packages bring their own set of problems and pitfalls. But definately not all is bad ;-) However, at the moment I don't see why this is better than shipping all necessary ppl files. BTW: I realize that ppl might be a bad TLA - since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. that is why versionnrs are included: RTL70.BPL (Delphi 7) vs RTL150.BPL (Delphi XE aka 2011) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Dimitri Smits schrieb: if you say you want to build with runtime packages x, y and z, the linker/compiler take into account that you implicitly dynamically link to the (units contained in) the packages that package x,y and z depend on (and recusively until no additional dependencies remain). if in none of the above x,y,z (and the bpl's they depend upon) is contained a unit you use in your current build-target (exe, dll, ...), then the unit is implicitly included into that build-target. Thanks for the clarification :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Am 04.10.2010 10:39, schrieb Marco van de Voort: However, at the moment I don't see why this is better than shipping all necessary ppl files. BTW: I realize that ppl might be a bad TLA - since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. So... what is your suggestion? Keep the platform specific library name? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
- Hans-Peter Diettrich drdiettri...@aol.com schreef: Dimitri Smits schrieb: It is therefore simple to say in delphi that you want to build with rtlXXX.bpl only, but still have the vclXXX.dcp statically linked into your executable when you use a TForm and include the Forms unit somewhere in your code. This sounds like a post-D7 feature? nope, D7 does this too. (maybe even D5, but cannot verify) if you say you want to build with runtime packages x, y and z, the linker/compiler take into account that you implicitly dynamically link to the (units contained in) the packages that package x,y and z depend on (and recusively until no additional dependencies remain). if in none of the above x,y,z (and the bpl's they depend upon) is contained a unit you use in your current build-target (exe, dll, ...), then the unit is implicitly included into that build-target. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
In our previous episode, Hans-Peter Diettrich said: I fear also a lot of pitfalls with this possibility for example executables using dyn. packages might be never smartlinked because it is unknown at link time which packages will be loaded so all symbols of the statically linked packages must be available. IMO all symbols, that are usable from dynamic packages, also must reside in dynamic packages. In Windows terms: a DLL can and must know nothing about the using application. That is generally the packages principle yes. Some very lowlevel (dependancy tables and RTL symbols that are also needed before the rtl.bpl initializes excepted maybe) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Non-local goto’s and nested exits
I wonder if there is anything special that hinders the implementation of non-local goto’s and
nested exits in macpas mode. I am asking because emulation through exception-handling does seem to
work (which implies that the code to unwind the stack is there).
For example:
{$mode macpas}
{$modeswitch exceptions+}
program unwind;
uses sysutils;
procedure A;
procedure B;
begin
writeln
( 'B begin');
raise Exception.Create
( 'B exception raised');
writeln
( 'B end')
end;
begin
writeln
( 'A begin');
B;
writeln
( 'A end')
end;
begin
writeln
( 'Program begin');
try
writeln
( 'try A');
A;
except
writeln
( 'except A');
end;
writeln
( 'Program end')
end.
compiles and prints
Program begin
try A
A begin
B begin
except A
Program end
Regards,
Adriaan van Os
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
In our previous episode, Sven Barth said: However, at the moment I don't see why this is better than shipping all necessary ppl files. BTW: I realize that ppl might be a bad TLA - since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. So... what is your suggestion? Keep the platform specific library name? bpl is fine with me on Windows. On *nix, what did Kylix use? Or maybe .dso ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Am 04.10.2010 11:52, schrieb Marco van de Voort: In our previous episode, Sven Barth said: However, at the moment I don't see why this is better than shipping all necessary ppl files. BTW: I realize that ppl might be a bad TLA - since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. So... what is your suggestion? Keep the platform specific library name? bpl is fine with me on Windows. On *nix, what did Kylix use? Or maybe .dso ? I'd not use *.bpl. People might get the idea to use FPC packages with Delphi (or the other way round). By using a extension that isn't equal to the Delphi ones we might avoid at least some questions about this topic. ^^ So I personally would prefer *.ppl (for Pascal Package Library) on every platform supporting packages. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
On 04/10/2010 10:56, Sven Barth wrote: So I personally would prefer *.ppl (for Pascal Package Library) on every platform supporting packages. Scenario - I'm using someother Pascal compiler (GNU/Delphi/Virtual/etc) so I can use the PPL's from Free Pascal with them? After all, they *are* Pascal Package Library files?! No matter how infrequently, this *will* happen at some point. I'd say, pick another more descriptive extension now, save your - [collective] - selves reiterating the same disclaimer every time someone asks this question. The assumption that Free Pascal is the only Pascal that will ever exist in a usable form going forward is probably subjective, but it's not a reliable constant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
Am 04.10.2010 09:35, schrieb Sven Barth: Yep. (For inlined methods/functions we could - theoretically - provide a 'non-inlined' version in the binary package) For generics: the token stream is already included in the PPUs (learned by looking at DoDi's ppudump patches ^^) This is interesting. So there might be no need to include the complete .o file after all. For inline: If I remember correctly inlined methods/functions/procedures are always available as non-inlined methods as well. It's up to the compiler to deside whether it inlines it or not. This makes life easier.. :) Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Dynamic Arrays as Static class variables
Hi! It seems there is a problem with dynamic arrays which are defined as static variables in classes. Type TTest = class FDynArr : Array of Integer; static; End; When the class is Destroy()ed, the call to CleanupInstance, which calls fpc_finalize, does a fpc_dynarray_decr_ref which generates a SEGV. Did anybody else experience this problem (using FPC2.4.0-2 on a AMD64 machine). If not, I'll put a test case together. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] LocalReferenceFixup
Hello FPC, I find a problem that I'm unable to resolve, with my limited skills. In TReader when a property is a TClass it is being added to be resolved after all components are loaded, but the Loaded call is performed before this fixup, so when a component receive the Loaded signal some fields are still not completly filled in. This is terrible in the SQLQuery (from Lazarus) as if you left anyone Active it always complaint in runtime with Database not set. :( -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
