Re: [fpc-devel] RIP NoGlobals
Am 30.09.2010 02:38, schrieb Hans-Peter Diettrich: Florian Klämpfl schrieb: In the past months I've been working on several aspects of such refactoring: - moving global variables into objects (mainly current_module) - turning back-ends into classes The fpc back end is completly OOP? To some degree. Basic data types are hard coded, True, not every type is a class in Object Pascal. and prevent the use of multiple back-ends in one binary. ... which has no use. - separation of parser (front-end) from AST processing (building AST, optimization, code generation) I fear that this will make the code even more fragile because the code gets spread among more locations. It's a matter of the related interfaces/APIs. When we agree to turn the current codebase into such an OO approach, eventually adding documentation, the maintenance could be simplified a lot. We had for 1.0 a rather complete documentation. However, it outdated too quick and it didn't simplify maintainance in any way. That's because the implementation didn't follow the documentation. A strict OO design can be implemented according to the documentation. Yes, in an ideal world with endless resources. During my experiments I've learned how fragile the current state of the compiler codebase is - even a minor change can have inpredictable consequences in other parts of the code. This won't change. A compiler is simply something very interwinded. Your problems with cyclic unit dependencies prove it. These problems only prove poor coding conventions. When speed is favored over stability and flexibility, Indeed, currently people complain more about FPC's speed than about it's stability. While I agree that we should refactor parts of the compiler, it should be done in an evolutionary way. Don't forget, work on 2.0 took 6 years. And the results of that work are not really pleasing :-( Really? Show me any *production* compiler which can be ported with a few thousand lines of code to another architecture. The FPC backend is one of the best written production compiler back ends I know. It's patchwork in many parts, that destabilized the legacy code. Well, you didn't come up with clean fixes yet either :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 09/29/2010 08:08 PM, Michael Van Canneyt wrote: That is only true if the functionality stays the same. Since there is more functionality, it is normal that there are more bugs. I am positively astonished about the development of the open bug count. To me it looks like open bugs divided by features in fact decreases. :) Great work of the FPC team ! Thanks ! .-Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
+1, But of course a rewrite would at first result in a huge jump up of open bugs. No idea how long it would take to get it down to the current level. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 30/09/2010, Michael Schnell mschn...@lumino.de wrote: But of course a rewrite would at first result in a huge jump up of open bugs. No idea how long it would take to get it down to the current level. Not necessarily. If the FPC test suite is run regularly, it should contain/minimize the amount of new bugs introduced [that is obviously very dependent on how complete the FPC test suite is]. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit 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] RIP NoGlobals
Michael Schnell schrieb: +1, But of course a rewrite would at first result in a huge jump up of open bugs. How that? Refactoring does not change the existing logic. No idea how long it would take to get it down to the current level. All refactoring steps can be verified immediately, using make all and compiler/make fullcycle. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Florian Klaempfl schrieb: and prevent the use of multiple back-ends in one binary. ... which has no use. Lazarus allows to switch targets on the fly, what currently prevents an incorporation of the compiler into the IDE. For compiler development and debugging purposes it would be very nice, when all targets are covered in one compile. This won't change. A compiler is simply something very interwinded. Your problems with cyclic unit dependencies prove it. These problems only prove poor coding conventions. When speed is favored over stability and flexibility, Indeed, currently people complain more about FPC's speed than about it's stability. Looking at make clean all, nearly half of the time is spent in the cleanup, not in compiling (Windows). I have no problems with the compilation speed, at least for repeated compilation during editing, where only changed files have to be recompiled. While I agree that we should refactor parts of the compiler, it should be done in an evolutionary way. Don't forget, work on 2.0 took 6 years. And the results of that work are not really pleasing :-( Really? Show me any *production* compiler which can be ported with a few thousand lines of code to another architecture. The FPC backend is one of the best written production compiler back ends I know. Which production compiler back ends have you inspected? Please note that my criticism is based on the implementation, not on the model - the latter is superb :-) The patchwork results in many open todo's, in the target units and other places. It's patchwork in many parts, that destabilized the legacy code. Well, you didn't come up with clean fixes yet either :) See above and parallel mail - the back ends have low priority on my todo list. Why should I publish branches and patches, when these have no chance to find their way into the trunk? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patches
Today I provided two new patches for old issues. One covers the preprocessor, which does not even compile in the trunk version (#16888). The other one addresses the initialization of the class type variables for node classes (#17516). Now I hope that these fundamental patches will be applied soon. Next I'll move ppudump into the compiler, according to Adem's suggestion, so that the dependency show stopper goes away. BTW I couldn't find patches and features lists, as exist for Lazarus. Any hints? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On Wed, Sep 29, 2010 at 1:17 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Now I'll resume my original work on multiple front-ends, this time using a git repository - thanks to Graeme for the FPC and Lazarus repositories :-) What do you mean with multiple front-ends? One binary which cross-compiles to multiple targets or multiple input languages? -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Am 30.09.2010 11:32, schrieb Hans-Peter Diettrich: No idea how long it would take to get it down to the current level. All refactoring steps can be verified immediately, using make all and compiler/make fullcycle. Well, and running the regression tests on all targets ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 30 Sep 2010, at 11:40, Hans-Peter Diettrich wrote: Next I'll move ppudump into the compiler, according to Adem's suggestion, so that the dependency show stopper goes away. The basic issue is that the functionality ppudump happens to depend on must not depend on the code generator. The current build system enforces this rather strictly. Removing the check from the build system so that you can break this separation of concerns is just wrong. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 30 Sep 2010, at 11:29, Hans-Peter Diettrich wrote: Lazarus allows to switch targets on the fly, what currently prevents an incorporation of the compiler into the IDE. There are more things that prevent that, not in the least that almost any source code error will result in lots of memory leaks from the compiler. For compiler development and debugging purposes it would be very nice, when all targets are covered in one compile. It increases the compiler build time, which is not nice. And I personally, as a compiler developer and debugger, think it's very nice that everything is cleanly separated and that it's not possible to have accidental cross-target dependencies, which could result in changes in the constants/types for one target to suddenly impact a completely different target. Until FPC is developed by perfect programmers that never make any errors, I think that minimising the way in which things can get entangled is the best way. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Am 30.09.2010 11:29, schrieb Hans-Peter Diettrich: Florian Klaempfl schrieb: and prevent the use of multiple back-ends in one binary. ... which has no use. Lazarus allows to switch targets on the fly, what currently prevents an incorporation of the compiler into the IDE. Define a proper compiler API and load the compiler as shared lib. This allows also to work with different compiler versions in the future when the API is stabilized. For compiler development and debugging purposes it would be very nice, when all targets are covered in one compile. make fullcycle does this too. Which production compiler back ends have you inspected? GCC, Watcom, LLVM. This won't change. A compiler is simply something very interwinded. Your problems with cyclic unit dependencies prove it. These problems only prove poor coding conventions. When speed is favored over stability and flexibility, Indeed, currently people complain more about FPC's speed than about it's stability. Looking at make clean all, nearly half of the time is spent in the cleanup, not in compiling (Windows). rm build-stamp.* make all is what I usually do :) I have no problems with the compilation speed, at least for repeated compilation during editing, where only changed files have to be recompiled. Me neither, but other people, see recent discussions. Please note that my criticism is based on the implementation, not on the model - the latter is superb :-) The patchwork results in many open todo's, in the target units and other places. It's patchwork in many parts, that destabilized the legacy code. Well, you didn't come up with clean fixes yet either :) See above and parallel mail - the back ends have low priority on my todo list. Why should I publish branches and patches, when these have no chance to find their way into the trunk? Well, to give them a chance, it's important to discuss them as early as possible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 30 Sep 2010, at 02:27, Ralf A. Quint wrote: Now, one interesting question/stat would rather be: How long do bugs stay open? How long does it take to resolve the issues of a bug? Mantis does not keep information about the evolution of that over time, but you can always look at the current average at http://bugs.freepascal.org/summary_page.php (under Time Stats For Resolved Issues (days)). Note that the Average time is kind of strange: it is only calculated from the already resolved bugs. This means that if you keep bugs older than the average open indefinitely, you get a better result than when you start fixing them. In general, it has been slowly increasing over time. Also, all bug counts and statistics also include feature requests, and bugs for the text mode ide which is seldom worked on anymore. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 2010-09-30 12:57, Jonas Maebe wrote: Mantis does not keep information about the evolution of that over time, but you can always look at the current average at http://bugs.freepascal.org/summary_page.php (under Time Stats For Resolved Issues (days)). Not all of us have rights to access these pages. I get: --- Access Denied. [ Click here to proceed ] --- Regards Žilvinas Ledas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Am 30.09.2010 13:06, schrieb Žilvinas Ledas: On 2010-09-30 12:57, Jonas Maebe wrote: Mantis does not keep information about the evolution of that over time, but you can always look at the current average at http://bugs.freepascal.org/summary_page.php (under Time Stats For Resolved Issues (days)). Not all of us have rights to access these pages. I get: --- Access Denied. [ Click here to proceed ] Since it causes a lot of DB load, it is disabled for common view. The results are: Time Stats For Resolved Issues (days) Longest open issue 0004889 Longest open2,409.26 Average time70.32 Total time 573,220.08 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 12:38, Jonas Maebe wrote: The basic issue is that the functionality ppudump happens to depend on must not depend on the code generator. The current build system enforces this rather strictly. Removing the check from the build system so that you can break this separation of concerns is just wrong. When I look at its description [ http://www.freepascal.org/tools/ppudump.var ] (ppudump writes the contents of a Free Pascal unit file to standard output. It gives a listing of all definitions in the unit file. The format of the listing can be controlled by the options.) it's not clear to me why ppudump must be a strictly independent stand-alone executable. Could you elaborate why you think it should be. Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 30 Sep 2010, at 13:39, Adem wrote: it's not clear to me why ppudump must be a strictly independent stand-alone executable. I did not say that it must be a stand-alone executable. I said that it must not depend on the code generator (whether it's inside or outside the compiler is irrelevant to that point). And the reason I said that is because Hans-Peter's wants to move it inside the compiler so that making ppudump depend on the code generator would no longer break the build. The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Zitat von Jonas Maebe jonas.ma...@elis.ugent.be: On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? So the proper way to integrate FPC is to run it as separate process or in a dyn lib with its own memory manager. Correct, or ? This means, in order to share some caches an IDE must use some IPC/shared memory. Right? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 30 Sep 2010, at 14:15, Mattias Gärtner wrote: Zitat von Jonas Maebe jonas.ma...@elis.ugent.be: On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? No, because it would be lots of work (writing test programs that trigger all possible error conditions and testing/debugging them one by one, or implementing some kind of mark/release system) with no real payoff except if you're an IDE developer that wants to integrate the compiler. Solving memory leaks that occur during a successful compilation is both easier (you have to compile less different programs to obtain large code coverage) and more important to everyone (memory leaks during a successful compilation can needlessly increase the memory requirements of the compiler). So the proper way to integrate FPC is to run it as separate process or in a dyn lib with its own memory manager. Correct, or ? This means, in order to share some caches an IDE must use some IPC/ shared memory. Right? Probably, I haven't really thought about that. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Am 30.09.2010 14:15, schrieb Mattias Gärtner: Zitat von Jonas Maebe jonas.ma...@elis.ugent.be: On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? No. But I don't consider it that bad: most of the memory is released even in case of an error. The overlefts shouldn't add up that much. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 15:03, Jonas Maebe wrote: And the reason I said that is because Hans-Peter's wants to move it inside the compiler so that making ppudump depend on the code generator would no longer break the build. The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Could it not be the other way around? That, it turned out that ppudump wasn't as independent as had been thought? -- Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Zitat von Florian Klaempfl flor...@freepascal.org: Am 30.09.2010 14:15, schrieb Mattias Gärtner: Zitat von Jonas Maebe jonas.ma...@elis.ugent.be: On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? No. But I don't consider it that bad: most of the memory is released even in case of an error. The overlefts shouldn't add up that much. When it is used for quick syntax check the compiler is invoked several times a minute - several thousand times a day. Is that a problem? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Op Thu, 30 Sep 2010, schreef Mattias Gärtner: When it is used for quick syntax check the compiler is invoked several times a minute - several thousand times a day. Is that a problem? Expect a few kilobytes that are left over at maximum, the compiler is been debugged for memory leaks, however, this is very difficult for all possible error conditions. If you find a memory leak that you don't like, report a bug, they can be fixed. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 30 Sep 2010, at 14:43, Adem wrote: On 2010-09-30 15:03, Jonas Maebe wrote: And the reason I said that is because Hans-Peter's wants to move it inside the compiler so that making ppudump depend on the code generator would no longer break the build. The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Could it not be the other way around? That, it turned out that ppudump wasn't as independent as had been thought? The compiler doesn't think, it just gives an error when a unit is not found. Hans-Peter tried putting global variables from all over the compiler into a single unit, so it's logical that this makes everything dependent on everything (because that single globals unit has to import type definitions from all over the compiler). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 16:07, Jonas Maebe wrote: On 30 Sep 2010, at 14:43, Adem wrote: On 2010-09-30 15:03, Jonas Maebe wrote: And the reason I said that is because Hans-Peter's wants to move it inside the compiler so that making ppudump depend on the code generator would no longer break the build. The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Could it not be the other way around? That, it turned out that ppudump wasn't as independent as had been thought? The compiler doesn't think, it just gives an error when a unit is not found. Hans-Peter tried putting global variables from all over the compiler into a single unit, so it's logical that this makes everything dependent on everything (because that single globals unit has to import type definitions from all over the compiler). I don't see why bringing together all the globals together should make everything dependent on everything else; after all 'globals' are those variables/routines that are common to all. Actually, if I were DoDi, I'd probably bring all those units (that do nothing but declare various types and constants) in the uses secions of globals.pas into globals.pas. Such as version.pas, globtype.pas, systems.pas, cpuinfo.pas, and probably a few more. These units either use no other units, or use no units that globals.pas doesn't. In order for globals.pas to be a proper global unit, I'd bring copy paste those units into globals.pas. And then remove/delete tose superfluous units. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On Thu, 30 Sep 2010, Adem wrote: On 2010-09-30 16:07, Jonas Maebe wrote: On 30 Sep 2010, at 14:43, Adem wrote: On 2010-09-30 15:03, Jonas Maebe wrote: And the reason I said that is because Hans-Peter's wants to move it inside the compiler so that making ppudump depend on the code generator would no longer break the build. The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Could it not be the other way around? That, it turned out that ppudump wasn't as independent as had been thought? The compiler doesn't think, it just gives an error when a unit is not found. Hans-Peter tried putting global variables from all over the compiler into a single unit, so it's logical that this makes everything dependent on everything (because that single globals unit has to import type definitions from all over the compiler). I don't see why bringing together all the globals together should make everything dependent on everything else; after all 'globals' are those variables/routines that are common to all. Actually, if I were DoDi, I'd probably bring all those units (that do nothing but declare various types and constants) in the uses secions of globals.pas into globals.pas. I think there is a misunderstanding: 'global variables' 'globals'. He meant variables that are not part of an object, but declared as a unit variable. If you put all such 'global' variables in 1 unit, you do drag in all the original units, if the variables are typed. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 18:07, Michael Van Canneyt wrote:
Actually, if I were DoDi, I'd probably bring all those units (that do
nothing but declare various types and constants) in the uses secions
of globals.pas into globals.pas. I don't see why bringing together
all the globals together should make everything dependent on
everything else; after all 'globals' are those variables/routines
that are common to all.
I think there is a misunderstanding: 'global variables' 'globals'.
True. 'Globals' include 'global variables', structures and routines.
He meant variables that are not part of an object, but declared as a unit
variable. If you put all such 'global' variables in 1 unit, you do
drag in all the original units, if the variables are typed.
I checked the following units used in globals.pas.
-- version.pas
Uses no external units. Comprises of a few type/constant declarations.
-- globtype.pas
Uses no external units. Comprises of a few type/constant declarations.
-- systems.pas
Uses some external units, all except one is already used in globals.pas.
The only extra unit is {$ifdef FreeBSD},SysCtl,{$endif} which could
easily be added to the uses section (or the body) of globals.pas.
-- cpuinfo.pas
Uses no external units. Comprises of a few type/constant declarations.
IOW, all these units could be combined into globals.pas
[ Curious: Why does every unit here has .pas extension but SysCtl ( .pp
extension)? ]
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On Thu, 30 Sep 2010, Adem wrote:
On 2010-09-30 18:07, Michael Van Canneyt wrote:
Actually, if I were DoDi, I'd probably bring all those units (that do
nothing but declare various types and constants) in the uses secions of
globals.pas into globals.pas. I don't see why bringing together all the
globals together should make everything dependent on everything else;
after all 'globals' are those variables/routines that are common to all.
I think there is a misunderstanding: 'global variables' 'globals'.
True. 'Globals' include 'global variables', structures and routines.
He meant variables that are not part of an object, but declared as a unit
variable. If you put all such 'global' variables in 1 unit, you do drag in
all the original units, if the variables are typed.
I checked the following units used in globals.pas.
-- version.pas
Uses no external units. Comprises of a few type/constant declarations.
-- globtype.pas
Uses no external units. Comprises of a few type/constant declarations.
-- systems.pas
Uses some external units, all except one is already used in globals.pas.
The only extra unit is {$ifdef FreeBSD},SysCtl,{$endif} which could easily
be added to the uses section (or the body) of globals.pas.
-- cpuinfo.pas
Uses no external units. Comprises of a few type/constant declarations.
IOW, all these units could be combined into globals.pas
You still don't understand.
take the unit export. It contains:
var
CExportLib : array[tsystem] of TExportLibClass;
ExportLib : TExportLib;
If you want to move the *global variables* (as in: unit scope)
CExportLib,ExportLib to globals, you must add export to the globals unit.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
Am 30.09.2010 19:12, schrieb Adem: On 2010-09-30 19:39, Michael Van Canneyt wrote: If you want to move the *global variables* (as in: unit scope) CExportLib,ExportLib to globals, you must add export to the globals unit. Not only do I think they should be moved to globals.pas, I also think they should be fields/properties/methods of, say, TFCPGlobalSettings class. Which, in turn, should be used in the compiler object as a field/property. Doing that does not increase complexity. Just the opposite: the code becomes more decipherable and hence more robust. BTW, removing all these var CExportLib : array[tsystem] of TExportLibClass; ExportLib : TExportLib; procedure RegisterExport(t: tsystem; c: TExportLibClass); procedure InitExport; procedure DoneExport; from export.pas, also enables us to remove 'globals' from the 'uses' of export.pas --which means less convolution to me. What I would like to know is why seem to think this is a bad idea? Because it requires that TExportLib with all methods goes into globals.pas so we can completely kick export.pas. In the end, we end up with one compiler.pas file of 200k lines. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 06:59, Florian Klämpfl wrote: Am 30.09.2010 19:12, schrieb Adem: On 2010-09-30 19:39, Michael Van Canneyt wrote: If you want to move the *global variables* (as in: unit scope) CExportLib,ExportLib to globals, you must add export to the globals unit. Not only do I think they should be moved to globals.pas, I also think they should be fields/properties/methods of, say, TFCPGlobalSettings class. Which, in turn, should be used in the compiler object as a field/property. Doing that does not increase complexity. Just the opposite: the code becomes more decipherable and hence more robust. BTW, removing all these var CExportLib : array[tsystem] of TExportLibClass; ExportLib : TExportLib; procedure RegisterExport(t: tsystem; c: TExportLibClass); procedure InitExport; procedure DoneExport; from export.pas, also enables us to remove 'globals' from the 'uses' of export.pas --which means less convolution to me. What I would like to know is why seem to think this is a bad idea? Because it requires that TExportLib with all methods goes into globals.pas so we can completely kick export.pas. In the end, we end up with one compiler.pas file of 200k lines. :) No. I don't think there's that risk. But, if we're talking specifically about export.pas, there's no reason that all of it should go into globals.pas. But, IMO, there's no reason why these should be in there procedure exportprocsym(sym: tsym; const s : string; index: longint; options: word); procedure exportvarsym(sym: tsym; const s : string; index: longint; options: word); procedure exportname(const s : string; options: word); procedure exportallprocdefnames(sym: tprocsym; pd: tprocdef; options: word); procedure exportallprocsymnames(ps: tprocsym; options: word); var CExportLib: array[tsystem] of TExportLibClass; ExportLib: TExportLib; procedure RegisterExport(t:tsystem;c:TExportLibClass); procedure InitExport; procedure DoneExport; It is only more logical/sensible to bring together all these one-instance global objects into a one-instance global object, instead of having them scattered all around the place. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
Am 30.09.2010 19:53, schrieb Adem: On 2010-09-30 06:59, Florian Klämpfl wrote: Am 30.09.2010 19:12, schrieb Adem: On 2010-09-30 19:39, Michael Van Canneyt wrote: If you want to move the *global variables* (as in: unit scope) CExportLib,ExportLib to globals, you must add export to the globals unit. Not only do I think they should be moved to globals.pas, I also think they should be fields/properties/methods of, say, TFCPGlobalSettings class. Which, in turn, should be used in the compiler object as a field/property. Doing that does not increase complexity. Just the opposite: the code becomes more decipherable and hence more robust. BTW, removing all these var CExportLib : array[tsystem] of TExportLibClass; ExportLib : TExportLib; procedure RegisterExport(t: tsystem; c: TExportLibClass); procedure InitExport; procedure DoneExport; from export.pas, also enables us to remove 'globals' from the 'uses' of export.pas --which means less convolution to me. What I would like to know is why seem to think this is a bad idea? Because it requires that TExportLib with all methods goes into globals.pas so we can completely kick export.pas. In the end, we end up with one compiler.pas file of 200k lines. :) No. I don't think there's that risk. But, if we're talking specifically about export.pas, there's no reason that all of it should go into globals.pas. But, IMO, there's no reason why these should be in there procedure exportprocsym(sym: tsym; const s : string; index: longint; options: word); procedure exportvarsym(sym: tsym; const s : string; index: longint; options: word); procedure exportname(const s : string; options: word); procedure exportallprocdefnames(sym: tprocsym; pd: tprocdef; options: word); procedure exportallprocsymnames(ps: tprocsym; options: word); var CExportLib: array[tsystem] of TExportLibClass; ExportLib: TExportLib; procedure RegisterExport(t:tsystem;c:TExportLibClass); procedure InitExport; procedure DoneExport; It is only more logical/sensible to bring together all these one-instance global objects into a one-instance global object, instead of having them scattered all around the place. I hope you are joking ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 20:56, Florian Klämpfl wrote: Am 30.09.2010 19:53, schrieb Adem: It is only more logical/sensible to bring together all these one-instance global objects into a one-instance global object, instead of having them scattered all around the place. I hope you are joking ... I have read the above sentence (of mine) a few times over; and I seriously cannot see why I should be expected to be joking. Could someone tell me what advantage there can ever be in/of having global variables scattered all around the place. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
2010/9/30 Adem listmem...@letterboxes.org: It is only more logical/sensible to bring together all these one-instance global objects into a one-instance global object, instead of having them scattered all around the place. I hope you are joking ... I have read the above sentence (of mine) a few times over; and I seriously cannot see why I should be expected to be joking. Could someone tell me what advantage there can ever be in/of having global variables scattered all around the place. Well, global variables are going to be all over the place and will be declared in the scope of the unit where they are established. It establishes their belonging in the unit/module in which they are/were declared :-) I think that the assertion of taking variables (just because they are global) and placing them in one unit file is indeed funny. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Jonas Maebe schrieb: There are more things that prevent that, not in the least that almost any source code error will result in lots of memory leaks from the compiler. IMO just such problems can be reduced by moving global variables into classes. When e.g. a single Compiler object holds the references to all other heap objects, an entire cleanup can be performed in the destructors. This is where the Pascal singleton hack (units for classes) differs from true OOP, because units can not be destroyed. The many constructors and destructors of such compiler singletons (InitCompiler, DoneCompiler...) should be callable (and actually be called) after every compilation. For compiler development and debugging purposes it would be very nice, when all targets are covered in one compile. It increases the compiler build time, which is not nice. Building an compiler for all targets can be done in e.g. make fullcycle, or in an according .lpi, while the default compiler still can be built for only the specified target. As before, every target has to be included explicitly, by referencing its root unit. And I personally, as a compiler developer and debugger, think it's very nice that everything is cleanly separated and that it's not possible to have accidental cross-target dependencies, which could result in changes in the constants/types for one target to suddenly impact a completely different target. The target specific types etc. have to be encapsulated, so that they can not be used by accident. This is not hard to manage (still hard to implement ;-), because the conflicting target-specific units and types have to be renamed for parallel use. Since this disallows to use target specific types in general compiler code, proper virtualization is enforced by that renaming, so that many of your problems will disappear consequently :-) Until FPC is developed by perfect programmers that never make any errors, I think that minimising the way in which things can get entangled is the best way. A good OOP language and development system shall not only *allow* for OO programming, it also should *encourage* the use of OOP. When compiler developers state that their OOP compiler is constructed in an non-OO way, for performance or other reasons, this IMO is only an excuse for not understanding the pros of OOP, or for bad use or implementation of the support for objects and related types (dynamic strings...). It's possible that the use of OO features, together with spaghetti code, can result in a performance degradation. But OTOH performance can improve as well, when *all* (related) parts of a project cooperate by using OO features. In detail I still doubt that the use of dynamic strings *everywhere* will really result in an much slower compiler - the opposite may be true as well. It's known that stringhandling in an OO way can result in poor performance (see .NET strings), due to clumsy overloading of the string operators - but such overhead can be reduced by using more compiler magics, instead of general overloading. Also arguments like FillChar takes a long time, as an argument against using classes (InitInstance), IMO is only a misinterpretation of the profiling information - it might come as well from the page faults, that occur on the first access to new heap objects, and only becomes *visible* in the use of a common (FillChar...) procedure, while otherwise the page faults are added to arbitrary code, that accesses an heap object for the first time. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Florian Klaempfl schrieb: and prevent the use of multiple back-ends in one binary. ... which has no use. Lazarus allows to switch targets on the fly, what currently prevents an incorporation of the compiler into the IDE. Define a proper compiler API and load the compiler as shared lib. This allows also to work with different compiler versions in the future when the API is stabilized. That's easy: function Compile(const filename, options: string; caches: TCaches): TMessageList; What else are you missing? For compiler development and debugging purposes it would be very nice, when all targets are covered in one compile. make fullcycle does this too. At a very high cost :-( Which production compiler back ends have you inspected? GCC, Watcom, LLVM. Which of these claims for best performance, in favor of best portability? Why should I publish branches and patches, when these have no chance to find their way into the trunk? Well, to give them a chance, it's important to discuss them as early as possible. That's problematic. While the goals are quite clear, the steps to achieve the goals are inpredictable in most cases - everything depends on problems encountered during an implementation attempt. A discussion of such problems requires some familiarity with the details, and with the consequences of possible solutions. Too bad when obvious consequences are not mentioned just-in-time, because some guru has no time for following the discussion(s). I'd appreciate better ways for providing material for discusson, than branches in the SVN repository. Such branches are hard to remove, if ever, and restarting with a preceding version, when a dead end was hit, also is problematic. Currently I try to provide some patches, based on SVN patches, but developed using a Git repo. I found no solution for the different revisions, that are required as the base of both SVN and Git patches - anybody? Another solution could be a (non-tracking) Git repo on some public server, where experimental branches can be created and removed freely. Patches for inclusion into the SVN repo can be created from a Git repo, when both share the same working copy. Thanks to Graeme for mentioning this trick :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Florian Klaempfl schrieb: All refactoring steps can be verified immediately, using make all and compiler/make fullcycle. Well, and running the regression tests on all targets For what purpose? When both changes to the trunk and branches result in different results, and all that differently again for every target, who can know the correct results? BTW, the tests can be run by everybody, no knowledge about the code details is required for that purpose. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Jonas Maebe schrieb: As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? No, because it would be lots of work (writing test programs that trigger all possible error conditions and testing/debugging them one by one, or implementing some kind of mark/release system) with no real payoff except if you're an IDE developer that wants to integrate the compiler. IMO you simply don't understand the reason for my NoGlobals refactoring, or deny its use for (assumed) performance degradation. Right? So the proper way to integrate FPC is to run it as separate process or in a dyn lib with its own memory manager. Correct, or ? This means, in order to share some caches an IDE must use some IPC/shared memory. Right? Probably, I haven't really thought about that. And this may be were a (possible) performance gain in the compiler can result in an even higher performance degradation, when the compiler is used by other applications. Overall performance may be increased as well, when parts of Make are added to the compiler itself. Then e.g. a simple flag could indicate which files or units can not be used without recompilation, instead of a long-running chain of file removes in advance (make clean). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Felipe Monteiro de Carvalho schrieb: Now I'll resume my original work on multiple front-ends, this time using a git repository - thanks to Graeme for the FPC and Lazarus repositories :-) What do you mean with multiple front-ends? One binary which cross-compiles to multiple targets or multiple input languages? Multiple input languages. Modula or Oberon for an first try, later followed by C and (eventually) ObjectiveC. The language specific standard libraries are not covered by the front-ends, and solutions must be found for separate implementation and interface files (in Modula and C). This is where the compiler infrastructure (node classes, ppu files) may deserve some extensions, later... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
Jonas Maebe schrieb: That, it turned out that ppudump wasn't as independent as had been thought? The compiler doesn't think, it just gives an error when a unit is not found. Consequently the compiler can not know about the reasons of such dependencies, and can not be used to judge what's the cause and what's only symptoms of the disease. Hans-Peter tried putting global variables from all over the compiler into a single unit, so it's logical that this makes everything dependent on everything (because that single globals unit has to import type definitions from all over the compiler). You know that this is *not* true :-( My last attempt, to move all *remaining* global variables into dedicated units (with/out cg dependences), only was an intermediate solution, in order to just figure out these dependencies. Once all evitable global variables have been elimited, there remains nothing that could introduce unwanted dependencies. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
Jonas Maebe schrieb: The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Then *ppudump* must be hacked further, since the currently present workarounds (not using symconst, globtype, systems and other compiler units) turned out to be insufficient. Perhaps e.g. the Globals unit has to be split into one general part, with no possible code generator dependencies, and one part with variables that may introduce such dependencies. But this IMO is fruitless work, when ppudump can be incorporated with almost no negative impact into the compiler itself. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Am 30.09.2010 20:21, schrieb Hans-Peter Diettrich: Florian Klaempfl schrieb: All refactoring steps can be verified immediately, using make all and compiler/make fullcycle. Well, and running the regression tests on all targets For what purpose? When both changes to the trunk and branches result in different results, and all that differently again for every target, who can know the correct results? As said, they are regression tests. New fails after changes = first fixing needed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
Am 30.09.2010 21:06, schrieb Hans-Peter Diettrich: Jonas Maebe schrieb: The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system. Then *ppudump* must be hacked further, since the currently present workarounds (not using symconst, globtype, systems and other compiler units) turned out to be insufficient. Perhaps e.g. the Globals unit has to be split into one general part, with no possible code generator dependencies, and one part with variables that may introduce such dependencies. But this IMO is fruitless work, when ppudump can be incorporated with almost no negative impact into the compiler itself. Don't forget that part of the purpose of ppudump is also to get a second opinion on a PPU file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
On 30 Sep 2010, at 19:21, Hans-Peter Diettrich wrote: Jonas Maebe schrieb: As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? No, because it would be lots of work (writing test programs that trigger all possible error conditions and testing/debugging them one by one, or implementing some kind of mark/release system) with no real payoff except if you're an IDE developer that wants to integrate the compiler. IMO you simply don't understand the reason for my NoGlobals refactoring I indeed probably don't, and certainly not in this context. Especially because the memory leaks above are virtually all caused by *local* variables that are not cleaned up properly in case of an error, while on the contrary most if not all global variables are destroyed/freed under all circumstances. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patches
On 2010-09-30 21:21, Andrew Brunner wrote: 2010/9/30 Ademlistmem...@letterboxes.org: It is only more logical/sensible to bring together all these one-instance global objects into a one-instance global object, instead of having them scattered all around the place. I hope you are joking ... I have read the above sentence (of mine) a few times over; and I seriously cannot see why I should be expected to be joking. Could someone tell me what advantage there can ever be in/of having global variables scattered all around the place. Well, global variables are going to be all over the place and will be declared in the scope of the unit where they are established. So, from what you're saying, I am supposed to think that it is better to declare global variables in 460+ unit files in the compiler directory alone. It establishes their belonging in the unit/module in which they are/were declared :-) ? I think that the assertion of taking variables (just because they are global) and placing them in one unit file is indeed funny. I'll remember this joke when I am writing the next Pascal code and declare my variables not at the top of each class/routine but right where they are needed and all over the place ;) -- Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Op Wed, 29 Sep 2010, schreef Hans-Peter Diettrich: A last note on the NoGlobals branch, and parallel processing in the compiler: A few comments: You seem to be reasoning from theory, and mainly OOP theory. In principle this is good, I have been reasoning from theory in the past as well, and this helped restructuring sections of the compiler, which we have done extensively in the past and I have had my share in this. This improved the robustness of the compiler. In essence your project was good. There are a few remarks to be made: * There are more theories (religions?) about how maintainable programs should be made. For example there is a strong group of programmers who strongly believes there should be no exceptions to type checking. You could have started a refactoring eliminating typecasts rather than elimination globals. There is functional programming theory. Each theory has its merits in it own way, but it would be wrong to say that turning everything OOP would solve all problems or removing all typecasts will necessarily make our life easier. * The Pascal language implemented by FPC is a mixed procedural/OOP language. Procedural programming has its strengths and FPC makes use of the potential to mix procedural and OOP. * Global variables cause problems with parallelization, but that does not mean the choice for a global variable is a bad idea. Variables like current_module is used so extensively that they are prime candidates to be global. In my opinion you have been following the OOP bible a bit too strict here. * OOP was your goal. Your goal should have been parallelization, OOP should have been your tool. There are more tools, like threadvars. It has been said meny times in this discussion: In a compiler there are dependencies between a lot of datastrcutures. Handling this effectively is a challenge. FPC's approach in many places is to put abstract interdependent objects in a single unit, so these objects can use each other wherever they want. We then add functionality in other units that derive from the abstract units. Tsym, Tdef, Tsymtable are in a single unit. All kinds of symbols, definitions, and symbtables have their own unit. I consider this design a strong one, the problem of cyclic dependencies in the compiler is well controllable. It helps maintenance: I know many C++ projects where all .cpp files over time started to include all .h files. In FPC, if you notice you can't access current_module from the current unit, you know you are doing something wrong. You seemed to have trouble with this model, rather than embrace it and use it to your advantage, you started to break things apart and change the dependencies. As expected this caused you a dependency nightmare, introducing what you tried to eliminate with the better design: You wanted clear interfaces between certain parts of the compiler, but you did end up breaking interfaces external tools can use, and fixing them became beyond any hope. The globals unit has its role. Many symbols are there for a good reason. There can be good reason for moving symbols out of it, if you do so, first try to understand why that symbol is there, and avoid changes in unit dependencies at all costs. Above all: You can get far with theory. FPC has a practical and pragmatic code base but I dare to say it has a theoretically sound base design. New theory can be a solution for practical problems but implementation of it requires of new practical compromises to be made. For performance, memory use or historic reasons, or maybe even because the theory can't catch 100% of the possible situations (there are even some goto statements in the compiler). Nevertheless, you have gotten a lot of knowledge of the compiler, and this project makes me optimistic you can become a good compiler developer. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
