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

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

by Sean P. DeNigris

Hannes Hirzel wrote > though Amber is said to be Pharo compatible there are some problems which > I > have to resolve first. Pharo is the reference implementation, but is a subset. I guess technically that's "compatible", but "compatible" is vague enough to be easily misleading... ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoCSVReader-and-an-empty-field-at-the-very-end-of-a-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 2, 2015

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

by H. Hirzel

Hello Joachim In May I did a port of NeoCSV to Cuis Smalltalk. I followed a process like this 1. download .mcz in its "original" version and unpack it to have the st file only. Keep the Core and the Tests st file in the target repository for reference. 2. Make a copy of the two files 3. Modify the st files with search/replace operations for obvious and safe changes 4. Import and further modify on target platform 5. Run tests and resolve remaining issues 6. Publish on target platform's public repository 7. Document the process so that it can be redone from scratch much faster by myself or somebody else in a semi-automatic way. Remarks: 1) https://github.com/hhzl/Cuis-NeoCSV/blob/master/Neo-CSV-Core-orig.st is 1011 LOC https://github.com/hhzl/Cuis-NeoCSV/blob/master/Neo-CSV-Tests-orig.st is 805 LOC It took me two attempts to arrive at the goal https://github.com/hhzl/Cuis-NeoCSV In the first attempt nearly all tests failed. But this was because of some minor differences which caused most of the problems. After having them fixed the number of tests which passed raised quickly. In the end it needed a combination of systematic changes and some 'compatibility layer' on Cuis which is necessary for the port. The package used for that contains much more than needed, I did not take the time yet to figure out which methods actually are needed. I think only very few methods are needed. I think the Neo-CSV package is very useful to do workspace based applications for an explorative analysis of complex data. CSV data is a representation of one of the most common file formats (Excel data). And we need to be able to do this in various Smalltalk distributions. The Neo-CSV package is well written and not all that complex. Porting can be done in some hours. Sven was very helpful and added another test for me to illustrate a particular use, actually my main use case. Summary: a) So the porting experience was good. b) Porting the tests is a necessity to prove that the port has been done. c) I think you can do the same thing quickly for VA Smalltalk if you actually take the plunge. Way forward: It might be worthwile to consider to maintain a github repository with steps 1,2 and 3 from above. FileOut format for ease of use. Using another repo will distinguish the effort to be a modified _copy_ of http://smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/ Actually Sven already has taken precautions to make the code porting-friendly and he might want to further facilitate this. I am considering a port to Amber Smalltalk, but interestingly though Amber is said to be Pharo compatible there are some problems which I have to resolve first. HTH Hannes On 7/2/15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > Sven, > > you are, of course, right! > I should have checked in Pharo first. But since my version is old > anyways, I would have to try with at least two versions in order to make > sure if the bug is fixed or not. As long as keeping ports current is a > lot of work due to (increasing) differences between Phar and most other > dialects, this is hard work ;-) I should invest in it anyways, however, > since I am using your code from Pharo and you didn't ask me to use it... > > So, to address this Array construction issue (as an example of others). > This cannot be handled with Grease or the like, since what is in my way > is the Smalltalk compiler (I am trying to concince Instantiations to > support {} for literal Array construction, but until I'm successful...). > > Given somebody wrote RewriteRules to replace {} with "(Array new: x) > addAll:", this should probably be used on non-Pharo-platforms as part of > a port, so that the "original" code is still the Metacello version it > was on Pharo. > > My plan for a port: > 1. download .mcz in its "original" version and don't modify it > 2. import and modify on target platform > 3. test and publish on target platform's public repository > > What do you think would be a good process to porting when it involves > such steps? > > The problem with Step 2 is: I am not sure if RewriteRules can work in > code that's not compiled. (Well, I am mostly sure this won't work, just > asking for confirmation) You cannot compile methods with Arrays > constructed with curly braces on VAST. > > So another possible process would be: > 1. use Pharo to modify downloaded code in order to make it importable on > target platform > 2. publish this code somewhere (not official Pharo repositories, maybe > StHub) > 3. Download the modified version and import into target dialect > 4. Make final adjustments to make code and tests run > 5. Publish to target platform's public repository > > Any thoughts or ideas? People interested in joining efforts? > > And, now that we're on a new topic anyways, misusing this thread (mea > culpa): > > I still wonder how we could make it easier to contribute back. Every > time I find a bug in some code from Pharo, there are several things to > consider: > 1. Is there a newer version on Pharo that doesn't have this bug? > a) yes: port newer version > b) no: I'm in trouble - see below > > in case of 1b), there are two options now: > 1. I fire up Pharo and fix the bug in the original code, then commit the > changes to the official repository/ies, and then port the fixed version > 2. I contact the ML or the author/maintainer of the code and give them a > bug report and hopefully a fix, which may or may not be compatible with > Pharo. Then I can either port the fixed version or just keep my fixed > version (if the fix is the same, this is not a problem from the code > perspective, but maybe from a version numbering standpoint). > > I am interested in ideas here and would like to hear from people > interested in discussing these issues. Maybe ESUG would be a good > opportunity to start discussing. Maybe we can start a new initiative for > this problem area... > > Joachim > > > > Am 01.07.15 um 21:27 schrieb 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 >>> >>> >> >> > > > -- > ----------------------------------------------------------------------- > 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 2, 2015

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

by Ben Coman

On Thu, Jul 2, 2015 at 3:48 PM, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > Sven, > > you are, of course, right! > I should have checked in Pharo first. But since my version is old anyways, I > would have to try with at least two versions in order to make sure if the > bug is fixed or not. As long as keeping ports current is a lot of work due > to (increasing) differences between Pharo and most other dialects, this is > hard work ;-) I should invest in it anyways, however, since I am using your > code from Pharo and you didn't ask me to use it... This reminds me of Joel Spolsky's article on "barriers to entry." He makes an interesting point with his "PayMyBills" example that a hidden barrier to entry is not how hard it is to switch in, but how hard it is to switch out [or port]. cheers -ben

July 2, 2015

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

by Marcus Denker

> On 01 Jul 2015, at 23:30, stepharo <stepharo(a)free.fr> wrote: > > >> > 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 > > the problem is that the idea is cool but if nobody spent time making it useful for real then > we will never know if it is working for real. I think that finding the right operations that makes sense > can be probably difficult. > > Now we did the same analysis that thierry. > The tree operations like parten children sibbling should not be on class side of nodes navigation > but in the AST itself. > > We can keep used code in the image but I do not really understand why? > So we have working tools such as the dependencies browser that could help us that > were out of the image and things that nobody ever used in. > > For me I would unload the code and find a student or somebody interested to > improve for real. > We could remove it for nowâ¦ it makes only sens when we can use CTRL-arrow keys to navigate, but there are problems with that related to the keyboard events, I think. Marcus

July 2, 2015

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

by jtuchel＠objektfabrik.de

Sven, you are, of course, right! I should have checked in Pharo first. But since my version is old anyways, I would have to try with at least two versions in order to make sure if the bug is fixed or not. As long as keeping ports current is a lot of work due to (increasing) differences between Phar and most other dialects, this is hard work ;-) I should invest in it anyways, however, since I am using your code from Pharo and you didn't ask me to use it... So, to address this Array construction issue (as an example of others). This cannot be handled with Grease or the like, since what is in my way is the Smalltalk compiler (I am trying to concince Instantiations to support {} for literal Array construction, but until I'm successful...). Given somebody wrote RewriteRules to replace {} with "(Array new: x) addAll:", this should probably be used on non-Pharo-platforms as part of a port, so that the "original" code is still the Metacello version it was on Pharo. My plan for a port: 1. download .mcz in its "original" version and don't modify it 2. import and modify on target platform 3. test and publish on target platform's public repository What do you think would be a good process to porting when it involves such steps? The problem with Step 2 is: I am not sure if RewriteRules can work in code that's not compiled. (Well, I am mostly sure this won't work, just asking for confirmation) You cannot compile methods with Arrays constructed with curly braces on VAST. So another possible process would be: 1. use Pharo to modify downloaded code in order to make it importable on target platform 2. publish this code somewhere (not official Pharo repositories, maybe StHub) 3. Download the modified version and import into target dialect 4. Make final adjustments to make code and tests run 5. Publish to target platform's public repository Any thoughts or ideas? People interested in joining efforts? And, now that we're on a new topic anyways, misusing this thread (mea culpa): I still wonder how we could make it easier to contribute back. Every time I find a bug in some code from Pharo, there are several things to consider: 1. Is there a newer version on Pharo that doesn't have this bug? a) yes: port newer version b) no: I'm in trouble - see below in case of 1b), there are two options now: 1. I fire up Pharo and fix the bug in the original code, then commit the changes to the official repository/ies, and then port the fixed version 2. I contact the ML or the author/maintainer of the code and give them a bug report and hopefully a fix, which may or may not be compatible with Pharo. Then I can either port the fixed version or just keep my fixed version (if the fix is the same, this is not a problem from the code perspective, but maybe from a version numbering standpoint). I am interested in ideas here and would like to hear from people interested in discussing these issues. Maybe ESUG would be a good opportunity to start discussing. Maybe we can start a new initiative for this problem area... Joachim Am 01.07.15 um 21:27 schrieb 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 >> >> > > -- ----------------------------------------------------------------------- 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 2, 2015

Re: [Pharo-users] HTTP file logging for Zinc

by Sven Van Caekenberghe

> On 02 Jul 2015, at 01:04, Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Jul 2, 2015 at 2:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> 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. > > Announcer is only thread safe with respect to its own data structures. > It does not make its users thread safe. > cheers -ben OK, that is what I thought. >> >> 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 2, 2015

Re: [Pharo-users] 1$ Recognizer in Pharo

by Peter UhnÃ¡k

This is cool indeed! It would be interesting to integrate it with Roassal to drag elements around. :) Peter On Thu, Jul 2, 2015 at 12:33 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Very cool ! > > > On Jul 1, 2015, at 18:52, stepharo <stepharo(a)free.fr> wrote: > > > > > > Now that we have gestures we can interface recognisers. > > Thanks Thales for the sponsoring. > > > > http://youtu.be/Ghxgv8c9OWM > > > > Stef > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

July 2, 2015

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

by Joachim Tuchel

Just found this on twitter: http://www.cs.wm.edu/~denys/pubs/ICSE%2715-BadSmells-CRC.pdf Am 01.07.2015 23:35 schrieb stepharo <stepharo(a)free.fr>: > > I know :D > > Le 1/7/15 15:19, jtuchel(a)objektfabrik.de a Ã©crit : > > 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 > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > > > > >

July 2, 2015

Phratch: Support for Spanish language in the interface

by Offray Vladimir Luna CÃ¡rdenas

Hi, Some teachers are considering to make some field work with Phratch on learning physics by modelling simple real world phenomena (uniform accelerated movement, free fall etc). I downloaded it today and try to change the interface to Spanish, but I couldn't find the proper place to do it. Has Phratch support for a Spanish interface. If not, how difficult will be to provide this and how can we help? Cheers, Offray

July 2, 2015

Re: [Pharo-users] HTTP file logging for Zinc

by Ben Coman

On Thu, Jul 2, 2015 at 2:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> 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. Announcer is only thread safe with respect to its own data structures. It does not make its users thread safe. cheers -ben > > 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

Re: [Pharo-users] 1$ Recognizer in Pharo

by Johan Fabry

Very cool ! > On Jul 1, 2015, at 18:52, stepharo <stepharo(a)free.fr> wrote: > > > Now that we have gestures we can interface recognisers. > Thanks Thales for the sponsoring. > > http://youtu.be/Ghxgv8c9OWM > > Stef > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

July 1, 2015

Re: [Pharo-users] Modern Events Touch and Gestures in Pharo.

by Merwan Ouddane

On 30/06/2015 22:35, J.F. Rick wrote: > Awesome! There's a reasonable chance that I can contribute to this (or > at least utilize it), depending on what contracts I get. If I do get > that in the near future, who do I contact about contributing? I will maintain it for a while, if you have any suggestions or questions, don't hesitate :) > > Cheers, > > Jeff > > On Tue, Jun 30, 2015 at 1:18 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Thanks Thales for the sponsoring. > > https://youtu.be/eNrbH8A5nyY > > Stef and the rmod team >

July 1, 2015

Re: [Pharo-users] [Pharo-dev] 1$ Recognizer in Pharo

by Merwan Ouddane

The DollarP is available too: (Gofer it smalltalkhubUser: 'MerwanOuddane' project: 'DollarPRecognizer'; package: 'DollarPRecognizer') load. On 02/07/2015 00:02, Sven Van Caekenberghe wrote: > Cool, cool, cool ! > >> On 01 Jul 2015, at 23:52, stepharo <stepharo(a)free.fr> wrote: >> >> >> Now that we have gestures we can interface recognisers. >> Thanks Thales for the sponsoring. >> >> http://youtu.be/Ghxgv8c9OWM >> >> Stef >> >

July 1, 2015

Re: [Pharo-users] 1$ Recognizer in Pharo

by Sven Van Caekenberghe

Cool, cool, cool ! > On 01 Jul 2015, at 23:52, stepharo <stepharo(a)free.fr> wrote: > > > Now that we have gestures we can interface recognisers. > Thanks Thales for the sponsoring. > > http://youtu.be/Ghxgv8c9OWM > > Stef >

July 1, 2015

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

by Matthieu Lacaton

This whole conversation really makes me want to ask: How do you know if some code is bad, good or completely ugly ? I've not been programming for long but I've already heard sentences like this: "Damn this piece of code is so bad !" so often that I am really wondering. What are the rules ? Performant code makes total sense but it seems there is something else. Le 1 juil. 2015 23:36, "stepharo" <stepharo(a)free.fr> a Ã©crit : > I know :D > > Le 1/7/15 15:19, jtuchel(a)objektfabrik.de a Ã©crit : > >> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > >

July 1, 2015

1$ Recognizer in Pharo

by stepharo

Now that we have gestures we can interface recognisers. Thanks Thales for the sponsoring. http://youtu.be/Ghxgv8c9OWM Stef

July 1, 2015

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

by stepharo

I know :D Le 1/7/15 15:19, jtuchel(a)objektfabrik.de a Ã©crit : > 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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > >

July 1, 2015

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

by stepharo

> > 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 the problem is that the idea is cool but if nobody spent time making it useful for real then we will never know if it is working for real. I think that finding the right operations that makes sense can be probably difficult. Now we did the same analysis that thierry. The tree operations like parten children sibbling should not be on class side of nodes navigation but in the AST itself. We can keep used code in the image but I do not really understand why? So we have working tools such as the dependencies browser that could help us that were out of the image and things that nobody ever used in. For me I would unload the code and find a student or somebody interested to improve for real. Stef

July 1, 2015

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

by Stephan Eggermont

On 01/07/15 23:07, Stephan Eggermont wrote: > 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 I should read the whole thread before posting. Large files in web services provide many more challenges than ram efficiency. Oh, the enterprise buses I've crashed... Stephan

July 1, 2015

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

by Stephan Eggermont

On 30/06/15 06:01, mikefilonov wrote: > Thank you for the link. It is a useful example of how ajax upload can be > implemented in Seaside. > > However, by looking at the code which works without nginx plugin I see the > project does not change the mechanism of request reading, meaning if you > upload 1Gb file you still need 1Gb of RAM to store WAFile rawContent. Yes, you want the code that uses the nginx plugin. Stephan

July 1, 2015

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

Re: [Pharo-users] HTTP file logging for Zinc

by Esteban A. Maringolo

Thank you Sven! 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. I will add the payload logging somehow. Maybe writing to an SQLite db. 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

Key language differences with VW2.5

by Laura Risani

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 Camille

> 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

skipping whole class

by Peter UhnÃ¡k

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? Thanks, Peter

July 1, 2015

Seeking help to build an accordion widget for GUI of sQuick

by Jigyasa Grover

Hello All :) I am a newbie in Pharo and have started to build my first application i.e. an offline text search application namely searchQuick. You all are welcome to fork the code (https://github.com/jig08/sQuick_new) , try the infancy application and send in suggestions. Currently, I have built the basic structure of the application using Morphs and have a lot to cover on the GUI part. sQ basically returns the list of file titles from the pre-loaded text files present in the resource folder when a string is searched for. I plan to build an accordion widget (https://jqueryui.com/accordion/) or something similiar to view the results. I seek help on the implementation of this part. Looking forward to a positive response. Regards Jigyasa -- View this message in context: http://forum.world.st/Seeking-help-to-build-an-accordion-widget-for-GUI-of-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

loading with gofer without network

by Christophe Demarey

Hi, I'm trying to load a package (mcz) from the package cache with Gofer. |gofer| gofer := Gofer new repository: MCCacheRepository uniqueInstance; repository: (MCSmalltalkhubRepository owner: 'Seaside' project: 'Grease11'); version: 'Grease-Core-JohanBrichau.94'; disableRepositoryErrors; load As you see, I gave 2 repositories (the first is local, the second one is remote) to Gofer. If you try to execute this code without the network, it will failed! It shouldn't because the mcz is in the package cache. I think it is a bad behavior of Gofer. It does not have to resolve references for ALL the repositories because, at the end, you only use one. I want to change this behavior to only get the first resolved reference (no need to iterate more). If not acceptable, I could only ignore repositories not reachable (disableRepositoryErrors does not work for this use case). Is it ok to change it? Christophe

July 1, 2015

Re: [Pharo-users] HTTP file logging for Zinc

by Sven Van Caekenberghe

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 | formatter | formatter := ZnCommonLogFormat new. ZnLogEvent announcer when: ZnServerTransactionEvent do: [ :event | formatter format: event on: Transcript. Transcript cr; endEntry ]. === 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

Re: [Pharo-users] stream not working with MemoryFileSystemFile

by Christophe Demarey

Le 1 juil. 2015 Ã 14:42, Torsten Bergmann a Ã©crit : > 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. oh, perfect. Looks like I was not using the good api. Thanks, Christophe

July 1, 2015

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

by 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] OpenCL problems since we switch to OS X 10.10.3

by Serge Stinckwich

I switch to 10.10.4 and still the same problem when I launch a simple demo. Process: Pharo [2003] Path: /Applications/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: Pharo 0.2.7-2015.04.20 (21.0) Code Type: X86 (Native) Parent Process: ??? [1] Responsible: Pharo [2003] User ID: 502 Date/Time: 2015-07-01 15:27:09.106 +0200 OS Version: Mac OS X 10.10.4 (14E46) Report Version: 11 Anonymous UUID: 53101D99-4009-6151-7D46-D4F943A588CF Sleep/Wake UUID: 9C69E3C7-C31D-4D2C-ADF8-CBCDC232EAE3 Time Awake Since Boot: 8500 seconds Time Since Wake: 3000 seconds Crashed Thread: 0 Dispatch queue: opencl_runtime Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 VM Regions Near 0x20: --> __TEXT 0000000000001000-00000000000a6000 [ 660K] r-x/rwx SM=COW /Applications/Pharo.app/Contents/MacOS/Pharo Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: opencl_runtime 0 libsystem_kernel.dylib 0x9b27869a __pthread_kill + 10 1 libsystem_pthread.dylib 0x9b3fef19 pthread_kill + 101 2 libsystem_c.dylib 0x91d2feee abort + 156 3 org.pharo.Pharo 0x0004c2bf sigsegv + 175 4 libsystem_platform.dylib 0x9a1c803b _sigtramp + 43 5 ??? 0xffffffff 0 + 4294967295 6 org.pharo.Pharo 0x0004c210 reportStackState + 496 7 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x4045d791 CHAL_INTEL::COCLGen7CommandTransport::AddSurfaceStateTokensForCopy(CHAL_INTEL::tagCHALCommandPacket*, bool, bool) + 225 8 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x4045c50f CHAL_INTEL::COCLGen7CommandTransport::BuildGen7CommandBuffer(CHAL_INTEL::tagCHALCommandPacket*) + 277 9 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x40456357 CHAL_INTEL::ChalContext::SetupFixedFunctionKernelExecute(CHAL_INTEL::tagCHALCommandPacket*, unsigned long*) + 725 10 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x40456df8 CHAL_INTEL::ChalContext::ChalExecuteCopyBufferData(GLDBufferImageRegionRec*, GLDBufferRec*, GLDBufferImageRegionRec*, GLDBufferRec*, GLDFenceRec*) + 1388 11 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x40450839 gldCopyBufferDataWithQueue + 315 12 com.apple.opencl 0x9bf1d69d 0x9bf1b000 + 9885 13 com.apple.opencl 0x9bf3ccca 0x9bf1b000 + 138442 14 com.apple.opencl 0x9bf40451 0x9bf1b000 + 152657 15 libdispatch.dylib 0x9b237130 _dispatch_client_callout + 50 16 libdispatch.dylib 0x9b238570 _dispatch_barrier_sync_f_invoke + 55 17 libdispatch.dylib 0x9b238537 dispatch_barrier_sync_f + 105 18 com.apple.opencl 0x9bf402c0 0x9bf1b000 + 152256 19 com.apple.opencl 0x9bf3bcd0 0x9bf1b000 + 134352 20 com.apple.opencl 0x9bf30c0f clEnqueueReadBuffer + 839 21 ??? 0x22b81b21 0 + 582490913 22 org.pharo.Pharo 0x0009727b primitiveNativeCall + 107 On Wed, May 20, 2015 at 5:05 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Hi Ronie, > > since we switch here from OS X 10.10.2 to 10.10.3, your OpenCL > framework doesn't not work anymore ... We crash Pharo everytime we try > to use GPU. > > This is an except of the crash log: > > Process: Pharo [21039] > Path: /Applications/Pharo.app/Contents/MacOS/Pharo > Identifier: org.pharo.Pharo > Version: Pharo 0.2.7-2015.04.20 (21.0) > Code Type: X86 (Native) > Parent Process: ??? [1] > Responsible: Pharo [21039] > User ID: 502 > > Date/Time: 2015-05-20 16:50:33.740 +0200 > OS Version: Mac OS X 10.10.3 (14D136) > Report Version: 11 > Anonymous UUID: 53101D99-4009-6151-7D46-D4F943A588CF > > Sleep/Wake UUID: D65CFFA9-9DD4-490B-99A5-D5A3F37C8649 > > Time Awake Since Boot: 240000 seconds > Time Since Wake: 19000 seconds > > Crashed Thread: 0 Dispatch queue: opencl_runtime > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > > What can we do ? Apparently this is difficult to downgrade back to 10.10.2 > > Regards > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 1, 2015

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

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

by 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 > >

July 1, 2015

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

by jtuchel＠objektfabrik.de

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

July 1, 2015

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

by H. Hirzel

Thank you for the custom made class CardsSvgWriter I loaded it from http://smalltalkhub.com/#!/~StephanEggermont/Documentation CardsMorphic-StephanEggermont.57 through the Monticello Browser. BTW Gofer new smalltalkhubUser: 'StephanEggermont' project: 'Documentation' package: 'CardsMorphic'; load. taken from above gives an error message. 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. 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. Adding a card by just typing the card text and hitting '<ENTER>' would be nice. --Hannes On 6/30/15, Stephan Eggermont <stephan(a)stack.nl> wrote: > The export as SVG is indeed easy. > I've added this helper class to CardsMorphic-StephanEggermont.56 > It is not well-factored, and for now ignores font families. > > A class helper method to directly create a file: > > CardSvgWriter class>newFile: aString on: aCardWall > ^self new write: aCardWall to: (aString asFileReference writeStream ) > > Write a SVG header, the size and then the contents of the cardwall, > finally close the SVG. > > CardSvgWriter>>write: aWall to: aStream > stream := aStream. > stream nextPutAll: self fileHeader. > self fileSized: aWall fullFrame. > stream cr. > aWall cardSpace submorphsDo: [ :column | > self writeColumn: column]. > stream nextPutAll: '</svg>'. > stream close > > SVG is an XML format > > CardSvgWriter>>fileHeader > ^'<?xml version="1.0" standalone="no"?> > <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" > "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> > ' > > Take the SVG size from the CardWall morph. Two namespaces are needed, > the second one to make the images work. > > CardSvgWriter>>fileSized: frame > stream nextPutAll: '<svg xmlns="http://www.w3.org/2000/svg" > xmlns:xlink="http://www.w3.org/1999/xlink" viewBox = "', > (frame left) asString,' ', > (frame top) asString,' ', > (frame width) asString,' ', > (frame height) asString,'" version = "1.1">' > > For each column, write the title and a gray background > > CardSvgWriter>>writeColumn: aColumn > |background| > stream nextPutAll: '<text x="',(aColumn left+2) asString,'" > y="',(aColumn top+2) asString,'" fill="gray" font-size= "11">'. > stream nextPutAll: aColumn title. > stream nextPutAll: '</text>'. > stream cr. > background := aColumn submorphs first. > stream nextPutAll: '<rect x= "',(background left) asString, > '" y="',(background top) asString, > '" width="',(background width) asString, > '" height="',(background height) asString, > '" fill="rgb(250,250,250)" />'. > stream cr. > background submorphsDo: [ :card | self writeCard: card ]. > > for each card, write its components > > CardSvgWriter>>writeCard: aCard > self writeCardRectangle: aCard. > self writeCardText: aCard. > self writeCardImage: aCard > > The rectangle still has hardcoded border and borderColor > > CardSvgWriter>>writeCardRectangle: aCard > stream nextPutAll: '<rect x= "',(aCard left) asString, > '" y="',(aCard top) asString, > '" width="',(aCard width) asString, > '" height="',(aCard height) asString, > '" stroke="','rgb(240,240,240)'"aCard borderColor asHTMLColor", > '" stroke-width="', '1',"aCard borderWidth asString," > '" fill="',aCard color asHTMLColor,'" />'. > stream cr. > > Positioning of text is different in SVG and Morphic. In SVG, > it is the left-bottom, vs left-top in Morphic. > > CardSVGWriter>>writeCardText: aCard > stream nextPutAll: '<text x="',(aCard left+2) asString,'" y="',(aCard > top+12) asString,'" fill="black" font-size= "10">'. > stream nextPutAll: aCard title. > stream nextPutAll: '</text>'. > stream cr. > > The avatars are jpegs. they need to be base64 encoded. > Here they are repeated for each card, they should be > written once and linked. > > CardSVGWriter>writeCardImage: aCard > aCard person ifNotNil: [ > stream nextPutAll: '<image x="',(aCard right-32) asString,'" > y="',(aCard bottom-32) asString,'" width="32" height="32" > xlink:href="data:image/jpg;base64,', > (ZnUtils encodeBase64: (ByteArray streamContents: [:s | > PluginBasedJPEGReadWriter putForm: (AvatarCache default imageFor: > aCard person) onStream: s])) > ,'"/>'. > stream cr] > >

July 1, 2015

Re: [Pharo-users] pharo looses font settings on linux with retina screen

by Martin BÃ¤hr

Excerpts from Esteban Lorenzano's message of 2015-07-01 11:56:21 +0200: > currently fonts+retina display is not a good combination :( > > can you link a screenshot of the problem you are describing? http://societyserver.org/scripts/get.pike?object=137514 i just ran into another issue. when i inspect that "IndexInterface open." in the playground, the fontsize resets right there. 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 secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

July 1, 2015

NeoCSVReader and an empty field at the very end of a file

by jtuchel＠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

July 1, 2015

Re: [Pharo-users] pharo looses font settings on linux with retina screen

by Esteban Lorenzano

currently fonts+retina display is not a good combination :( can you link a screenshot of the problem you are describing? Esteban > On 01 Jul 2015, at 11:47, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > > hi, > > i am running pharo 40614 on linux on a mac with a retina screen. > > i have not tested this on a normal laptop yet, so i don't know if the retina > resolution is the problem or the pharo version i am using. probably a bit of both. > > the worst issue is that when i restart an image, the font settings are > partially lost and reverted to the original size, which is to small to read on > such a screen. and restoring the font size requires me to reopen all the affected windows. > > there are also issues with some widgets not resizing to the full size of the > font, making the text only partially readable. > > and then there are widgets that have the correct size, but the font remains small. > > and all that is not consistent, sometimes all sizes are correct, sometimes it > is a complete mess. pretty much every time i restart after resetting the font > size i get different results. it makes pharo practically unusable on this > machine, because i am spending to much time fixing fonts, and am not getting > any work done. > > is there some other setting to adjust to the resolution besides selecting a huge font? > > 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 > secretary beijinglug.org > mentor fossasia.org > foresight developer foresightlinux.org realss.com > unix sysadmin > Martin BÃ¤hr working in china http://societyserver.org/mbaehr/ >

July 1, 2015

pharo looses font settings on linux with retina screen

by Martin BÃ¤hr

hi, i am running pharo 40614 on linux on a mac with a retina screen. i have not tested this on a normal laptop yet, so i don't know if the retina resolution is the problem or the pharo version i am using. probably a bit of both. the worst issue is that when i restart an image, the font settings are partially lost and reverted to the original size, which is to small to read on such a screen. and restoring the font size requires me to reopen all the affected windows. there are also issues with some widgets not resizing to the full size of the font, making the text only partially readable. and then there are widgets that have the correct size, but the font remains small. and all that is not consistent, sometimes all sizes are correct, sometimes it is a complete mess. pretty much every time i restart after resetting the font size i get different results. it makes pharo practically unusable on this machine, because i am spending to much time fixing fonts, and am not getting any work done. is there some other setting to adjust to the resolution besides selecting a huge font? 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 secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

July 1, 2015

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

by Marcus Denker

> On 30 Jun 2015, at 19:21, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > does any of you use the AST code navigation? > 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

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

I tried commenting primFlush: fileID in StandardFileStream>>#flush on my desktop PC and the "store" benchmark's speed improved significantly. Original result on Windows 7: 11 per sec Result without flushing on Windows 7: 9 430 per sec Original result on Linux Mint 17: 26 590 per sec Result without flushing on Linux Mint 17: 34 879 per sec Mentioned Linux Mint is in VirtualBox on the same PC. Also loading of Roassal2 now takes 58 seconds insted of 386. Jan Nicolai Hess wrote > 2015-07-01 7:46 GMT+02:00 Jan BlizniÄenko < > bliznjan@.cvut > >: > >> Sounds good, could I try it and run all those benchmarks etc. on it on my >> PCs? >> >> Jan >> > > With this: > http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile… > It seems this all comes down to calling FlushFileBuffers. > > You can check what would happen if we just disabling the explicit flushing > (comment out > self primFlush: fileID > in StandardFileStream>>#flush) > and run the benchmarks. > > > (Of course, I don't know what side effects this have, *I* think WriteFile > calls flush on > its own, and of course *if* this solves the problem, we can not just > disable call to flush in the > image, but have to change the windows file plugin). > > > > > > >> >> >> Nicolai Hess wrote >> > Yes, the vm primitives, like I already told some messages above. >> > FilePrimitives ARE slow on windows. >> > >> > We may get better performance, if we disable windows file >> cache/buffering >> > and use slightly different ways to do the CreateFile and WriteFile >> > calls, and do the buffering on our own, but this is not easy. >> > >> > Luckily (?), this may be alread work if we use the std file api (?) >> > >> > A small dirty test: >> > >> > store bench >> > latest vm -> '22.098 per second' >> > modified vm -> '31,027 per second' >> > >> > (in the modified vm I replaced all file operation from >> > sqWin32FilePrims.c >> > with the code from >> > sqFilePluginBasicPrims.c) >> > >> > The result may seem strange, because both implementation will actually >> use >> > win32s CreateFile/WriteFile methods, but >> > maybe the second one uses better caching/buffering. >> > >> > nicolai >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Nicolai Hess

2015-07-01 7:46 GMT+02:00 Jan BlizniÄenko <bliznjan(a)fit.cvut.cz>: > Sounds good, could I try it and run all those benchmarks etc. on it on my > PCs? > > Jan > With this: http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile… It seems this all comes down to calling FlushFileBuffers. You can check what would happen if we just disabling the explicit flushing (comment out self primFlush: fileID in StandardFileStream>>#flush) and run the benchmarks. (Of course, I don't know what side effects this have, *I* think WriteFile calls flush on its own, and of course *if* this solves the problem, we can not just disable call to flush in the image, but have to change the windows file plugin). > > > Nicolai Hess wrote > > Yes, the vm primitives, like I already told some messages above. > > FilePrimitives ARE slow on windows. > > > > We may get better performance, if we disable windows file cache/buffering > > and use slightly different ways to do the CreateFile and WriteFile > > calls, and do the buffering on our own, but this is not easy. > > > > Luckily (?), this may be alread work if we use the std file api (?) > > > > A small dirty test: > > > > store bench > > latest vm -> '22.098 per second' > > modified vm -> '31,027 per second' > > > > (in the modified vm I replaced all file operation from > > sqWin32FilePrims.c > > with the code from > > sqFilePluginBasicPrims.c) > > > > The result may seem strange, because both implementation will actually > use > > win32s CreateFile/WriteFile methods, but > > maybe the second one uses better caching/buffering. > > > > nicolai > > > > > > -- > View this message in context: > http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 1, 2015

Re: [Pharo-users] Pharo image processing library

by Luc Fabresse

2015-06-30 9:34 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Tue, Jun 30, 2015 at 8:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > > 2015-06-25 18:41 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> > >> Hi, > >> > >> is there any image (as in picture) processing library in the likes of > >> Python's PIL(http://effbot.org/imagingbook/image.htm), > >> > >> or even (highly unlikely) something like OpenCV (http://opencv.org/)? > > > > > > Not that I know of. > > I was interested at one time with the same topic. > > > Juan Vuletich had a nice PhotoSqueak project (squeak 1 or 2?) > > > http://www.jvuletich.org/Squeak/PhotoSqueak/PhotoSqueakGallery/PhotoSqueakG… > > I ask Juan about this one, but apparently this is not open-source. > > > There is Smagick > > http://smalltalkhub.com/#!/~StefanReichhart/Smagick/ > > > > (not a library on its own, but an interface to imagemagick) > > > > I think there was another squeak/imagemagic project but I don't remember. > > > > It would be great to have something like imagemagick, but implemented > > entirely in smalltalk. > > There was some experiments done by Luc : > http://smalltalkhub.com/#!/~LucFabresse/OpenCV this repo only contains some highly experimental code that do not work anymore :-( Luc > > > There is also some basic image processing in VirtualGPU : > http://smalltalkhub.com/#!/~ronsaldo/VirtualGPU > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

Sounds good, could I try it and run all those benchmarks etc. on it on my PCs? Jan Nicolai Hess wrote > Yes, the vm primitives, like I already told some messages above. > FilePrimitives ARE slow on windows. > > We may get better performance, if we disable windows file cache/buffering > and use slightly different ways to do the CreateFile and WriteFile > calls, and do the buffering on our own, but this is not easy. > > Luckily (?), this may be alread work if we use the std file api (?) > > A small dirty test: > > store bench > latest vm -> '22.098 per second' > modified vm -> '31,027 per second' > > (in the modified vm I replaced all file operation from > sqWin32FilePrims.c > with the code from > sqFilePluginBasicPrims.c) > > The result may seem strange, because both implementation will actually use > win32s CreateFile/WriteFile methods, but > maybe the second one uses better caching/buffering. > > nicolai -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by David T. Lewis

On Wed, Jul 01, 2015 at 01:39:25AM +0200, Nicolai Hess wrote: > 2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > Then the only thing I can think of is a vm primitive that is implemented > > differently in linux/mac than windows vm... > > > > Yes, the vm primitives, like I already told some messages above. > FilePrimitives ARE slow on windows. Is that actually true? I have not done any work on Windows in a while, but I recall that file primitives on Windows were quite efficient. They work differently because they operate at the level of direct file handles rather than stdio streams, but this may be faster in many cases. So unless you have measurable evidence that the Windows IO is slower, don't assume it to be true. Dave

July 1, 2015