Time to think about parallel Smalltalk stuff
Brian T. Rice
water at tunes.org
Tue Jan 25 01:07:26 UTC 2005
Mark Miller <markm at caplet.com> said:
> [cross posted]
>
> Brian Rice wrote:
> > While E has a narrow focus on security, the concurrency model may be
> > taken without the security/crypto design implications that go with it.
>
> I see it as a "primary" focus rather than a narrow one, but perhaps this is
a
> matter of taste. In any case, I agree that E's concurrency model is of value
> independent of E's security model. And thanks.
Sorry; I really didn't think anyone would notice this, and was sort of
ranting based on some undiscussed frustrations with trying a deeper
integration of E and Smalltalk-ish implementations than Squeak-E or E-on-
Squeak or even E-on-CL (I've been conversing with Kevin Reid on IRC for some
time now).
> > In my case, I am working with such an option for Slate as a concurrent
> > language extension, and eventually cryptographic security can be added
> > as an optional transport layer.
>
> So, are you interested in building something secure or not? I'm confused.
Yes, but gradually. The implementation has started from the bare working
prototype, so we don't support a lot of things that are necessary for full-E
semantics yet, and have been focussing on getting the language and library
design correct and fully debugged - security issues have been kept in mind,
but only in regards to library designs and partly on language design. I
basically collect every email I possibly can that's relevant and
collate/sort/glean from them.
The approach to take on all of E's semantics partially relies on some
language features which are currently not implemented, though they were
present in previous Slate versions (namely, subjective programming), as well
as things like weak references and network programming support - these are
all currently missing due to various historical choices and lack of developer
time (everyone works on this part time, with ZERO funding).
> > I also want to focus on Erlang-style
> > signalling between processes, which goes a step further than broken
> > promise resolution in E.
>
> Sounds like a promising approach. I like Erlang. As you develop this, I'd
like
> to hear more about it, and I'm sure other e-lang'ers would too. Thanks.
Okay. I'll write something up on that soon, but I have to address remaining
basic concurrency issues first.
> > Of course, the E fellows aren't directly helpful with this kind of
> > effort, simply because their whole focus is security and their example
> > of E. It's difficult to bring up an issue with them and not get just
> > the security slant, so I've had to work it out myself.
>
> From web searching
>
> http://www.google.com/search?
as_q=Brian+Rice&num=50&hl=en&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_f
t=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=eros-
os.org&safe=off
>
> the only messages I could find that you've posted to e-lang are
> http://www.eros-os.org/pipermail/e-lang/2004-August/010007.html
> and
> http://www.eros-os.org/pipermail/e-lang/2004-July/009938.html
>
> Could you please point us at the message where you asked about concurrency,
> and we were unhelpful in our responses? I would appreciate it if you'd give
> the e-lang community another chance before writing us off as unhelpful. If
you
> are indeed interested in concurrency without security, please make that
clear,
> and perhaps you'll find us more helpful. Thanks.
Well, I'm interested in concurrency /before/ security, since we currently
have NO concurrency, which that email stated. I'm guilty here of turning
hyperbole into lying, and I do apologize. :( I'll try to be more
forthcoming / straightforward in the future. I was mostly annoyed that there
was zero response from my email, and that E's implementation is so steeped in
Java backwardsness that I spent months just trying to decipher any lessons it
had (there's an extended rant based on this with my frustrations with the E
language as a whole - I'm subscribed to the mailing list, and 80% of the
content is noise and confusion surrounding this horrible inflexible syntax!
I'm aghast. After a year toying with E, I still can't read it or program in
it.). Only recently did I realize how simple a large part of it is to port,
although there are a couple of extremely sticky points when you want an
efficient implementation on a VM with one-bit-tagged references rather than
full References, and also where open implementation is the principle of
design.
> > Also, from what I understand from following the Croquet and E projects,
> > it seems that the interest from Croqueteers towards E has not seen a
> > real follow-through, at least from the E perspective, so don't count on
> > them to deliver a full solution to the integration issues. It's a tough
> > task and requires a lot of focus.
>
> I agree, though I'm still hopeful that the Croquet project might yet decide
to
> take security seriously before it's too late. But if you're not interested
in
> security, what problems with Croquet are you referring to?
I am interested in security, so I am referring to that, but also the
concurrency model requires a fairly deep re-thinking to integrate properly -
an activity that I don't think they have time for. I've also been monitoring
the Croquet list and it's been inundated with publicity-fallout, since people
are posting many different ideas and there's very little response to it. They
have to focus on the technical aspects and get those out of the way - and
once that's done, they'll have a large body of working code to maintain - the
Squeak situation all over again!
I do apologize again for the exaggerations and manner of introduction. It
really did bother me that I didn't get a response after people had been
casting about for ideas on how to integrate and even cross-posting
announcements on collaboration. I am often frustrated: I have this fully open
system and project organization that allow for lightning-fast integrations of
ideas when utilized, and it feels like no one cares! We created this project
*specifically* to integrate hundreds of good ideas, and have this nice long
period of gestation before it's useful enough that users might flock to use
it, so it should be taken advantage of! But I have this tendency to try to
keep things quiet on the PR front since people interpret talk as promises,
but the number of people interested in contributing to a kernel system is
really quite small (so we clearly can't keep all of them with such a tiny
group). Even just one person weighing in and contributing can have a huge
effect!
I don't know quite what else to say. You or someone in your project should
check out the website and reference manual and make some kind of commitment
to the effort. We /will/ make it worth your while if the collaboration is
beneficial - that is the deal we offer - you'll get back what you put into
it, and optimistically, more.
More information about the Squeak-dev
mailing list
|