- Pharo-users - lists.pharo.org

New list(s)

by Sean P. DeNigris

I've updated nabble to work with the new users list. I'm not exactly sure what's going on with the dev list... is there a new url / email address? I tried http://lists.pharo.org/mailman/listinfo/pharo-project_lists.pharo.org, but got "No such list..." ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-list-s-tp4687029.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 13, 2013

Fwd: test

by DeNigris Sean

>> please ignore

May 13, 2013

Re: [Pharo-users] test

by DeNigris Sean

> please ignore

May 13, 2013

test

by DeNigris Sean

please ignore

May 13, 2013

Re: [Pharo-users] pharo-users Mailinglist moved

by Marcus Denker

On May 13, 2013, at 10:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > As the old setup stopped working last week, we decided to move the mailing list to a new > server. > > > New Address: pharo-users(a)lists.pharo.org > > Web: > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > > -> digest option is preserverd > -> others we will fix by hand later this morning (or you can do it yourself now > > We unsubscribed all users with the "Nomail" option set before retrieving the list > of users. > I went through all subscribers and compared it with the old list and set options accordingly. Marcus

May 13, 2013

Welcome to our new mailing list

by StÃ©phane Ducasse

Hello Pharoers We are moving to a new and much stable mailing-list. Sorry for the inconvenience. Stef

May 13, 2013

pharo-users Mailinglist moved

by Marcus Denker

Hi, As the old setup stopped working last week, we decided to move the mailing list to a new server. New Address: pharo-users(a)lists.pharo.org Web: http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org -> digest option is preserverd -> others we will fix by hand later this morning (or you can do it yourself now We unsubscribed all users with the "Nomail" option set before retrieving the list of users. Marcus

May 13, 2013

WideString and FTP Client

by Hilaire Fernandes

Hello, I am using FTP Client to save xml file. Some of these files may be WideString, in that case the FTP Client fails. I got a ByteArray(Object)>>errorImproperStore The code snippet to save is like this (client is ftp client) readonlyStream := ReadStream on: stream contents. client putFileStreamContents: readonlyStream as: aFilename If I convert the content to ByteArray, in that case file is x4 times greater, which should not be the case. Enclosed PharoDebug Thanks Hilaire -- Dr. Geo http://drgeo.eu

May 12, 2013

Re: [Pharo-users] Sockstream vs ZnSocketStream

by Sven Van Caekenberghe

On 11 May 2013, at 06:34, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi Sven, > > Thanks for the explanation. > You confirm what I was thinking, I will inegrate the ZdcAbstractSocketStream. Cool. Is there a place where I can already see what you did up to now ? > I never used deeply SocketStream. > So, I will also have a closer look at SocketStream to understand what you said about "abuse this binary stream for writing characters or strings or reading lines while ignoring encoding issues". > My first impression is that we could have an "Encoder" hierarchy on top of a binary streams. > Perhaps it is already there. Yes, there are ZnCharacterReadStream and ZnCharacterWriteStream that convert a binary stream into a character read and write stream respectively, using a decoder/encoder. BTW, there are also ZnBufferedReadStream and ZnBufferedWriteStream. Sven > Thanks, > > #Luc > > > #Luc > > > 2013/5/10 Sven Van Caekenberghe <sven(a)stfx.eu> > 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 11, 2013

Re: [Pharo-users] Sockstream vs ZnSocketStream

by Luc Fabresse

Hi Sven, Thanks for the explanation. You confirm what I was thinking, I will inegrate the ZdcAbstractSocketStream. I never used deeply SocketStream. So, I will also have a closer look at SocketStream to understand what you said about "abuse this binary stream for writing characters or strings or reading lines while ignoring encoding issues". My first impression is that we could have an "Encoder" hierarchy on top of a binary streams. Perhaps it is already there. Thanks, #Luc #Luc 2013/5/10 Sven Van Caekenberghe <sven(a)stfx.eu> > 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 11, 2013