Ian,

thanks for all the great work sorting this out.  Were the sockets
reasonable across the different flavors or *nix?  I had fun getting in
there!

a few notes on sockets and things vm, below...

cheers,
Rob

Ian Piumarta wrote:

[snip]

> 
> Well, this kind of ignores an important source of headaches.  Squeak
> is trying to use .so files in cruel and unusual ways that many Unix
> designers never dreamed of (even in their worst nightmares).  On some
> platforms (including at least one of the supported ones, I might add)
> it is *impossible* for the loader to figure out the dynamic
> dependencies for the VM unless the plugins are (i) installed in a
> standard place that ld.so knows about; (ii) prefixed with "lib", and
> (iii) suffixed by ".so.<maj>.<min>".  This makes the build kind of
> tricky, since a partial install is absolutely required at "half-time".

Is it not possible to use an .squeakrc file to specify module paths to
the LD_LIBRARYPATH (or something) env variable?  We could also create
soft links to the ".so.<maj>.<min>".

[snip]


>  - For Andreas's amusement: the Unix VM now understands how to look for
>    and read an (optionally gzipped) internal image file.  (He asked me
>    last week: "Do you think it would be possible to make a Unix VM
>    that ...", and I took it as a challenge. ;-)  In the above directory
>    are also (and FOR ENTERTAINMENT PURPOSES ONLY):

Sweet!  Could you embed font/bitmap resources in the vm or in a plugin?
 
> 
> 2.9a is also kind of ready, but before putting it up for FTP I'm
> waiting until the new three-primitive Socket and GUI event semantics
> are finalised so that preliminary versions of the relevant code can go
> into the relevant places.  When Andreas gives the green light I'll be
> onto it.  (Besides, getting 2.8 ready for prime time has to take
> priority -- and there's a way to go yet.)


Could you explain what the 3 *prim* socket/event semantics are?

[snip]
 
> hum...), and a half-hearted test of Sockets reveals that peers are
> responding to all the starfleet regulation hailing frequencies.  I
> haven't gone over some of the new stuff with a fine-toothed comb yet
> (and there _are_ problems that I am aware of, for example in the new
> socket code someone has modified something someplace that puts the
> fds[] array out of sync with a private socket struct causing "bad
> match" errors --

This looks like it is occuring in the sqSocketCloseConnection prim.  I
am guessing that with me sending aioDisable at the beginning, when the
close is delayed, the async branch is taken and the
aioHandler("closeHandler") is called.  I don't think it is happening
during data send/receive is it?

Several of the Network tests still fail, including a few that try to
send really large packets.  


> I'll fix this while adding the three-prim socket
> stuff for 2.9a, then retrofit the working code to 2.8).  Par
> conséquence I don't really want to vouch for the quality of this
> "2.8 hackers release" for the moment.  Don't upgrade your granny's
> pacemaker with it.

but the new directory structure will help get us there.  Nice.


> That's it.  Time for bed.  Over and out.  (And above all, enjoy!)
> 
> Ian

rob

PS - I'll update the UnixVMBuilder to reflect the new directory
structure this weekend.  It would be really cool if someone could write
a quick CProject class that we could persist with the
SmartFileDictionary, and then use a CEnvironment to exec the make
commands.  Any takers?

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!