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
release
int idx = o.hashCode();
InOut.Obj.remove(idx);
Io.Out.write(InOut.NIX);
Io.Out.write(InOut.NIX);
x = null;
Or am I heading in the wrong direction?
/todd
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
