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, an
On 2010-09-30 21:21, Andrew Brunner wrote:
2010/9/30 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 sente
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 t
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
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
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,
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:
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 r
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:
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 wor
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
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
Mattias Gärtner 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.
Ehm, are you saying, that the compiler must be restarted when there were
errors, because it does not clean up properly?
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
2010/9/30 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 tim
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 r
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
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 sh
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 thin
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
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 t
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 eve
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 generato
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 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 ma
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, howeve
Zitat von Florian Klaempfl :
Am 30.09.2010 14:15, schrieb Mattias Gärtner:
Zitat von Jonas Maebe :
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 generato
Am 30.09.2010 14:15, schrieb Mattias Gärtner:
> Zitat von Jonas Maebe :
>
>>
>> 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 co
On 30 Sep 2010, at 14:15, Mattias Gärtner wrote:
Zitat von Jonas Maebe :
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.
Zitat von Jonas Maebe :
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 occur
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 irrel
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
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 concer
Zitat von Jonas Maebe :
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 wi
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
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
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 curre
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.
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 memor
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 c
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 Wed, Sep 29, 2010 at 1:17 AM, Hans-Peter Diettrich
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 mult
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 so
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 nic
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, usi
On 30/09/2010, Michael Schnell 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
+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/mail
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
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 com
50 matches
Mail list logo
