December 2014 - Pharo-users

Re: [Pharo-users] pharo at google code-in

by stepharo

Le 31/12/14 08:03, Martin BÃ¤hr a Ã©crit : > Excerpts from Martin BÃ¤hr's message of 2014-12-24 19:48:47 +0100: >> i have been meaning to learn smalltalk for a while, but i always lacked a good >> project that i could do with it, until recently. and figuring that teaching is >> the best way to learn i put up my projects as tasks for google code-in as part >> of FOSSASIA which is a code-in mentor organization. > i posted a write-up of the smalltalk projects and tasks here: > http://societyserver.org/mbaehr/learning-smalltalk-with-Google-Code-In > > i'll be updating that as students work progresses and if i add new tasks. > > i am also still looking for tutorials that can be used to start learning pharo. > in particular for spec and desktop apps in general, but i don't mind having > more options for webframeworks too. I will make sure that the Spec chapter compile and I will let you know. There are hosted at https://github.com/SquareBracketAssociates/PharoInProgress I will create a jenkins job > > so far i have 4 students started on smalltalk, one of them didn't continue > after the tutorial (so i reopened the task for others), and one who is learning > amber. we'll see if any of them pick up the actual project tasks. I strongly suggest them to register to the mailing-lists and ask questions. Tell them that we are all happy to help them. Stef > > greetings, martin. >

Dec. 31, 2014

Re: [Pharo-users] pharo at google code-in

by Martin BÃ¤hr

Excerpts from Martin BÃ¤hr's message of 2014-12-24 19:48:47 +0100: > i have been meaning to learn smalltalk for a while, but i always lacked a good > project that i could do with it, until recently. and figuring that teaching is > the best way to learn i put up my projects as tasks for google code-in as part > of FOSSASIA which is a code-in mentor organization. i posted a write-up of the smalltalk projects and tasks here: http://societyserver.org/mbaehr/learning-smalltalk-with-Google-Code-In i'll be updating that as students work progresses and if i add new tasks. i am also still looking for tutorials that can be used to start learning pharo. in particular for spec and desktop apps in general, but i don't mind having more options for webframeworks too. so far i have 4 students started on smalltalk, one of them didn't continue after the tutorial (so i reopened the task for others), and one who is learning amber. we'll see if any of them pick up the actual project tasks. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org BLUG secretary beijinglug.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 31, 2014

Re: [Pharo-users] ZnClient Error - Improper store into indexable object

by stepharo

Sven this is a really cool answer! May be we should add that somewhere :) Stef Le 29/12/14 20:16, Sven Van Caekenberghe a Ã©crit : > Hi Edward, > >> On 29 Dec 2014, at 17:19, Edward Povazan <empovazan(a)gmail.com> wrote: >> >> I am playing around with Zinc, and I get an >> "Error - Improper store into indexable objectâ >> at >> ZnBufferedWriteStream>>nextPut: >> >> My Workspace: >> ----- >> | response | >> response := ZnClient new >> url:'http://amazon.com'; >> get; >> response. >> >> response writeOn: Transcript. >> Transcript flush >> ----- >> >> The reason is that instead of a Character, there is a SmallInteger of value 10 being added at ByteString>>at:put: (and 10 is a linefeed). >> >> Also the string in the entity is a WideString (ZnUTF8Encoder>>next:putAll:startingAt:toStream is where the choice is made to decode a ByteString vs WideString). >> >> Is this a bug? Running on Pharo 3. My newb debugging skills donât go further :( Other sites that fail are reddit.com, news.ycombinator.com. >> >> Thanks, >> -Ed > Short answer: > > Zinc writes to or reads from binary streams, the Transcript is a character stream. I know that what you are trying to do is actually in the documentation and in the API, and it normally works, just not in all cases. It is better to use inspection to look at what is going on, you'll get a much more structured (object-oriented) view of what is going on. I would suggest inspecting the ZnClient instance, which will hold the state of the last request and response. > > Long answer: > > If you try > > | response | > response := ZnClient new > url:'http://stfx.eu/small.html'; > get; > response. > > response writeToTranscript. > > It will work and print > > HTTP/1.1 200 OK > X-Pad: avoid browser bug > Date: Mon, 29 Dec 2014 18:56:37 GMT > Content-Length: 113 > Etag: "202f9-71-4c7ae94364f1e" > Server: Apache/2.2.22 (Ubuntu) > Accept-Ranges: bytes > Last-Modified: Mon, 20 Aug 2012 08:48:51 GMT > Vary: Accept-Encoding > Content-Type: text/html > > <html> > <head><title>Small</title></head> > <body><h1>Small</h1><p>This is a small HTML document</p></body> > </html> > > So what is the difference ? > > The fact that the responses that you get from the website you mention are using chunked transfer encoding (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) Zinc deals with this in both ways, while reading a response, but also while writing a response (which is what you are trying to do here). > > Here is how you disable chunked transfer encoding so that you can write the response to the Transcript > > | response | > response := ZnClient new > url:'http://amazon.com'; > get; > response. > > response headers removeKey: 'Transfer-Encoding'. > response writeToTranscript. > > Zinc manages to write to the Transcript in most cases by cheating a bit: it wraps a ZnBivalentWriteStream around another stream when needed - such a stream can do both binary and character writing at the same time (though the result is only good for quick and dirty debugging, since it is not 100% correct). > > I hope the long explanation didn't make it worse ;-) > > HTH, > > Sven > > PS: BTW, in Pharo 4 with Zinc #bleedingEdge you get even nicer and more high level presentations of Zinc objects in GT-Inspector ! > > >

Dec. 29, 2014

Re: [Pharo-users] ZnClient Error - Improper store into indexable object

by Edward Povazan

Sven, thank you so much for the detailed explanation. I used it to look at the debugger again so I could reformulate the way I look for bugs. Iâd was looking backwards from the error, but had I started at the DoIt, I would have seen the ZnBivalentWriteStream and seen the class comment. Moreover, I would have realized it all starts with the Transcript. I guess habits from my other environment (iOS, where the stack leads into closed source). And here in Pharo I can inspect the MethodContext and see the program counter :) Thanks again, -Edward > On Dec 29, 2014, at 11:16 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Edward, > >> On 29 Dec 2014, at 17:19, Edward Povazan <empovazan(a)gmail.com> wrote: >> >> I am playing around with Zinc, and I get an >> "Error - Improper store into indexable objectâ >> at >> ZnBufferedWriteStream>>nextPut: >> >> My Workspace: >> ----- >> | response | >> response := ZnClient new >> url:'http://amazon.com'; >> get; >> response. >> >> response writeOn: Transcript. >> Transcript flush >> ----- >> >> The reason is that instead of a Character, there is a SmallInteger of value 10 being added at ByteString>>at:put: (and 10 is a linefeed). >> >> Also the string in the entity is a WideString (ZnUTF8Encoder>>next:putAll:startingAt:toStream is where the choice is made to decode a ByteString vs WideString). >> >> Is this a bug? Running on Pharo 3. My newb debugging skills donât go further :( Other sites that fail are reddit.com, news.ycombinator.com. >> >> Thanks, >> -Ed > > Short answer: > > Zinc writes to or reads from binary streams, the Transcript is a character stream. I know that what you are trying to do is actually in the documentation and in the API, and it normally works, just not in all cases. It is better to use inspection to look at what is going on, you'll get a much more structured (object-oriented) view of what is going on. I would suggest inspecting the ZnClient instance, which will hold the state of the last request and response. > > Long answer: > > If you try > > | response | > response := ZnClient new > url:'http://stfx.eu/small.html'; > get; > response. > > response writeToTranscript. > > It will work and print > > HTTP/1.1 200 OK > X-Pad: avoid browser bug > Date: Mon, 29 Dec 2014 18:56:37 GMT > Content-Length: 113 > Etag: "202f9-71-4c7ae94364f1e" > Server: Apache/2.2.22 (Ubuntu) > Accept-Ranges: bytes > Last-Modified: Mon, 20 Aug 2012 08:48:51 GMT > Vary: Accept-Encoding > Content-Type: text/html > > <html> > <head><title>Small</title></head> > <body><h1>Small</h1><p>This is a small HTML document</p></body> > </html> > > So what is the difference ? > > The fact that the responses that you get from the website you mention are using chunked transfer encoding (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) Zinc deals with this in both ways, while reading a response, but also while writing a response (which is what you are trying to do here). > > Here is how you disable chunked transfer encoding so that you can write the response to the Transcript > > | response | > response := ZnClient new > url:'http://amazon.com'; > get; > response. > > response headers removeKey: 'Transfer-Encoding'. > response writeToTranscript. > > Zinc manages to write to the Transcript in most cases by cheating a bit: it wraps a ZnBivalentWriteStream around another stream when needed - such a stream can do both binary and character writing at the same time (though the result is only good for quick and dirty debugging, since it is not 100% correct). > > I hope the long explanation didn't make it worse ;-) > > HTH, > > Sven > > PS: BTW, in Pharo 4 with Zinc #bleedingEdge you get even nicer and more high level presentations of Zinc objects in GT-Inspector ! > >

Dec. 29, 2014

Re: [Pharo-users] ZnClient Error - Improper store into indexable object

by Sven Van Caekenberghe

> On 29 Dec 2014, at 20:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Edward, > >> On 29 Dec 2014, at 17:19, Edward Povazan <empovazan(a)gmail.com> wrote: >> >> I am playing around with Zinc, and I get an >> "Error - Improper store into indexable objectâ >> at >> ZnBufferedWriteStream>>nextPut: >> >> My Workspace: >> ----- >> | response | >> response := ZnClient new >> url:'http://amazon.com'; >> get; >> response. >> >> response writeOn: Transcript. >> Transcript flush >> ----- >> >> The reason is that instead of a Character, there is a SmallInteger of value 10 being added at ByteString>>at:put: (and 10 is a linefeed). >> >> Also the string in the entity is a WideString (ZnUTF8Encoder>>next:putAll:startingAt:toStream is where the choice is made to decode a ByteString vs WideString). >> >> Is this a bug? Running on Pharo 3. My newb debugging skills donât go further :( Other sites that fail are reddit.com, news.ycombinator.com. >> >> Thanks, >> -Ed > > Short answer: > > Zinc writes to or reads from binary streams, the Transcript is a character stream. I know that what you are trying to do is actually in the documentation and in the API, and it normally works, just not in all cases. It is better to use inspection to look at what is going on, you'll get a much more structured (object-oriented) view of what is going on. I would suggest inspecting the ZnClient instance, which will hold the state of the last request and response. > > Long answer: > > If you try > > | response | > response := ZnClient new > url:'http://stfx.eu/small.html'; > get; > response. > > response writeToTranscript. > > It will work and print > > HTTP/1.1 200 OK > X-Pad: avoid browser bug > Date: Mon, 29 Dec 2014 18:56:37 GMT > Content-Length: 113 > Etag: "202f9-71-4c7ae94364f1e" > Server: Apache/2.2.22 (Ubuntu) > Accept-Ranges: bytes > Last-Modified: Mon, 20 Aug 2012 08:48:51 GMT > Vary: Accept-Encoding > Content-Type: text/html > > <html> > <head><title>Small</title></head> > <body><h1>Small</h1><p>This is a small HTML document</p></body> > </html> > > So what is the difference ? > > The fact that the responses that you get from the website you mention are using chunked transfer encoding (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) Zinc deals with this in both ways, while reading a response, but also while writing a response (which is what you are trying to do here). > > Here is how you disable chunked transfer encoding so that you can write the response to the Transcript > > | response | > response := ZnClient new > url:'http://amazon.com'; > get; > response. > > response headers removeKey: 'Transfer-Encoding'. > response writeToTranscript. > > Zinc manages to write to the Transcript in most cases by cheating a bit: it wraps a ZnBivalentWriteStream around another stream when needed - such a stream can do both binary and character writing at the same time (though the result is only good for quick and dirty debugging, since it is not 100% correct). I forgot to add that in the case of chunked transfer encoding, the bivalent property of the output stream gets lost because it gets wrapped in both a ZnChunkedWriteStream and a ZnBufferedWriteStream. > I hope the long explanation didn't make it worse ;-) > > HTH, > > Sven > > PS: BTW, in Pharo 4 with Zinc #bleedingEdge you get even nicer and more high level presentations of Zinc objects in GT-Inspector ! >

Dec. 29, 2014

Re: [Pharo-users] ZnClient Error - Improper store into indexable object

by Sven Van Caekenberghe

Hi Edward, > On 29 Dec 2014, at 17:19, Edward Povazan <empovazan(a)gmail.com> wrote: > > I am playing around with Zinc, and I get an > "Error - Improper store into indexable objectâ > at > ZnBufferedWriteStream>>nextPut: > > My Workspace: > ----- > | response | > response := ZnClient new > url:'http://amazon.com'; > get; > response. > > response writeOn: Transcript. > Transcript flush > ----- > > The reason is that instead of a Character, there is a SmallInteger of value 10 being added at ByteString>>at:put: (and 10 is a linefeed). > > Also the string in the entity is a WideString (ZnUTF8Encoder>>next:putAll:startingAt:toStream is where the choice is made to decode a ByteString vs WideString). > > Is this a bug? Running on Pharo 3. My newb debugging skills donât go further :( Other sites that fail are reddit.com, news.ycombinator.com. > > Thanks, > -Ed Short answer: Zinc writes to or reads from binary streams, the Transcript is a character stream. I know that what you are trying to do is actually in the documentation and in the API, and it normally works, just not in all cases. It is better to use inspection to look at what is going on, you'll get a much more structured (object-oriented) view of what is going on. I would suggest inspecting the ZnClient instance, which will hold the state of the last request and response. Long answer: If you try | response | response := ZnClient new url:'http://stfx.eu/small.html'; get; response. response writeToTranscript. It will work and print HTTP/1.1 200 OK X-Pad: avoid browser bug Date: Mon, 29 Dec 2014 18:56:37 GMT Content-Length: 113 Etag: "202f9-71-4c7ae94364f1e" Server: Apache/2.2.22 (Ubuntu) Accept-Ranges: bytes Last-Modified: Mon, 20 Aug 2012 08:48:51 GMT Vary: Accept-Encoding Content-Type: text/html <html> <head><title>Small</title></head> <body><h1>Small</h1><p>This is a small HTML document</p></body> </html> So what is the difference ? The fact that the responses that you get from the website you mention are using chunked transfer encoding (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) Zinc deals with this in both ways, while reading a response, but also while writing a response (which is what you are trying to do here). Here is how you disable chunked transfer encoding so that you can write the response to the Transcript | response | response := ZnClient new url:'http://amazon.com'; get; response. response headers removeKey: 'Transfer-Encoding'. response writeToTranscript. Zinc manages to write to the Transcript in most cases by cheating a bit: it wraps a ZnBivalentWriteStream around another stream when needed - such a stream can do both binary and character writing at the same time (though the result is only good for quick and dirty debugging, since it is not 100% correct). I hope the long explanation didn't make it worse ;-) HTH, Sven PS: BTW, in Pharo 4 with Zinc #bleedingEdge you get even nicer and more high level presentations of Zinc objects in GT-Inspector !

Dec. 29, 2014

ZnClient Error - Improper store into indexable object

by Edward Povazan

I am playing around with Zinc, and I get an "Error - Improper store into indexable objectâ at ZnBufferedWriteStream>>nextPut: My Workspace: ----- | response | response := ZnClient new url:'http://amazon.com'; get; response. response writeOn: Transcript. Transcript flush ----- The reason is that instead of a Character, there is a SmallInteger of value 10 being added at ByteString>>at:put: (and 10 is a linefeed). Also the string in the entity is a WideString (ZnUTF8Encoder>>next:putAll:startingAt:toStream is where the choice is made to decode a ByteString vs WideString). Is this a bug? Running on Pharo 3. My newb debugging skills donât go further :( Other sites that fail are reddit.com, news.ycombinator.com. Thanks, -Ed

Dec. 29, 2014

Re: [Pharo-users] Question on temporal variables in Workspace

by nacho

Thanks Doru, That was perfectly clear. Best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Question-on-temporal-variables-in-Workspace-tp4797161… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 29, 2014

Re: [Pharo-users] Question on temporal variables in Workspace

by Tudor Girba

Hi, The current behavior, which indeed is preserved in the Playground because we did not get to revisit it yet, is like that: - if you do not define a variable explicitly, it will appear red. - if you run the code, the variable will be automatically define within the scope of the Playground/Workspace object which lives as long as the window does - thus, essentially you get a kind of a persistent variable that survives an execution - that is the reason why you can inspect the variable and get the result that it has accumulated - one source of confusion is that after you run the code, the variable still remains red. However, after you type one character, it gets blue. Ideally, we should have a more interactive way of defining variables and have an overview available at all times. Cheers, Doru On Mon, Dec 29, 2014 at 1:27 AM, Edward Povazan <empovazan(a)gmail.com> wrote: > Interesting - when I use Playground, the variable is red at first. After > the first doit, it turns blue, I assume because it is now bound to an > object. When I inspect after the initial doit, I get an inspector with the > real object. > So ... installing GToolkit on Pharo 3 is the answer :) > > -Edward > > On Dec 28, 2014, at 10:23 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > yes that is an issue I have as well and it seems that it also continues in > Pharo 4 Playground. But generally should not affect your code. > > On Sun, Dec 28, 2014 at 4:32 PM, nacho <0800nacho(a)gmail.com> wrote: > >> First of all thanks for all the responses. I should have checked the class >> comment first. >> >> I agree with Kilon, if I use a temporary variable in a workspace after >> doing >> the code if I inspect it the object is gone whereas doing it the way Kilon >> does the object is still there. >> Now why in my Pharo images Workspace variable (I suppose this is the >> correct >> term isn't it?) are in red and in Kilon's awesome tutorials are in blue? >> best regards >> Nacho >> >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context: >> http://forum.world.st/Question-on-temporal-variables-in-Workspace-tp4797161… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 29, 2014

Re: [Pharo-users] Question on temporal variables in Workspace

by Edward Povazan

Interesting - when I use Playground, the variable is red at first. After the first doit, it turns blue, I assume because it is now bound to an object. When I inspect after the initial doit, I get an inspector with the real object. So ... installing GToolkit on Pharo 3 is the answer :) -Edward > On Dec 28, 2014, at 10:23 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > yes that is an issue I have as well and it seems that it also continues in Pharo 4 Playground. But generally should not affect your code. > >> On Sun, Dec 28, 2014 at 4:32 PM, nacho <0800nacho(a)gmail.com> wrote: >> First of all thanks for all the responses. I should have checked the class >> comment first. >> >> I agree with Kilon, if I use a temporary variable in a workspace after doing >> the code if I inspect it the object is gone whereas doing it the way Kilon >> does the object is still there. >> Now why in my Pharo images Workspace variable (I suppose this is the correct >> term isn't it?) are in red and in Kilon's awesome tutorials are in blue? >> best regards >> Nacho >> >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context: http://forum.world.st/Question-on-temporal-variables-in-Workspace-tp4797161… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 29, 2014