[fpc-devel] Test
Please ignore. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
Am 13.09.2010 14:51, schrieb Willibald Krenn: > >>> Well, it's the Delphi way of creating a new type rather than an >>> alias. >> >> Since they are still assignment compatible, I don't consider it as >> a really new type. > > Are you sure they are assignment compatible? I don't have a delphi here, but I'am pretty sure, yes. > I thought the whole > point of the type A = type B was to make a new type, not an alias. Well, the point is to be able to overload procedures/functions. They are no more equal but compatible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
Florian Klämpfl schrieb: This is a very specific example which allows to explain rather simple the slowness of 2.x: The reason is a decision geared by maintainability and portability: 2.x uses a so-called graph colouring register allocator while 1.x used a pretty simple register allocator specifically tailored for i386. Shouldn't we make the register allocator configurable, so that e.g. non-release builds can become faster, and several replacements can be tested easily? The same for other parts of the compiler, where the time-per-task is the first information required to detect real bottlenecks, and to check alternative solutions. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
- "Sven Barth" schreef: > Am 13.09.2010 14:46, schrieb Dimitri Smits: > > as said before, inspiration can be had from how they do it, but that > doesn't mean fpc should do it that way. Especially in a crossplatform > context, and more so cross-architecture, it is not a one-size fits all > per se. > > Basically the package system needs the following: > > - The ability to import/export functions, procedures AND variables > from > binaries (although export from shared library only should be > sufficient). This works on Windows, but on Linux I had problems. > - The ability to declare init and finit procedures for shared images. > > This works on Windows with the entry point and on Linux with special > symbols. I don't know about the other platforms. > - The ability to add the init/finit entries (which call the unit > initialization/finalization sections) uniquely to the shared RTL and > execute them. This is of yet a todo as it means a bit of work in the > RTL. > > The first two points must be provided by the platform/OS while the > third > one is defined by us (at best as the same for all platforms). > > > What would you do different/better then the Delphi developers when > implementing such a package system in a crossplatform way? > I can't imagine currently what should be done additonally, but that > might be because I don't use every feature that FPC provides. So > please > share your ideas. :) a few "cleanups" and "improvements" I'd sneak in are due to the fact that Delphi comes as a whole: VCL and compiler are distributed. Building for a version is building that version. FPC and it's close companion Lazarus are not like that. Compiler is released a few times a year (?), IDE and visual componentset are separate. There is not really a maximum requirement for what compiler you use to build the IDE and components. There is sometimes a minimum version requirement. DLL-hell is bigger, I know. However, take for instance LCL 1.0. (LCL-win32-1.0_fpc2.4.fpl ?) The requires could take just LCL-win32-1.0 as package name and "rtl". Another thing I'd place inside the packageinfo is the compiler with which the package was build (for runtime checking). I do not believe that a version like 2.4.2 should contain other EABI/RTTI or even as worse: other interfaces. They are bugfixes (?). So 2.4.0 can work with 2.4.2 packages. Also, some packageinfo+unittableentry stuff is less than optimal in alignment with the shortstrings iso pchar? Something I've found bizarre with Delphi 7 RTTI in typeinfo as well. Every unit has a local "tunitinfo" block generated: tunitinfo=record ... unitname: shortstring; end; punitinfo=^tunitinfo; tunittableentry=record init, finit: pointer; unitinfo: Punitinfo; typecount: cardinal; unittypes: pptypeinfo; // array[0..typecount-1] of ptypeinfo for all the types in interface & implementation end; Every package/exe(!)/library(!) has a packageinfo table with all the contained (implicitly/explicitly) units in order (like now) of dependencies containing a link like punittableentry. Yes, the executable is a package too! Another thing is what to do with weak packages or what with "if you include this unit first in your project, then it will be initialized after system... for instance a memorymanager-swap"? Packages and the used/described register-init order implies that when you use a memory manager like that, a lot of memory can have been allocated during "init" of units using the default manager before a swap happens. one can mediate that a bit if one can indicate the order of "build with runtimepackages" and if "rtl" contains no units that allocate memory (direct/indirect) in their init sections. So, working further on the "register packages first, then initialize in order" doctrine, one can make the above records and especially the unittableentries and/or table as a doubly linked list. But that is just an idea. I'm gonna stop here, because packages entail ofcourse a lot more than RTTI or dll generation/ini/fini. This is just the top of the iceberg. kind regards Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fatal: Internal error 200111022
Hi, does anyone knows what the error "Fatal: Internal error 200111022" means?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
Am 13.09.2010 23:38, schrieb Hans-Peter Diettrich: > Florian Klämpfl schrieb: > >> This is a very specific example which allows to explain rather simple >> the slowness of 2.x: The reason is a decision geared by maintainability >> and portability: 2.x uses a so-called graph colouring register allocator >> while 1.x used a pretty simple register allocator specifically tailored >> for i386. > > Shouldn't we make the register allocator configurable, so that e.g. > non-release builds can become faster, and several replacements can be > tested easily? Well, as usual: somebody has to implement one. Problem is also: using e.g. a different register allocator for -O- and -O2 will result in less testing by users of one or the other. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
Am 13.09.2010 17:10, schrieb Dimitri Smits: > > - "Florian Klaempfl" schreef: > >> Am 13.09.2010 13:47, schrieb Martin Schreiber: >>> On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote: Am 13.09.2010 11:15, schrieb Martin Schreiber: > Delphi 7 FPC > Exe size: 3131392 3689304 > Code: 2128524 2138240 > Data: 752085 1541256 Do you use a lot of resource strings? >>> >>> I can not use resource strings because FPC resource strings are not >> unicode >>> capable AFAIK. >>> In MSEgui there are many local classdefs in the form of >>> " >>> type >>> ttheclass1 = class(ttheclass); >>> " >>> in order to access protected class members >> >> This should not create any additional data. > > not even rtti-related and vmt-surrounding-data? Should be smartlinked aways if the class is not used. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
Am 14.09.2010 01:26, schrieb Willibald Krenn: > > [lots of useful information snipped] >> - The ability to import/export functions, procedures AND variables >> from binaries (although export from shared library only should be >> sufficient). This works on Windows, but on Linux I had problems. > > Packages also export/import RTTI, ClassVars, types, all the > initialization/finalization code for each unit > (@packageun...@initialization$qqrv ..), compiler magic functions, and > some other stuff like > @packa...@initialization$qqrv > @Package1@@PackageUnload$qqrv > @Package1@@PackageLoad$qqrv > @Package1@@GetPackageInfoTable$qqrv > Finalize > Initialize > @GetPackageInfoTable Since this is also exported by static libs, the main issue is to create proper exports in shared libs (including dlls). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fatal: Internal error 200111022
Am 14.09.2010 01:13, schrieb Leonardo M. Ramé: > Hi, does anyone knows what the error "Fatal: Internal error 200111022" means?. > Something happened which should not happen ;) Looks like an error with overloading. Can you create a cut down example? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
Florian Klämpfl schrieb: Anyways, before this ends in an endless discussion: if anybody is interested in improving FPC compilation speed (for my needs is sufficient) and have a look at fillchar IMO not FillChar is the bottleneck, instead it's the access to newly allocated memory in/around InitInstance, resulting in page faults. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
- "Florian Klaempfl" schreef: > Am 13.09.2010 13:47, schrieb Martin Schreiber: > > On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote: > >> Am 13.09.2010 11:15, schrieb Martin Schreiber: > >>> Delphi 7 FPC > >>> Exe size: 3131392 3689304 > >>> Code: 2128524 2138240 > >>> Data: 752085 1541256 > >> > >> Do you use a lot of resource strings? > > > > I can not use resource strings because FPC resource strings are not > unicode > > capable AFAIK. > > In MSEgui there are many local classdefs in the form of > > " > > type > > ttheclass1 = class(ttheclass); > > " > > in order to access protected class members > > This should not create any additional data. not even rtti-related and vmt-surrounding-data? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
[lots of useful information snipped] - The ability to import/export functions, procedures AND variables from binaries (although export from shared library only should be sufficient). This works on Windows, but on Linux I had problems. Packages also export/import RTTI, ClassVars, types, all the initialization/finalization code for each unit (@packageun...@initialization$qqrv ..), compiler magic functions, and some other stuff like @packa...@initialization$qqrv @Package1@@PackageUnload$qqrv @Package1@@PackageLoad$qqrv @Package1@@GetPackageInfoTable$qqrv Finalize Initialize @GetPackageInfoTable [...] What would you do different/better then the Delphi developers when implementing such a package system in a crossplatform way? Packages worked quite well under Delphi and Kylix. :) Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
On Sat, 2010-08-28 at 22:51 +0300, Žilvinas Ledas wrote: > Tried sample project today. Some a comment and a question: > 1) I have a strange error when the same file is modified twice (and > afterwards restored twice). One is: I'm looking at this issue atm. As soon as I have a definite solution I will commit. > 2) Where should I write comments/bug reports for fpprofiler? Please put up a bug report in mantis and assign it to me. I have updated SVN with all patches Graeme has sent me, so we should use this from now on. I have also create a separate wiki page: http://wiki.freepascal.org/fpprofiler. Feel free to add screen shots and more information. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
appareantly this one didn't get through - "Sven Barth" schreef: > Am 13.09.2010 14:46, schrieb Dimitri Smits: > > as said before, inspiration can be had from how they do it, but that > doesn't mean fpc should do it that way. Especially in a crossplatform > context, and more so cross-architecture, it is not a one-size fits all > per se. > > Basically the package system needs the following: > > - The ability to import/export functions, procedures AND variables > from > binaries (although export from shared library only should be > sufficient). This works on Windows, but on Linux I had problems. > - The ability to declare init and finit procedures for shared images. > > This works on Windows with the entry point and on Linux with special > symbols. I don't know about the other platforms. > - The ability to add the init/finit entries (which call the unit > initialization/finalization sections) uniquely to the shared RTL and > execute them. This is of yet a todo as it means a bit of work in the > RTL. > > The first two points must be provided by the platform/OS while the > third > one is defined by us (at best as the same for all platforms). > > > What would you do different/better then the Delphi developers when > implementing such a package system in a crossplatform way? > I can't imagine currently what should be done additonally, but that > might be because I don't use every feature that FPC provides. So > please > share your ideas. :) a few "cleanups" and "improvements" I'd sneak in are due to the fact that Delphi comes as a whole: VCL and compiler are distributed. Building for a version is building that version. FPC and it's close companion Lazarus are not like that. Compiler is released a few times a year (?), IDE and visual componentset are separate. There is not really a maximum requirement for what compiler you use to build the IDE and components. There is sometimes a minimum version requirement. DLL-hell is bigger, I know. However, take for instance LCL 1.0. (LCL-win32-1.0_fpc2.4.fpl ?) The requires could take just LCL-win32-1.0 as package name and "rtl". Another thing I'd place inside the packageinfo is the compiler with which the package was build (for runtime checking). I do not believe that a version like 2.4.2 should contain other EABI/RTTI or even as worse: other interfaces. They are bugfixes (?). So 2.4.0 can work with 2.4.2 packages. Also, some packageinfo+unittableentry stuff is less than optimal in alignment with the shortstrings iso pchar? Something I've found bizarre with Delphi 7 RTTI in typeinfo as well. Every unit has a local "tunitinfo" block generated: tunitinfo=record ... unitname: shortstring; end; punitinfo=^tunitinfo; tunittableentry=record init, finit: pointer; unitinfo: Punitinfo; typecount: cardinal; unittypes: pptypeinfo; // array[0..typecount-1] of ptypeinfo for all the types in interface & implementation end; Every package/exe(!)/library(!) has a packageinfo table with all the contained (implicitly/explicitly) units in order (like now) of dependencies containing a link like punittableentry. Yes, the executable is a package too! Another thing is what to do with weak packages or what with "if you include this unit first in your project, then it will be initialized after system... for instance a memorymanager-swap"? Packages and the used/described register-init order implies that when you use a memory manager like that, a lot of memory can have been allocated during "init" of units using the default manager before a swap happens. one can mediate that a bit if one can indicate the order of "build with runtimepackages" and if "rtl" contains no units that allocate memory (direct/indirect) in their init sections. So, working further on the "register packages first, then initialize in order" doctrine, one can make the above records and especially the unittableentries and/or table as a doubly linked list. But that is just an idea. I'm gonna stop here, because packages entail ofcourse a lot more than RTTI or dll generation/ini/fini. This is just the top of the iceberg. kind regards Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
Sven Barth schrieb: [snip] In theory(!) it should be "rather" simple to implement shared cross platform packages (those that are loaded on app startup by the OS and not dynamically during the run). Thanks for the hints! They are very welcome. Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
Op 2010-09-13 14:34, Daniël Mantione het geskryf: > > Please don't turn this discussion into a UTF-8 versus UCS-2/UTF-16 > debate. I had no such intension. I guess I was simply stating the obvious - that FPC resourcestrings might have issue with other Unicode formats (which wouldn't surprise me), but that it does work with UTF-8 strings (luckily). Then again, even with UTF-8, FPC still fails in many Unicode areas (as expected since it doesn't support Unicode - contrary to what Martin says) - like locale variables that require more that 1 byte of space. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with makefiles, fpcmake, Package.fpc and fppkg
On Mon, 2010-09-13 at 09:03 +0200, Michael Van Canneyt wrote: > > On Sun, 12 Sep 2010, Joost van der Sluis wrote: > > > Hi all, > > > > Seems like that after all these years there are still bugs in fpc's > > makefiles... > > > > When you install a package, not the Package.fpc which is generated for > > the whole package, but the Package.fpc generated for the last > > sub-package is installed into > > xxx//units//. > > > > Normally not really a problem, but fppkg uses these files to resolve > > dependencies. But the dependencies of the sub-package could be different > > from the dependencies of the main package. > > > > Example: when you do 'make install' in fcl-web, a Package.fpc will be > > installed without the dependency on fcl-db. (In fact a Package.fpc made > > for jsonrpc is installed, which doesn't depend on fcl-db) > > > > The result is that if you have fcl-web installed using fpcmake, and you > > want to install some other package using fpmake that depends on fcl-web, > > that will fail. > > > > Shall I submit a bug-report for fpcmake with a request to use the proper > > Package.fpc file? > > No, in no case. I think we should. > The whole idea of fppkg & fpmake is to get totally rid of fpcmake. > Your proposal implies its continued use. We need it to make a smooth transition. As long as people have packages installed using the fpcmake-makefiles (which is as long as released fpc-versions still use this system, which bill be a long time...), we need this backward-compatibility. > I think that fpmake should output the proper dependencies based on the > dependencies specified in it. This output can be written to Package.fpc. > (although I don't understand why it is in a Package.fpc, dependencies > should be in the central package repository) If you use fpmake to install a package, a file named 'fpunits.conf' is created. In that case everything works. But fpcmake creates a file named Package.cfg. When fpmake can't find a file named 'fpunits.conf', it searches and uses the Package.cfg file. If this file contains the wrong information, fpmake can't process the installed packages all right. This is about installed packages, which maybe could not even exist in the central repository. The 'local' repository is nothing more than the sum of all fpunits.conf and Package.fpc files. The problem I have now is that I want to add package that depends in fcl-web. Most users have fcl-web installed using the fpcmake-system. (That's after all what we use by default) When you try to install this package depending on fcl-web, it won't detect the dependency on fcl-db, since the Package.fpc from fcl-web is invalid. So you can't build this new package. So as long as this problem isn't fixed in fpcmake, we can't use fpmake for packages which are installed using fpcmake. Iow: we can't make package which have dependencies on any package which comes with Free Pascal. (As long as we don't switch to fpmake entirely) So in principle your statement is right: fixing this will lead to a (long) period that both systems can be used at the same time. But I doubt that forcing a transition at once, will lead to a faster acceptance of fpmake. ;) Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
On 14 Sep 2010, at 17:23, Martin Schreiber wrote: The classes are used for example by " with ttheclass1(theclassinstance) do begin end; " Using a class means sending a class message to it, or using the class type as a first class entity in the program (e.g. "x is classtype"). A typecast can be handled completely at compile time (unless you compile with -CR, in which case above will be translated into "with (theclassinstance as ttheclass1) do begin" and hence the class type will becomes a first class entity; but you cannot do that anyway when using "class crackers" since the as-operation would throw an error). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
On Tuesday, 14. September 2010 17.00:02 Florian Klaempfl wrote: > >>> In MSEgui there are many local classdefs in the form of > >>> " > >>> type > >>> ttheclass1 = class(ttheclass); > >>> " > >>> in order to access protected class members > >> > >> This should not create any additional data. > > > > not even rtti-related and vmt-surrounding-data? > > Should be smartlinked aways if the class is not used. The classes are used for example by " with ttheclass1(theclassinstance) do begin end; " On 9/14/10, Florian Klaempfl wrote: > Am 13.09.2010 17:10, schrieb Dimitri Smits: >> >> - "Florian Klaempfl" schreef: >> >>> Am 13.09.2010 13:47, schrieb Martin Schreiber: On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote: > Am 13.09.2010 11:15, schrieb Martin Schreiber: >> Delphi 7 FPC >> Exe size: 3131392 3689304 >> Code: 2128524 2138240 >> Data: 752085 1541256 > > Do you use a lot of resource strings? I can not use resource strings because FPC resource strings are not >>> unicode capable AFAIK. In MSEgui there are many local classdefs in the form of " type ttheclass1 = class(ttheclass); " in order to access protected class members >>> >>> This should not create any additional data. >> >> not even rtti-related and vmt-surrounding-data? > > Should be smartlinked aways if the class is not used. > ___ > 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] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
On Mon, 2010-09-13 at 23:31 +0200, Darius Blaszyk wrote: > On Sat, 2010-08-28 at 22:51 +0300, Žilvinas Ledas wrote: > > Tried sample project today. Some a comment and a question: > > 1) I have a strange error when the same file is modified twice (and > > afterwards restored twice). One is: > I'm looking at this issue atm. As soon as I have a definite solution I will > commit. > fixed in rev2491 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with makefiles, fpcmake, Package.fpc and fppkg
On Mon, 13 Sep 2010, Joost van der Sluis wrote: So as long as this problem isn't fixed in fpcmake, we can't use fpmake for packages which are installed using fpcmake. Iow: we can't make package which have dependencies on any package which comes with Free Pascal. (As long as we don't switch to fpmake entirely) So in principle your statement is right: fixing this will lead to a (long) period that both systems can be used at the same time. But I doubt that forcing a transition at once, will lead to a faster acceptance of fpmake. ;) If handled right, I don't see why not. I doubt many users are aware of the Package.fpc and fpcmake. But since you'll be doing the work, who am I to complain ? :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fatal: Internal error 200111022
Sorry Florian, the error happened trying to compile some auto-generated code with wrong property assignments, with overloaded setters. It's fixed now. Leonardo M. Ramé http://leonardorame.blogspot.com --- On Tue, 9/14/10, Florian Klaempfl wrote: > From: Florian Klaempfl > Subject: Re: [fpc-devel] Fatal: Internal error 200111022 > To: "FPC developers' list" > Date: Tuesday, September 14, 2010, 12:04 PM > Am 14.09.2010 01:13, schrieb Leonardo > M. Ramé: > > Hi, does anyone knows what the error "Fatal: Internal > error 200111022" means?. > > > > Something happened which should not happen ;) Looks like an > error with > overloading. Can you create a cut down example? > ___ > 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] Problems with makefiles, fpcmake, Package.fpc and fppkg
On Tue, 2010-09-14 at 18:53 +0200, Michael Van Canneyt wrote: > > On Mon, 13 Sep 2010, Joost van der Sluis wrote: > > > > > So as long as this problem isn't fixed in fpcmake, we can't use fpmake > > for packages which are installed using fpcmake. Iow: we can't make > > package which have dependencies on any package which comes with Free > > Pascal. (As long as we don't switch to fpmake entirely) > > > > So in principle your statement is right: fixing this will lead to a > > (long) period that both systems can be used at the same time. But I > > doubt that forcing a transition at once, will lead to a faster > > acceptance of fpmake. ;) > > If handled right, I don't see why not. > I doubt many users are aware of the Package.fpc and fpcmake. Yeah, well, on second thought. Maybe you're right. See what happens if I change the makefile from one package... > But since you'll be doing the work, who am I to complain ? :-) Well, in this case you would have to help me fixing fpcmake. But I'll try to go for the big bang. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fatal: Internal error 200111022
Am 14.09.2010 19:39, schrieb Leonardo M. Ramé: > Sorry Florian, the error happened trying to compile some auto-generated code > with wrong property assignments, with overloaded setters. It's fixed now. In FPC or your code? > > Leonardo M. Ramé > http://leonardorame.blogspot.com > > > --- On Tue, 9/14/10, Florian Klaempfl wrote: > >> From: Florian Klaempfl >> Subject: Re: [fpc-devel] Fatal: Internal error 200111022 >> To: "FPC developers' list" >> Date: Tuesday, September 14, 2010, 12:04 PM >> Am 14.09.2010 01:13, schrieb Leonardo >> M. Ramé: >>> Hi, does anyone knows what the error "Fatal: Internal >> error 200111022" means?. >>> >> >> Something happened which should not happen ;) Looks like an >> error with >> overloading. Can you create a cut down example? >> ___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-devel >> > > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fatal: Internal error 200111022
My code, don't worry. Leonardo M. Ramé http://leonardorame.blogspot.com --- On Tue, 9/14/10, Florian Klämpfl wrote: > From: Florian Klämpfl > Subject: Re: [fpc-devel] Fatal: Internal error 200111022 > To: "FPC developers' list" > Date: Tuesday, September 14, 2010, 4:01 PM > Am 14.09.2010 19:39, schrieb Leonardo > M. Ramé: > > Sorry Florian, the error happened trying to compile > some auto-generated code with wrong property assignments, > with overloaded setters. It's fixed now. > > In FPC or your code? > > > > > Leonardo M. Ramé > > http://leonardorame.blogspot.com > > > > > > --- On Tue, 9/14/10, Florian Klaempfl > wrote: > > > >> From: Florian Klaempfl > >> Subject: Re: [fpc-devel] Fatal: Internal error > 200111022 > >> To: "FPC developers' list" > >> Date: Tuesday, September 14, 2010, 12:04 PM > >> Am 14.09.2010 01:13, schrieb Leonardo > >> M. Ramé: > >>> Hi, does anyone knows what the error "Fatal: > Internal > >> error 200111022" means?. > >>> > >> > >> Something happened which should not happen ;) > Looks like an > >> error with > >> overloading. Can you create a cut down example? > >> ___ > >> fpc-devel maillist - fpc-devel@lists.freepascal.org > >> http://lists.freepascal.org/mailman/listinfo/fpc-devel > >> > > > > > > > > ___ > > fpc-devel maillist - fpc-devel@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-devel > > > > ___ > fpc-devel 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] Fatal: Internal error 200111022
Am 14.09.2010 21:31, schrieb Leonardo M. Ramé: > My code, don't worry. Well, I worry because no code to compile should be able to trigger an internal error. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
Am 14.09.2010 01:26, schrieb Willibald Krenn: [lots of useful information snipped] - The ability to import/export functions, procedures AND variables from binaries (although export from shared library only should be sufficient). This works on Windows, but on Linux I had problems. Packages also export/import RTTI, ClassVars, types, all the initialization/finalization code for each unit (@packageun...@initialization$qqrv ..), compiler magic functions, and some other stuff like @packa...@initialization$qqrv @Package1@@PackageUnload$qqrv @Package1@@PackageLoad$qqrv @Package1@@GetPackageInfoTable$qqrv Finalize Initialize @GetPackageInfoTable Bascially everything that a Package exports is either a function/procedure or a variable. But currently the package code of FPC only exports functions and procedures, but no variables, so you miss the important variables of the RTL which are needed to generate a working package version of the RTL. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fatal: Internal error 200111022
I understand. Sadly I can't reproduce the error anymore, my code was fixed yesterday, if I can get the broken code again I'll send it to you. Leonardo M. Ramé http://leonardorame.blogspot.com --- On Tue, 9/14/10, Florian Klämpfl wrote: > From: Florian Klämpfl > Subject: Re: [fpc-devel] Fatal: Internal error 200111022 > To: "FPC developers' list" > Date: Tuesday, September 14, 2010, 4:32 PM > Am 14.09.2010 21:31, schrieb Leonardo > M. Ramé: > > My code, don't worry. > > Well, I worry because no code to compile should be able to > trigger an > internal error. > ___ > 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] Problems with makefiles, fpcmake, Package.fpc and fppkg
On Tue, 14 Sep 2010, Joost van der Sluis wrote: On Tue, 2010-09-14 at 18:53 +0200, Michael Van Canneyt wrote: On Mon, 13 Sep 2010, Joost van der Sluis wrote: So as long as this problem isn't fixed in fpcmake, we can't use fpmake for packages which are installed using fpcmake. Iow: we can't make package which have dependencies on any package which comes with Free Pascal. (As long as we don't switch to fpmake entirely) So in principle your statement is right: fixing this will lead to a (long) period that both systems can be used at the same time. But I doubt that forcing a transition at once, will lead to a faster acceptance of fpmake. ;) If handled right, I don't see why not. I doubt many users are aware of the Package.fpc and fpcmake. Yeah, well, on second thought. Maybe you're right. See what happens if I change the makefile from one package... But since you'll be doing the work, who am I to complain ? :-) Well, in this case you would have to help me fixing fpcmake. But I'll try to go for the big bang. I'll be glad to test things for you with fpmake/fppkg, just give me specific things you want tested. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
On 13/09/2010 14:16, Florian Klaempfl wrote: Am 13.09.2010 14:51, schrieb Willibald Krenn: Well, it's the Delphi way of creating a new type rather than an alias. Since they are still assignment compatible, I don't consider it as a really new type. Are you sure they are assignment compatible? I don't have a delphi here, but I'am pretty sure, yes. It works that way. The following snippet compiles and gives the expected result in D7 type TMyInteger = type Integer; procedure TForm1.FormCreate(Sender: TObject); var my: TMyInteger; notmy: integer; begin my := 10; notmy := my; showmessage(inttostr(notmy)); showmessage(inttostr(my)); end; Paulo Costa ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
