[e-lang] E-on-CL progress, and request for information

[Kevin Reid]

On Jun 25, 2005, at 15:20, Mark Miller wrote:

> Kevin Reid wrote:
>> Incomplete listing of significant changes since the first source 
>> announcement:

I forgot to mention: for anyone who missed the original announcement, 
there is no web page yet, but the source is at:

   <svn://slimy.com/cl-e/cl-e/trunk/>

> Very cool! I just updated, and noticed from one of your update 
> comments that you're also reporting all your progress to the CIA. That 
> is, the CIA Open Source Notification System ;) 
> <http://cia.navi.cx/stats/project/e-on-cl>.

Yes. I did it in order to have their IRC bot deliver commit 
notifications to <irc://irc.freenode.net/erights>, but it seems that 
the person who configures that is on vacation.

> I hadn't known about this system. Any idea why they call it "CIA"?

See <http://cia.navi.cx/doc>.

>> Is there anything you'd like to use E for that you can't do with any 
>> existing implementation due to lack of features?
>
> For me, when I think about using E-on-CL, the most pressing lack is 
> the joint absence of a tamed gui library and Pluribus.

Incidentally:

I've been experimenting with getting E-on-CL and CLIM (the "Common Lisp 
Interface Manager" UI framework) to cooperate. It mostly works, but I 
haven't done much yet, and I haven't commited the relevant code.

I suspect that CLIM is not very suitable for taming, but I haven't 
looked carefully yet.

I also have not investigated other Lisp GUI frameworks/libraries. I 
picked CLIM because it looked technically interesting and is supposed 
to be cross-platform.

>  That's why I've bumped up my priority for integrating Tyler's 
> VatTP-on-TLS changes, and for redoing CapTP in E using Data-E.
>
> Without these, E-on-CL doesn't have a gui library, and can't 
> communicate to E-on-Java it order to use its gui library.

Great!

Todo for my end:
   * Make sure the Data-E emakers will run.
   * Find an appropriate encryption library. (I know very little about 
this area. What protocol names should I look for?)

(Interoperation issue: What should happen if VatA sends a 
non-mobile-code Selfless object (say, a Twine) to VatB, which doesn't 
have an implementation for it? Should this cause the message send to 
break, or deliver the object as a broken reference?)

> If your E-on-ABCL-on-Java experiment works out, if we can get a 
> boot-comm system working between an E-on-ABCL-on-Java vat and an 
> E-on-Java vat in the same JVM process, then we could use E-on-Java's 
> gui well before we have a working implementation of Pluribus.

E-on-CL, if/when it gets intra-process multi-vat operation, will need 
some equivalent of the boot-comm system.

Not having looked at how boot-comm works in E-on-Java: would a 
reasonable implementation approach be hooking up a deSubgraphKit 
builder and recognizer across a more-trivial comm system that can pass 
their messages?


(Also, I've concluded that calling it "CL-E" is a bad idea. I haven't 
renamed anything yet, though.)

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