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
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
+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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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,
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
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
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
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 ...
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,
46 matches
Mail list logo
