Daniël Mantione schrieb:
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.
Right, paradigms are somewhat religious. But as with every religion, I
only believe what matches my own exper
Florian Klämpfl schrieb:
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. Ne
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 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 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
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
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
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: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
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
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
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
Op 2010-09-29 23:50, Mattias Gaertner het geskryf:
>
> While touching the fpc sources I often got a compile
> error which was "fixed" by compiling a second time.
> Is this normal?
I get a similar problem with FPC 2.4.3 and fpGUI. fpGUI is in a Lazarus
package, so compiled units are in a single lo
At 11:04 AM 9/29/2010, Florian Klämpfl wrote:
Am 29.09.2010 19:57, schrieb Michael Van Canneyt:
>
> Only 5% open bugs ? That's not bad. At work it's much worse.
Problem is imo: the open ones are the time consuming. And imo over time
the absolute number of open bugs should at least stay stable a
Mattias Gaertner schrieb:
While touching the fpc sources I often got a compile
error which was "fixed" by compiling a second time.
Is this normal?
Sometimes I get very strange error messages, about types that are not
used in the indicated locations.
There exist more possible problems, with
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, and preven
On Wed, 29 Sep 2010 23:59:15 +0200
Jonas Maebe wrote:
>
> On 29 Sep 2010, at 23:50, Mattias Gaertner wrote:
>
> > While touching the fpc sources I often got a compile
> > error which was "fixed" by compiling a second time.
> > Is this normal?
>
> There are some bugs in the ppu loading logic (m
On 29 Sep 2010, at 23:50, Mattias Gaertner wrote:
> While touching the fpc sources I often got a compile
> error which was "fixed" by compiling a second time.
> Is this normal?
There are some bugs in the ppu loading logic (mostly related to "inline" in
combination with cyclic dependencies) that
On Wed, 29 Sep 2010 22:34:18 +0200
Florian Klämpfl wrote:
>[...]
> > 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 si
Am 29.09.2010 22:05, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
>>> too much supported platforms and
>>> features and too few developers working on bug fixing.
>>
>> Just as a side node, development of open bugs during the last years:
>> summary_graph_cumulative_bydate.php.png
>
>
Florian Klämpfl schrieb:
too much supported platforms and
features and too few developers working on bug fixing.
Just as a side node, development of open bugs during the last years:
summary_graph_cumulative_bydate.php.png
This situation could be improved by an OO rewrite - better
modulariza
On Wed, 29 Sep 2010, Florian Klämpfl wrote:
Am 29.09.2010 19:57, schrieb Michael Van Canneyt:
On Wed, 29 Sep 2010, Florian Klämpfl wrote:
Am 29.09.2010 19:49, schrieb Florian Klämpfl:
Am 29.09.2010 19:42, schrieb Florian Klämpfl:
too much supported platforms and
features and too few dev
Am 29.09.2010 19:57, schrieb Michael Van Canneyt:
>
>
> On Wed, 29 Sep 2010, Florian Klämpfl wrote:
>
>> Am 29.09.2010 19:49, schrieb Florian Klämpfl:
>>> Am 29.09.2010 19:42, schrieb Florian Klämpfl:
too much supported platforms and
features and too few developers working on bug fixin
On Wed, 29 Sep 2010, Florian Klämpfl wrote:
Am 29.09.2010 19:49, schrieb Florian Klämpfl:
Am 29.09.2010 19:42, schrieb Florian Klämpfl:
too much supported platforms and
features and too few developers working on bug fixing.
Just as a side node, development of open bugs during the last year
Am 29.09.2010 19:49, schrieb Florian Klämpfl:
> Am 29.09.2010 19:42, schrieb Florian Klämpfl:
>> too much supported platforms and
>> features and too few developers working on bug fixing.
>
> Just as a side node, development of open bugs during the last years:
> summary_graph_cumulative_bydate.php
Am 29.09.2010 19:42, schrieb Florian Klämpfl:
> too much supported platforms and
> features and too few developers working on bug fixing.
Just as a side node, development of open bugs during the last years:
summary_graph_cumulative_bydate.php.png
___
fpc
Am 29.09.2010 17:26, schrieb Alexander Klenin:
> On Thu, Sep 30, 2010 at 00:05, Hans-Peter Diettrich
> wrote:
>> Florian Klaempfl schrieb:
Now I'll resume my original work on multiple front-ends, this time using
a git repository
>>>
>>> Well, I wonder what the advantage of this will be,
On Thu, Sep 30, 2010 at 00:05, Hans-Peter Diettrich
wrote:
> Florian Klaempfl schrieb:
>>> Now I'll resume my original work on multiple front-ends, this time using
>>> a git repository
>>
>> Well, I wonder what the advantage of this will be, besides that there
>> will be not feedback possible on t
Florian Klaempfl schrieb:
Am 29.09.2010 01:17, schrieb Hans-Peter Diettrich:
A last note on the NoGlobals branch, and parallel processing in the
compiler:
I couldn't find any way to move global variables from globals.pas into
e.g. fmodule (tmodule, current_module), without breaking ppudump
depe
Adem schrieb:
I couldn't find any way to move global variables from globals.pas into
e.g. fmodule (tmodule, current_module), without breaking ppudump
dependencies.
I suspect you have thought about this, but let me try anyway.
If globals.pas is where twins are conjoined (think of Siamese twin
Am 29.09.2010 01:17, schrieb Hans-Peter Diettrich:
> A last note on the NoGlobals branch, and parallel processing in the
> compiler:
>
> I couldn't find any way to move global variables from globals.pas into
> e.g. fmodule (tmodule, current_module), without breaking ppudump
> dependencies. As long
On 2010-09-29 02:17, Hans-Peter Diettrich wrote:
I couldn't find any way to move global variables from globals.pas into
e.g. fmodule (tmodule, current_module), without breaking ppudump
dependencies.
I suspect you have thought about this, but let me try anyway.
If globals.pas is where twins a
51 matches
Mail list logo
