caplisp-devel Mailing List for caplisp
Status: Planning
Brought to you by:
radix42
Menu
▾
▴
caplisp-devel — List for developers working on CapLisp
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
|---|
|
From: James G. <an...@xn...> - 2005-10-09 23:33:57
|
David Mercer wrote: > Sorry for the very delayed replay, 3 math classes at once has been > more of a load than I thought it would! Comments interspersed below. Yeah, well, having a 60+ hour a week day job also isn't conducive to working on free software in my free time either. > I'm actually kinda glad you're back to s48 for your efforts, as that's > a direction I'd wanted to explore for a while, too. Even emailed jar > about some things regarding such an effort a time or two. I punted > to image level confinement in my current caplisp aspirations for > pretty much the reasons jar outlined in very good detail in your > message (on elang I think) recently. Or at least a decent subset of > them! If there's anything interesting/useful that he or you said, please forword it if you can get permission. >>So we've got some other tools to do the FFI generation for OpenSSL >>and/or GNU TLS. I'm only going to need a small part of the API to begin >>with anyway. > > That sounds like a great place to start. I haven't made much progress lately. I did get Scheffig up and running, and that stuff is detailed on the Scheme 48 mailing list. However, I've continued to run into problems with it, and until I spend some more time studying it, I'm putting Scheffig on the shelf for now. This was also prompted because the existing socket library for Scheme 48 doesn't expose the Unix file descriptors, just Scheme ports. Whereas OpenSSL (*) expects to be handed Unix file descriptors, and it makes the SSL connection on top of that. So I'll need to create some wrapper functions which can extract the Unix file descriptor (easy). And then we'll also want to create a Scheme-ish port interface on top of that. (also not hard) That's probably about a day's work total. What is inconvenient though, is that there are plans to re-vamp the network programming library for Scheme 48, as part of a possible re-unification with SCSH (**). I'm thinking I just want to create the minimal possible interface to OpenSSL, and then wait to see what happens with the networking API. >>I'm also tempted to work on some kind of tool to automatically convert >>modules for other Schemes (most notably Chicken and DrScheme) to make it >>easier to import their libraries. I'll need to hand-convert a few >>first, to get a good feel for what that would require. > > > Oh such a tool would be very, very sweet! Yeah, but it will be a fair amount of work. Perhaps it would be better to support the "Common Scheme" effort, and try to get people to port their libraries to that instead. > I'm very interested to follow any/all progress you make with s48. Let > us all know when there's code to look at! Will do. James Graves (*) I started first working with GNU TLS. I downloaded their documentation page, and started trying to compile the example code. This didn't work for a couple reasons: missing functions (which I could easily have fixed) and that all the structure names have changed between version 1.0.x and version 1.2.x. The documentation refers to 1.2, and I have 1.0 installed on my Debian Sarge machines. I could download and install 1.2, and then point the compiler and linker at the new version, but I didn't want to futz with it. Meanwhile, I found some 9 year old demo code for OpenSSL, and after a few very minor tweaks, it compiled, ran, and appears to function correctly. Huzzah for stable APIs! Defintely using OpenSSL for now, despite the license issues. (**) So in this case, Scheme 48 is the Vulcans, and SCSH is the Romulans. |
|
From: David M. <ra...@gm...> - 2005-10-09 03:10:33
|
Sorry for the very delayed replay, 3 math classes at once has been more of a load than I thought it would! Comments interspersed below.=20 -David Mercer On 9/27/05, James Graves <an...@xn...> wrote: > > I got the good word from the Scheme 48 folks. I'm not going to bother > with SWIG at this point. It would be difficult to add support for > another target. In fact, though I thought it was the case, there is no > support in SWIG for any CL implementation either. :-( I'm actually kinda glad you're back to s48 for your efforts, as that's a direction I'd wanted to explore for a while, too. Even emailed jar about some things regarding such an effort a time or two. I punted to image level confinement in my current caplisp aspirations for pretty much the reasons jar outlined in very good detail in your message (on elang I think) recently. Or at least a decent subset of them! > So we've got some other tools to do the FFI generation for OpenSSL > and/or GNU TLS. I'm only going to need a small part of the API to begin > with anyway. That sounds like a great place to start. > I'm also tempted to work on some kind of tool to automatically convert > modules for other Schemes (most notably Chicken and DrScheme) to make it > easier to import their libraries. I'll need to hand-convert a few > first, to get a good feel for what that would require. Oh such a tool would be very, very sweet! I'd actually started a reply to your longish email I referred to above, but realized it would be mostly just "yes, I agree" type statements; hence this one instead. I'm very interested to follow any/all progress you make with s48. Let us all know when there's code to look at! Cheers, David Mercer Tucson, AZ |
|
From: James G. <an...@xn...> - 2005-09-27 22:41:13
|
I got the good word from the Scheme 48 folks. I'm not going to bother with SWIG at this point. It would be difficult to add support for another target. In fact, though I thought it was the case, there is no support in SWIG for any CL implementation either. :-( So we've got some other tools to do the FFI generation for OpenSSL and/or GNU TLS. I'm only going to need a small part of the API to begin with anyway. I'm also tempted to work on some kind of tool to automatically convert modules for other Schemes (most notably Chicken and DrScheme) to make it easier to import their libraries. I'll need to hand-convert a few first, to get a good feel for what that would require. Cheers, James Graves |
|
From: James G. <an...@xn...> - 2005-09-27 04:30:14
|
As I mentioned over in e-lang, I've decided to switch gears and focus on
development based on Scheme 48. My posting policy will probably be as
follows:
e-lang
General discussion, policy issues, E-specific issues.
caplisp-devel
Implementation issues for CL and Scheme.
sch...@s4...
General discussion of Scheme 48 issues.
-----------------------------------------------------------
It looks like it will be a non-trivial amount of work to even get httpsy
ported to Scheme 48. Scheme isn't going to be as easy for a lot of this
stuff, in general. The libraries and applications aren't as well developed.
At any rate, I'm currently looking at SWIG support for Scheme 48. There
are already three other Schemes supported, so on the surface, adding
support for S48 shouldn't be too hard. As I have started getting into
this more, it looks like it might be quite challenging.
SWIG is being considered because S48 will need some kind of SSL support.
I'm leaning towards GNU TLS, but that's still quite open for discussion.
There's a fair amount of support for SSL in CL, so that shouldn't be a
problem.
After that, there's a web server to think about. Gotta have http,
before you have httpsy, right? There's a couple choices for CL,
Uncommon Web seems popular.
For Scheme, you've got the web server which comes with MzScheme, and
that's it. I don't consider the mod_NNN projects viable; I'm only
thinking about native implementations. The SISC server runs on top of
J2EE. So it isn't actually doing any actual http stuff itself.
And even for the MzScheme web server, it's got a fairly deep dependance
tree, and there seems to be a fair amount of infrastructure that will
need to be ported.
Huh. Just ran across "spiffy" which is for Chicken Scheme. Seems
fairly small in compairison.
But porting stuff _from_ MzScheme couldn't be easier... in a sense. The
DrScheme enviroment as a nice source and module browser. It even draws
dependancy graphs.
Guess we'll have to see how small Spiffy is, and if it is worth the bother.
James Graves
|
|
From: David M. <ra...@gm...> - 2005-09-17 19:19:20
|
Here ya go! -David ---------- Forwarded message ---------- From: Jonathan Rees <ja...@mu...> Date: Aug 26, 2005 6:47 PM Subject: Re: [e-lang] "Fixing" the Common Lisp package system To: Kevin Reid <kp...@at...>, David Mercer <ra...@gm...> (Not cc'ing e-lang for uninteresting reasons related to my incomplete transition to new email client infrastructure. Feel free to forward but change the email address to ja...@mu.... Sorry I haven't followed the whole thread.) I think this is a herculean task. Good luck. There are scores of features in Common Lisp that show abysmal capability discipline. This is one thing that led me to give up on it (I worked on the first Common Lisp implementation, NIL) and do T and Scheme 48 instead. I always had in mind the goal of running multiple mistrusting users in a single address space, which is tantamount to capability security. While this has never happened in a serious way, it would be very easy to do a capability-disciplined Scheme 48 if anyone cared to. E.g. pairs are mutable in Scheme 48, for compatibility with the Scheme report, but it is easy to remove set-car! and set-cdr! from the namespace with little change in functionality. (You'd have to rewrite list-sort and some other things that use them internally.) Let's see... you'll have to make GET local to a lexical namespace somehow, and OPEN... and Lisp INTERN has the same problem that Java's does - if you can detect the internedness of a string then confinement is impossible. I guess you already ditched dynamic binding, catch and throw, and the condition system. And there are tons of things that are similar to GET in that they access global state - logical pathnames, readtables, defsetf, properties on keyword symbols, etc. Were you going to make packages be the atomic security domain, so that each had its own GET and so on (in effect a separate address space)? I'm using Common Lisp now so the horrors of the package system and the rest of the language are fresh in my mind. I think your eventual language won't be recognizable as Common Lisp, but it will be much improved. Best of luck Jonathan --=20 "Nothing above represents the position or opinion of the University of Arizona or the Dept. of Mathematics, so there! :-)" |
|
From: Mark M. <ma...@cs...> - 2005-09-15 14:30:29
|
David Mercer wrote:
> **snip of some excellent gory details of the lisp package system that I
> should cc over to James later**
David, I suspect everyone on this list would love to see these gory details.
Could you forward Rees' message in its entirety? Thanks.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
|
|
From: David M. <ra...@gm...> - 2005-09-14 16:34:16
|
Sorry for the extremely delayed reply, I've been out of commission due to= =20 oral surgery, and then dancing like mad to stay on top of multiple math classes....my initial, ver= y=20 late, thoughts on=20 Jonathan's excellent message are below. -David Mercer On 8/26/05, Jonathan Rees <ja...@mu...> wrote: >=20 > (Not cc'ing e-lang for uninteresting reasons related to my incomplete > transition to new email client infrastructure. Feel free to forward > but change the email address to ja...@mu.... Sorry I haven't > followed the whole thread.) That's ok, it branched out over on the new caplisp list, which I've cc'd=20 this to (cap...@li... running mailman, so if you'd= =20 like to join us [myself, Kevin, James, MarkM and David Hopwood] there, you= =20 know what to do! :-) It's there for us to hash out heavily lisp-specific implementation issues i= n=20 our various different capability lisp efforts. Kevin is of course making good headway with E-on-CL, James is trying to=20 attack CL's defficiencies in re capability discipline (such as the numerous= =20 problems you point out in detail below) which in the e-lang taxonomy of=20 flavors of E-ish things is a LispE, and I'm more dedicated to adding=20 distributed capability features to warts and all CL, with the lisp image=20 being the unit of trust, at least initially, making my efforts caplisp unde= r=20 the same naming convention.=20 I think this is a herculean task. Good luck. There are scores of > features in Common Lisp that show abysmal capability discipline. This > is one thing that led me to give up on it (I worked on the first > Common Lisp implementation, NIL) and do T and Scheme 48 instead.=20 I was at first (and still am in many ways) drawn to starting off with W7 an= d working from there, but I just can't stand to do actual heavy work in=20 Scheme. I love it for proof-ish type things and minimalist stuff, but CL just has= =20 such better working libraries available, etc. that I always seem to get sucked= =20 back in that direction (perhaps it was the Maclisp exposure at the tender age of 14 that scarred me! :-) I always had in mind the goal of running multiple mistrusting users in > a single address space, which is tantamount to capability security. I have the goal of using a hypervisor to control VM's that are mistrusting on the same hardware, rather than in the same address space. I may want to write such a 'landlord process' in a capsec Scheme variant for easier provability (or even ML or Haskell or something, whoever has the best proof engine at that point), but I wanna do some things that need LOTS of libraries not available out of the box for scheme, but that are available for CL.=20 **snip of some excellent gory details of the lisp package system that I=20 should cc over to James later** I'm using Common Lisp now so the horrors of the package system and > the rest of the language are fresh in my mind. I think your eventual > language won't be recognizable as Common Lisp, but it will be much > improved. Yes, I think that James' LispE implementation will only look like Common=20 Lisp, with quite a bit of stuff chopped out or heavily hacked! Best of luck >=20 > Jonathan >=20 Cheers, David Mercer Tucson, AZ --=20 "Nothing above represents the position or opinion of the University of Arizona or the Dept. of Mathematics, so there! :-)" |
|
From: James G. <an...@xn...> - 2005-08-29 16:53:24
|
Hello all, This is just to let y'all know what my current (slow) progress is. I was able to add an immutable flag to all the objects (cons, array, hashtable, etc.). There is some padding at the beginning of the objects, and I stuck the flag in there. Then there are the immediate types, which aren't really objects, but just values. These are fixnum and character. So you don't need to make these immutable, just the structure / container which holds them. Though ECL seems to only support boxed floats, there don't appear to be any operations which directly modify the floating point value in-place. All the operations seem to create a new FP value and return that instead. I need to take a closer look at ARRAY, however. There seemed to be some code in there to support unboxed floats, but then issues of immutability should be covered by the array itself. I've still got a lot of code to read through for all the data type to see who can modify objects in-place. For some it was relatively easy, like CONS. A CONS cell is only modified by RPLACA and RPLACD, so that was simple to check. There's a lot more code to check for some types such as string. I'll send another message on the proposed interface for immutable types, there are some issues I would like to discuss. Later, James Graves |
|
From: David H. <dav...@bl...> - 2005-08-27 23:53:00
|
David Mercer wrote: > Lord, I suppose I need to go and see if Tyler has any list(s) for httpsy and > friends, or is all that on captalk? web...@wa... (Should be <http://mail.waterken.com/mailman/listinfo/web-calculus> for subscription and archives, but there seems to be a server error.) -- David Hopwood <dav...@bl...> |
|
From: David M. <ra...@gm...> - 2005-08-27 19:31:13
|
On 8/25/05, Mark Miller <ma...@cs...> wrote: >=20 > David Mercer wrote: > > And then there have been an occasion or two where I failed to > > communicate an idea clearly enough, got pooh-poohed or ignored, and > > saw the idea come back around a year or more later in new clothes and > > be hailed as wonderful. Ah well, live and let live! >=20 > Happens to all of us repeatedly. I've lost count myself. I've also=20 > committed > this sin myself, and I always appreciate when someone lets me know. When= =20 > such > an occurrence happens, whether to you or anyone else, please post a > clarification and a link to the earlier expression of the idea. That's on= e=20 > of > the wonderful benefits of having a permanent public archive! I'll google up my ODNS post(s) and the relevant VLS/httpys bits that are=20 comparable for posting to the appropriate list(s)....but probably not right now, as I= =20 still intend to=20 further extend httpys in a (compatible) way with the ODNS features that are= =20 not in the current httpsy spec/implementation (basically "rooted" vs. "unrooted"= =20 httpsy hashes). Lord, I suppose I need to go and see if Tyler has any list(s) for httpsy an= d=20 friends, or is all that on captalk? > Hhmmm, in that case I think that perhaps "caplisp" is more precise > > than I'd even intended, since it is object level security that will > > require (perhaps) modifications to the guts of lisp itself, rather > > than being purely extensions. >=20 > If you want the project's name to align this work with CaPerl or CaPython= , > perhaps you should consider CaLisp? Only a suggestion. Naw, I think that they got lucky in having a first letter of "P" so that CA= P=20 is the beginning of the name! And CaLisp looks like something from canada or=20 california!=20 **bit snipped** >=20 > > If so, then I am indeed starting work on caplisp, James appears most > > interested in Lisp-E (which I did consider, having remembered your > > above referenced note!) before I created the project, and Kevin of > > course has already made quite a start on E-on-CL! I imagine much code > > can/will be cross polinated, and James is welcome to host > > code/lists/webpages on the caplisp sourceforge project space if he'd > > rather not deal with the (minor) fuss and bother of setting up a > > seperate home for Lisp-E (or would CLisp-E be preferred?) >=20 > This is a good clarification. Could you post something along these lines= =20 > to > caplisp? Thanks. Wil do!=20 > Oh yes, whomever had the idea to grab the coinage "object > > capabilities" hit the nail on the head. My god, how many endless > > threads and re-hashings did it take for that term to emerge? :-) >=20 > Yup, that was painful. Well I do think that the struggle merely enphasizes the worth of what came= =20 out of it. "Object capabilities" has been great shorthand to immediately Not Confuse= =20 unix/security people I've talked to who have been exposed to prior/other uses of the term= =20 "capability" in a meaning other that what we mean completely. Then comparin= g=20 that to a unix file descriptor and you're all the way home and that 'get it'. > > I think I thought things out on the keyboard pretty well above, thanks > > very much for the nomenclature clarification, it was essential! >=20 > You're welcome! >=20 > -- > Text by me above is hereby placed in the public domain >=20 > Cheers, > --MarkM >=20 >=20 Cross-posted to caplisp, hope you don't mind! (See your license above! :-) -David Mercer Tucson, AZ --=20 "Nothing above represents the position or opinion of the University of Arizona or the Dept. of Mathematics, so there! :-)" |
|
From: Mark M. <ma...@cs...> - 2005-08-25 18:50:10
|
David Mercer wrote: > I just re-read most of that post (thanks for the link!) and I recall > it pretty clearly. The "why not just implement a fast E?" attitude of > Jonathan's in the message you were replying to is part of why this > effort exists. Some on e-lang seem to be prejudiced against anything > non-E in capsec languages, and can't see IT'S theoretical limitations, > which smacks me as a bit ironic, considering how that attitude > somewhat mirrors the prejudice experienced by the cap community in the > wider computing world (god, an outcast among outcasts, that must be > the story of my life! :-) Please see my response <http://www.eros-os.org/pipermail/cap-talk/2004-December/002432.html> and my clarification of that response <http://www.eros-os.org/pipermail/cap-talk/2004-December/002433.html>. AFAIK, it is rare that anything that sounds like a prejudice against other capsec languages is voiced on e-lang; and whenever it is, it is always quickly answered. My sense of the general consensus of e-lang as a community (to the extent that it makes sense to speak of such a thing) is that there is no such prejudice. Note that Jonathan, the author of the response you're reacting to, is currently working on bitc -- a Scheme-like language with elements of ML, C, E, and eventually (in the meta-level proof sublanguage) Twelf. >>As far as what to post where... I really appreciate the feedback from >>the regulars on e-lang, so anything I have to say which isn't strictly >>an implementation detail is likely to be posted there. I did ask >>recently, and MarkM said that we were quite welcome to discuss a >>cap-secure CL on the e-lang list. > > Certainly! Yes, agreed, certainly! Also, I'd like to clarify the notion of "E proper". AFAI can tell, the active Oz-E, defunct Squeak-E, and soon-to-be-announced Joe-E efforts do not resemble the E language itself anymore than does the caplisp effort you have in mind. If you adopt httpsy and E's concurrency control, then you'll resemble E even more than some of these. The naming convention we've been using is "E-on-X" to mean a port of the E language itself onto platform X, whereas "X-E" is an adaptation of X to incorporate ideas from E while still retaining the look-and-feel of X. Kevin renamed his efforts from CL-E to E-on-CL in order to follow this convention, and avoid confusion with a possible future CL-E or Lisp-E effort. Brian of Twisted Python fame (see <http://www.lothar.com/blog/twisted/>) suggests a further clarification. He'd like to eventually create a Python variant supporting object-granularity capability security. In the meantime, inspired by Ben Laurie's "CaPerl", he's contemplating a compromise giving only "zone" granularity capability security (much like the J-Kernel did for Java). He's using the name CaPython for the zone granularity system and reserving the names Mont-E or Pyth-E for a possible future object-granularity system. So, as you can guess by now, I would like to gently suggest that the caplisp effort be renamed to something along the lines of CL-E or Lisp-E. Of course, the E-language effort itself would benefit from such a renaming, so you should regard my reasoning here with caution. Why do I think the caplisp effort would benefit from this renaming? All our efforts taken together are still well below critical mass is getting attention from the wider world. But "Buzz" feeds on the perception that something new and big may be brewing -- that there's a growing movement of something underfoot. E has struggled to try to get people's attention despite its alignment with an old and long-ago discredited paradigm, capabilities. Simply renaming this "object capabilities", which we did largely for other reasons, has done wonders getting us past this initial barrier. Those who've gotten the standard CS education who hear about a "caplisp" may quickly dismiss it as well for the same reason. However, with several similar efforts using names that make it clear they're somehow related, then someone who hears only the names of several of these has a sense that "something's happening, perhaps I should find out what". Breaking through this first barrier is a huge deal that shouldn't be underestimated. In light of these various uses of the "-E" suffix, all or which I've encouraged, I propose that we regard the letter "E" as being about a bundle of ideas. The "E language" per se serves only as a flagship for this bundle of ideas. Because of my conflict of interest, I will shut up on this topic now and leave it to the rest of caplisp community to decide what name they wish to use. Whatever you choose, I will certainly remain supportive of your efforts! -- Text by me above is hereby placed in the public domain Cheers, --MarkM |
|
From: James G. <an...@xn...> - 2005-08-25 18:45:15
|
David Mercer wrote:
> I just re-read most of that post (thanks for the link!) and I recall
> it pretty clearly. The "why not just implement a fast E?" attitude of
> Jonathan's in the message you were replying to is part of why this
> effort exists. Some on e-lang seem to be prejudiced against anything
> non-E in capsec languages, and can't see IT'S theoretical limitations,
> which smacks me as a bit ironic, considering how that attitude
> somewhat mirrors the prejudice experienced by the cap community in the
> wider computing world (god, an outcast among outcasts, that must be
> the story of my life! :-)
I believe the primary issue is that the cap-security community is very
small now. And we can't (in some sense) afford to split up into our own
little camps.
Unfortunately, for anything I'm not paid to work on, I can't deal with
anything other than what I really want. And at this point, I really
want CL.
> And that's great! I'm just of the opinion that, from a theoretical
> standpoint, since one can't even (usually) tell if they are running on
> real hardware more and more these days, and are guaranteed to be on
> some sort of VM if you're interpreted anyway, and language based
> security can never be the whole enchilada (it mostly protects you from
> yourself), Why Not start on the distributed case, since it's the
> interesting one that's the goal!
The distributed case is the most interesting. And the area where we
(the software development community in general) need to improve most.
Processors aren't going to just keep doubling in clock speed every so
often. In fact, lately, the clock speed has been just inching up slowly
over time.
It is distributed computing where the big thing is.
I just don't want us to forget the local case either.
> Oh that'd be great. Nothing stops us from having seperate branches
> ('inside out' vs 'outside in', or something) and concentrating most on
> specifying interfaces in a portable way, which will make porting
> things between lisps easier.
Actually, I'm sure we don't want to get tied down to any particular
codebase more than we have to. Ideally, we'd concentrate on keeping the
changes needed for a CL implementation as small and portable as
possible, because we're not likely to get our stuff accepted into the
main branch (because it won't be strictly CL anymore).
As far as darcs goes, I'm not saying I won't use it, I just haven't used
it yet. I don't want anyone spending much time on infrastructure, and I
know that CVS is not a good long-term solution. I've been meaning to
move my company over to Subversion or some such, but haven't had the
time. I can learn darcs, don't worry.
>>I _assume_, and I hope this will continue to be true for at least the
>>near future, that everyone on this list is also subscribed to e-lang and
>>cap-talk as well.
>
>
> You betcha, I highly prize my annotated copy of the last couple of years posts!
What, using crit.org? I'm a big fan to wikis myself. We've got a
couple mediawiki sites set up for our company. Very useful.
>>(1) There are not one, not two, but three different routines called
>>'make_cons' to create CONS cells in ECL. But only one of them is
>>actually used. I was, of course, modifying the wrong one, and wondering
>>why my initialization code wasn't working.
>
>
> Ew, now THAT's a messy codebase! :-)
It's really not that bad, I think it is mostly a matter of me learning
what's where. If you want to see something more scary, look at CLisp or
GCL. ABCL is also a pain to work with, all the code is basically in one
directory, and there are few comments. It looks like Peter Graves (no
relation) wrote the whole thing himself. Which is fine, I'm not
complaining. I mean heck, I haven't pushed any big chunks of code out
there that others have used yet.
I still need to work on the ECL build system maybe, it often seems to
require a complete rebuild when making changes. And it doesn't detect
when it needs to do it in some cases. But at least it has a separate
build directory that all the object files get dumped into.
James Graves
|
|
From: David M. <ra...@gm...> - 2005-08-25 16:57:16
|
On 8/25/05, James Graves <an...@xn...> wrote: >=20 > Hello Everyone! >=20 > I don't have a lot of time to chat, and for a quick intro into my > motivations, you can check this post on the cap-talk mailing list from > last year: >=20 > http://www.eros-os.org/pipermail/cap-talk/2004-December/002435.html I just re-read most of that post (thanks for the link!) and I recall it pretty clearly. The "why not just implement a fast E?" attitude of Jonathan's in the message you were replying to is part of why this effort exists. Some on e-lang seem to be prejudiced against anything non-E in capsec languages, and can't see IT'S theoretical limitations, which smacks me as a bit ironic, considering how that attitude somewhat mirrors the prejudice experienced by the cap community in the wider computing world (god, an outcast among outcasts, that must be the story of my life! :-) > For whatever reason, unlike David, I seem to be most interested in the > internals of implementing cap-security in Common Lisp. So I guess I'll > be working from the VM on out to the network. And that's great! I'm just of the opinion that, from a theoretical standpoint, since one can't even (usually) tell if they are running on real hardware more and more these days, and are guaranteed to be on some sort of VM if you're interpreted anyway, and language based security can never be the whole enchilada (it mostly protects you from yourself), Why Not start on the distributed case, since it's the interesting one that's the goal! > But I definitely want all the good bits from E, so I'm definitely > looking forward to trying everything. Oh yeah, that list you posted in the message linked above shockingly mirrors a parallel computing quest of mine, and strikes me as a good place to mine Things To Do for this project. > Expect progress from me to be a bit slow. My day job doesn't (yet) > involve capability security, but I'll be steering things in that > direction as time goes by. In the mean time, however, Caplisp is a > nights/weekends project for me. Well I'm hip deep in a mathematics degree right now, so my activity level on this will be fairly bursty too! > I've chosen ECL as my implementation of choice, not because it's the > fastest or anything, but because it seems to be the easist to hack the > internals. After some initial stumbling (1), I think I've gotten my > feet under me and I should have something to show soon in regards to > immutable types. I'll need to send out another post on that stuff in > regards to what kind of interface we want soon. Oh that'd be great. Nothing stops us from having seperate branches ('inside out' vs 'outside in', or something) and concentrating most on specifying interfaces in a portable way, which will make porting things between lisps easier. > I'm not as worried about license issues right now. I prefer the GPL for > everything, but I'm not too picky. As long as whatever we're using is > compatable with whichever CL implmentations we're using, I don't see any > problems. I generally prefer the GPL too, especially for infrastructure level code, but I'm more agnostic about it with regard to language/library technology, and more concerned with GPL purity in regard to basic infrastructure server apps. In other words, even if any future released code from this project is MIT licensed, I'm intending to use it to write GPLed apps. for general release. > I've never used darcs, but I suppose it wouldn't kill me to check it out. It's really simple to use, but if you specifically prefer cvs, every sourceforge project has cvs services, and you're more than welcome to use it for your work, while I use darcs for the 'outside in' branch.=20 I can easily automate cross-updating between the two for any common code, also (ssh, rsync and cron are your friends :-) You need merely create a sourceforge login, and I can give you write access to the caplisp cvs (I may have to set it up, recursive dependancies, yay!) > As far as what to post where... I really appreciate the feedback from > the regulars on e-lang, so anything I have to say which isn't strictly > an implementation detail is likely to be posted there. I did ask > recently, and MarkM said that we were quite welcome to discuss a > cap-secure CL on the e-lang list. Certainly! I just felt we were getting a bit too much away from E proper, and more implementation specific than cap-talk would warrant in some cases, and wanted things more easily collectable in one place. > I _assume_, and I hope this will continue to be true for at least the > near future, that everyone on this list is also subscribed to e-lang and > cap-talk as well. You betcha, I highly prize my annotated copy of the last couple of years po= sts! > (1) There are not one, not two, but three different routines called > 'make_cons' to create CONS cells in ECL. But only one of them is > actually used. I was, of course, modifying the wrong one, and wondering > why my initialization code wasn't working. Ew, now THAT's a messy codebase! :-) Cheers, -David Mercer Tucson, AZ |
|
From: James G. <an...@xn...> - 2005-08-25 15:49:20
|
Hello Everyone! I don't have a lot of time to chat, and for a quick intro into my motivations, you can check this post on the cap-talk mailing list from last year: http://www.eros-os.org/pipermail/cap-talk/2004-December/002435.html For whatever reason, unlike David, I seem to be most interested in the internals of implementing cap-security in Common Lisp. So I guess I'll be working from the VM on out to the network. But I definitely want all the good bits from E, so I'm definitely looking forward to trying everything. Expect progress from me to be a bit slow. My day job doesn't (yet) involve capability security, but I'll be steering things in that direction as time goes by. In the mean time, however, Caplisp is a nights/weekends project for me. I've chosen ECL as my implementation of choice, not because it's the fastest or anything, but because it seems to be the easist to hack the internals. After some initial stumbling (1), I think I've gotten my feet under me and I should have something to show soon in regards to immutable types. I'll need to send out another post on that stuff in regards to what kind of interface we want soon. I'm not as worried about license issues right now. I prefer the GPL for everything, but I'm not too picky. As long as whatever we're using is compatable with whichever CL implmentations we're using, I don't see any problems. I've never used darcs, but I suppose it wouldn't kill me to check it out. As far as what to post where... I really appreciate the feedback from the regulars on e-lang, so anything I have to say which isn't strictly an implementation detail is likely to be posted there. I did ask recently, and MarkM said that we were quite welcome to discuss a cap-secure CL on the e-lang list. I _assume_, and I hope this will continue to be true for at least the near future, that everyone on this list is also subscribed to e-lang and cap-talk as well. Take care, James Graves (1) There are not one, not two, but three different routines called 'make_cons' to create CONS cells in ECL. But only one of them is actually used. I was, of course, modifying the wrong one, and wondering why my initialization code wasn't working. |
|
From: David M. <ra...@gm...> - 2005-08-25 07:11:10
|
Hi all, of course right after dashing off the last missive I of course remembered several more things I'd meant to mention. First, why this project, and not just help Kevin with E-on-CL? We'll almost certainly be sharing quite a bit of lower level infrastructure code in places, such as httpsy and other things that in E-on-java rely on the underlying java and aren't written in E itself, which we'll have to do for caplisp too. So why not just pitch in there? Well because, no offense to anyone, LEAST not the Mar[ck]s, I quite frankly prefer lisp! I've always been somewhat heavy into meta-programming, and growing the language to fit the problem. The lisp and forth language families are where I tend to get that kind of syntax-less goodness. My personal preference is to use forth for really small things, and Common Lisp for really big things. And I'm talking about building a really big thing with the tools built in this project, so that kicked me in the CL direction rather than a more scheme-ish or forth based effort. I think that the name "caplisp" pretty much writes itself, and has zero hits in the USPTO database of trademarks, and one totally un-related hit in google. So I think that that was pretty much a no-brainer. I picked sourceforge for hosting as it's free, permanent (you can't delete releases, only add new ones, and they won't remove stuff except for legal takedown orders for patent violation or suchnot in most cases), not tied down to myself or a specific corporation, university or other institution, even to sourceforge itself, as there are so many other mirrors of it that would never dream of deleting open source code from their archive. And a sourceforge project comes with ALL the trimmings! Hey, maybe you E guys could look into getting one, it's quick, it's easy! (and I own no stock in ANY company save my dead dotcom, so it's purely a user endorsement). I'm intending to use darcs as the version control/patch management tool for the project. It is very convenient to use, both via the web or email (or any other media, for that matter) for distributed development, and is much simpler to use than cvs, subversion, arch, etc. IMNSHO. I've setup the list caplisp-patches (on the project Lists webpage) for distribution of darcs patches between developers in realtime for anyone who commits code. darcs is setup to handle auto-patching in some very sophisticated ways, but with a very simple interface. Of course one would only want to auto-apply patches that are signed by known developers! There, those 2 emails should give everyone plenty to harangue or argue with me about! Cheers, David Mercer Tucson, AZ |
|
From: David M. <ra...@gm...> - 2005-08-25 06:45:15
|
Well as the creator of this thing I suppose I should get the ball rolling! I think I can skip the 'who are we?' portion of the program as the initial members (5 of us I think!) of this list are all from captalk/e-lang-land, as I intended it. I'm pretty sure most of the rest of the lisp community would think we're crazy, and we know how nearly universally blind almost all of the wider security community is to the theoretical shortcomings of purely ambient authority, principal based systems. So yeah, this is by definition a 'build it and they will come' move, or rather a fora to build tools that I intend to use to build software that will shake the roots of the Net. Hey, gotta have a 'take over the world' angle in there somewhere, no? How else is one to fire up the troops, as it were! :-) Anyhoo, forgive me if the following runs too long, or the tone becomes a bit too much in the style of a manifesto in parts. Here are my initial personal priorities for capability-like features to add to Common LIsp, keeping as much within the Standard as possible, breaking it only if we must, keeping as much as possible compatible with multiple CL implementations: 1. httpsy I'm pretty much of a mind with Jed on this one, start from the Network and go in. Compatibility with other cap systems is a major design goal for me, and Tyler has whipped up a very nice URI type there, and interoperability will be required for capabilities to reach any critical mass in the market. I want to leverage them with as much of the full power of lisp as I can. I don't care what other people use, but I want to be able to talk to them and their systems' objects, and I hate wheel reinvention. 2. E-style event loop concurrency with promises. Now that I can talk to others via httpsy, I'd like to be able to do so in a deadlock-free manner. I've not seen anything in the (2? 3?) years since I subscribed to e-lang/captalk that has convinced me of any better paradigm for distributed computing, at least in most general cases. Lots of code can probably be salvaged or encapsulated at a lower level from threading libraries that already exist for many CL implementations, with suitable modifications of course! 3. Factories, and whatever recursive sub-goals that ends up including. 4. Una, I don't want my Factories to make just things that sit on a HD, I want dynamic, Secure Objects a la Nick Szabo's paper on that topic. Ones that can be traded via distributed auction platforms. I'm pretty certain all of those have quite a few subgoals that need to be mapped, and the feature priority gets fuzzier and the subgoals bigger as you move down the above list. As to issues of licensing, since most of the open source capability universe appears to me to be under a Moz. or MIT style license, as are most of my preferred CL implementations (at least the self-hosted ones), I started with that as the license setting for the project on sourceforge. That's changeable with any future release if we need/want to, and of course multiple licenses and differently licensed shim libraries for linking to incompatibly licensed code is always possible (if inconvenient) if there is sufficient motivation for it. Lisp implementation: I'm starting with sbcl as my platform for initial feature development. As I'm going to use cl-uffi as my foreign library calling convention for evil things like ssl/tls that no one wants to build from scratch, most if not all of the early work (esp. on httpsy) should run on at least a half dozen or so Common Lisps. Oh and sbcl is mostly public domain, with a very few (sometimes large) bits under MIT license, which adds motivation to the previous licensing paragraph, too. Cheers and thanks for signing up for the list! Sincerely, David Mercer Tucson, AZ |
|
From: David M. <ra...@gm...> - 2005-08-24 07:57:51
|
On 8/23/05, Kevin Reid <kp...@at...> wrote: > This was going to be a lengthy message on how to make a capability > Lisp, but I haven't thought of anything further to say, so: >=20 > The Obvious Thing, to me, to do to the package system to remove the > global namespace aspect of it is to use symbols as package names. Oh that's a plenty good place to start, and should be quite a bit of work to start with! We almost have to fix that first I'd think. > (read-from-string "foo::bar") >=20 > would internally do something like >=20 > (intern "BAR" (get (intern "FOO" *package*) 'package)) >=20 > , so it is entirely relative to the current package. (The above code is > showing only this change - I expect that GET and *PACKAGE* would be > modified in some way as well.) >=20 > This eliminates the package system as a specific problem, reducing it > to the general existing problem of mutable symbol-keyed namespaces. Which sounds like a much better place to work from to me. By the way, as one could perhaps surmise from the cc line of this message, I've created the caplisp-devel mailing list and it's associated sourceforge project, as I'm familiar with their systems, it's free, and it feels more and more all the time that the caplisp folks on cap-talk/e-lang need a dedicated forum to hash out nitty gritty technical nuts and bolts on a lisp-heavy list where the amount of parens would probably exceed the sanity threshold of many e-lang/cap-talk subscribers! Not all by any means, so interested parties please head over to http://lists.sourceforge.net/lists/listinfo/caplisp-devel to subscribe! Project info (not much more than licensing info at this point) can be found= at: http://sourceforge.net/projects/caplisp I wasn't planning on making any wider mention of it until we have at least SOMETHING to show the world in the form of running code. I'd imagine that at the very least Kevin and James should be interested in paren heavy hacking! And I'm certain there will be lots of cap-talk/e-lang crossposting at times to refine some of the finer points in capability discipline, things about already solved problems, and all around general cap head scratching from time to time. Cheers, David Mercer Tucson, AZ |
|
From: David M. <ra...@gm...> - 2005-08-24 07:28:08
|
This is merely a test message for the list, and it can be safely ignored! -David |
