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