Mantis 7624. Originally reported as an error pulling out a badge. Investigation reveals that the primitive is failing to return the local IP address.
<primitive: 'primitiveResolverLocalAddress' module: 'SocketPlugin'> in class NetNameResolver.
Works correctly in Win7 and Mac OS X.
FreeBSD has a reputation of dealing with network configuration differently than Linux.
On Tue, 17 May 2011, Gary Dunn wrote:
Mantis 7624. Originally reported as an error pulling out a badge. Investigation reveals that the primitive is failing to return the local IP address.
<primitive: 'primitiveResolverLocalAddress' module: 'SocketPlugin'> in class NetNameResolver.
Works correctly in Win7 and Mac OS X.
FreeBSD has a reputation of dealing with network configuration differently than Linux.
The primitive can't work correctly, because it only returns one local address, but a host can have any number of such addresses. If you bring up a new network interface, then the primitive will return the address of the new interface (on windows), so using this primitive from different parts of the same program can result in unexpected behavior.
Levente
-- Gary Dunn Honolulu
I understand what you are saying, but my point is that it works for me on Win7 and OS X. Those machines have wired interfaces and WiFi, only the WiFi is active. Win7 and FreeBSD are on the same box. It works for Win7, not FreeBSD.
I was wondering what happens when the routine finds two active interfaces, but for anything other than a router that would be unlikely, if not dangerous.
Gary Dunn Open Slate Project http://openslate.org
On May 17, 2011 9:13 AM, "Levente Uzonyi" leves@elte.hu wrote:
On Tue, 17 May 2011, Gary Dunn wrote:
Mantis 7624. Originally reported as an error pulling out a ...
The primitive can't work correctly, because it only returns one local address, but a host can have any number of such addresses. If you bring up a new network interface, then the primitive will return the address of the new interface (on windows), so using this primitive from different parts of the same program can result in unexpected behavior.
Levente
-- Gary Dunn Honolulu
I was wondering what happens when the routine finds two active interfaces, but for anything other than a router that would be unlikely, if not dangerous.
I disagree. I have several boxes that are on two separate networks, thus two active interfaces and they are not routers.
Elliot
On Wed, May 18, 2011 at 10:13 AM, Elliot Finley efinley.lists@gmail.com wrote:
I was wondering what happens when the routine finds two active interfaces, but for anything other than a router that would be unlikely, if not dangerous.
I disagree. I have several boxes that are on two separate networks, thus two active interfaces and they are not routers.
Yup. I run virtual machines (VMware, not Smalltalk) for development, and that also tends to result in a lot of interfaces and IP address. My desktop machine has 3 active interfaces and 3 addresses. One of my virtual machines has 2 interfaces, with a total of 5 IP addresses, and the other has 2 interfaces and 2 addresses.
We should probably just get rid of that primitive entirely.
Colin
Ok guys, I guess you are the exception that proves the rule ... something like that. My perspective is high school students in a classroom-like setting. You give me your IP address, I make a badge for you, and I can drop a morph on your badge to send it to you. You need a way to discover your IP address. Nice to be able to do it in Squeak.
Gary Dunn Open Slate Project http://openslate.org
On May 18, 2011 10:02 AM, "Colin Putney" colin@wiresong.com wrote:
On Wed, May 18, 2011 at 10:13 AM, Elliot Finley efinley.lists@gmail.com wrote:
I was wondering ...
Yup. I run virtual machines (VMware, not Smalltalk) for development, and that also tends to result in a lot of interfaces and IP address. My desktop machine has 3 active interfaces and 3 addresses. One of my virtual machines has 2 interfaces, with a total of 5 IP addresses, and the other has 2 interfaces and 2 addresses.
We should probably just get rid of that primitive entirely.
Colin
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
- Bert -
On 18.05.2011, at 23:22, Gary Dunn wrote:
Ok guys, I guess you are the exception that proves the rule ... something like that. My perspective is high school students in a classroom-like setting. You give me your IP address, I make a badge for you, and I can drop a morph on your badge to send it to you. You need a way to discover your IP address. Nice to be able to do it in Squeak.
Gary Dunn Open Slate Project http://openslate.org
On May 18, 2011 10:02 AM, "Colin Putney" colin@wiresong.com wrote:
On Wed, May 18, 2011 at 10:13 AM, Elliot Finley efinley.lists@gmail.com wrote:
I was wondering ...
Yup. I run virtual machines (VMware, not Smalltalk) for development, and that also tends to result in a lot of interfaces and IP address. My desktop machine has 3 active interfaces and 3 addresses. One of my virtual machines has 2 interfaces, with a total of 5 IP addresses, and the other has 2 interfaces and 2 addresses.
We should probably just get rid of that primitive entirely.
Colin
On Thu, 19 May 2011, Bert Freudenberg wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
It's not in the Trunk yet. I extracted and converted the code, it's in the Inbox now, Network-ul.100.mcz. I didn't push it to the Trunk, because 1) Cog doesn't support the new primitives and the fallback code has to be tested thoroughly. 2) I don't really like SocketAddress, because IIRC it's like CompiledMethod, in the sense that it's a ByteArray, but it's storing pointers/words. 3) SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
Levente
- Bert -
On 18.05.2011, at 23:22, Gary Dunn wrote:
Ok guys, I guess you are the exception that proves the rule ... something like that. My perspective is high school students in a classroom-like setting. You give me your IP address, I make a badge for you, and I can drop a morph on your badge to send it to you. You need a way to discover your IP address. Nice to be able to do it in Squeak.
Gary Dunn Open Slate Project http://openslate.org
On May 18, 2011 10:02 AM, "Colin Putney" colin@wiresong.com wrote:
On Wed, May 18, 2011 at 10:13 AM, Elliot Finley efinley.lists@gmail.com wrote:
I was wondering ...
Yup. I run virtual machines (VMware, not Smalltalk) for development, and that also tends to result in a lot of interfaces and IP address. My desktop machine has 3 active interfaces and 3 addresses. One of my virtual machines has 2 interfaces, with a total of 5 IP addresses, and the other has 2 interfaces and 2 addresses.
We should probably just get rid of that primitive entirely.
Colin
On 19.05.2011, at 00:31, Levente Uzonyi wrote:
On Thu, 19 May 2011, Bert Freudenberg wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
It's not in the Trunk yet. I extracted and converted the code, it's in the Inbox now, Network-ul.100.mcz. I didn't push it to the Trunk, because
- Cog doesn't support the new primitives and the fallback code has to be tested thoroughly.
True. But maybe the new SocketPlugin would just work with Cog if somebody tried?
- I don't really like SocketAddress, because IIRC it's like CompiledMethod, in the sense that it's a ByteArray, but it's storing
pointers/words.
No, it does not store pointers. It's just a platform-dependent chunk of memory. See "man getnameinfo". POSIX requires to use that function to get fields out of the "sockaddr" struct.
- SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.
- Bert -
On Thu, 19 May 2011, Bert Freudenberg wrote:
On 19.05.2011, at 00:31, Levente Uzonyi wrote:
On Thu, 19 May 2011, Bert Freudenberg wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
It's not in the Trunk yet. I extracted and converted the code, it's in the Inbox now, Network-ul.100.mcz. I didn't push it to the Trunk, because
- Cog doesn't support the new primitives and the fallback code has to be tested thoroughly.
True. But maybe the new SocketPlugin would just work with Cog if somebody tried?
I think it would work, though I didn't try it.
- I don't really like SocketAddress, because IIRC it's like CompiledMethod, in the sense that it's a ByteArray, but it's storing
pointers/words.
No, it does not store pointers. It's just a platform-dependent chunk of memory. See "man getnameinfo". POSIX requires to use that function to get fields out of the "sockaddr" struct.
Okay, I got it, but what will happen if I save an image with SocketAddress instances on Linux and open it on Windows? Will it crash if I try to use those SocketAddresses?
- SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.
Existing code (e.g.: all senders of Socket >> #connectTo:port:) uses ByteArrays where the new socket code expects SocketAddresses, so these conversion methods are mandatory.
Levente
- Bert -
On 21.05.2011, at 01:52, Levente Uzonyi wrote:
On Thu, 19 May 2011, Bert Freudenberg wrote:
On 19.05.2011, at 00:31, Levente Uzonyi wrote:
On Thu, 19 May 2011, Bert Freudenberg wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
It's not in the Trunk yet. I extracted and converted the code, it's in the Inbox now, Network-ul.100.mcz. I didn't push it to the Trunk, because
- Cog doesn't support the new primitives and the fallback code has to be tested thoroughly.
True. But maybe the new SocketPlugin would just work with Cog if somebody tried?
I think it would work, though I didn't try it.
- I don't really like SocketAddress, because IIRC it's like CompiledMethod, in the sense that it's a ByteArray, but it's storing
pointers/words.
No, it does not store pointers. It's just a platform-dependent chunk of memory. See "man getnameinfo". POSIX requires to use that function to get fields out of the "sockaddr" struct.
Okay, I got it, but what will happen if I save an image with SocketAddress instances on Linux and open it on Windows? Will it crash if I try to use those SocketAddresses?
I don't know. SocketAddress instances are supposed to be temporary, IIUC, application code would not store them.
- SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.
Existing code (e.g.: all senders of Socket >> #connectTo:port:) uses ByteArrays where the new socket code expects SocketAddresses, so these conversion methods are mandatory.
#connectTo:port: has been changed to use either the old or the new socket code.
Anyhow: are you suggesting the extended SocketPlugin is completely useless, or that we should not use Michael's new in-image code?
IMHO the new primitives are a good foundation for the networking code to move forward. If we don't like how it's been integrated in the image, I would rather change (or even completely rewrite) that image code, encapsulating the new primitives as needed. But the plugin itself seems solid to me.
- Bert -
On Mon, 23 May 2011, Bert Freudenberg wrote:
On 21.05.2011, at 01:52, Levente Uzonyi wrote:
snip
Okay, I got it, but what will happen if I save an image with SocketAddress instances on Linux and open it on Windows? Will it crash if I try to use those SocketAddresses?
I don't know. SocketAddress instances are supposed to be temporary, IIUC, application code would not store them.
Ok, I'll take a closer look at this.
- SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.
Existing code (e.g.: all senders of Socket >> #connectTo:port:) uses ByteArrays where the new socket code expects SocketAddresses, so these conversion methods are mandatory.
#connectTo:port: has been changed to use either the old or the new socket code.
That's right, but if my package has the following code:
Socket new connectTo: #[127 0 0 1] port: 12345
and I the image uses the new socket code, then I'll get an error, because the ByteArray is not a SocketAddress.
Anyhow: are you suggesting the extended SocketPlugin is completely useless, or that we should not use Michael's new in-image code?
No, nothing like that. We should only make sure that it's compatible with the current socket API.
Levente
IMHO the new primitives are a good foundation for the networking code to move forward. If we don't like how it's been integrated in the image, I would rather change (or even completely rewrite) that image code, encapsulating the new primitives as needed. But the plugin itself seems solid to me.
- Bert -
On Wed, May 18, 2011 at 3:02 PM, Bert Freudenberg bert@freudenbergs.de wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
Not sure how to use Etoys image. I downloaded Etoys To Go 4.1.1 from Squeakland. Right off the bat it would not run because FreeBSD puts bash in /usr/local/bin. I edited etoys.sh to fix that and it errors. The unzipped folder is still in my Downloads folder:
$ ./etoys.sh ./etoys.sh: line 68: cd: /usr/home/gary/Desktop/Downloads/Etoys-To-Go 4.1.1.app/Contents/FreeBSD-i386: No such file or directory ./etoys.sh: line 69: cd: /usr/home/gary/Desktop/Downloads/Etoys-To-Go 4.1.1.app/Contents/FreeBSD-i386: No such file or directory cp: Contents is a directory (not copied). exec: /tmp/-d.GhRtmJ3g etoys-to-go-Ht2FZ/etoys: not found rm: Contents: No such file or directory
So I guess this is Linux specific. Is there an image I can run with the usual vm?
On Thu, May 19, 2011 at 10:57:29PM -0700, Gary Dunn wrote:
On Wed, May 18, 2011 at 3:02 PM, Bert Freudenberg bert@freudenbergs.de wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
Not sure how to use Etoys image. I downloaded Etoys To Go 4.1.1 from Squeakland. Right off the bat it would not run because FreeBSD puts bash in /usr/local/bin. I edited etoys.sh to fix that and it errors. The unzipped folder is still in my Downloads folder:
There should be etoys.image and etoys.changes files somewhere in that directory (perhaps Etoys-Dev-4.1.app/Contents/Resources/etoys.image and Etoys-Dev-4.1.app/Contents/Resources/etoys.changes). You should be able to copy those files to wherever you normally keep your images, and use them directly like any other image.
Instructions for getting a "development" version of the Etoys image are here:
http://wiki.immuexa.com/display/sq/Starting+with+Etoys+Development+-+A+Five+...
http://wiki.immuexa.com/display/sq/Starting+with+Etoys+Development
Dave
On 20.05.2011, at 07:57, Gary Dunn wrote:
On Wed, May 18, 2011 at 3:02 PM, Bert Freudenberg bert@freudenbergs.de wrote:
What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
Not sure how to use Etoys image. I downloaded Etoys To Go 4.1.1 from Squeakland. Right off the bat it would not run because FreeBSD puts bash in /usr/local/bin. I edited etoys.sh to fix that and it errors. The unzipped folder is still in my Downloads folder:
$ ./etoys.sh ./etoys.sh: line 68: cd: /usr/home/gary/Desktop/Downloads/Etoys-To-Go 4.1.1.app/Contents/FreeBSD-i386: No such file or directory ./etoys.sh: line 69: cd: /usr/home/gary/Desktop/Downloads/Etoys-To-Go 4.1.1.app/Contents/FreeBSD-i386: No such file or directory cp: Contents is a directory (not copied). exec: /tmp/-d.GhRtmJ3g etoys-to-go-Ht2FZ/etoys: not found rm: Contents: No such file or directory
So I guess this is Linux specific. Is there an image I can run with the usual vm?
Ah, FreeBSD. Etoys-To-Go does not include a BSD VM. Do you know if it can run Linux binaries? If so, then you could edit etoys.sh to make it work. Replace:
BIN="$APP/Contents/$OS-$CPU" with BIN="$APP/Contents/Linux-i686"
then run etoys.sh.
Or, as David wrote, just running "squeak etoys.image" should work, which would use your regular VM.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Colin Putney -
David T. Lewis -
Elliot Finley -
Gary Dunn -
Levente Uzonyi