Hi Alex,
Fantastic language (Picolisp) and very, very useful port to Android.

On Thu, Aug 24, 2023, at 2:15 PM, Alexander Burger wrote:

> Is this is really the cause of the problem? Most java calls do not make a new
> object each time, and stored in the hash map are not all involved objects, but
> only those which are reflected back to Lisp (and not all created internally).

TBH,  most of my troubles came from using the Android JSON library (which 
requires me to explicitly create the Java objects to add) and I do plan to move 
to a pure Picolisp implementation.  But it did get me thinking about everywhere 
I instantiate a Java object via  (java "classname" T).  

> The objects in the hash map are indeed never removed. This would be difficult 
> to
> implement, because the Java side has no information about which objects are
> still in use on the Lisp side.

I'm pushing PilBox to the limits of (probably) what you intended: I want to run 
a minimal UI background service that scans BLE.  It works well, but I'd like to 
keep track of the Java objects, even if done explicitly.  With that said, there 
are occasionally instantiated objects I'd like to keep track of and don't mind 
house cleaning.  I could even imagine instrumenting something handled in catch 
clauses or loop/function exit situations.

I just need access to that hashtable.  

> Perhaps we can come up with ideas how to improve the situation.

Perhaps something like:
(java NIL 'obj) for removing it from the hashtable? The "complex management" of 
this could then be handled in pure Picolisp...

Would it be as simple as something like (in Reflector.java  reflect()):
               if (y == InOut.Nil) {                       // Release reference 
to Object
                   Object o = lst[1];                              // object to 
                   int idx  = o.hashCode();
                   x = null;
Or am I heading in the wrong direction?


UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to