[Pharo-project] Network training
Hi, I am playing with Network package. I am giving a practical work to my students, in Java :( And I am doing the same in Pharo to understand the Network package :))) A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address. Does it exist something to have all my ip address? Thank you, --- Jannik Laval
On 4 févr. 2011, at 06:43, jannik.laval wrote:
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
I'm not aware of such thing, though we need it. Note that you can however force a server socket to listen for connections on any IP of your machine. Noury
but how can i find these ip address in pharo? Le 4 févr. 2011 à 07:49, Noury Bouraqadi <bouraqadi@gmail.com> a écrit :
On 4 févr. 2011, at 06:43, jannik.laval wrote:
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
I'm not aware of such thing, though we need it. Note that you can however force a server socket to listen for connections on any IP of your machine.
Noury
On 4 February 2011 09:19, Laval Jannik <jannik.laval@gmail.com> wrote:
but how can i find these ip address in pharo?
perhaps by writing new primitive :)
Le 4 févr. 2011 à 07:49, Noury Bouraqadi <bouraqadi@gmail.com> a écrit :
On 4 févr. 2011, at 06:43, jannik.laval wrote:
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
I'm not aware of such thing, though we need it. Note that you can however force a server socket to listen for connections on any IP of your machine.
Noury
-- Best regards, Igor Stasenko AKA sig.
I've started to play a little bit with network, you can see the repo: SockectExamples (you should have been added as dev) ;) Ben On Feb 4, 2011, at 9:48 AM, Igor Stasenko wrote:
On 4 February 2011 09:19, Laval Jannik <jannik.laval@gmail.com> wrote:
but how can i find these ip address in pharo?
perhaps by writing new primitive :)
Le 4 févr. 2011 à 07:49, Noury Bouraqadi <bouraqadi@gmail.com> a écrit :
On 4 févr. 2011, at 06:43, jannik.laval wrote:
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
I'm not aware of such thing, though we need it. Note that you can however force a server socket to listen for connections on any IP of your machine.
Noury
-- Best regards, Igor Stasenko AKA sig.
On Feb 4, 2011, at 09:48 , Igor Stasenko wrote:
On 4 February 2011 09:19, Laval Jannik <jannik.laval@gmail.com> wrote:
but how can i find these ip address in pharo?
perhaps by writing new primitive :)
Is there one already existing ? Now, another thing, the method: NetNameResolver>>isConnected. Inside there is this code: === isConnected "Dirty, but avoids fixing the plugin bug" [NetNameResolver addressForName: 'www.esug.org'.] on: NameLookupFailure do: [:ex| ^false]. ^true === The comment is clear... is the plugin bug fixed ? --- Jannik Laval
On 4 févr. 2011, at 12:38, jannik.laval wrote:
On Feb 4, 2011, at 09:48 , Igor Stasenko wrote:
On 4 February 2011 09:19, Laval Jannik <jannik.laval@gmail.com> wrote:
but how can i find these ip address in pharo?
perhaps by writing new primitive :)
Is there one already existing ?
I don't think so. An alternative might be to use an Ocean-like approach and call OS features directly through some FFI.
Now, another thing, the method: NetNameResolver>>isConnected. Inside there is this code:
=== isConnected "Dirty, but avoids fixing the plugin bug" [NetNameResolver addressForName: 'www.esug.org'.] on: NameLookupFailure do: [:ex| ^false]. ^true ===
The comment is clear... is the plugin bug fixed ?
No. Luc and I decided that it does not worth it struggling with the plugin. This is why we initiated the Ocean project (plugin-free networking) available on SqueakSource. We made interesting (though slow) progress so far. Currently we have a complete library for TCP client socket. For the server socket to be usable we need multithreading Alien which is not available yet. Hope Eliot will have time to work on this soon or may be we'll get NativeBoost working on all major platforms (Go Igore!!!). Instead of remaining stalled or hacking some temporary solution, we changed a bit our strategy in order to have (hopefully) support for TCP sockets ready for Pharo 1.3. Our idea is that the limitations of networking problem have 2 origins: The poor library and the plugin. We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests. Our design is independent of the low-level network support (Bridge pattern). So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI. Once we'll be done with the library, we'll tackle the plugin issue. The Ocean is wide, we have to row a lot ;-) Noury
I think that your new strategy is really good! Stef
We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests. Our design is independent of the low-level network support (Bridge pattern). So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI. Once we'll be done with the library, we'll tackle the plugin issue.
The Ocean is wide, we have to row a lot ;-) Noury
On Fri, 4 Feb 2011, Noury Bouraqadi wrote:
On 4 févr. 2011, at 12:38, jannik.laval wrote:
On Feb 4, 2011, at 09:48 , Igor Stasenko wrote:
On 4 February 2011 09:19, Laval Jannik <jannik.laval@gmail.com> wrote:
but how can i find these ip address in pharo?
perhaps by writing new primitive :)
Is there one already existing ?
I don't think so. An alternative might be to use an Ocean-like approach and call OS features directly through some FFI.
There is. See my previous mail in this thread.
Now, another thing, the method: NetNameResolver>>isConnected. Inside there is this code:
=== isConnected "Dirty, but avoids fixing the plugin bug" [NetNameResolver addressForName: 'www.esug.org'.] on: NameLookupFailure do: [:ex| ^false]. ^true ===
The comment is clear... is the plugin bug fixed ?
No.
Luc and I decided that it does not worth it struggling with the plugin. This is why we initiated the Ocean project (plugin-free networking) available on SqueakSource.
Plugin-free networking doesn't exist. You either use the SocketPlugin, FFIPlugin or the plugin for Alien. Levente
We made interesting (though slow) progress so far. Currently we have a complete library for TCP client socket. For the server socket to be usable we need multithreading Alien which is not available yet. Hope Eliot will have time to work on this soon or may be we'll get NativeBoost working on all major platforms (Go Igore!!!).
Instead of remaining stalled or hacking some temporary solution, we changed a bit our strategy in order to have (hopefully) support for TCP sockets ready for Pharo 1.3. Our idea is that the limitations of networking problem have 2 origins: The poor library and the plugin.
We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests. Our design is independent of the low-level network support (Bridge pattern). So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI. Once we'll be done with the library, we'll tackle the plugin issue.
The Ocean is wide, we have to row a lot ;-) Noury
2011/2/4 Levente Uzonyi <leves@elte.hu>
On Fri, 4 Feb 2011, Noury Bouraqadi wrote:
On 4 févr. 2011, at 12:38, jannik.laval wrote:
On Feb 4, 2011, at 09:48 , Igor Stasenko wrote:
On 4 February 2011 09:19, Laval Jannik <jannik.laval@gmail.com> wrote:
but how can i find these ip address in pharo?
perhaps by writing new primitive :)
Is there one already existing ?
I don't think so. An alternative might be to use an Ocean-like approach and call OS features directly through some FFI.
There is. See my previous mail in this thread.
Now, another thing, the method: NetNameResolver>>isConnected.
Inside there is this code:
=== isConnected "Dirty, but avoids fixing the plugin bug" [NetNameResolver addressForName: 'www.esug.org'.] on: NameLookupFailure do: [:ex| ^false]. ^true ===
The comment is clear... is the plugin bug fixed ?
No.
Luc and I decided that it does not worth it struggling with the plugin. This is why we initiated the Ocean project (plugin-free networking) available on SqueakSource.
Plugin-free networking doesn't exist. You either use the SocketPlugin, FFIPlugin or the plugin for Alien.
Yes, but hopefully we will be SocketPlugin free. At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible. #Luc
Levente
We made interesting (though slow) progress so far. Currently we have a complete library for TCP client socket. For the server socket to be usable we need multithreading Alien which is not available yet. Hope Eliot will have time to work on this soon or may be we'll get NativeBoost working on all major platforms (Go Igore!!!).
Instead of remaining stalled or hacking some temporary solution, we changed a bit our strategy in order to have (hopefully) support for TCP sockets ready for Pharo 1.3. Our idea is that the limitations of networking problem have 2 origins: The poor library and the plugin.
We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests. Our design is independent of the low-level network support (Bridge pattern). So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI. Once we'll be done with the library, we'll tackle the plugin issue.
The Ocean is wide, we have to row a lot ;-) Noury
On Fri, 4 Feb 2011, Luc Fabresse wrote:
Yes, but hopefully we will be SocketPlugin free.
Is SocketPlugin buggy? If yes, where's the bug report? If not, what's the problem with it?
At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible.
Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot easier than doing the same with FFI or Alien. Eliot's threaded FFI plugin is very complex compared to (the pretty simple) SocketPlugin. Levente
On 5 February 2011 00:12, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 4 Feb 2011, Luc Fabresse wrote:
Yes, but hopefully we will be SocketPlugin free.
Is SocketPlugin buggy? If yes, where's the bug report? If not, what's the problem with it?
Just one: it is highly resistant to evolution and changes. As well as everything else in VM.
At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible.
Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot easier than doing the same with FFI or Alien.
I wouldn't say so.
Eliot's threaded FFI plugin is very complex compared to (the pretty simple) SocketPlugin.
It could be simple too. But just not fast enough :) There's always a lot of tradeoffs to consider.
Levente
-- Best regards, Igor Stasenko AKA sig.
On Sat, 5 Feb 2011, Igor Stasenko wrote:
On 5 February 2011 00:12, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 4 Feb 2011, Luc Fabresse wrote:
Yes, but hopefully we will be SocketPlugin free.
Is SocketPlugin buggy? If yes, where's the bug report? If not, what's the problem with it?
Just one: it is highly resistant to evolution and changes. As well as everything else in VM.
Does the Socket API change often? No. I'm sure all my 10 years old network code (written in C) would compile and run on the first try.
At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible.
Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot easier than doing the same with FFI or Alien.
I wouldn't say so.
Why? Couldn't you reimplement SocketPlugin from scratch without looking at the current implementation in at most a few days? I could, so I'm sure you could do that too. The same is not true for FFI or Alien (at least not for me).
Eliot's threaded FFI plugin is very complex compared to (the pretty simple) SocketPlugin.
It could be simple too. But just not fast enough :) There's always a lot of tradeoffs to consider.
It could be, but it's not. Levente
Levente
-- Best regards, Igor Stasenko AKA sig.
On 5 February 2011 00:53, Levente Uzonyi <leves@elte.hu> wrote:
On Sat, 5 Feb 2011, Igor Stasenko wrote:
On 5 February 2011 00:12, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 4 Feb 2011, Luc Fabresse wrote:
Yes, but hopefully we will be SocketPlugin free.
Is SocketPlugin buggy? If yes, where's the bug report? If not, what's the problem with it?
Just one: it is highly resistant to evolution and changes. As well as everything else in VM.
Does the Socket API change often? No. I'm sure all my 10 years old network code (written in C) would compile and run on the first try.
I can tell you more: Does C syntax changes often? No. So, then why there so many silly people wasting their time writing own compilers for it? Or why people inventing new languages? Isn't C enough? :) Levente, when is the last time you checked the meaning of word 'development' in dictionary?
At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible.
Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot easier than doing the same with FFI or Alien.
I wouldn't say so.
Why?
Because coding in smalltalk much easier than in C. Including cases, when you need to communicate with external library using C ABI. Otherwise, why would i be sitting here? And why VM written in smalltalk?.. For same reason, bro :)
Couldn't you reimplement SocketPlugin from scratch without looking at the current implementation in at most a few days? I could, so I'm sure you could do that too. The same is not true for FFI or Alien (at least not for me).
So you have something to learn left in this world :)
Eliot's threaded FFI plugin is very complex compared to (the pretty simple) SocketPlugin.
It could be simple too. But just not fast enough :) There's always a lot of tradeoffs to consider.
It could be, but it's not.
You will never know if you don't try. And besides, what is your point? People learning network by implementing own network layer. Exploring something new and trying to adopt design to their own vision/mindset. Now you came and saying "you are on the losing side, because A, B, C".. Do, you think people should learn SocketPlugin instead? Been there did that. Frankly, don't want to touch it again or teach people about it. I seen much more cleaner and robust socket library OO wrappers. Not in smalltalk though. P.S. Don't take me wrong. Yes there is a lot to learn from SocketPlugin. But you would better spend time learning/reading other well written and well documented multithreaded library for serving socket connections.
Levente
-- Best regards, Igor Stasenko AKA sig.
On Sat, 5 Feb 2011, Igor Stasenko wrote:
On 5 February 2011 00:53, Levente Uzonyi <leves@elte.hu> wrote:
On Sat, 5 Feb 2011, Igor Stasenko wrote:
On 5 February 2011 00:12, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 4 Feb 2011, Luc Fabresse wrote:
Yes, but hopefully we will be SocketPlugin free.
Is SocketPlugin buggy? If yes, where's the bug report? If not, what's the problem with it?
Just one: it is highly resistant to evolution and changes. As well as everything else in VM.
Does the Socket API change often? No. I'm sure all my 10 years old network code (written in C) would compile and run on the first try.
I can tell you more: Does C syntax changes often? No. So, then why there so many silly people wasting their time writing own compilers for it? Or why people inventing new languages? Isn't C enough? :)
Why do you compare APIs wrapping the OS's socket API to programming languages? I don't see how is the two similar at all.
Levente, when is the last time you checked the meaning of word 'development' in dictionary?
I can tell you what's not developement: Throwing away working solutions without a reason, then writing something similar. That's reinventing the wheel + optional NIH syndrome.
At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible.
Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot easier than doing the same with FFI or Alien.
I wouldn't say so.
Why?
Because coding in smalltalk much easier than in C. Including cases, when you need to communicate with external library using C ABI.
Otherwise, why would i be sitting here? And why VM written in smalltalk?.. For same reason, bro :)
That's not an anwser to my question, but I see your point.
Couldn't you reimplement SocketPlugin from scratch without looking at the current implementation in at most a few days? I could, so I'm sure you could do that too. The same is not true for FFI or Alien (at least not for me).
So you have something to learn left in this world :)
Lol...
Eliot's threaded FFI plugin is very complex compared to (the pretty simple) SocketPlugin.
It could be simple too. But just not fast enough :) There's always a lot of tradeoffs to consider.
It could be, but it's not.
You will never know if you don't try.
I'm talking about Eliot's FFI implementation, while you're talking about something else.
And besides, what is your point? People learning network by implementing own network layer. Exploring something new and trying to adopt design to their own vision/mindset.
There's nothing wrong with that, until they don't start saying that the plugin sucks without telling what's the problem with it.
Now you came and saying "you are on the losing side, because A, B, C".. Do, you think people should learn SocketPlugin instead? Been there did that. Frankly, don't want to touch it again or teach people about it. I seen much more cleaner and robust socket library OO wrappers. Not in smalltalk though.
And you're doing the same now. You say it sucks, but you don't tell what's wrong with it.
P.S. Don't take me wrong. Yes there is a lot to learn from SocketPlugin. But you would better spend time learning/reading other
I didn't say that anyone should learn from SocketPlugin. Forget the plugin. People should learn how the API works that SocketPlugin provides. Not many people know how to use it according to my earlier discussions on this list about networking.
well written and well documented multithreaded library for serving socket connections.
Without pointing to those better libraries and the things they do better than the current solution, this is just an empty phrase. Levente
Levente
-- Best regards, Igor Stasenko AKA sig.
2011/2/5 Levente Uzonyi <leves@elte.hu>
On Sat, 5 Feb 2011, Igor Stasenko wrote:
On 5 February 2011 00:53, Levente Uzonyi <leves@elte.hu> wrote:
On Sat, 5 Feb 2011, Igor Stasenko wrote:
On 5 February 2011 00:12, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 4 Feb 2011, Luc Fabresse wrote:
Yes, but hopefully we will be SocketPlugin free.
Is SocketPlugin buggy? If yes, where's the bug report? If not, what's the problem with it?
Just one: it is highly resistant to evolution and changes. As well as
everything else in VM.
Does the Socket API change often? No. I'm sure all my 10 years old network code (written in C) would compile and run on the first try.
I can tell you more: Does C syntax changes often? No. So, then why there so many silly people wasting their time writing own compilers for it? Or why people inventing new languages? Isn't C enough? :)
Why do you compare APIs wrapping the OS's socket API to programming languages? I don't see how is the two similar at all.
Levente, when is the last time you checked the meaning of word 'development' in dictionary?
I can tell you what's not developement: Throwing away working solutions without a reason, then writing something similar. That's reinventing the wheel + optional NIH syndrome.
At the end, "There can be only one" (FFI or Alien or NB or a better
one) ;-) IMHO, plugins are a pain to understand, maintain, integrate in the latest VM... so let's kill them as much as possible.
Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot easier than doing the same with FFI or Alien.
I wouldn't say so.
Why?
Because coding in smalltalk much easier than in C. Including cases, when you need to communicate with external library using C ABI.
Otherwise, why would i be sitting here? And why VM written in smalltalk?.. For same reason, bro :)
That's not an anwser to my question, but I see your point.
Couldn't you reimplement SocketPlugin from scratch without looking at the
current implementation in at most a few days? I could, so I'm sure you could do that too. The same is not true for FFI or Alien (at least not for me).
So you have something to learn left in this world :)
Lol...
Eliot's threaded FFI plugin is
very complex compared to (the pretty simple) SocketPlugin.
It could be simple too. But just not fast enough :) There's always a lot of tradeoffs to consider.
It could be, but it's not.
You will never know if you don't try.
I'm talking about Eliot's FFI implementation, while you're talking about something else.
And besides, what is your point? People learning network by implementing own network layer. Exploring something new and trying to adopt design to their own vision/mindset.
There's nothing wrong with that, until they don't start saying that the plugin sucks without telling what's the problem with it.
Hi Levente, Why I am doing Ocean with Noury is: 1) Network never worked fine for me (NetNameResolver ,...). The API (Image side) is not OO (All concerns in Socket: IPV4, IPV6, TCD, UDP, ...). We first try to write unit tests and then we planned to redesign the API. But it implies to understand well the primitives and it is not EASY at all. Some are said old in comments (IPV4 primitives?), some are new (IPV6?),... So it is a too HARD to understand this code without doc or explanations (and you are right I am also a poor newbie). 2) I do not want to hear this sentence anymore: "Oh yes, you use a VM with an old version of the socket plugin. You should recompile the VM." NO! I CAN'T DO THAT BECAUSE (until recently) RECOMPILING THE VM REQUIRE DEEP KNOWLEDGE AND SOME BLACK MAGIC. (Thanks to Igor, Esteban and all others to prepare a simple process for newbies like me such as checkout and compile). 3) Ocean idea: pull up the network stuff on the image side. use an FFI to call OS libs. With this approach I am able to: load new versions of the network without changing the VM, in the future directly call the new OS API (Grand Central on OSX for asynchronous sockets, --yes network libs evolve--...), write more high level code and it is a little bit easier to debug it. Ocean is our vision, perhaps it is wrong but I can not do better. It is not as complete as the plugin yet. We also plan to use either Alien+OS lib or the plugin as a backend for Ocean so the plugin will still be there at the end for those who want it. And for this last part, we will certainly need some explanations on the primitives in SocketPlugin code. So if you know it well, feel free to educate me. #Luc
Now you came and saying "you are on the losing side, because A, B, C"..
Do, you think people should learn SocketPlugin instead? Been there did that. Frankly, don't want to touch it again or teach people about it. I seen much more cleaner and robust socket library OO wrappers. Not in smalltalk though.
And you're doing the same now. You say it sucks, but you don't tell what's wrong with it.
P.S. Don't take me wrong. Yes there is a lot to learn from SocketPlugin. But you would better spend time learning/reading other
I didn't say that anyone should learn from SocketPlugin. Forget the plugin. People should learn how the API works that SocketPlugin provides. Not many people know how to use it according to my earlier discussions on this list about networking.
well written and well documented multithreaded library for serving
socket connections.
Without pointing to those better libraries and the things they do better than the current solution, this is just an empty phrase.
Levente
Levente
-- Best regards, Igor Stasenko AKA sig.
luc and levente @luc: you are a newbie with 6 years or more of smalltalk so a kind a strange one. I understand the points of levente - if the plugin code would be nice (documented, cleaned) and if we would have build server to recompile everything without warning every line then this is probably true that recompiling the plugin is easier for a new platform. This is a valid argument. - now I understand luc, noury, igor idea. Minimize truck factor. Now the key point is to see if threaded FFI is there, working and maintainable. So levente no need to bash them. I think that this is an interesting experience and I want more: - I want a new api and design of network that can work on the plugin or not - I want a VM that compile every times we commit a change to pharo - I want plugin code and VM to be be cleaned: using abstraction instead of bitAnd: everywhere and no warning. This is the only way that in 5 years from now (when eliot will be turned into a Javascript Virtual machine guru and andreas gone to android business or whatever and ), the community can continue to have good tools and I HATE to think that in 5 years I should think: "SHIT the code rot during all that time and if only we would have invested in cleaning and maintaining it". So let us do it NOW! When do we start to think about process, tools and artefacts that will survive us. Stef
On Sat, 5 Feb 2011, Luc Fabresse wrote: snip
Hi Levente,
Why I am doing Ocean with Noury is:
1) Network never worked fine for me (NetNameResolver ,...). The API (Image side) is not OO (All concerns in Socket: IPV4, IPV6, TCD, UDP, ...). We first try to write unit tests and then we planned to redesign the API. But it implies to understand well the primitives and it is not EASY at all. Some are said old in comments (IPV4 primitives?), some are new (IPV6?),... So it is a too HARD to understand this code without doc or explanations (and you are right I am also a poor newbie).
There was an "old" implementation of sockets, where every socket had a single semaphore. The "new" implementation added separate read and write semaphores. I guess this change was around 2005, so you can assume that every VM has the "new" implementation. There was another change for IPv6 support.AFAIK CogVMs don't have these primitives, but SqueakVMs do.
2) I do not want to hear this sentence anymore: "Oh yes, you use a VM with an old version of the socket plugin. You should recompile the VM." NO! I CAN'T DO THAT BECAUSE (until recently) RECOMPILING THE VM REQUIRE DEEP KNOWLEDGE AND SOME BLACK MAGIC. (Thanks to Igor, Esteban and all others to
Sorry but this is simply bullshit, the result of some people spreading FUD. Recompiling the VM is easy. I could compile VMs when I was a Squeak newbie. The same applies for writing plugins.
prepare a simple process for newbies like me such as checkout and compile).
3) Ocean idea: pull up the network stuff on the image side. use an FFI to call OS libs. With this approach I am able to: load new versions of the network without changing the VM, in the future directly call the new OS API (Grand Central on OSX for asynchronous sockets, --yes network libs evolve--...), write more high level code and it is a little bit easier to debug it.
The idea is nice, but I guess the performance will be a lot worse than using a custom plugin.
Ocean is our vision, perhaps it is wrong but I can not do better. It is not as complete as the plugin yet. We also plan to use either Alien+OS lib or the plugin as a backend for Ocean so the plugin will still be there at the end for those who want it. And for this last part, we will certainly need some explanations on the primitives in SocketPlugin code. So if you know it well, feel free to educate me.
I don't know it well, but I usually deeply explore the code if I want to know how it works (or how it should work). Googling mailing lists and the squeak wiki used to be helpful too. Levente
#Luc
snip
Levente, the problem is not the difficulty to recompile the VM... if it is well documented (I do not know here), but I do not want to have my vm that nobody uses with a project that nobody can use. And why would I compile a VM ??? Is it a viable process ? I am not sure. Cheers, Jannik On Feb 6, 2011, at 19:15 , Levente Uzonyi wrote:
On Sat, 5 Feb 2011, Luc Fabresse wrote:
snip
Hi Levente,
Why I am doing Ocean with Noury is:
1) Network never worked fine for me (NetNameResolver ,...). The API (Image side) is not OO (All concerns in Socket: IPV4, IPV6, TCD, UDP, ...). We first try to write unit tests and then we planned to redesign the API. But it implies to understand well the primitives and it is not EASY at all. Some are said old in comments (IPV4 primitives?), some are new (IPV6?),... So it is a too HARD to understand this code without doc or explanations (and you are right I am also a poor newbie).
There was an "old" implementation of sockets, where every socket had a single semaphore. The "new" implementation added separate read and write semaphores. I guess this change was around 2005, so you can assume that every VM has the "new" implementation.
There was another change for IPv6 support.AFAIK CogVMs don't have these primitives, but SqueakVMs do.
2) I do not want to hear this sentence anymore: "Oh yes, you use a VM with an old version of the socket plugin. You should recompile the VM." NO! I CAN'T DO THAT BECAUSE (until recently) RECOMPILING THE VM REQUIRE DEEP KNOWLEDGE AND SOME BLACK MAGIC. (Thanks to Igor, Esteban and all others to
Sorry but this is simply bullshit, the result of some people spreading FUD. Recompiling the VM is easy. I could compile VMs when I was a Squeak newbie. The same applies for writing plugins.
prepare a simple process for newbies like me such as checkout and compile).
3) Ocean idea: pull up the network stuff on the image side. use an FFI to call OS libs. With this approach I am able to: load new versions of the network without changing the VM, in the future directly call the new OS API (Grand Central on OSX for asynchronous sockets, --yes network libs evolve--...), write more high level code and it is a little bit easier to debug it.
The idea is nice, but I guess the performance will be a lot worse than using a custom plugin.
Ocean is our vision, perhaps it is wrong but I can not do better. It is not as complete as the plugin yet. We also plan to use either Alien+OS lib or the plugin as a backend for Ocean so the plugin will still be there at the end for those who want it. And for this last part, we will certainly need some explanations on the primitives in SocketPlugin code. So if you know it well, feel free to educate me.
I don't know it well, but I usually deeply explore the code if I want to know how it works (or how it should work). Googling mailing lists and the squeak wiki used to be helpful too.
Levente
#Luc
snip
Thanks jannik this is an important action. Stef On Feb 4, 2011, at 6:43 AM, jannik.laval wrote:
Hi,
I am playing with Network package. I am giving a practical work to my students, in Java :( And I am doing the same in Pharo to understand the Network package :)))
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
Thank you,
--- Jannik Laval
On Fri, 4 Feb 2011, jannik.laval wrote:
Hi,
I am playing with Network package. I am giving a practical work to my students, in Java :( And I am doing the same in Pharo to understand the Network package :)))
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
Yes. The network changes that were introduced in Pharo 1.1 and were reverted before the release contained such methods. In theory both the VM side and client side code is ready for this (Etoys uses it on OLPC), but some VMs (e.g. Cog) don't have the latest plugin versions, so the primitives don't work there. Levente
Thank you,
--- Jannik Laval
Hi Levente, Thank you for the answer, but it is not clear for me where is this source code. You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? And how can I find the source code ? I will try to search on eToys image. Why was in included in removed from Pharo ? Jannik On Feb 4, 2011, at 13:24 , Levente Uzonyi wrote:
On Fri, 4 Feb 2011, jannik.laval wrote:
Hi,
I am playing with Network package. I am giving a practical work to my students, in Java :( And I am doing the same in Pharo to understand the Network package :)))
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
Yes. The network changes that were introduced in Pharo 1.1 and were reverted before the release contained such methods. In theory both the VM side and client side code is ready for this (Etoys uses it on OLPC), but some VMs (e.g. Cog) don't have the latest plugin versions, so the primitives don't work there.
Levente
Thank you,
--- Jannik Laval
On Sat, 5 Feb 2011, jannik.laval wrote:
Hi Levente,
Thank you for the answer, but it is not clear for me where is this source code. You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? And how can I find the source code ? I will try to search on eToys image.
If you're lucky, then the sourcecode is attached to the tracker issues. If there are only slices, then it'll be a bit harder to find the relevant changes, because you can't diff a slice to the current version. If none of the above works, then this diff may be helpful: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/155685.... Levente
Why was in included in removed from Pharo ?
Jannik
On Feb 4, 2011, at 13:24 , Levente Uzonyi wrote:
On Fri, 4 Feb 2011, jannik.laval wrote:
Hi,
I am playing with Network package. I am giving a practical work to my students, in Java :( And I am doing the same in Pharo to understand the Network package :)))
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
Yes. The network changes that were introduced in Pharo 1.1 and were reverted before the release contained such methods. In theory both the VM side and client side code is ready for this (Etoys uses it on OLPC), but some VMs (e.g. Cog) don't have the latest plugin versions, so the primitives don't work there.
Levente
Thank you,
--- Jannik Laval
Thank you Levente, I will check that, try it and check if it works fine... and write tests. Cheers, Jannik On Feb 6, 2011, at 18:48 , Levente Uzonyi wrote:
On Sat, 5 Feb 2011, jannik.laval wrote:
Hi Levente,
Thank you for the answer, but it is not clear for me where is this source code. You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? And how can I find the source code ? I will try to search on eToys image.
If you're lucky, then the sourcecode is attached to the tracker issues. If there are only slices, then it'll be a bit harder to find the relevant changes, because you can't diff a slice to the current version. If none of the above works, then this diff may be helpful:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/155685....
Levente
Why was in included in removed from Pharo ?
Jannik
On Feb 4, 2011, at 13:24 , Levente Uzonyi wrote:
On Fri, 4 Feb 2011, jannik.laval wrote:
Hi,
I am playing with Network package. I am giving a practical work to my students, in Java :( And I am doing the same in Pharo to understand the Network package :)))
A first question: I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
Does it exist something to have all my ip address?
Yes. The network changes that were introduced in Pharo 1.1 and were reverted before the release contained such methods. In theory both the VM side and client side code is ready for this (Etoys uses it on OLPC), but some VMs (e.g. Cog) don't have the latest plugin versions, so the primitives don't work there.
Levente
Thank you,
--- Jannik Laval
participants (8)
-
Benjamin -
Igor Stasenko -
jannik.laval -
Laval Jannik
-
Levente Uzonyi -
Luc Fabresse -
Noury Bouraqadi -
Stéphane Ducasse