Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #30455 > unrolled thread

Implementing TCL/CCI commands in JavaTCL

Started bynataraja.3.833@gmail.com
First post2014-11-29 23:54 -0800
Last post2014-11-30 21:44 -0800
Articles 3 — 3 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  Implementing TCL/CCI commands in JavaTCL nataraja.3.833@gmail.com - 2014-11-29 23:54 -0800
    Re: Implementing TCL/CCI commands in JavaTCL Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-11-30 17:40 +0000
      Re: Implementing TCL/CCI commands in JavaTCL nataraja gadikota <nataraja.3.833@gmail.com> - 2014-11-30 21:44 -0800

#30455 — Implementing TCL/CCI commands in JavaTCL

Fromnataraja.3.833@gmail.com
Date2014-11-29 23:54 -0800
SubjectImplementing TCL/CCI commands in JavaTCL
Message-ID<91e0be65-71fb-4bbd-a509-0a0a8bf22f84@googlegroups.com>
I'm trying to implement CCI ( common command interface ) using collections as in Synposis TCL-EDA suite ( http://www.eda.org/edps/edp04/submissions/presentationDwight2.pdf) 

I'm not able to think of proper memory management while using CCI , 
let me give an example 

## sizeof_collection will return the collection size ( integer ) 
dc_shell> sizeof_collection [get_cells reset_port*] 
4 

## get_cells will return a pointer to a collection , actually it is an index of a collection list 
dc_shell> get_cells reset_port* 
0x10 

## below command will give error as CCI engine has free'd up memory ( no references pointing to collection ) 
dc_shell>sizeof_collection 0x10 
TCL ERROR 

## now set the collection to a variable , collection pointer increments by one . 
dc_shell> set a [get_cells reset_port*] 
0x11 

## Now the sizeof_collection returns correct value , i.e collection is still in memory 
dc_shell> sizeof_collection $a 
4 
dc_shell>puts $a 
0x11 

## Even in this case sizeof_collection returns the correct value , as it has reference ( pointed by variable "a" ) 
dc_shell > sizeof_collection 0x11 
4 

### Clear reference pointer 
dc_shell > set a "" 

## Now we will get error , as the reference from a has been removed !! 
dc_shell > sizeof_collection 0x11 
TCL ERROR 

Can you tell me know to keep track of TCL_Object and 
free resources when there are no references pointing to them . 

and I'm using TCL-Java where garbage collection is been done by Java.GC 
this is another headache ! 

Jacl Page : http://wiki.tcl.tk/1637

Regards 
Nataraja G 

[toc] | [next] | [standalone]


#30458

FromAndreas Leitgeb <avl@auth.logic.tuwien.ac.at>
Date2014-11-30 17:40 +0000
Message-ID<slrnm7mllg.uoi.avl@login.logic.tuwien.ac.at>
In reply to#30455
Although the topic involves both Tcl and Java, I think
  comp.lang.tcl
might have been the better group for this question.

nataraja.3.833@gmail.com <nataraja.3.833@gmail.com> wrote:
> dc_shell> set a [get_cells reset_port*] ;# -> 0x11 
> dc_shell > sizeof_collection 0x11       ;# -> ok
> dc_shell > set a "" 
> dc_shell > sizeof_collection 0x11       ;# -> TCL ERROR 

Something seems to explicitly tie lifetime of the collection
to the lifetime of that one particular "0x11" instance returned
from "get_cells".

That's just outright ugly design of CCI.

> Can you tell me know to keep track of TCL_Object and 
> free resources when there are no references pointing to them . 

It's not completely clear to me, what you really want.

There was a reference stored in variable a, and once that's gone, the
collection is gone.  (This is not following Tcl-design, but seems to
work sufficiently well on sunny days...)

The real problem seems to be the condition: "when no refs point to them",
as for some time any newly generated "0x11" string could be considered a
reference, but if the one originally saved away is freed, then all others
turn stale. An ugly consequence of CCI's ugly design.

If you ignore this detail of creating new "pseudo"-references, and
just copied the value $a to every "user", you should just get what
you seem to be asking for.

> and I'm using TCL-Java where garbage collection is been done by Java.GC 
> this is another headache ! 

Tcl_Objects "cannot" have loops in their referencial paths,
because by design they're immutable. That makes explicit 
refcounting a good approach in native Tcl, whereas the Java
based implementation of Tcl has dropped the ref-counter and just
leaves it to the JVM to collect the garbage. Either way, unused
Objects get collected sooner(refcount) or later(GC).

[toc] | [prev] | [next] | [standalone]


#30459

Fromnataraja gadikota <nataraja.3.833@gmail.com>
Date2014-11-30 21:44 -0800
Message-ID<f2f2a0e0-90c8-4ccc-b558-4725d17ffaba@googlegroups.com>
In reply to#30458
Hi Andreas , 
     Yes I've posted this on comp.lang.tcl too , 
I didn't know where TclJava Authors will hangout so ..
https://groups.google.com/forum/#!topic/comp.lang.tcl/wd0EWIopNYE

>>It's not completely clear to me, what you really want.
Backend I'm implementing CCI like below .

// Golbal Variable 
hashMap<String,ArrayList<objects> collectionList ; 
ArrayList<my_objects> collectionObjects; 
collectionObjects = new ArrayList<my_objects>() ; 
collectionList.put(0x11,collectionObjects); 

#set a ""  or
#when varaible 'a' is set to different collection . 
#I've to remove this pair
collectionList.delete(0x11); 

and then "collectionObjects" will be GC 
my problem is how to trace this .

Initial I thought of overriding var.SetVar method but this was defined as final , so went into TCLJava code and to  my suprise saw more than 10 variants of setVar function in Var.java !!
I was not able to add proper hooks , so here I'm .

Thanks
Nataraja G

On Sunday, 30 November 2014 23:11:14 UTC+5:30, Andreas Leitgeb  wrote:
> Although the topic involves both Tcl and Java, I think
>   comp.lang.tcl
> might have been the better group for this question.
> 
> > dc_shell> set a [get_cells reset_port*] ;# -> 0x11 
> > dc_shell > sizeof_collection 0x11       ;# -> ok
> > dc_shell > set a "" 
> > dc_shell > sizeof_collection 0x11       ;# -> TCL ERROR 
> 
> Something seems to explicitly tie lifetime of the collection
> to the lifetime of that one particular "0x11" instance returned
> from "get_cells".
> 
> That's just outright ugly design of CCI.
> 
> > Can you tell me know to keep track of TCL_Object and 
> > free resources when there are no references pointing to them . 
> 
> It's not completely clear to me, what you really want.
> 
> There was a reference stored in variable a, and once that's gone, the
> collection is gone.  (This is not following Tcl-design, but seems to
> work sufficiently well on sunny days...)
> 
> The real problem seems to be the condition: "when no refs point to them",
> as for some time any newly generated "0x11" string could be considered a
> reference, but if the one originally saved away is freed, then all others
> turn stale. An ugly consequence of CCI's ugly design.
> 
> If you ignore this detail of creating new "pseudo"-references, and
> just copied the value $a to every "user", you should just get what
> you seem to be asking for.
> 
> > and I'm using TCL-Java where garbage collection is been done by Java.GC 
> > this is another headache ! 
> 
> Tcl_Objects "cannot" have loops in their referencial paths,
> because by design they're immutable. That makes explicit 
> refcounting a good approach in native Tcl, whereas the Java
> based implementation of Tcl has dropped the ref-counter and just
> leaves it to the JVM to collect the garbage. Either way, unused
> Objects get collected sooner(refcount) or later(GC).

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web