Paul Ishenin schrieb:
For some reason the visibility is completely ignored here. I can add a
class helper to the strict private or even move it to another unit - it
is always visible.
IMO class helper methods always should become visible as part of the
class, regardless of where they are dec
On 30.01.2011 09:03, Hans-Peter Diettrich wrote:
Paul Ishenin schrieb:
For some reason the visibility is completely ignored here. I can add a
class helper to the strict private or even move it to another unit -
it is always visible.
IMO class helper methods always should become visible as par
On 30.01.2011 04:30, Paul Ishenin wrote:
30.01.2011 5:22, Sven Barth wrote:
Ok, I have now implemented a set of flags in TSymtable of which one is
set when the (global-,static-)symtable contains a class helper (I
haven't refactored b_needs_init_final yet).
Here are the new results with the sear
30.01.2011 15:45, Sven Barth wrote:
Imo it works much better now.
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
2m22.980s -
2m15.362s =
0m7.xxxs - were is a minute?
How often is the compiler compiled completly during a make c
On 30.01.2011 09:55, Paul Ishenin wrote:
30.01.2011 15:45, Sven Barth wrote:
Imo it works much better now.
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
2m22.980s -
2m15.362s =
0m7.xxxs - were is a minute?
That was two runs o
On 29.01.2011 23:22, Sven Barth wrote:
Ok, I have now implemented a set of flags in TSymtable of which one is
set when the (global-,static-)symtable contains a class helper (I
haven't refactored b_needs_init_final yet).
I have commited the changes now as well (I was too tired yesterday), so
pl
30.01.2011 16:22, Sven Barth wrote:
I have commited the changes now as well (I was too tired yesterday),
so please fell free to critize them (especially the ones in ppudump)
as I need to build on on these changes regarding b_needs_init_final
(or should this wait until everything is merged back
30.01.2011 16:22, Sven Barth wrote:
I have commited the changes now as well (I was too tired yesterday),
so please fell free to critize them (especially the ones in ppudump).
Why do you need ibsymtableoptions ?
Best regards,
Paul Ishenin
___
fpc-devel
On 30.01.2011 11:30, Paul Ishenin wrote:
30.01.2011 16:22, Sven Barth wrote:
I have commited the changes now as well (I was too tired yesterday),
so please fell free to critize them (especially the ones in ppudump).
Why do you need ibsymtableoptions ?
tstoredsymtable stores only definitions a
On 30 Jan 2011, at 09:45, Sven Barth wrote:
> Only one minute slower in the complete run instead of four. I let you guys
> decide whether this is good enough ^^
It's still a lot of overhead.
An alternative solution could be to add a hashtable (tfphaslist) to tmodule
whose entries are hashed o
Am 29.01.2011 23:22, schrieb Sven Barth:
>
> Here are the new results with the search for class helpers enabled (only
> two runs this time):
>
> Run 1:
> real2m22.980s
> user0m47.140s
> sys0m4.333s
>
> Run 2:
> real2m15.362s
> user0m47.274s
> sys0m4.140s
With which times
Am 30.01.2011 09:45, schrieb Sven Barth:
> On 30.01.2011 04:30, Paul Ishenin wrote:
>> 30.01.2011 5:22, Sven Barth wrote:
>>> Ok, I have now implemented a set of flags in TSymtable of which one is
>>> set when the (global-,static-)symtable contains a class helper (I
>>> haven't refactored b_needs_i
On 30.01.2011 12:13, Florian Klämpfl wrote:
Am 30.01.2011 09:45, schrieb Sven Barth:
On 30.01.2011 04:30, Paul Ishenin wrote:
30.01.2011 5:22, Sven Barth wrote:
Ok, I have now implemented a set of flags in TSymtable of which one is
set when the (global-,static-)symtable contains a class helper
On 30.01.2011 12:06, Jonas Maebe wrote:
On 30 Jan 2011, at 09:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you guys
decide whether this is good enough ^^
It's still a lot of overhead.
Yes and that's why I'm thankful for every suggestion I can ge
30.01.2011 15:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
How often is the compiler compiled completly during a make cycle?
I still see an ability to optimize your implementation.
procedure update
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
>
> Actually I think anything about a ten percent slower compiler will
> people make cry ... And as far as I understand, for projects with a lot
> of units it will be even worse, right?
>
I cry if FPC doesn't compile at least ten percent *
Am 30.01.2011 12:37, schrieb Martin Schreiber:
> On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
>>
>> Actually I think anything about a ten percent slower compiler will
>> people make cry ... And as far as I understand, for projects with a lot
>> of units it will be even worse, right?
On 30 Jan 2011, at 12:37, Martin Schreiber wrote:
> I cry if FPC doesn't compile at least ten percent *faster* than the previous
> release...
At least on Mac OS X/i386, we are pretty close to that currently as far as
compiling the compiler with itself is concerned:
* Compiling it with 2.4.2:
On 30.01.2011 13:11, Florian Klämpfl wrote:
Am 30.01.2011 12:37, schrieb Martin Schreiber:
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
Actually I think anything about a ten percent slower compiler will
people make cry ... And as far as I understand, for projects with a lot
of u
On 30.01.2011 12:36, Paul Ishenin wrote:
30.01.2011 15:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
How often is the compiler compiled completly during a make cycle?
I still see an ability to optimize you
In our previous episode, Sven Barth said:
> >>>
> >>> Actually I think anything about a ten percent slower compiler will
> >>> people make cry ... And as far as I understand, for projects with a lot
> >>> of units it will be even worse, right?
> >>>
> >> I cry if FPC doesn't compile at least ten pe
current trunk doesn't build. fails on pxlib
- make clean
- make all
- make zipinstall
Platform i-386-win32
OS XP sp3
Bootstrap 2.4.2
---
make[3]: Entering directory `C:/FPC/2.5.1/packages/pxlib'
make all LINKSMART=1 CREATESMART=1
make[4]: Entering directory `C:/FPC/2.5.1/packages/pxlib'
C:
30.01.2011 19:41, Sven Barth wrote:
procedure update_unit_symtable_options;
var
st: tsymtable;
begin
st:=owner;
while not(st.symtabletype in [globalsymtable,staticsymtable]) do
st:=st.defowner.owner;
if objecttype in [odt_classhelper,odt_objccategory] then
include(st.tableoptions,sto_has_classhe
On 30.01.2011 15:10, Paul Ishenin wrote:
30.01.2011 19:41, Sven Barth wrote:
procedure update_unit_symtable_options;
var
st: tsymtable;
begin
st:=owner;
while not(st.symtabletype in [globalsymtable,staticsymtable]) do
st:=st.defowner.owner;
if objecttype in [odt_classhelper,odt_objccategory] th
31.01.2011 0:26, Sven Barth wrote:
Timings without that change:
Run 1:
real1m3.461s
user0m45.957s
sys0m4.590s
Timings with that change:
Run 1:
real1m8.919s
user0m46.597s
sys0m4.166s
But previously you gave 2 minutes values.
Best regards,
Paul Ishenin
__
Sven Barth schrieb:
Sorry, I don't understand what you want to tell here.
Sorry2, I'll retry.
I personally expect a class helper that is defined inside a private
section of a class not to be available in another unit like I can't
access a field or another type defined in there as well.
De
Jonas Maebe schrieb:
An alternative solution could be to add a hashtable (tfphaslist) to
tmodule whose entries are hashed on the qualified class names
(unit$classname, since different units can contain classes with the
same name). The value of such an entry would a tfpobjectlist of class
helpers
On 31-1-2011 2:06, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
Is the hashtable *really* rebuilt with every push and pop of another
symtable? It would be much easier to have a hashtable per symtable,
that deserves no further modifications. When all hashtables use the
same hash algorithm
Am Montag, 31. Januar 2011 00:57 schrieb Paul Ishenin:
> 31.01.2011 0:26, Sven Barth wrote:
> > Timings without that change:
> >
> > Run 1:
> >
> > real1m3.461s
> > user0m45.957s
> > sys0m4.590s
> >
> > Timings with that change:
> >
> > Run 1:
> >
> > real1m8.919s
> > user0m46.5
29 matches
Mail list logo