I tried to send this earlier, but I got a mailer error, so let's try again:
On Sat, 29 Mar 2003 21:33:32 +0100, <goran.hultgren at bluefish.se> wrote:
> Andrew Berg <andrew_c_berg at yahoo.com> wrote:
> [SNIP of JIT-ideas that others like Markus Denker, Ian Piumarta etc
> knows much more about]
>> By the way, the last project I spent about 2 months worth of evenings
>> working on was embedding Mozilla into Squeak. I gave up because: I
>> Interesting. Wasn't that what Exobox did too? I think so. Anyway, even
> if it didn't work out it would be interesting to hear the story. At
> least we could avoid others trying to do the same! :-)
>> regards, Göran
>
There's really not much of a story. I started into it, made a primitive
for calling the XPCOM's version of IDispatch (if that does not make sense
to you, don't worry about it) and started writing the code to parse out
their type library. About then I realized that there was a fundamental
flaw in what I was planning to do. I was planning to embed an X window
into Squeak, so that Mozilla's output could show up inside of Squeak, and
then use XPCOM to control it from Squeak. So far, so good, but it would
not really look much like it was running inside of Squeak. It would really
be running on top of Squeak, so Squeak windows would not be able to overlap
the Mozilla windows, etc. Also, the display managment aspect would only
work for X. I could probably cobble together something for Windows as
well, but I would have ended up writing a bunch of platform-specific code
in order to use a "platform independant" browser along with a platform
independant language. And it would not have ended up even working that
well together. Plus, in retrospect, I probably should have written a C
wrapper for the XPCOM version of IDispatch so that I could call it with
plain old FFI.
Also, how to write the part to allow XPCOM components to send messages to
Smalltalk objects was unclear in my head, which meant that it was probably
going to end up being a bad design, and I would have gotten to rewrite it a
couple of times in order to figure out how not to do it. That's fine for
stuff I'm getting paid to do, but for freebie/volunteer stuff I'd prefer to
be able to finish it.
Right now I am (absurdly enough) contemplating:
1) Implementing (at least a working subset of) SSL in PureSqueak.
2) Fiddling around with the VM and trying to write a JIT (almost)
completely in Squeak. Well, it would be completely in Squeak, I guess, but
a little bit of it would be in slang and influencing the VM, but most of it
would just be Plain Old Smalltalk.
3) Embedding Perl into Squeak using FFI and libperl.so (my Linux box only
has libperl.a, but I assume that with a little massaging I can make a
libperl.so). Why would I want to do that? Well, DBI is an example of
something that Perl has (and has a lot of) that IMHO Squeak could use a bit
more of. It would be real whizzy if I could make Perl proxy objects which
somehow tie back to Squeak objects, but that does not look quite as easy.
Maybe a real Perl hacker could show me how easy it really is.
The trouble is that any one of these is a large enough project that I'd be
working on it for months or years before it was usable, by which time
Squeak would probably be up to version 5 or 6 at the rate things go!
-andrew
--
andrew_c_berg at yahoo.com