Very simple answer.
The Inspector has no idea about local spaces.
The Browser has a reflection semantics in a local space: upon invocation it
makes a ground data structure of what is being browsed and sends it up to
the toplevel. In particular it does no incremental updates (very tricky to
do as this is based on suspensions which would change the status of a
space...)
Christian
-- Christian Schulte, http://www.ps.uni-sb.de/~schulte/----- Original Message ----- From: "Luis Quesada" <luque@info.ucl.ac.be> Newsgroups: mozart-oz.hackers Sent: Thursday, September 06, 2001 8:08 PM Subject: Re: Inspector, Browser and Local computation spaces
> I think the original one was not received so I send a copy of it. > > ---------------- > > Raph wrote: > > > The call {Browse R.2} exports the *value* of R.2 outside the space S2. > > But the space may not export its "own stuff", i.e., undetermined > > variables, names, procedures, cells, etc. created inside the space. > > Christian's thesis explains this and why it is a good design rule. > > Ok. I agree. > > > > > > > 2. Why is R.1 restricted to a in S1? > > > > > > local > > > S1={Space.new proc {$ R} > > > R='#'(_ _) > > > thread if R.1==a then R.2=b end end > > > {Wait R.1} {Browse R.1} > > > end > > > } > > > S2={Space.clone S1} > > > in > > > {Space.inject S2 proc {$ R} > > > R.1=a > > > {Wait R.2} {Browse R.2} > > > end} > > > end > > > > > > Are not S1 and S2 two *different* local computation spaces? I think R.1=a, > > > which is done in S2, should not affect S1. > > > > S2 is a clone of S1. Thus, it contains a clone of the thread doing > > > > if R.1==a then R.2=b end > > > > So, binding R.1=a *in S2*, R.2=b will be executed *in S2*. > > The concept of cloning spaces is clear for me. I precisely based my last > message to the user list on this concept. The fact is that I was not taking > into account that the implicit thread of {Browse R.1} is also being copied into > > the cloned space. This copy, as you noted when we were discussing, is the > responsible of showing a in the browser. > > > > > The "Situatedness violation" error is the violation of the rule that I > > mentioned in question #1. > > I still think this is a bug. Not always a solution is defined in terms of total > > determination of the variables involved (just take into account Kenneth's > problem). > > In the following example the browser works without any problem at all. However, > > the inspector crashes when doing so. > > > {Space.new proc {$ R} > R::2#10 > {Inspect R} > end _} > > %************************** Error: Space ************************ > %** > %** Situatedness violation > %** > %** Culprits: [_{2#10}] > %** In statement: {<P/2 Port.send> <Port> inspect(_{2#10})} > %** > %** Call Stack: > %** procedure 'Inspect' in file > "/.amd_mnt/krumelur/host/e2/dsl/kost/compile/build-1.2.0/mozart/share/tools/ inspector/InspectorMain.", > line 553, column 6, PC = 6387144 > %**-------------------------------------------------------------- > > Luis > > -- > Catholic University of Louvain > Department of Computing Science and Engineering > Place Sainte Barbe, 2 > B-1348 Louvain-la-Neuve, Belgium > Phone: (++32) (10) 47 90 13 > Fax: (++32) (10) 45 03 45 > E-mail: luque@info.ucl.ac.be > > - > Please send submissions to hackers@mozart-oz.org > and administriva mail to hackers-request@mozart-oz.org. > The Mozart Oz web site is at http://www.mozart-oz.org/.
- Please send submissions to hackers@mozart-oz.org and administriva mail to hackers-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/.