> You can finalize it, so that it releases all private resources. That's
> common practice in a GC environment. But then you are responsible when
> the interfaced object is referenced from one of the still remaining
> references, and it fails to act properly due to the missing resources.
I wish I
>> Why are you looking at GC/Refcounting when the problem is the
>> try..finally?
>> It is better to rewrite the try..finally code using the C++ ABI for
>> exception handling.
>
> Where do you see improvements in the C++ ABI? Or even differences?
>
> Windows implements this ABI, and every language
Jamie McCracken wrote:
> Rather than continuing the GC stuff which seems fruitless I thought it
> might be better to improve what we have with ref counting (whilst taking
> a leaf out of the GC book as well).
A reasonable attempt.
> 2) Have a single linked list that contains references to all m
Uberto Barbini wrote:
> > You already have them in Iunknown, ansistrings and variants. Its all a
> > question of making them faster cause they are dog slow atm.
>
> I wish them "NOT" managed, you cannot free a interface in Delphi.
You can finalize it, so that it releases all private resources. T
Peter Vreman wrote:
> Why are you looking at GC/Refcounting when the problem is the try..finally?
> It is better to rewrite the try..finally code using the C++ ABI for
> exception handling.
Where do you see improvements in the C++ ABI? Or even differences?
Windows implements this ABI, and every
peter green wrote:
> one thing i have heared (i don't use garbage collected languages much so
> i've never seen this myself) is that the GC gets some CPU time and starts
> causing stuff to be swapped in. This slows other threads down which gives
> the GC more CPU and causes more stuff to be swappe
Jamie McCracken wrote:
> The problem with GC is the lifetime of (dead) objects is significantly
> extended under GC. This means it hogs more memory for much longer.
> Memory allocation is also potentially slowed as a result of more objects
> remaining allocated on the heap so less chance of holes
[EMAIL PROTECTED] wrote:
> At work, we have a plugin system which cannot work unless packages are used.
Agreed.
> I also think that Lazarus would benefit from it.
Currently Lazarus must be rebuilt for the installation of custom
controls, which in Delphi can be loaded dynamically. If this behav
05-02-27 19.28, skrev Marco van de Voort följande:
>>> Thats a possibility, but then you do not win anything by running it in a
>>> thread. It could as well be run when a memory allocation is done, and then
>>> as a subroutine.
>>
>> No, because the background thread get more time slices during i
05-02-27 19.16, skrev Uberto Barbini följande:
>> Thats a possibility, but then you do not win anything by running it in a
>> thread. It could as well be run when a memory allocation is done, and then
>> as a subroutine.
>
> No, because the background thread get more time slices during idle momen
Joost van der Sluis wrote:
Hi all,
I tried to compile lazarus(cvs) with 1.9.9 and got this error:
lclproc.pas(832,8) Error: Illegal type conversion: "Text" to ""
on this line:
if TextRec(Output).Mode=fmClosed then
Mode and fmClosed are integers. Can anyone help me with this? (1.9.8
works fine)
> >>Why are you looking at GC/Refcounting when the problem is the
> >> try..finally? It is better to rewrite the try..finally code using the
> >> C++ ABI for exception handling.
> >
> > +1
> > and it'd be benefical to all applications.
>
> Using the C++ ABI the overhead is almost zero.
Out of curi
Uberto Barbini wrote:
On Sunday 27 February 2005 15:29, Peter Vreman wrote:
Why are you looking at GC/Refcounting when the problem is the try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
+1
and it'd be benefical to all applications.
Using the C+
Hi all,
I tried to compile lazarus(cvs) with 1.9.9 and got this error:
lclproc.pas(832,8) Error: Illegal type conversion: "Text" to ""
on this line:
if TextRec(Output).Mode=fmClosed then
Mode and fmClosed are integers. Can anyone help me with this? (1.9.8
works fine)
--
Met vriendelijke
> > Thats a possibility, but then you do not win anything by running it in a
> > thread. It could as well be run when a memory allocation is done, and then
> > as a subroutine.
>
> No, because the background thread get more time slices during idle moments
> and
> none at all during intense compu
> Thats a possibility, but then you do not win anything by running it in a
> thread. It could as well be run when a memory allocation is done, and then
> as a subroutine.
No, because the background thread get more time slices during idle moments and
none at all during intense computations.
GC hav
05-02-27 14.23, skrev Uberto Barbini följande:
>> Afaik the simplest GC's need to have exclusive access to the heap and
>> stack, so it cant be run in parallell with ordinary processing.
>
> What you mean with parallell? I imagine that it's protected into a critical
> section.
Thats a possibilit
> > I almost finished the porting of the core part of IO to fpc.
>
> I am *very* interested in seeing this working :)
Nice to know! ;)
> > I added bugs for the (few) function I had to rewrite or modify passing
> > from Delphi to fpc.
> >
> > Anyway I'm still in trouble with streams.
> > IO use de
On Sun, 27 Feb 2005, Uberto Barbini wrote:
> I almost finished the porting of the core part of IO to fpc.
I am *very* interested in seeing this working :)
>
> I added bugs for the (few) function I had to rewrite or modify passing from
> Delphi to fpc.
>
> Anyway I'm still in trouble with st
I almost finished the porting of the core part of IO to fpc.
I added bugs for the (few) function I had to rewrite or modify passing from
Delphi to fpc.
Anyway I'm still in trouble with streams.
IO use descendants of TRead and TWrite like files.
It goes back when an error rises and it needs readi
On Sunday 27 February 2005 15:29, Peter Vreman wrote:
> Why are you looking at GC/Refcounting when the problem is the try..finally?
> It is better to rewrite the try..finally code using the C++ ABI for
> exception handling.
+1
and it'd be benefical to all applications.
Bye Uberto
___
At 12:35 27-2-2005, you wrote:
Hi,
Rather than continuing the GC stuff which seems fruitless I thought it
might be better to improve what we have with ref counting (whilst taking a
leaf out of the GC book as well).
I note that ref counting is very fast without all the implicit
try..finally stuf
[ Charset ISO-8859-1 unsupported, converting... ]
> Marco van de Voort wrote:
> >>circular refs should also be done if applicable)
> >>6) Whenever an exception is thrown, wait until its either handled or
> >>fully propagated and then perform some garbage collection. (traverse the
> >>single linke
> Marco van de Voort wrote:
> >>>a valid/invalid reference without accessing memory that is invalid in the
> >>>mean
> >>>time.
> >>
> >>How does a GC do this? It would have the same problem?
> >
> >
> > A GC manages all memory, local variable allocation inclusive. IOW, the
> > way a GC does it,
> Afaik the simplest GC's need to have exclusive access to the heap and
> stack, so it cant be run in parallell with ordinary processing.
What you mean with parallell? I imagine that it's protected into a critical
section.
Anyway I'm not a GC expert but there's tons of stuff on GC theories and al
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether any
05-02-27 13.47, skrev Uberto Barbini följande:
>> A GC needs to trace an object's references to see if anything still
>> points to it. How else can it decide whether an object is no longer in use?
>
> Yes, this is right, but it hasn't to decide if reference are valid or invalid.
> Moreover also t
> A more simplictic alternative could be to have objects (declared to be
> managed) managed in the same way as ansistrings.
This is exactly what delphi do with interfaces, the result is an orrible mess,
and passing them as parameters a nightmare.
Refcounted objects are possible, python used them
05-02-27 12.35, skrev Jamie McCracken följande:
> Hi,
>
> Rather than continuing the GC stuff which seems fruitless I thought it
> might be better to improve what we have with ref counting (whilst taking
> a leaf out of the GC book as well).
A more simplictic alternative could be to have objects
> A GC needs to trace an object's references to see if anything still
> points to it. How else can it decide whether an object is no longer in use?
Yes, this is right, but it hasn't to decide if reference are valid or invalid.
Moreover also the simpliest GC techniques (mark'n'swift) are quite slow
Uberto Barbini wrote:
I also thought immediately what Uberto already said: how do you recognize
a valid/invalid reference without accessing memory that is invalid in the
mean time.
How does a GC do this? It would have the same problem?
A GC dont' try to recognize a valid/invalid reference, it is i
> > I also thought immediately what Uberto already said: how do you recognize
> > a valid/invalid reference without accessing memory that is invalid in the
> > mean time.
>
> How does a GC do this? It would have the same problem?
A GC dont' try to recognize a valid/invalid reference, it is invoked
Marco van de Voort wrote:
a valid/invalid reference without accessing memory that is invalid in the mean
time.
How does a GC do this? It would have the same problem?
A GC manages all memory, local variable allocation inclusive. IOW, the
way a GC does it, is not possible in a mixed environment.
Are
> > a valid/invalid reference without accessing memory that is invalid in the
> > mean
> > time.
>
> How does a GC do this? It would have the same problem?
A GC manages all memory, local variable allocation inclusive. IOW, the
way a GC does it, is not possible in a mixed environment.
> > Also
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether any
Uberto Barbini wrote:
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether anything that references it is still valid and delete if
ap
> circular refs should also be done if applicable)
> 6) Whenever an exception is thrown, wait until its either handled or
> fully propagated and then perform some garbage collection. (traverse the
> single linked list of all managed objects and for each object check
> whether anything that refer
> 6) Whenever an exception is thrown, wait until its either handled or
> fully propagated and then perform some garbage collection. (traverse the
> single linked list of all managed objects and for each object check
> whether anything that references it is still valid and delete if
> appropriate).
Hi,
Rather than continuing the GC stuff which seems fruitless I thought it
might be better to improve what we have with ref counting (whilst taking
a leaf out of the GC book as well).
I note that ref counting is very fast without all the implicit
try..finally stuff so I was wondering if it was
DrDiettrich wrote:
Jamie McCracken wrote:
GC is very inefficient with memory and current implementations tend to
cost a lot performance wise too.
I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Reference cou
- Original Message -
From: <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Saturday, February 26, 2005 12:05 PM
Subject: Re: [fpc-devel] dynamic package support
On Sat, 26 Feb 2005, Florian Klaempfl wrote:
> Hans-JÃrg Vasold wrote:
>
> > for a long time support for loading packages
41 matches
Mail list logo
