I'm investigating if Socket>>socketError is usable for anything. Could someone try this on Linux or MacOS:
s _ Socket new. s connectNonBlockingTo: #(127 0 0 1) asByteArray port: 12345.
and then print
s socketError
on Windows (WinXP) I'm still getting zero.
Kamil Kukura wrote:
I'm investigating if Socket>>socketError is usable for anything. Could someone try this on Linux or MacOS:
s _ Socket new. s connectNonBlockingTo: #(127 0 0 1) asByteArray port: 12345.and then print
If here is some pause (inspecting s)...
s socketErroron Windows (WinXP) I'm still getting zero.
(and self socketError in the inspector) then under Linux I get: 111.
On Linux I got 111.
Ken
On Tue, 2004-08-24 at 14:35, Kamil Kukura wrote:
I'm investigating if Socket>>socketError is usable for anything. Could someone try this on Linux or MacOS:
s _ Socket new. s connectNonBlockingTo: #(127 0 0 1) asByteArray port: 12345.and then print
s socketErroron Windows (WinXP) I'm still getting zero.
On Aug 24, 2004, at 3:35 PM, Kamil Kukura wrote:
I'm investigating if Socket>>socketError is usable for anything. Could someone try this on Linux or MacOS:
s _ Socket new. s connectNonBlockingTo: #(127 0 0 1) asByteArray port: 12345.
and then print
s socketError
on Windows (WinXP) I'm still getting zero.
-- Kamil
On Mac OSX vm 3.7.4b1 I get 61.
Frank
I'll be the first to say this is all a bit ill defined. You really need to check the C source code for the socket support code to understand what is happening. For os-x on or after the carbon VM 3.5.1b2 we switched to the Unix BSD socket code. The socketError primitive returns the results of capturing errno, or getsockopt(s, SOL_SOCKET, SO_ERROR, (void *)&error, &errsz) depending on what is happening at the time. This all assumes us VM folks capture the error data and don't have multiple calls trashing things (accept processing comes to mind).
Really one needs to review the C source code for the called primitive at the time of the error is required to understand where the data comes from.
On the other hand, sticking some documentation in the Socket>>socketError could be useful.
in errno.h we find #define ECONNREFUSED 61 /* Connection refused */ That seems like a reasonable error, base on the fact we see that errno when the connection request fails.
FYI pre VM 3.5.1b2 the Open Transport code would return either
kENOTCONNErr = -3256, /* Socket is not connected */ or one of another 74 numbers from MacErrors.h I'd think you would get kECONNREFUSEDErr = -3260, /* Connection refused */
I see that the window source which btw now has the three semaphore support (Yah...)
Dated: * RCSID: $Id: sqWin32NewNet.c,v 1.9 2004/01/19 22:25:51 andreasraab Exp $
It calls WSAGetLastError() from time to time to collect the error information. However I suspect you'll need to confirm which windows VM you are using, then backtrack to the source code to see if having zero is the expected results....
On Aug 24, 2004, at 5:50 PM, Frank Caggiano wrote:
On Aug 24, 2004, at 3:35 PM, Kamil Kukura wrote:
I'm investigating if Socket>>socketError is usable for anything. Could someone try this on Linux or MacOS:
s _ Socket new. s connectNonBlockingTo: #(127 0 0 1) asByteArray port: 12345.
and then print
s socketError
on Windows (WinXP) I'm still getting zero.
-- Kamil
On Mac OSX vm 3.7.4b1 I get 61.
Frank
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh wrote:
I'll be the first to say this is all a bit ill defined. You really need to check the C source code for the socket support code to understand what is happening. For os-x on or after the carbon VM 3.5.1b2 we switched to the Unix BSD socket code. The socketError primitive returns the results of capturing errno, or getsockopt(s, SOL_SOCKET, SO_ERROR, (void *)&error, &errsz) depending on what is happening at the time.
That's great even though I've thought that BSD socket's API is unified on error codes. Right now, there's no way to tell if outgoing connection to remote host failed because of network error such as connection refused, no route to host, network unreachable, etc. or because there was real timeout while connecting.
This all assumes us VM folks capture the error data and don't have multiple calls trashing things (accept processing comes to mind).
I didn't quite get that. Multiple calls inside VM or transitions in interpreting primitive calls?
Really one needs to review the C source code for the called primitive at the time of the error is required to understand where the data comes from.
On the other hand, sticking some documentation in the Socket>>socketError could be useful.
Question is, if this method could be used for error handling at all. I can imagine there would be another socket state (Socket class>>initialize) something like "Failed" which would indicate an error condition. Then #socketError could identify problem by some code - but we would need to settle on something crossplatform.
in errno.h we find #define ECONNREFUSED 61 /* Connection refused */ That seems like a reasonable error, base on the fact we see that errno when the connection request fails.
FYI pre VM 3.5.1b2 the Open Transport code would return either
kENOTCONNErr = -3256, /* Socket is not connected */ or one of another 74 numbers from MacErrors.h I'd think you would get kECONNREFUSEDErr = -3260, /* Connection refused */
On Linux I found in asm-generic/errno.h: #define ECONNREFUSED 111 /* Connection refused */
so it is different everywhere...
I see that the window source which btw now has the three semaphore support (Yah...)
Dated: * RCSID: $Id: sqWin32NewNet.c,v 1.9 2004/01/19 22:25:51 andreasraab Exp $
It calls WSAGetLastError() from time to time to collect the error information. However I suspect you'll need to confirm which windows VM you are using, then backtrack to the source code to see if having zero is the expected results....
3.6.2 as found in distribution ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.6/win/ and I assume it is one published on http://sourceforge.net/projects/squeak/ which seems to have sqWin32NewNet.c in version 1.7 - I'll try to build windows VM from CVS source.
On Aug 25, 2004, at 2:08 AM, Kamil Kukura wrote:
This all assumes us VM folks capture the error data and don't have multiple calls trashing things (accept processing comes to mind).
I didn't quite get that. Multiple calls inside VM or transitions in interpreting primitive calls?
Multiple host os api calls within a single primitive call, resulting in perhaps a rather generic error code, question then is which host os api call failed?
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
I'd like to make a suggestion to the VM maintainers. It would be nice to get the actual error message back from the OS, but one that would be platform independent, so that a developer could, if they choose, try to recover from the error.
For example, the C macro ECONNREFUSED is mapped to 61 on OSX, 111 on Linux, and 146 on Solaris; and ETIMEDOUT is mapped to 60 on OSX, 110 on Linux, and 145 on Solaris. (sorry, no Windows examples, I've not coded in Windows since the early 90's.)
I think it would be nice to have a new primitive that returns a platform independent code instead of the raw error code. Then we could add a new method that gives the developer access to that value.
As an aside to Kamil Kukura, you might want to use the message statusString for now, I think it might work better than socketError does for now.
I'll be the first to say this is all a bit ill defined. You really need to check the C source code for the socket support code to understand what is happening. For os-x on or after the carbon VM 3.5.1b2 we switched to the Unix BSD socket code. The socketError primitive returns the results of capturing errno, or getsockopt(s, SOL_SOCKET, SO_ERROR, (void *)&error, &errsz) depending on what is happening at the time. This all assumes us VM folks capture the error data and don't have multiple calls trashing things (accept processing comes to mind).
Really one needs to review the C source code for the called primitive at the time of the error is required to understand where the data comes from.
On the other hand, sticking some documentation in the Socket>>socketError could be useful. -- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John Pfersich jp1660@att.net wrote:
I'd like to make a suggestion to the VM maintainers. It would be nice to get the actual error message back from the OS, but one that would be platform independent, so that a developer could, if they choose, try to recover from the error.
It's quite tricky to get both actual and platform independent - but worth trying and int the case of sockets it might be plausible since so many socket apis are based on bsd.
I think it would be nice to have a new primitive that returns a platform independent code instead of the raw error code. Then we could add a new method that gives the developer access to that value.
Nah, that's not the way to implement it. The problem with that is, as John mentioned, the time domain validity. A global error flag is a truly dumb idea.
I have code that allows a prim to return an error code as a virtual method temp. That allows you to check quite precisely what the actual error was _from that prim_. Using the new stuff well requires quite a lot of work to make prims actually return a meaningful value so don't expect it soon. It also requires a recompile of every method calling a prim and quite possibly some work on the external prim calling stuff.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim "Bother!" said Pooh, as Piglet pressed <START> on the Microwave...
Ah, don't forget the SUnits to retest all these rewritten primitives. That would help with folks doing porting.
On Aug 25, 2004, at 12:32 PM, Tim Rowledge wrote:
I have code that allows a prim to return an error code as a virtual method temp. That allows you to check quite precisely what the actual error was _from that prim_. Using the new stuff well requires quite a lot of work to make prims actually return a meaningful value so don't expect it soon. It also requires a recompile of every method calling a prim and quite possibly some work on the external prim calling stuff.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim "Bother!" said Pooh, as Piglet pressed <START> on the Microwave...
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh wrote:
Ah, don't forget the SUnits to retest all these rewritten primitives. That would help with folks doing porting.
Just some decent *specifications* of what the prim is supposed to do, what side-effects are allowed/banned/needed, permissable failure cases, all that would be nice.
Consider the looseness of, for example, ioSetMode:fullscreen: (or whatever it's called). Not a fun prim to try to implement. Then there are a bunch of obsoletes to get rid of... sigh, a porter's job is never done.
tim
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
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..."
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.
On Aug 25, 2004, at 10:46 AM, John Pfersich wrote:
I'd like to make a suggestion to the VM maintainers. It would be nice to get the actual error message back from the OS, but one that would be platform independent, so that a developer could, if they choose, try to recover from the error.
For example, the C macro ECONNREFUSED is mapped to 61 on OSX, 111 on Linux, and 146 on Solaris; and ETIMEDOUT is mapped to 60 on OSX, 110 on Linux, and 145 on Solaris. (sorry, no Windows examples, I've not coded in Windows since the early 90's.)
I think it would be nice to have a new primitive that returns a platform independent code instead of the raw error code. Then we could add a new method that gives the developer access to that value.
As an aside to Kamil Kukura, you might want to use the message statusString for now, I think it might work better than socketError does for now.
I'll be the first to say this is all a bit ill defined. You really need to check the C source code for the socket support code to understand what is happening. For os-x on or after the carbon VM 3.5.1b2 we switched to the Unix BSD socket code. The socketError primitive returns the results of capturing errno, or getsockopt(s, SOL_SOCKET, SO_ERROR, (void *)&error, &errsz) depending on what is happening at the time. This all assumes us VM folks capture the error data and don't have multiple calls trashing things (accept processing comes to mind).
Really one needs to review the C source code for the called primitive at the time of the error is required to understand where the data comes from.
On the other hand, sticking some documentation in the Socket>>socketError could be useful.
--
== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ====================================================================== == ===
-- ---------------------------------------------------- Source code in files. How quaint. -- Kent Beck
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Wed, Aug 25, 2004 at 01:13:10PM -0700, 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
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]].
Good point, but note also that strerror() and strerror_r() may already do everything that is necessary. I'm not sure if they are available on all platforms, but I think that Unix, Windows, and OS/X would be covered.
For example, a non-thread-safe implementation could look like this (excerpted from some unreleased OSProcessPlugin code):
primitiveErrorMessageAt: errno "Answer a string describing an error message" | index errMessage p | self export: true. self var: 'p' declareC: 'char *p'. index _ interpreterProxy stackIntegerValue: 0. p _ self cCoerce: (self cCode: 'strerror(index)' inSmalltalk: ['']) to: 'char *'. errMessage _ self stringFromCString: p. interpreterProxy pop: 2; push: errMessage
stringFromCString: aCString "Answer a new String copied from a null-terminated C string. Caution: This may invoke the garbage collector." | len newString stringPtr | self var: 'aCString' declareC: 'char *aCString'. self var: 'stringPtr' declareC: 'char *stringPtr'. len _ self cCode: 'strlen(aCString)' inSmalltalk: [0]. newString _ interpreterProxy instantiateClass: interpreterProxy classString indexableSize: len. stringPtr _ interpreterProxy arrayValueOf: newString. self cCode: '(char *)strncpy(stringPtr, aCString, len)'. ^ newString
Dave
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.ht...
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.
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@lists.squeakfoundation.org [mailto:squeak-dev- bounces@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
On Sun, Aug 29, 2004 at 03:45:22PM +1000, Russell Penney wrote:
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).
Well, no, it doesn't need to be organized poorly. See OSProcessAccessor and subclasses (in OSProcess package) for an example of how to approach it.
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.
But yes, I agree that your suggestion here might be a simpler approach for reporting socket errors. (I'm no expert on POSIX sockets, so I don't know if this is workable across a range of platforms.)
Dave
On Sunday 29 August 2004 6:43 am, David T. Lewis wrote:
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.
But yes, I agree that your suggestion here might be a simpler approach for reporting socket errors. (I'm no expert on POSIX sockets, so I don't know if this is workable across a range of platforms.)
That doesn't fix the problem that you get when your primitive calls several API calls, each of which can return roughly the same set of errors.
In cases like that you'd either have to: * pass back the *first* error code and let people guess what it meant (i.e. what API call generated it), or * generate a new error code that names a particular error condition * include more context (like for instance what the API call was that generated the error)
I guess my point was more the fact that we should come up with a standard error list that can be returned from a set primitive. What they are called I don't really care, I just used the POSIX example as... well... an example :)
However I do think that a lot of the POSIX error symbols can be used even though many APIs are called. For example #ECONNREFUSED could be returned from a socket open primitive and even though you have no idea/don't care what the primitive is doing internally; it is pretty obvious what the error means.
The main thing would be to "standardise" the interfaces between Squeak and primitives to MINIMISE the amount of platform specific code in very crucial parts of the kernel. I don't think it is hard to do; I think the problem is that very few people are willing to touch the guts and so we are left with the status quo which is getting old and hairy.
Russell
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Monday, 30 August 2004 1:19 AM To: The general-purpose Squeak developers list Cc: David T. Lewis Subject: Re: functionality of Socket>>socketError
On Sunday 29 August 2004 6:43 am, David T. Lewis wrote:
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.
But yes, I agree that your suggestion here might be a simpler approach
for
reporting socket errors. (I'm no expert on POSIX sockets, so I don't
know
if this is workable across a range of platforms.)
That doesn't fix the problem that you get when your primitive calls several API calls, each of which can return roughly the same set of errors.
In cases like that you'd either have to:
- pass back the *first* error code and let people guess what it meant
(i.e. what API call generated it), or
- generate a new error code that names a particular error condition
- include more context (like for instance what the API call was that
generated the error)
-- Ned Konz http://bike-nomad.com/squeak/
If I may flame in general for a moment, I really dislike platform-specific codes creaping up into the image at all. I agree that many things are nice to write in Smalltalk instead of C, but presently, we have no good way to do that for platform-specific code. Our best effort is to include in every image the platform-specific code for every platform the image might ever run on. This is impossible in general, though, because Squeak runs on ever more platforms as time goes by. I find it a very sad thought that someone could have a perfectly valid VM and yet not be able to run standard Squeak images.
There are solutions to this general problem that aren't too hard. For example, we could have a global variable Platform that is initialized by a file-in that the VM supplies. We could even work out a caching scheme so that if an image is loaded on the same platform twice, it does not reload the Platform variable. But at any rate, we do not have such an ability right now, and so I think it is a bad idea to have platform-specific stuff at the image level.
On the specific problem, I think that any error-returning method should have platform-independent codes. And actually, we already have a platform-independent way to report the errors for class Socket: the method statusString is already sufficient. The only thing it doesn't do is tell you *why* a failure happened, but I don't think that is sufficient reason to introduce non-portability.
Thus, I say we should axe this method, or at least rename it to something long and obnoxious like #reallyUnportableErrorCodePleaseDoNotInvokeThisMethod. Then people who want the method for debugging can use it, but most code will take the hint and use the portable API.
-Lex
Lex Spoon wrote:
If I may flame in general for a moment, I really dislike platform-specific codes creaping up into the image at all. I agree that many things are nice to write in Smalltalk instead of C, but presently, we have no good way to do that for platform-specific code. Our best effort is to include in every image the platform-specific code for every platform the image might ever run on. This is impossible in general, though, because Squeak runs on ever more platforms as time goes by.
Hmm, I somehow don't see how is it impossible when it is happening right now, see subclasses of FileDirectory. Downside I see is that it makes image rather bigger, having code inside which will never be used while running on same platform.
I find it a very sad thought that someone could have a perfectly valid VM and yet not be able to run standard Squeak images.
I can't imagine an example of such situation. Maybe I don't exactly get what is "standard" image and what is "perfectly valid" VM.
There are solutions to this general problem that aren't too hard. For example, we could have a global variable Platform that is initialized by a file-in that the VM supplies. We could even work out a caching scheme so that if an image is loaded on the same platform twice, it does not reload the Platform variable. But at any rate, we do not have such an ability right now, and so I think it is a bad idea to have platform-specific stuff at the image level.
I can imagine a scenario of having auxiliary small image with platform specific containment. I don't know if such thing would be possible. It brings out a lot of questions as well.
On the specific problem, I think that any error-returning method should have platform-independent codes. And actually, we already have a platform-independent way to report the errors for class Socket: the method statusString is already sufficient. The only thing it doesn't do is tell you *why* a failure happened, but I don't think that is sufficient reason to introduce non-portability.
In this specific case it tells you why connection was not successful. But reason reported (connection timed out) is somewhat different from reality (connection refused). But of course if purity of image should be touched by this I also prefer not involve platform-specific code into the image. I guess I'll better do like I don't see class PowerManagement and classes alike inside.
Thus, I say we should axe this method, or at least rename it to something long and obnoxious like #reallyUnportableErrorCodePleaseDoNotInvokeThisMethod. Then people who want the method for debugging can use it, but most code will take the hint and use the portable API.
No need. I freely resign to solution that my application just reports "there was a network error". It just leaves me in little sadness that my java, c# and other friends are more matured in this way. Sorry for disturbing.
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Frank Caggiano -
John M McIntosh -
John Pfersich -
Kamil Kukura -
Ken Causey -
Lex Spoon -
Ned Konz -
Russell Penney -
Stephan Rudlof -
tim Rowledge -
Tim Rowledge