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

Re: [Pharo-users] RAM-efficient alternative to ZnMultiPartFormDataEntity

by Stephan Eggermont

On 29/06/15 10:00, mikefilonov wrote: > Hi Sven, > > Thank you for a prompt reply. > > I have in mind something similar to the followin nginx plugin: > http://www.grid.net.ru/nginx/upload.en.html That is in http://www.squeaksource.com/fileupload Stephan

July 1, 2015

Re: [Pharo-users] [Ann] DragPanels: Floating palette windows with drag-and-drop in Morphic

by Stephan Eggermont

On 01/07/15 13:00, H. Hirzel wrote: > BTW > > Gofer new > smalltalkhubUser: 'StephanEggermont' project: 'Documentation' > package: 'CardsMorphic'; > load. > > taken from above gives an error message. Needs a configuration, depends on DragPanels and WebSocket from Zinc. > I understand that there is no menu command yet to do the export so I did > > CardsSvgWriter newFile: 'cards.svg' on: (CardWall allInstances at: 1) > > in a playground workspace window. I suggest to include that the context menu. You noticed the websocket client? > Texts are preserved in the svg file, so search is possible. > > Fontsize is an issue: in the exported SVG file it is much smaller than > in the CardWall panel. Is it? I didn't define a font in SVG, and most fonts look smaller than the one I used in the panel. Including fonts looks more painful than including pictures. > Adding a card by just typing the card text and hitting '<ENTER>' would be nice. There is a shortcut Alt-A defined in CardsApplication. I tried defining <enter> but that seems to be intercepted somewhere. Stephan

July 1, 2015

Re: [Pharo-users] Key language differences with VW2.5

by stepharo

not that much in fact. Pharo as sharedPool (special class) instead of PoolDictionrary > Hi all, > I'm dealing with some VW2.5 code i want to read/port/rewrite. Are > there any key syntactical/semantical differences one should be aware of? > Thank you!

July 1, 2015

Re: [Pharo-users] skipping whole class

by Peter UhnÃ¡k

Of course... thanks :) Peter On Wed, Jul 1, 2015 at 6:44 PM, Camille <camille.teruel(a)gmail.com> wrote: > > > On 01 Jul 2015, at 18:24, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Is it possible to skip whole class from testing? > > I could do "self skip" for individual methods, but the problems arise > even in setUp so I would like to stop the whole class from being tested. Is > that possbile? > > Yes it is: put a âself skipâ in the setUp method :) > > Camille > > > > > Thanks, > > Peter > > >

July 1, 2015

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

by Thierry Goubier

Le 01/07/2015 21:16, jtuchel(a)objektfabrik.de a Ã©crit : > You mean RewriteRules? I was planning to do that, for this exact reason. > But you know how things go when there is a long list of priorities. > I know it saves a lot of time and makes porting so much more safe, but > it needs an up-front investment in time... Yes, rewrite rules. Mark Rizun GUI attempts are a very interesting direction to handle that... Oh, by the way, Mark, if you're listening... I did what you were trying to do by changing AST nodes positions in Pharo, but on a SmaCC based AST for another language. I have to admit that you were right to try to do it that way, but that the Pharo/RB AST infrastructure wasn't suitable whereas SmaCC infrastructure is. Thierry

July 1, 2015

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

by Sven Van Caekenberghe

But before you ask for help on the Pharo ML you should run the NeoCSV code on Pharo to validate that your assumption hold there. If not, it is a porting error/problem. And unit tests are *VERY IMPORTANT* to maintain our sanity across versions and/or platforms. Again, what you report as a potential problem isn't one, I think. Please test on Pharo itself. > On 01 Jul 2015, at 21:07, jtuchel(a)objektfabrik.de wrote: > > I gave up on porting tests. VAST doesn't support creating Arrays with curly braces, and they are used all over the place in Pharo code. I wuld use them if I had them, so this is not an accuse or anything. It's just a huge load of work to keep tests up to date when porting newer versions, so I just ignore tests when porting. A sad truth. > > Joachim > > Am 01.07.15 um 16:14 schrieb H. Hirzel: >> Joachim, >> >> which results do you get on VA Smalltalk for the tests? >> >> Do they all pass? >> >> --Hannes >> >> On 7/1/15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>> 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 >>> >>> >>> >> > > > -- > ----------------------------------------------------------------------- > 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

You mean RewriteRules? I was planning to do that, for this exact reason. But you know how things go when there is a long list of priorities. I know it saves a lot of time and makes porting so much more safe, but it needs an up-front investment in time... Joachim Am 01.07.15 um 21:10 schrieb Thierry Goubier: > Le 01/07/2015 21:07, jtuchel(a)objektfabrik.de a Ã©crit : >> I gave up on porting tests. VAST doesn't support creating Arrays with >> curly braces, and they are used all over the place in Pharo code. I wuld >> use them if I had them, so this is not an accuse or anything. It's just >> a huge load of work to keep tests up to date when porting newer >> versions, so I just ignore tests when porting. A sad truth. > > Maybe we should write a refactoring to change those curly braces into > an equivalent Array based syntax? > > I'll have some significant porting from Pharo to do one of these days, > so maybe I'll setup something for that. > > Thierry > >> >> Joachim >> >> Am 01.07.15 um 16:14 schrieb H. Hirzel: >>> Joachim, >>> >>> which results do you get on VA Smalltalk for the tests? >>> >>> Do they all pass? >>> >>> --Hannes >>> >>> On 7/1/15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>> 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 >>>> >>>> >>>> >>> >> >> > > > -- ----------------------------------------------------------------------- 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 Thierry Goubier

Le 01/07/2015 21:07, jtuchel(a)objektfabrik.de a Ã©crit : > I gave up on porting tests. VAST doesn't support creating Arrays with > curly braces, and they are used all over the place in Pharo code. I wuld > use them if I had them, so this is not an accuse or anything. It's just > a huge load of work to keep tests up to date when porting newer > versions, so I just ignore tests when porting. A sad truth. Maybe we should write a refactoring to change those curly braces into an equivalent Array based syntax? I'll have some significant porting from Pharo to do one of these days, so maybe I'll setup something for that. Thierry > > Joachim > > Am 01.07.15 um 16:14 schrieb H. Hirzel: >> Joachim, >> >> which results do you get on VA Smalltalk for the tests? >> >> Do they all pass? >> >> --Hannes >> >> On 7/1/15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>> 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 jtuchel＠objektfabrik.de

I gave up on porting tests. VAST doesn't support creating Arrays with curly braces, and they are used all over the place in Pharo code. I wuld use them if I had them, so this is not an accuse or anything. It's just a huge load of work to keep tests up to date when porting newer versions, so I just ignore tests when porting. A sad truth. Joachim Am 01.07.15 um 16:14 schrieb H. Hirzel: > Joachim, > > which results do you get on VA Smalltalk for the tests? > > Do they all pass? > > --Hannes > > On 7/1/15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >> 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 >> >> >> > -- ----------------------------------------------------------------------- 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] HTTP file logging for Zinc

by Sven Van Caekenberghe

> On 01 Jul 2015, at 19:54, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Thank you Sven! You're welcome. One thing that I did that I am not sure of is, whether Referer and User-Agent should be "-" or just "" when absent, I chose the first one but I am not sure. > How does it work with FileStreams when the requests come from different threads of the server? I mean, is FileStream thread safe? I guess that if I have multiple images I should have a file per image, otherwise I couldn't write to a single file. Everything goes through Announcer, but that does not seem to serialise access (but I might be wrong). It should technically be possible to add monitor on the receiving end. If you have multiple images, that you need to consolidate things yourself. > I will add the payload logging somehow. Maybe writing to an SQLite db. Let us know how it goes. I am especially interested if other tools dig the output. > Thank you again. > > > Esteban A. Maringolo > > 2015-07-01 12:01 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Esteban, > > > On 29 Jun 2015, at 21:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > > Hello everyone, > > > > I want to record everything that goes in or out from our REST API servers, maybe including HTTP payload (JSON mostly). > > > > ZnLogEvent seems to have the basic building blocks for logging, but I want to know if there is > > a package/project that already provides file logging, so I can not only have the logs, but also if the file format is compatible with other http logs I can run traditional web log tools on them, like Webalizer or AWStats. > > > > Thank you! > > > > Esteban A. Maringolo > > I committed the following: > > === > Name: Zinc-HTTP-SvenVanCaekenberghe.432 > Author: SvenVanCaekenberghe > Time: 1 July 2015, 4:50:46.339985 pm > UUID: 56da27df-1641-4b62-ba6d-34345f31a1af > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.431 > > Added ZnCommonLogFormat, an object that formats ZnServerTransactionEvent log objects using the Apache Common Log Format (Combined) > === > > From the class comment: > > === > I am ZnCommonLogFormat, I can output ZnServerTransactionEvent objects using Apache Common Log Format (CLF). > > https://en.wikipedia.org/wiki/Common_Log_Format > https://httpd.apache.org/docs/trunk/logs.html#common > > > === > > Which will give the following output: > > === > 127.0.0.1 - - [01/Jul/2015:16:35:36 +02:00] "GET /random HTTP/1.1" 200 64 "http://localhost:1701/help" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:35:37 +02:00] "GET /random HTTP/1.1" 200 64 "http://localhost:1701/help" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:20 +02:00] "GET / HTTP/1.1" 200 977 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:21 +02:00] "GET /echo HTTP/1.1" 200 674 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:25 +02:00] "GET /echo?foo=1 HTTP/1.1" 200 680 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:53 +02:00] "GET /echo?foo=12 HTTP/1.1" 200 681 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:39:13 +02:00] "GET /random HTTP/1.1" 200 64 "-" "curl/7.37.1" > 127.0.0.1 - sven [01/Jul/2015:16:40:43 +02:00] "GET /random HTTP/1.1" 200 64 "-" "curl/7.37.1" > 127.0.0.1 - - [01/Jul/2015:16:42:18 +02:00] "GET /bytes/256 HTTP/1.1" 200 256 "-" "Zinc HTTP Components 1.0" > === > > This still needs battle testing and feedback. > > HTH, > > Sven > > >

July 1, 2015