- Pharo-users - lists.pharo.org

Re: [Pharo-users] Sockstream vs ZnSocketStream

by stephane ducasse

cool signature :) > Hi Luc, > > On 09 May 2013, at 22:05, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > >> Hi all, >> >> I am *experimenting* with the replacement of the current network layer with OCEAN. >> My current plan is to make Zinc tests green while working on the top of OCEAN. >> And investigate the removal of all the current Network classes (does it play?). >> After looking at Zinc code, there are few dependencies. >> Basically, I implemented an OCNSOcketStream (inheriting from SocketStream) and redefined some methods of ZnNetworkingUtils. >> It seems to play so far (green tests). > > It is great that you are picking this up again. > > If you mean that your OCNSocketStream with OCEAN Sockets can now run the full Zn test suite, that would be very good news indeed ! > >> But then, I discovered that Zodiac introduces a new SocketStream hierarchy (ZdcAbstractSocketStream). >> Now remember the mails of Sven. >> >> So my questions are: >> >> 1) Is the intent of ZdcSocketStream to be a future replacement for SocketStream? >> >> 2) why ZnNetworkingUtils>>initialize makes use of SocketStream instead of ZdcSocketStream? >> why the code isn't something like that: >> >> ZnNetworkingUtils>>initialize >> super initialize. >> self socketStreamClass: (Smalltalk globals at: #ZdcSocketStream ifAbsent: [ SocketStream ]) . >> self secureSocketStreamClass: (Smalltalk globals at: #ZdcSecureSocketStream ifAbsent: [ nil ]) >> >> Moreover, I guess that ZdcSocketStream should speed up things (it says optimized version in the name of the superclass ;-)). >> >> So probably, my OCNSOcketStream should better inherit from ZdcSocketStream. >> >> Thanks for giving me some light here, >> >> Luc > > When I started writing Zinc, now already more than 2 years ago, I used the regular SocketStreams. But I limited my use to the following semantic options and just the regular ReadStream API: > > stream > binary; > shouldSignal: true; > autoFlush: false > > Some time later I did Zodiac. Before doing the TLS/SSL streams I wanted to make sure I correctly understood the SocketStream API and semantics that I was using. That is why I first reimplemented regular socket streams. Hence the hierarchy: > > ZdcAbstractSocketStream > ZdcSimpleSocketStream > ZdcOptimizedSocketStream > ZdcSocketStream > > My goal too was to be able to run the full Zn test suite. That is still possible, you can switch the plain socket stream being used by doing > > ZnNetworkingUtils default socketStreamClass: ZdcSocketStream > > After that came the actual ZdcSecureSocketStream. Nowadays, Zodiac is a full part of Pharo, and thus used in the wild, which validates the implementation. > > Yes, I think it would be way better (and easier for you) to plug into the hierarchy described above. If you need any help, just ask. I am very interested in that. Maybe the 'pluggability' can be improved. > > Now the question 'should ZdcSocketStream replace SocketStream ?' can only be answered by users like yourself. As fas as I use socket streams I think it can, but I am sure some people will protest when they can no longer abuse this binary stream for writing characters or strings or reading lines while ignoring encoding issues. > > The SocketStream that we have today works, but it is overly complex in API and implementation. It is also inefficient: try following what happens when you write a 1Mb ByteArray. > > Regards, > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > >

May 10, 2013

Re: [Pharo-users] Sockstream vs ZnSocketStream

by Sven Van Caekenberghe

Hi Luc, On 09 May 2013, at 22:05, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi all, > > I am *experimenting* with the replacement of the current network layer with OCEAN. > My current plan is to make Zinc tests green while working on the top of OCEAN. > And investigate the removal of all the current Network classes (does it play?). > After looking at Zinc code, there are few dependencies. > Basically, I implemented an OCNSOcketStream (inheriting from SocketStream) and redefined some methods of ZnNetworkingUtils. > It seems to play so far (green tests). It is great that you are picking this up again. If you mean that your OCNSocketStream with OCEAN Sockets can now run the full Zn test suite, that would be very good news indeed ! > But then, I discovered that Zodiac introduces a new SocketStream hierarchy (ZdcAbstractSocketStream). > Now remember the mails of Sven. > > So my questions are: > > 1) Is the intent of ZdcSocketStream to be a future replacement for SocketStream? > > 2) why ZnNetworkingUtils>>initialize makes use of SocketStream instead of ZdcSocketStream? > why the code isn't something like that: > > ZnNetworkingUtils>>initialize > super initialize. > self socketStreamClass: (Smalltalk globals at: #ZdcSocketStream ifAbsent: [ SocketStream ]) . > self secureSocketStreamClass: (Smalltalk globals at: #ZdcSecureSocketStream ifAbsent: [ nil ]) > > Moreover, I guess that ZdcSocketStream should speed up things (it says optimized version in the name of the superclass ;-)). > > So probably, my OCNSOcketStream should better inherit from ZdcSocketStream. > > Thanks for giving me some light here, > > Luc When I started writing Zinc, now already more than 2 years ago, I used the regular SocketStreams. But I limited my use to the following semantic options and just the regular ReadStream API: stream binary; shouldSignal: true; autoFlush: false Some time later I did Zodiac. Before doing the TLS/SSL streams I wanted to make sure I correctly understood the SocketStream API and semantics that I was using. That is why I first reimplemented regular socket streams. Hence the hierarchy: ZdcAbstractSocketStream ZdcSimpleSocketStream ZdcOptimizedSocketStream ZdcSocketStream My goal too was to be able to run the full Zn test suite. That is still possible, you can switch the plain socket stream being used by doing ZnNetworkingUtils default socketStreamClass: ZdcSocketStream After that came the actual ZdcSecureSocketStream. Nowadays, Zodiac is a full part of Pharo, and thus used in the wild, which validates the implementation. Yes, I think it would be way better (and easier for you) to plug into the hierarchy described above. If you need any help, just ask. I am very interested in that. Maybe the 'pluggability' can be improved. Now the question 'should ZdcSocketStream replace SocketStream ?' can only be answered by users like yourself. As fas as I use socket streams I think it can, but I am sure some people will protest when they can no longer abuse this binary stream for writing characters or strings or reading lines while ignoring encoding issues. The SocketStream that we have today works, but it is overly complex in API and implementation. It is also inefficient: try following what happens when you write a 1Mb ByteArray. Regards, Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 10, 2013

Re: [Pharo-users] Sockstream vs ZnSocketStream

by Luc Fabresse

2013/5/10 Ben Coman <btc(a)openinworld.com> > Luc Fabresse wrote: > >> Hi all, >> >> I am *experimenting* with the replacement of the current network layer >> with OCEAN. >> My current plan is to make Zinc tests green while working on the top of >> OCEAN. >> And investigate the removal of all the current Network classes (does it >> play?). >> After looking at Zinc code, there are few dependencies. >> Basically, I implemented an OCNSOcketStream (inheriting from >> SocketStream) >> and redefined some methods of ZnNetworkingUtils. >> It seems to play so far (green tests). >> >> But then, I discovered that Zodiac introduces a new SocketStream >> hierarchy >> (ZdcAbstractSocketStream). >> Now remember the mails of Sven. >> >> So my questions are: >> >> 1) Is the intent of ZdcSocketStream to be a future replacement for >> SocketStream? >> >> 2) why ZnNetworkingUtils>>initialize makes use of SocketStream instead of >> ZdcSocketStream? >> why the code isn't something like that: >> ZnNetworkingUtils>>initialize >> super initialize. >> self socketStreamClass: (Smalltalk globals at: #ZdcSocketStream ifAbsent: >> [ SocketStream ]) . >> self secureSocketStreamClass: (Smalltalk globals at: >> #ZdcSecureSocketStream ifAbsent: [ nil ]) >> >> Moreover, I guess that ZdcSocketStream should speed up things (it says >> optimized version in the name of the superclass ;-)). >> So probably, my OCNSOcketStream should better inherit from >> ZdcSocketStream. >> >> Thanks for giving me some light here, >> >> Luc >> >> >> > I'm not even close to knowing the answers you'd like, but it looks really > interesting. Slide 9 at [1] shows Alien being used to interact with the OS > Network API. What are you thoughts on NativeBoost being used instead ? > It is old slides ;-) History: At the beginning we would like to replace the Network VM plugin by wraping the POSIX socket layer through Alien. At that time, we chose Alien because it supports callbacks. And it was a nightmare to use Nativeboost because it required a special VM (with NB plugin) but that VM had not some Network primitives about ipv6 and UDP. Now things are much much better ;-) one VM and everything inside. But now we focus on the image part (Network API) that still uses the plugin as backend (no need for Alien at all). When it will work we will implement another backend with NB probably. I know that Igor started one. But I would to investigate wrapping ZeroMQ (I saw some mails about that). Cheers, Luc > > [1] http://www.slideshare.net/**esug/ocean-5305932<http://www.slideshare.net/esug/ocean-5305932> > > cheers -ben > > > >

May 10, 2013

Re: [Pharo-users] Sockstream vs ZnSocketStream

by Ben Coman

Luc Fabresse wrote: > Hi all, > > I am *experimenting* with the replacement of the current network layer > with OCEAN. > My current plan is to make Zinc tests green while working on the top of > OCEAN. > And investigate the removal of all the current Network classes (does it > play?). > After looking at Zinc code, there are few dependencies. > Basically, I implemented an OCNSOcketStream (inheriting from SocketStream) > and redefined some methods of ZnNetworkingUtils. > It seems to play so far (green tests). > > But then, I discovered that Zodiac introduces a new SocketStream hierarchy > (ZdcAbstractSocketStream). > Now remember the mails of Sven. > > So my questions are: > > 1) Is the intent of ZdcSocketStream to be a future replacement for > SocketStream? > > 2) why ZnNetworkingUtils>>initialize makes use of SocketStream instead of > ZdcSocketStream? > why the code isn't something like that: > ZnNetworkingUtils>>initialize > super initialize. > self socketStreamClass: (Smalltalk globals at: #ZdcSocketStream ifAbsent: > [ SocketStream ]) . > self secureSocketStreamClass: (Smalltalk globals at: > #ZdcSecureSocketStream ifAbsent: [ nil ]) > > Moreover, I guess that ZdcSocketStream should speed up things (it says > optimized version in the name of the superclass ;-)). > So probably, my OCNSOcketStream should better inherit from ZdcSocketStream. > > Thanks for giving me some light here, > > Luc > > I'm not even close to knowing the answers you'd like, but it looks really interesting. Slide 9 at [1] shows Alien being used to interact with the OS Network API. What are you thoughts on NativeBoost being used instead ? [1] http://www.slideshare.net/esug/ocean-5305932 cheers -ben

May 10, 2013

Sockstream vs ZnSocketStream

by Luc Fabresse

Hi all, I am *experimenting* with the replacement of the current network layer with OCEAN. My current plan is to make Zinc tests green while working on the top of OCEAN. And investigate the removal of all the current Network classes (does it play?). After looking at Zinc code, there are few dependencies. Basically, I implemented an OCNSOcketStream (inheriting from SocketStream) and redefined some methods of ZnNetworkingUtils. It seems to play so far (green tests). But then, I discovered that Zodiac introduces a new SocketStream hierarchy (ZdcAbstractSocketStream). Now remember the mails of Sven. So my questions are: 1) Is the intent of ZdcSocketStream to be a future replacement for SocketStream? 2) why ZnNetworkingUtils>>initialize makes use of SocketStream instead of ZdcSocketStream? why the code isn't something like that: ZnNetworkingUtils>>initialize super initialize. self socketStreamClass: (Smalltalk globals at: #ZdcSocketStream ifAbsent: [ SocketStream ]) . self secureSocketStreamClass: (Smalltalk globals at: #ZdcSecureSocketStream ifAbsent: [ nil ]) Moreover, I guess that ZdcSocketStream should speed up things (it says optimized version in the name of the superclass ;-)). So probably, my OCNSOcketStream should better inherit from ZdcSocketStream. Thanks for giving me some light here, Luc

May 9, 2013

Re: [Pharo-users] the future of squeaksource

by Hilaire Fernandes

Le 08/05/2013 18:08, Andrei Vasile Chis a Ã©crit : > Thanks. I will add this script to the front page of SqueakSource. > Thanks. Hilaire -- Dr. Geo http://drgeo.eu

May 9, 2013

Re: [Pharo-users] the future of squeaksource

by Andrei Vasile Chis

The project descriptions and the wiki entries are stored in the image. On May 8, 2013 7:05 PM, "Paul DeBruicker" <pdebruic(a)gmail.com> wrote: > Are the project descriptions and wiki entries stored in the file system > or the image? > > > On 05/08/2013 09:07 AM, Andrei Vasile Chis wrote: > > We were thinking of keeping the current image alive for one or two more > > months. > > Then replace it with just a simple view of the file system. > > > > > > On Wed, May 8, 2013 at 9:50 AM, stephane ducasse > > <stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>> wrote: > > > > > > On May 7, 2013, at 5:19 PM, Andrei Vasile Chis > > <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> > wrote: > > > > > Hi all, > > > > > > Given that SmalltalkHub is now stable we were considering to > > discontinue SqueakSource. > > > Our idea is to provide a grace period of a couple of months to > > allow the current active users to migrate their projects to the new > > service and then simply put squeaksource in read-only mode (simply > > exposing the directory structure and allowing downloads). > > > > > > What do you think about it ? > > > Are there any good reasons to still keep SqueakSource alive? > > > > Keep it alive so that we can slowly migrate. Because migrating takes > > a lot of time. > > > > > > > > > > > > Cheers, > > > The SCG Team > > > > > > > > >

May 8, 2013

Re: [Pharo-users] the future of squeaksource

by stephane ducasse

On May 8, 2013, at 6:11 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > We can add a search based on project names. > Also I'd like to create a virtual machine and move an instance of the SqueakSource image there. > This way if in the future people will want to access any meta-information they could download the virtual machine and get a running SqueakSource. yes this is a really good idea! > > > On Wed, May 8, 2013 at 11:25 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/7 Andrei Vasile Chis <chisvasileandrei(a)gmail.com> > I don't really think so. Read-only mode is perfect, you only waste time to > relaunch squeaksource when it crashes :) > > We were thinking at something more dramatic, like killing the image and putting all the public > licensed projects on some ftp (or something similar). > > If you go such way it will be impossible to find old projects by description and wiki page contents. Squeaksource have search. > > Lately the image has become more unstable then usual. From time to time it just hangs and keeps that processor of > the server at 100% > > >

May 8, 2013

Re: [Pharo-users] the future of squeaksource

by Paul DeBruicker

Are the project descriptions and wiki entries stored in the file system or the image? On 05/08/2013 09:07 AM, Andrei Vasile Chis wrote: > We were thinking of keeping the current image alive for one or two more > months. > Then replace it with just a simple view of the file system. > > > On Wed, May 8, 2013 at 9:50 AM, stephane ducasse > <stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>> wrote: > > > On May 7, 2013, at 5:19 PM, Andrei Vasile Chis > <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > > Hi all, > > > > Given that SmalltalkHub is now stable we were considering to > discontinue SqueakSource. > > Our idea is to provide a grace period of a couple of months to > allow the current active users to migrate their projects to the new > service and then simply put squeaksource in read-only mode (simply > exposing the directory structure and allowing downloads). > > > > What do you think about it ? > > Are there any good reasons to still keep SqueakSource alive? > > Keep it alive so that we can slowly migrate. Because migrating takes > a lot of time. > > > > > > > Cheers, > > The SCG Team > > >

May 8, 2013

Re: [Pharo-users] [ANN] ConfigurationOfOpenDBXDriver in MetaRepoForPharo20

by Chris

Thanks Guille, will be interested to know how you get on with Glorp. I've had a few issues since 1.4 where Glorp's tests didn't all pass in the test runner (they did from the system browser and seemed to work everywhere in 1.3) and it only seems to be getting worse still in 2.0 as my HDTestReport application ones are just starting to have trouble too now. I assumed it was some weird timing thing and wondered if you'd come across it? I also have a couple of personal Glorp fixes if you're interested. > Hi! > > I just took some time to load and test opendbx in 2.0, with the latest > fixes to be able to load ffi. > > The configuration stable version loads cleanly in Pharo 2.0 and the > configuration is available in the configuration browser. > > I'll continue with Glorp & friends following :) > > Guille

May 8, 2013