mattyb149 / clojure-jsr223

Automatically exported from code.google.com/p/clojure-jsr223
0 stars 0 forks source link

Clearing out ScriptEngine context of variables and attributes. #2

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Get ScriptEngine instance from ScriptEngineManager
2. Evaluate '(def a #(+ 1 2 3))'
3. Evaluate '(a)' -> '6'
4. Clear out bindings or set ScriptContext to new script context.
5. Evaluate '(a)' -> '6' - Should be non existent.

What is the expected output? What do you see instead?
The above produces an output of '6', when it should complain that there is
no variable named 'a'.

What version of the product are you using? On what operating system?
Released on Nov, 2009. On Mac OS X, Java 6.

Please provide any additional information below.
I'm not sure how to get a new "clean" instance of the script engine. If I
try to grab a "new" script engine it seems to return the same instance.

Original issue reported on code.google.com by elbe...@gmail.com on 3 May 2010 at 11:59

GoogleCodeExporter commented 8 years ago

Original comment by abm221...@gmail.com on 4 May 2010 at 3:28

GoogleCodeExporter commented 8 years ago

Original comment by abm221...@gmail.com on 4 May 2010 at 3:28

GoogleCodeExporter commented 8 years ago
ScriptContext objects provide bindings from Clojure vars to Java objects, so 
you can 
refer to them in Clojure with the names you provide. But these bindings do not 
form 
nor affect the Clojure execution environment. That is, the definition of 'a' 
is "interned" into the Clojure runtime and from then on it can only be re-bound 
in 
the current or any other thread, but not removed. Passing a clean script 
context 
can't change that.

Clojure vars live for the life of the process. You can see this in the REPL, 
where 
the definition of 'a' will remain unless you quit and reload.

The relationship between the passed script context and the Clojure runtime is 
that 
this library does an automatic "(def name value)" for every entry, like the 
example 
that sets a File object.

I hope this explanation was useful.

Original comment by abm221...@gmail.com on 4 May 2010 at 8:35

GoogleCodeExporter commented 8 years ago
Hi Armando, Thanks very much for the explanation, it was very helpful. I am 
using the ScriptEngine from within a 
TextEditor, and I need to be able to clean out the Clojure execution 
environment without shutting down the 
TextEditor. Is there a way to do this, or can this simply not be done?

Original comment by elbe...@gmail.com on 4 May 2010 at 8:47

GoogleCodeExporter commented 8 years ago
I'm afraid I don't know if it can be done. Could there be an alternative, say, 
using 
namespaces? If you prepend (ns xyz) to any code it'll be evaluated there. If 
you 
later prepend (ns abc), code in there won't know about defs in xyz. 

I'd recommend asking this in the Google group with your particular scenario and 
goals; somebody will know for sure.
http://groups.google.com/group/clojure

Original comment by abm221...@gmail.com on 5 May 2010 at 12:12

GoogleCodeExporter commented 8 years ago

Original comment by abm221...@gmail.com on 1 Jun 2010 at 3:44

GoogleCodeExporter commented 8 years ago
Hi Armando, are you marking this as done because you figured out a way to do it 
in
the ScriptEngine impl? Or because it can't be fixed on your end and should be 
done in
clojure itself?

Original comment by elbe...@gmail.com on 1 Jun 2010 at 4:28

GoogleCodeExporter commented 8 years ago
I figure that there's nothing for this ScriptEngine to do about this. If 
Clojure 
supports a runtime cleanup you should be able to do it at the REPL or through 
code 
in this API, but I haven't seen that done or a use case that'd required. The 
guide 
in Learning Emacs didn't have that situation either.

The function ns-vars in ns-utils lib returns the defined vars in a namespace 
and you 
can set them to nil. Try the Clojure group with your use case, somebody may 
come up 
with something useful.

Original comment by abm221...@gmail.com on 1 Jun 2010 at 6:49