Network training
Locked
12
12
 
|
2011/2/5 Levente Uzonyi <[hidden email]>
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
|
|
|
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 |
|
|
In reply to this post by 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.html 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 >>> >>> >>> >> > > > |
|
|
In reply to this post by Luc Fabresse
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 |
|
|
In reply to this post by Levente Uzonyi-2
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.html > > > 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 >>>> >>>> >>>> >>> >> >> >> > |
|
|
In reply to this post by Levente Uzonyi-2
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 > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |