Prev: Fedora 12 + Komodo-IDE+debugger=segfault
Next: iso: tcl/tk 8.5.4 or so developers using iwidgets
From: dave.joubert on 10 Mar 2010 10:09
On Mar 10, 2:05 pm, fips <filiberto.silves...(a)hotmail.de> wrote:

> The idea is, as proposed by some in the ng here, to "store" objects
> created by methods where they can easily be found and deleted as
> needed.
Good
> I thought about storing them as child objects in their classes.

Will your proposed solution allow you to write code that looks like
this:

set c1 [Complex 2 2]
set c2 [Complex 2 2]
set c3 [$c1 + $c2]
set c4 [$c2 + [$c3 + $c1]]
set c5 [[$c1 + $c4] + $c2]

If it does not, why should you (as a programmer (not you as a
designer)) have to know that some objects are not 'equal citizens' ?

(Note: having to sugar each variable with a consistent namespace would
not fundamentally change the question, and can in fact improve code
readability.)

Dave
From: fips on 10 Mar 2010 10:44
On 10 Mrz., 16:09, "dave.joub...(a)googlemail.com"
<dave.joub...(a)googlemail.com> wrote:
> On Mar 10, 2:05 pm, fips <filiberto.silves...(a)hotmail.de> wrote:
>
>
>
> > The idea is, as proposed by some in the ng here, to "store" objects
> > created by methods where they can easily be found and deleted as
> > needed.
> Good
> > I thought about storing them as child objects in their classes.
>
> Will your proposed solution allow you to write code that looks like
> this:
>
> set c1 [Complex 2  2]
> set c2 [Complex 2  2]
> set c3 [$c1 + $c2]
> set c4 [$c2 + [$c3 + $c1]]
> set c5 [[$c1 + $c4] + $c2]
>
> If it does not, why should you (as a programmer (not you as a
> designer)) have to know that some objects are not 'equal citizens' ?
>
> (Note: having to sugar each variable with a consistent namespace would
> not fundamentally change the question, and can in fact improve code
> readability.)
>
> Dave

The code will be used like this:

Complex c1 1 3
Complex c2 -2 10
Complex c3 4.5 13.6
Complex c4

c4 assign [[c1 sub c2] add [c3 addNumber 100]]

c1 destroy
c2 destroy
c3 destroy
c4 destroy

gc

Here, I supposed to have methods similar to "add":
- "sub" to subtract complex numbers
- "addNumber" to add a complex number to a scalar number
- "assign" to assign the value of a complex number to another complex
number
The whole complex number thing is only an example.

As I like symmetries in code, I'd like to see the "destroys" in equal
number to the "inits" for each class. Maybe this is due to my C/C++
background...

Anyway, to delete the "temporaries" created by the methods, calling a
garbage collector method like "gc" will free the memory not needed
anymore.

The call to "gc" does not necessarily have to occur at the "end of a
program". Think of a server program intended to run for an indefinite
period of time. If this program creates "temporaries" continuously,
without garbage collection there will be an out of memory problem
sooner or later.

By the way, I found that there is no need to store the temporaries as
children of a class. If they are created with a naming convention,
e.g. by using "new", they can easily be found and recognized simply by
walking through the instances of a class.


From: stefan on 11 Mar 2010 04:57
> The call to "gc" does not necessarily have to occur at the "end of a
> program". Think of a server program intended to run for an indefinite
> period of time. If this program creates "temporaries" continuously,
> without garbage collection there will be an out of memory problem
> sooner or later.

this is certainly an important requirement, but there is hardly a
general-purpose solution. rather, it requires application-specific
deletion procedures. for instance, there is active development of
XOTcl components for AOLServer and Naviserver, which provide worker
thread pools for connection and request handling. the thread pools
realise particular lifecycle models for the managed threads. Each
thread and the embedded Tcl interpreter go through certain
lifestages (cleanup, idleness, wakeup etc.). each stage is marked by
signalling events (e.g., cleanup) with application components being
registered as event handlers. For XOTcl objects, there is a
special-purpose destroy_on_cleanup() marker which registers the
receiving object for cleanup upon the thread and its Tcl interpreter
entering their cleanup stages.

see destroy_on_cleanup() and at_cleanup() in
http://fisheye.openacs.org/browse/OpenACS/openacs-4/packages/xotcl-core/tcl/01-debug-procs.tcl?r=HEAD

> By the way, I found that there is no need to store the temporaries as
> children of a class. If they are created with a naming convention,
> e.g. by using "new", they can easily be found and recognized simply by
> walking through the instances of a class.

indeed, introspection helps here, yet sometimes it is more convenient
(i.e., a finer-grained control) to allow each object to register for
deletion explicitly rather than have it deleted due to its structural
relationships (is-a, ...).

a final remark regarding volatile() in XOTcl: You can declare an
object volatile at any time, you are not restricted to its creation
time:

Class create Complex -parameter {real imag}
Complex instproc + {aComplex} {
my instvar real imag
set resultReal [expr { $real + [$aComplex real] }]
set resultImag [expr { $imag + [$aComplex imag] }]
set result [Complex new \
-real $resultReal \
-imag $resultImag]
return $result
}

Complex instproc foo {} {
Complex c1 -real 2 -imag 2
Complex c2 -real 2 -imag 2
set c3 [c1 + c2]
# !!! declare volatile !!!
$c3 volatile
# !!!!!!!!!!!!!!!!!!!!!!!!
puts stderr [$c3 imag]; # returns '4'
puts stderr [$c3 real]; # returns '4'
return $c3
}

set c3 [[Complex new] foo]
puts stderr [$c3 imag]; # FAILS! object behind c3 has been pruned
after leaving foo()
From: Donal K. Fellows on 11 Mar 2010 09:53
On 11 Mar, 09:57, stefan <stefan.sober...(a)wu.ac.at> wrote:
> a final remark regarding volatile() in XOTcl: You can declare an
> object volatile at any time, you are not restricted to its creation
> time:

What I'd like to see from these "volatile" schemes is for there to be
a way to say "I want to expand the scope of the volatility". For
example, to be able to do this:

set o [FooBar new]
$o volatile
# ... blah ...
# Discover that we want the caller's lifetime to manage instead
$o return

In that case, it would be like [return $o] except that it also adjusts
the volatility scope too. If volatility is implemented with an unset
trace on a local variable in the caller's scope - which is how I'd do
it - then this is just a matter of changing the registration so it is
instead registered on the variable in the caller's caller's scope, and
then a two-level return. Which sounds more complex than it really
is. :-) I've not looked how XOTcl does it, but it seems that this
would be something that could be done with little effort if you're
doing stuff in the "lazy simple sensible way".

Donal.
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Fedora 12 + Komodo-IDE+debugger=segfault
Next: iso: tcl/tk 8.5.4 or so developers using iwidgets