[e-lang] Causeway viewing your E-on-CL traces

Kevin Reid kpreid at mac.com
Wed Aug 6 07:01:41 CDT 2008

On Aug 5, 2008, at 18:47, Tyler Close wrote:
> On Tue, Aug 5, 2008 at 1:42 PM, Tyler Close <tyler.close at gmail.com>  
> wrote:
>> On Tue, Aug 5, 2008 at 11:38 AM, Kevin Reid <kpreid at mac.com> wrote:
>>> If they are to be generated relative, what should they be relative  
>>> to?
>> Assume all source code is found under some root directory. The source
>> path is then the relative path from this root to the source file. ...
>> "source" : "example/src/org/waterken/bang/Drum.java"
>> which assumes a root folder under which each project is stored.
>> Obviously this means all the source code in a given interaction must
>> coordinate their chosen project names.
> ...
> The contention on the project name is unfortunate, given that part of
> the path name already encodes a globally unique identifier. It might
> make more sense to make the path be:
> "source" : "org/waterken/bang/Drum.java" ...
> I think this would do a better job of decoupling source packages.  
> Thoughts?

I like this approach, with the caveat that if I get my way, E will  
move away from depending on the DNS system for module isolation, and  
I'm not yet sure whether the resulting system will have globally  
unique identifiers *in the pathnames*.

Also, there will always be source files which are not organized unique- 
name-wise: top-level programs ("scripts"), caplets, etc. I don't see  
how to generate reasonable relative paths for these.

On Aug 5, 2008, at 16:42, Tyler Close wrote:

>> Perhaps the log should have a field for a nickname (in the Zooko's-
>> Triangle sense) for the vat, since one exists in E and it's more
>> likely to be what the user wants?
> The event loop URIs in the Waterken server take the form:
> "loop" : "http://localhost:8080/-/t7/",
> where everything after the "-/" segment may be a programmer chosen
> name. I figured the Causeway viewer could use the last segment in the
> URI as the short name and the full URI as the globally unique name.

I think this is a decent and simple solution. It Violates The  
Opaqueness Of URIs, but has lots of precedent. I'll do it.

Kevin Reid                            <http://homepage.mac.com/kpreid/>

More information about the e-lang mailing list