functionality of Socket>>socketError

Russell Penney russell.penney at tincanct.com
Sun Aug 29 05:45:22 UTC 2004


I must admit I do not see the reason behind putting this sort of code in the
Squeak side. I see it as extremely ugly.

The "just do something like..." below is fine if you are looking at a Mac
but add PC, Unix (several flavours), Acorn, Handhelds, etc and the code
starts becoming a dog's breakfast!! Much like FileDirectory handling is now
(lots of lovely exceptions scattered throughout the image).

Why not have the primitives return a symbol which is a POSIX error name? We
have a list of codes that can be returned from the Socket primitives and
each platform VM is coded to that standard. Then you don't need to know what
error code on each platform is, the code in the Squeak side is standard and
you don't need a platform mapping class.
Plus people who know POSIX stuff :) can at least make some sense of what is
going wrong.

Russell

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Kamil Kukura
> Sent: Friday, 27 August 2004 6:48 PM
> To: The general-purpose Squeak developers list
> Subject: Re: functionality of Socket>>socketError
> 
> John M McIntosh wrote:
> 
> > Let me turn that around and suggest code in Smalltalk versus in C
> > primitives, then anyone can participate. Not that one can't suggest
> > VM  changes, it's just way easier for all parties if it's in the
> image...
> >
> > englishErrorForSocketPrims: anErrorCode
> >     ^EnglishErrorCodes for: anErrorCode hint: #SocketPrims
> >
> > where hint tells me something about the primitive being used, thus
> > I've  a handle on the fact it's from the SocketPrims
> 
> I agree. Having resolution of platform or dialect specific
> codes/messages right in the image seems to provide at some degree of
> abstration level the support for keeping up the independence. In this
> case I would delegate a resolving into english messages to NetworkError
> and its children though.
> 
> > The just do something like
> >     platform _ Smalltalk platformName.
> >         platform = 'Mac OS' ifTrue:
> >          [Smalltalk osVersion asInteger >= 1000
> >             ifTrue: [stuff for osx ]
> >             ifFalse: [stuff for os 9 and earlier]].
> > "Note that actually for os-x you would need to consider VM version to
> > demarcate OpenTransport versus BSD sockets plus another check for
> > Classic under os-x and I'm not quite sure how to get a handle on
> > which  operating system type & version you have..."
> 
> I like that. Now if only Win32 VM could provide #socketError gives some
> actual code rather than zero all the time. I'm going to give a try to
> compile Windows VM and try to get deeper inside to see what's going on.
> The only mailing list for VM development I see is at sourceforge.net and
> perhaps one should be created at SqF if CVS is going to move there as
> Tim mentioned in
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-
> August/081460.html
> 
> > The stuff for the operating system then would resolve that 61 means
> > #ECONNREFUSED, versus 111 or 146...
> >
> > I would suspect there is a reasonably small set of errors code
> > between  all unix flavors and also have reasonable meaning in os-9 and
> > windows. Additional error codes could be added per operating
> > system/version as  the coder see fit.
> 
> Hmm, this brings the question of some plaform/dialect mapping support.
> For example in Seaside there's SeasidePlatformSupport class providing
> such thing. I think it's too soon to model something on system level but
> time will tell. I believe having strong support for crossplatform and
> crossdialect issues would give Squeak a nice boost.
> 
> --
> Kamil
> 






More information about the Squeak-dev mailing list