bugKawa - Bugs: bug #11577, gnu.mapping.InheritingEnvironment...

 
 

bug #11577: gnu.mapping.InheritingEnvironment not seeing symbols in parent environment

Submitter:  tk <huh>
Submitted:  Thu 13 Jan 2005 12:11:45 AM UTC
   
 
Category:  Scheme language Severity:  3 - Normal
Item Group:  Unexpected result Status:  Fixed
Privacy:  Public Assigned to:  bothner
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 02 Feb 2016 04:57:59 PM UTC, comment #11: 

I haven't looked closely enough at Swank to understand to undersand the code.  But you shouldn't need to "create a child repl thread" - you're already working with some Kawa thread, possibly a repl.  Use the same thread.

Per Bothner <bothner>
Group administrator
Tue 02 Feb 2016 04:54:20 PM UTC, comment #10: 

Thank for reply.

> Call the procedure (or evaluate the expression) in the repl thread.


Can I do this by swank? Maybe I need to create child repl thread by swank for evaluating expressions sended from emacs to swank in this new repl context.

Anonymous
Tue 02 Feb 2016 04:14:34 PM UTC, comment #9: 

I'm not sure I understand.  Do you mean if you create a new procedure (or expression) in the Swank context, and then when call the procedure (or evaluate the method) you want it to have access to the Repl dynamic variables?  And you can't do that if you're running in the Swank thread?

The answer is: don't do that.  Call the procedure (or evaluate the expression) in the repl thread. You can use JDI's ObjectReference,invokeMethod and specify the REPL thread.


Per Bothner <bothner>
Group administrator
Tue 02 Feb 2016 02:18:58 PM UTC, comment #8: 

swank-kawa (part of slime) already use jdwp but in the same jvm (in other thread).

> Why do you need that?

For experimenting with new procedure defined in the swank thread by the repl (parent thread). If you have another solution for this please write (links maybe).

Anonymous
Mon 01 Feb 2016 09:39:16 PM UTC, comment #7: 

I'm not sure how Slime/Swank works, in terms of threads.  In principle it seems wrong for symbols defined in child environment to be visible in the parent. Why do you need that?

As far as I can tell, swank-kawa uses JDI running in the same JVM process as the Kawa application.  This is not recommended.  I think a better approach would use JDIbug, which uses JDWP to communicate with the application.

Per Bothner <bothner>
Group administrator
Mon 01 Feb 2016 07:28:20 PM UTC, comment #6: 


>  Inheriting environments only share symbols that existed before the child environment is created. Symbols subsequently defined in either the child or parent environment aren't seen in the other.


Can it be fixed? I want to improve SLIME for kawa. So I want to use symbols defined in child environment in his parent environment for better repl interaction.

Anonymous
Tue 15 Feb 2005 06:57:58 PM UTC, comment #5: 

thanks for the fixes, this is working much better -- but there are still
a few cases where symbols aren't being inherited properly.

1. Inheriting environments only share symbols that existed before the
child environment is created. Symbols subsequently defined in either
the child or parent environment aren't seen in the other.
(this isn't necessarily unreasonable behavior, but it's different
than the earlier implementation of environments).

2. Some predefined symbols (e.g. those defined in kawa.standard.Scheme) that
exist in the parent environment aren't seen in the inheriting environment
unless the symbol has been retrieved (say, for printing). For example,
the symbol "eval" (r5rs-environment) or "sleep" (kawa-environment) aren't
visible in a child environment unless the symbol has been referenced
in the parent environment.

3. this case is a bit more peculiar, as I thought that primitive and java
class type names were treated as literals. Referencing any of these
names (e.g. <int> or <java.lang.Object>) in a child environment will throw
an UnboundLocationException unless the name was seen in the parent environment
before the new environment was created.


to reproduce:

$ CLASSPATH=kawa-1.7.91.jar rlwrap java kawa.repl

#|kawa:1|# (define x 1)

#|kawa:2|# <long>
Type long

#|kawa:3|# sleep
#<procedure sleep>

#|kawa:4|# (scheme-window #t)
kawa.GuiConsole[frame0,100,50,700x500,layout=java.awt.BorderLayout,title=Kawa,resizable,normal]

#|kawa:5|# (define y 1)

#|kawa:6|# z
gnu.mapping.UnboundLocationException: unbound location z
        at gnu.expr.ReferenceExp.eval(ReferenceExp.java:93)
        at gnu.expr.Expression.apply(Expression.java:28)
        at gnu.expr.ModuleExp.evalModule(ModuleExp.java:190)
        at kawa.Shell.run(Shell.java:231)
        at kawa.Shell.run(Shell.java:177)
        at kawa.Shell.run(Shell.java:164)
        at kawa.Shell.run(Shell.java:151)
        at kawa.repl.main(repl.java:672)
#|kawa:7|#



;; in scheme window:
;; first 3 cases ok, as these were seen in parent
;; before current environment was created:

#|kawa:1|# x
1
#|kawa:2|# <long>
Type long

#|kawa:3|# sleep
#<procedure sleep>

#|kawa:4|# y
gnu.mapping.UnboundLocationException: unbound location y
at gnu.expr.ReferenceExp.eval(ReferenceExp.java:93)
at gnu.expr.Expression.apply(Expression.java:28)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:190)
at kawa.Shell.run(Shell.java:231)
at kawa.Shell.run(Shell.java:177)
at kawa.Shell.run(Shell.java:164)
at kawa.repl.apply0(repl.java:27)
at gnu.mapping.Future.run(Future.java:50)

#|kawa:5|# <int>
gnu.mapping.UnboundLocationException: unbound location <int>
at gnu.expr.ReferenceExp.eval(ReferenceExp.java:93)
at gnu.expr.Expression.apply(Expression.java:28)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:190)
at kawa.Shell.run(Shell.java:231)
at kawa.Shell.run(Shell.java:177)
at kawa.Shell.run(Shell.java:164)
at kawa.repl.apply0(repl.java:27)
at gnu.mapping.Future.run(Future.java:50)

#|kawa:6|# eval
gnu.mapping.UnboundLocationException: unbound location eval
at gnu.expr.ReferenceExp.eval(ReferenceExp.java:93)
at gnu.expr.Expression.apply(Expression.java:28)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:190)
at kawa.Shell.run(Shell.java:231)
at kawa.Shell.run(Shell.java:177)
at kawa.Shell.run(Shell.java:164)
at kawa.repl.apply0(repl.java:27)
at gnu.mapping.Future.run(Future.java:50)

#|kawa:7|# (define z 1)
#|kawa:8|#

tk <huh>
Sat 12 Feb 2005 07:56:21 AM UTC, comment #4: 

The latest check-in seems to have fixed the problem, including the problem mentioned in comment #2.

Per Bothner <bothner>
Group administrator
Mon 07 Feb 2005 07:28:11 PM UTC, comment #3: 

I checked in your patch.  Even if there is still a problem, I do think it is a correct patch.

Per Bothner <bothner>
Group administrator
Mon 07 Feb 2005 07:23:27 PM UTC, comment #2: 

Actually, things still aren't right:
A (set! foo 3) in the new window isn't visible in the original repl.  It should be: the bindings are supposed to be shared, (unless define is used rather than set!).
I'm thinking about how to represent "parameter" objects, which might lead to changing how bindings are done, so assuming you can move forwards I'd like to defer this a little.  (This is still very high on my list.)

Per Bothner <bothner>
Group administrator
Mon 07 Feb 2005 06:38:14 AM UTC, comment #1: 

That looks like a correct fix.
Sorry for letting this one slide.
I'll check it as soon (probably tomorrow).

Per Bothner <bothner>
Group administrator
Thu 13 Jan 2005 12:11:45 AM UTC, original submission:  

in the current cvs version, sharing environments doesn't seem to
be working properly.

it appears that baseTimestamp in gnu/mapping/InheritingEnvironment.java
is never initialized, so the following test in lookupInherited (starting
at line 68) will always be false.

NamedLocation loc = inherited[i].lookup(sym, prop, hash);
if (loc != null && loc.isBound())
  {
    if (! (loc instanceof SharedLocation)
|| ((SharedLocation) loc).timestamp < baseTimestamp)
      return loc;
  }



the following change seems to be an incomplete fix:

$ cvs diff Environment.java
Index: Environment.java
===================================================================
RCS file: /cvs/kawa/kawa/gnu/mapping/Environment.java,v
retrieving revision 1.26
diff -r1.26 Environment.java
342c342,344
<     return new InheritingEnvironment(name, parent);
---

>     InheritingEnvironment env = new InheritingEnvironment(name, parent);
>     env.baseTimestamp = ((SimpleEnvironment)parent).currentTimestamp;
>     return env;





the condition can be reproduced as follows:


$ CLASSPATH=lib/kawa.jar rlwrap java kawa.repl
#|kawa:1|# (make <java.lang.Integer> 1)
1
#|kawa:2|# (define foo 1)
#|kawa:3|# (scheme-window #t)
kawa.GuiConsole[frame0,100,50,700x500,layout=java.awt.BorderLayout,title=Kawa,resizable,normal]
#|kawa:4|#


;;; in the window:

#|kawa:1|# foo
gnu.mapping.UnboundLocationException: unbound location foo
at gnu.expr.ReferenceExp.eval(ReferenceExp.java:108)
at gnu.expr.Expression.eval(Expression.java:21)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:189)
at kawa.Shell.run(Shell.java:231)
at kawa.Shell.run(Shell.java:177)
at kawa.Shell.run(Shell.java:164)
at kawa.repl.apply0(repl.java:27)
at gnu.mapping.Future.run(Future.java:47)
#|kawa:2|# (make <java.lang.Integer> 1)
gnu.mapping.UnboundLocationException: unbound location <java.lang.Integer>
at gnu.expr.ReferenceExp.eval(ReferenceExp.java:108)
at gnu.expr.ApplyExp.eval(ApplyExp.java:69)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:189)
at kawa.Shell.run(Shell.java:231)
at kawa.Shell.run(Shell.java:177)
at kawa.Shell.run(Shell.java:164)
at kawa.repl.apply0(repl.java:27)
at gnu.mapping.Future.run(Future.java:47)
#|kawa:3|#

tk <huh>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bothner (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2005-02-12 bothner StatusNone Fixed
        Open/ClosedOpen Closed
    2005-02-07 bothner Assigned toNone bothner

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code