July 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Interactive table support in Pharo (thanks to the new OS window architecture)

by Merwan Ouddane

The objects on the screen are just shapes printed on paper and then glued on plastic ^^ These shapes looks like QRCodes and the table sends different IDs for each of them Cheers, Merwan On mer., 2015-07-01 at 15:39 +0200, Luc Fabresse wrote: > Hi Stef, > > > Nice ! > Did you build the objects that you put on the screen? > What materials are they made with? > > Cheers, > > #Luc > > > 2015-06-30 16:16 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Cool stuff. > > Let's keep on truckin' > > This makes for interesting Roassal interactions. > > Phil > > > Le 30 juin 2015 13:49, "Sean P. DeNigris" > <sean(a)clipperadams.com> a Ã©crit : > > > > stepharo wrote > > > Interactive table support in Pharo > > > > Wow! > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Interactive-table-support-in-Pharo-thanks-to-the-new-… > > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > >

July 1, 2015

Re: [Pharo-users] Interactive table support in Pharo (thanks to the new OS window architecture)

by Luc Fabresse

Hi Stef, Nice ! Did you build the objects that you put on the screen? What materials are they made with? Cheers, #Luc 2015-06-30 16:16 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Cool stuff. > > Let's keep on truckin' > > This makes for interesting Roassal interactions. > > Phil > > Le 30 juin 2015 13:49, "Sean P. DeNigris" <sean(a)clipperadams.com> a > Ã©crit : > > > > stepharo wrote > > > Interactive table support in Pharo > > > > Wow! > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Interactive-table-support-in-Pharo-thanks-to-the-new-… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > >

July 1, 2015

Re: [Pharo-users] an elegant way to return a result

by jtuchel＠objektfabrik.de

Stef, you're shooting the wrong man! ;-) The crime was committed in your team ;-)))) See you in Brescia Joachim Am 30.06.15 um 19:19 schrieb stepharo: > > > Le 30/6/15 14:39, jtuchel(a)objektfabrik.de a Ã©crit : >> Ah, Okay, you are mentioning the one and only one case in which this >> could make sense.... ;-) >> >> Something like >> >> stream next ifNil: [^stream next]. > > so ugly. > Please we should not teach how to do exception with blocks :) >> >> So there may be cases where the two sends do not return the same >> result. But that is, of course, not what the OP suggested. >> Nevertheless, I was too fast in criticizing ;-) >> >> I would consider code like that "less easy" to maintain, however. >> >> Nice thinking Kata ;-) >> >> Joachim >> >> >> >> Am 30.06.15 um 14:22 schrieb Esteban Lorenzano: >>> ah yeah :) >>> >>> I assumed >>> >>> first "something aMsg" ~= second "something aMsgâ >>> >>> In case is the same, the correct way is as you say: >>> >>> ^ something aMsg ifNil: [ anotherResult ] >>> >>> (sorry, he :P) >>> >>>> On 30 Jun 2015, at 13:43, jtuchel(a)objektfabrik.de wrote: >>>> >>>> Am 30.06.15 um 13:40 schrieb Peter UhnÃ¡k: >>>>> Make sense if there's code in between. >>>> not sure what you're saying. I mean, sending the message twice >>>> makes sense if you already know the outcome? Hmmm... >>>> >>>>> something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" >>>>> "much more code" >>>>> ^ aNotherResult >>>>> >>>>> Peter >>>> >>>> -- >>>> ----------------------------------------------------------------------- >>>> >>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>> Fliederweg 1 http://www.objektfabrik.de >>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>>> >>>> >>> >>> >> >> > > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 1, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by jtuchel＠objektfabrik.de

I am not complaining. It just makes porting harder. What made the thing especially strange was that I only had that problem with uploaded files because the Browser removes the trailing CrLf (or better, doesn't add another one in the multipart form data). So reading from a file all works like a charm, but not when you process the same, uploaded file on the server side... Joachim Am 01.07.15 um 15:12 schrieb Sven Van Caekenberghe: > Yes, on Pharo, #next (and #peek or #peekFor:) all return nil when #atEnd. > > It is the way it is (I am personally for stricter semantics), but that fact is certainly used in code all allround the place. > >> On 01 Jul 2015, at 15:06, jtuchel(a)objektfabrik.de wrote: >> >> Hi Sven, >> >> I didn't test on Pharo. But I remember seeing differences in the way Pharo and VAST react to reads beyond the end of a Stream. >> Not sure, but this could have been in NeoCSV context two or three years ago. >> >> So it is very likely I was bitten by platform differences. >> >> Thanks for answering. >> >> Joachim >> >> Am 01.07.15 um 14:05 schrieb Sven Van Caekenberghe: >>> Hi Joachim, >>> >>> First, thanks for the feedback. >>> >>> Second, since you are on a different platform, that might be a factor. >>> >>> Did you test your problem on Pharo itself ? >>> >>> Because there are already unit tests specifically for the case you describe: >>> >>> #testEmptyLastFieldUnquoted >>> #testEmptyLastFieldQuoted >>> >>> These obviously pass for Pharo, do they pass for you ? >>> >>> Maybe your problem case is slightly different though ? >>> >>> Sven >>> >>>> On 01 Jul 2015, at 13:40, jtuchel(a)objektfabrik.de wrote: >>>> >>>> Hi, >>>> >>>> I've tried porting SvenVanCaekenberghe.20 and see the same problems in this version. IN addition to the fix already mentioned, I also had to change readSeparator: >>>> >>>> readSeparator >>>> >>>> ^self atEnd ifFalse: [self peekFor: separator] >>>> >>>> As far as I can tell by now, this fixes the problem at hand. Any ideas if this is a safe fix? >>>> >>>> Joachim >>>> >>>> >>>> Am 01.07.15 um 12:35 schrieb jtuchel(a)objektfabrik.de: >>>>> Hi there, >>>>> >>>>> I am on VA Smalltalk and therefor using an older version of NeoCSV (SvenVanCaekenberghe.14). I found a bug in this old version that is somewhat special. >>>>> >>>>> It seems NeoCSV cannot handle the situation where the very last field is just empty AND if there is no trailing CRLF at the end of the file. Somethinng like this: >>>>> >>>>> SecondLastColumnValue;;<EOF> >>>>> >>>>> In that case, readField fails because it tries to do a readQuotedField or readUnquotedField, both of which try to read beyond EOF. >>>>> >>>>> So I changed readField to this: >>>>> >>>>> readField >>>>> >>>>> ^self atEnd "In case the very last field of a file is empty, like '45;56;;'" >>>>> ifTrue: [''] >>>>> ifFalse: [self peekQuote ifTrue: [self readQuotedField] ifFalse: [self readUnquotedField]] >>>>> >>>>> and all seems fine so far. >>>>> >>>>> Side note: My original file has a trailing CrLf but if I upload it via a browser to a Seaside Server, the Browser cuts off the trailing CrLf (I can see this in the Browser's Network debugging tools - both in IE and FF) - so it seems NeoCSV has to be ready for this situation. >>>>> >>>>> Joachim >>>>> >>>>> >>>> -- >>>> ----------------------------------------------------------------------- >>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>> Fliederweg 1 http://www.objektfabrik.de >>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>>> >>>> >>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 1, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by Sven Van Caekenberghe

Yes, on Pharo, #next (and #peek or #peekFor:) all return nil when #atEnd. It is the way it is (I am personally for stricter semantics), but that fact is certainly used in code all allround the place. > On 01 Jul 2015, at 15:06, jtuchel(a)objektfabrik.de wrote: > > Hi Sven, > > I didn't test on Pharo. But I remember seeing differences in the way Pharo and VAST react to reads beyond the end of a Stream. > Not sure, but this could have been in NeoCSV context two or three years ago. > > So it is very likely I was bitten by platform differences. > > Thanks for answering. > > Joachim > > Am 01.07.15 um 14:05 schrieb Sven Van Caekenberghe: >> Hi Joachim, >> >> First, thanks for the feedback. >> >> Second, since you are on a different platform, that might be a factor. >> >> Did you test your problem on Pharo itself ? >> >> Because there are already unit tests specifically for the case you describe: >> >> #testEmptyLastFieldUnquoted >> #testEmptyLastFieldQuoted >> >> These obviously pass for Pharo, do they pass for you ? >> >> Maybe your problem case is slightly different though ? >> >> Sven >> >>> On 01 Jul 2015, at 13:40, jtuchel(a)objektfabrik.de wrote: >>> >>> Hi, >>> >>> I've tried porting SvenVanCaekenberghe.20 and see the same problems in this version. IN addition to the fix already mentioned, I also had to change readSeparator: >>> >>> readSeparator >>> >>> ^self atEnd ifFalse: [self peekFor: separator] >>> >>> As far as I can tell by now, this fixes the problem at hand. Any ideas if this is a safe fix? >>> >>> Joachim >>> >>> >>> Am 01.07.15 um 12:35 schrieb jtuchel(a)objektfabrik.de: >>>> Hi there, >>>> >>>> I am on VA Smalltalk and therefor using an older version of NeoCSV (SvenVanCaekenberghe.14). I found a bug in this old version that is somewhat special. >>>> >>>> It seems NeoCSV cannot handle the situation where the very last field is just empty AND if there is no trailing CRLF at the end of the file. Somethinng like this: >>>> >>>> SecondLastColumnValue;;<EOF> >>>> >>>> In that case, readField fails because it tries to do a readQuotedField or readUnquotedField, both of which try to read beyond EOF. >>>> >>>> So I changed readField to this: >>>> >>>> readField >>>> >>>> ^self atEnd "In case the very last field of a file is empty, like '45;56;;'" >>>> ifTrue: [''] >>>> ifFalse: [self peekQuote ifTrue: [self readQuotedField] ifFalse: [self readUnquotedField]] >>>> >>>> and all seems fine so far. >>>> >>>> Side note: My original file has a trailing CrLf but if I upload it via a browser to a Seaside Server, the Browser cuts off the trailing CrLf (I can see this in the Browser's Network debugging tools - both in IE and FF) - so it seems NeoCSV has to be ready for this situation. >>>> >>>> Joachim >>>> >>>> >>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>> Fliederweg 1 http://www.objektfabrik.de >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >>> >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

July 1, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by jtuchel＠objektfabrik.de

Hi Sven, I didn't test on Pharo. But I remember seeing differences in the way Pharo and VAST react to reads beyond the end of a Stream. Not sure, but this could have been in NeoCSV context two or three years ago. So it is very likely I was bitten by platform differences. Thanks for answering. Joachim Am 01.07.15 um 14:05 schrieb Sven Van Caekenberghe: > Hi Joachim, > > First, thanks for the feedback. > > Second, since you are on a different platform, that might be a factor. > > Did you test your problem on Pharo itself ? > > Because there are already unit tests specifically for the case you describe: > > #testEmptyLastFieldUnquoted > #testEmptyLastFieldQuoted > > These obviously pass for Pharo, do they pass for you ? > > Maybe your problem case is slightly different though ? > > Sven > >> On 01 Jul 2015, at 13:40, jtuchel(a)objektfabrik.de wrote: >> >> Hi, >> >> I've tried porting SvenVanCaekenberghe.20 and see the same problems in this version. IN addition to the fix already mentioned, I also had to change readSeparator: >> >> readSeparator >> >> ^self atEnd ifFalse: [self peekFor: separator] >> >> As far as I can tell by now, this fixes the problem at hand. Any ideas if this is a safe fix? >> >> Joachim >> >> >> Am 01.07.15 um 12:35 schrieb jtuchel(a)objektfabrik.de: >>> Hi there, >>> >>> I am on VA Smalltalk and therefor using an older version of NeoCSV (SvenVanCaekenberghe.14). I found a bug in this old version that is somewhat special. >>> >>> It seems NeoCSV cannot handle the situation where the very last field is just empty AND if there is no trailing CRLF at the end of the file. Somethinng like this: >>> >>> SecondLastColumnValue;;<EOF> >>> >>> In that case, readField fails because it tries to do a readQuotedField or readUnquotedField, both of which try to read beyond EOF. >>> >>> So I changed readField to this: >>> >>> readField >>> >>> ^self atEnd "In case the very last field of a file is empty, like '45;56;;'" >>> ifTrue: [''] >>> ifFalse: [self peekQuote ifTrue: [self readQuotedField] ifFalse: [self readUnquotedField]] >>> >>> and all seems fine so far. >>> >>> Side note: My original file has a trailing CrLf but if I upload it via a browser to a Seaside Server, the Browser cuts off the trailing CrLf (I can see this in the Browser's Network debugging tools - both in IE and FF) - so it seems NeoCSV has to be ready for this situation. >>> >>> Joachim >>> >>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 1, 2015

Re: [Pharo-users] does anybody use the AST navigation?

by Marcus Denker

> On 01 Jul 2015, at 14:28, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Marcus, Stef, > > 2015-07-01 11:24 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > On 30 Jun 2015, at 19:21, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > Hi guys > > > > does any of you use the AST code navigation? > > I haven't. > > > Because we could remove it. > > I think we never enabled it because we could not use good key combinationsâ¦ the idea > was to use ctrl-arrow keys for itâ¦ > > I still think that AST based navigation is a very good idea, removing it now without having > ever used it for real is not good. > > Marcus, would that make sense to: > > * extract the core of the AST navigation as an API onto the RB AST (the ability to go up, down, left and right in a RB AST, basically), i.e. trying to preserve that way a bit some of the patterns solved by the AST navigation... > > * and reduce whatever is linked with the GUI / text morph components ? > Yes, sounds good... > Oh, looking at the code, the two aspects are implemented together, so it will be painfull to refactor. Looking a bit more at the code... I'm interested by the rationale for askForNodeSelectionFrom: >

July 1, 2015

Re: [Pharo-users] Any Huffman implementation ?

by Martin Dias

Hi, InflateStream has several methods under the "huffman trees" protocol. (In Pharo 40616) MartÃn On Fri, Jun 26, 2015 at 12:46 PM, Merwan Ouddane <merwanouddane(a)gmail.com> wrote: > Hi everybody, > > I was wondering if anyone has implemented or knows where to find the > Huffman compression algorithm in Pharo ? > > Cheers, > Merwan > > >

July 1, 2015

stream not working with MemoryFileSystemFile

by Torsten Bergmann

Christophe Demarey >I tried to create an in-memory file as following: >(MemoryFileSystemFile named: 'Foo') > writeStreamDo: [ :stream | stream nextPutAll: 'bar' ] > >Then I get an improper store into ByteArray. It looks like Character cannot be store in a byte array. >I do not know if the bug is on the memory file system part or other. >Any idea? Why do you use MemoryFileSystemFile directly. Usually the FileSystem is the starting point. And there it works: |fs file| fs := FileSystem memory. file := fs / 'test'. file writeStreamDo: [ :stream | stream nextPutAll: 'bar' ]. fs inspect The nice thing is that you can now browse the file system and file contents with the new GT Inspector. Thanks T.

July 1, 2015

Re: [Pharo-users] does anybody use the AST navigation?

by Thierry Goubier

Hi Marcus, Stef, 2015-07-01 11:24 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 30 Jun 2015, at 19:21, stepharo <stepharo(a)free.fr> wrote: > > > > Hi guys > > > > does any of you use the AST code navigation? > I haven't. > > Because we could remove it. > > I think we never enabled it because we could not use good key > combinationsâ¦ the idea > was to use ctrl-arrow keys for itâ¦ > > I still think that AST based navigation is a very good idea, removing it > now without having > ever used it for real is not good. > Marcus, would that make sense to: * extract the core of the AST navigation as an API onto the RB AST (the ability to go up, down, left and right in a RB AST, basically), i.e. trying to preserve that way a bit some of the patterns solved by the AST navigation... * and reduce whatever is linked with the GUI / text morph components ? Oh, looking at the code, the two aspects are implemented together, so it will be painfull to refactor. Looking a bit more at the code... I'm interested by the rationale for askForNodeSelectionFrom: Thierry > > Marcus >

July 1, 2015