- Pharo-users - lists.pharo.org

Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)

by Thierry Goubier

Le 09/11/2017 Ã 21:02, Stephane Ducasse a Ã©critÂ : > Yes thierry :) your turn now :) That's will be harder than I expected. I have issues in the LaTeX setup used by the booklet. Thierry > > Stef > > On Thu, Nov 9, 2017 at 8:41 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 09/11/2017 Ã 20:15, Federico.Balaguer a Ã©crit : >>> >>> I am following this tutorial >>> >>> >>> http://files.pharo.org/books-pdfs/booklet-Smacc/2017-05-05-Smacc-Spiral.pdf >>> >>> I typed the first example and when I try to compile either LR(1) or >>> LALR(1) >>> there is a pop-up saying that both clases where not specified. I also >>> tried >>> adding the classes for the scanner and parser manually but I got the >>> result. >> >> >> Yes. I changed the GUI and that means I need to update the booklet. >> >> This part: >> >> â¢ Edit the definition the pane below the compile LR(1) buttons. >> â¢ Once you are done: >> â Click on the Scanner class and type ExpressionScanner. >> â Click on the Parser class and type ExpressionParser. >> â¢ press either Compiler LR(1) or Compiled LALR(1) buttons. >> >> Should now be: >> >> â¢ Edit the definition the pane below the compile LR(1) buttons. >> â¢ Once you are done: >> â Type ExpressionParser and return in the text field left of Parser:. >> â¢ press either Compiler LR(1) or Compiled LALR(1) buttons. >> >>> There are a couple other things in the tutorial at the very start that >>> didn't add up. I can send an annotated pdf if that is of any help >> >> >> Yes, that would be very helpfull! >> >> Thanks, >> >> Thierry >> >> >>> >>> Thanks!! >>> >>> Federico >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >> > >

Nov. 10, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Richard Sargent

> > I think it is correct to show green if you fix your problem in the > debugger and then proceed and it passes all assertions. But it should > equally fail if you proceed and it asserts false or craps out. > It would be a lie. The truth is only that from that point on, it is correct. You have no guarantee that your correction hasn't broken something that would occur in the next run prior to the point at which you applied the correction. Hence my assertion that you cannot determine the colour until the next run. On Thu, Nov 9, 2017 at 2:47 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Thanks Denis - I'll try my simple TDD test case in Pharo 7 (I haven't > tried it yet - probably time to). > > I think it is correct to show green if you fix your problem in the > debugger and then proceed and it passes all assertions. But it should > equally fail if you proceed and it asserts false or craps out. > > Strange it would vary in 6.1 - but I'll check. > > Tim > > Sent from my iPhone > > > > Sent from my iPhone > On 9 Nov 2017, at 19:54, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > In Pharo 7 it works. > > 2017-11-09 18:29 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: > >> Thanks for looking at this - there is an issue however - when you apply >> that change (at least in a Pharo 6.1 image) - it shows green even when a >> test fails? So I think its turned one problem into the opposite one. >> >> Unfortunately I havenât got a chance to look a bit deeper to help - but >> it might be worth rolling back this change for now. We should fix it though >> - and the answer must be in the area you have identified. >> >> tim >> >> On 9 Nov 2017, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> And now it is in latest Pharo >> >> 2017-11-09 12:16 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Hi Tim. >>> >>> Fix is here 20661-Fixing-test-from-debugger-should-mark-test-as-gre >>> en-when-proceed <https://github.com/pharo-project/pharo/pull/456> . >>> Thank's for reporting. It forces me to fix. I always noticed it but >>> never take it seriously :) >>> >>> 2017-11-09 11:32 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> Hi - I really like the build in test runner in the Pharo browsers, and >>>> I was preparing a talk to show how great TDD is in Pharo and how we arenât >>>> ashamed of our debugger when testing (it augments the experience in fact - >>>> letting you poke around and get your thoughts straight). >>>> >>>> However - if I pick rerun in the test runner debugger - and step >>>> through a test and then correct the failing code, and hit resume - the >>>> browser always shows a red failure, even though the execution is now >>>> correct. I have to run the test again. >>>> >>>> This doesnât seem right to me - are we missing a success event or >>>> something? >>>> >>>> >>>> Tim >>>> >>> >>> >> >> >

Nov. 9, 2017

Re: [Pharo-users] I18n in pharo

by Esteban Lorenzano

I think this is two different problems: 1. pharo itself supporting different languages/keyboards, etc. 2. pharo allowing the development of i18n applications I think we still need to work on point 1, but for point 2 we already have gettext package, which is a standard we can/should use. Maybe that needs to be better documented (as everything), but wellâ¦ we have a solution there :) Esteban > On 9 Nov 2017, at 18:58, Torsten Bergmann <astares(a)gmx.de> wrote: > > The Pharo 7/8 roadmap does not (yet) include I18N: https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… > > and the Pharo core image still includes the "NaturalLanguageTranslator" solution still from Squeak. See this class for more details and > all senders of #translated message. So far the whole Pharo UI is in English and while books, the mooc or others were translated the Pharo > image so far is not. > I guess some more work would be needed also on the font frontier to provide an internationalized image and the different languages. > > > > But for own applications (like web applications) there are some more (external) solutions: > > > 1. I once wrote and announced an own I18N framwork: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… > which is fully documented on http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely proprietary solution. > > 2. There is also some stuff from Jan van de Sandt: > https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h… > > 3. And there is GetText (from Seaside web framework) which I guess is either here http://smalltalkhub.com/#!/~PharoExtras/Gettext > or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext > > Unfortunately back at the time this one was not independently loadable and had other trouble which I critisized on > http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html > > Maybe situation for this project has improved. > > > But so far nobody pushed I18N really into Pharo ... > > 4. Therefore back in 2014 I started with a consolidation by starting a clean room implementation of Gettext - based on code from 3. > but now with tests and Pharo Spec based tools (see screenshot attached). I did it in an own repo to be able to experiment and > not break the Seaside solution right in the beginning. > > My code is on STHub http://smalltalkhub.com/#!/~TorstenBergmann/Gettext and it is not yet fully usable and so far still > unfinished > > But one can load the project still in Pharo 7 using > > Gofer it > smalltalkhubUser: 'TorstenBergmann' project: 'Gettext'; > configuration; > load. > > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load > > All 11 Tests are green so at least what is there should work. Check the world menu and the code. Load the "Foo" package from the same repository > to see something in the tools. The idea was to have support for MO and PO files completely written in Smalltalk as well as tools that allow you > to find and translate internationalized text. > > But as always: this would require more work. I would still favour a fully in Pharo written solution (following the gettext formats) but maybe for > performance reasons then also bind to libgettext using UFFI. > > > Hope this gives some insights on the current existing solutions/status. > > Thanks > Torsten > > >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr >> Von: "ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²" <vikenti.potapov(a)gmail.com> >> An: pharo-users(a)lists.pharo.org >> Betreff: [Pharo-users] I18n in pharo >> >> >> Will Pharo 7 be ready for i18n of applications? >> I mean some simple and useful way like in Cincom Visual Works, where translation dictionaries are separated from code and could be dinamycally changed without changing my application. >> >> It is very important for huge commercial applications, especially with lots of UI forms, dialogs and user-messages. >> >> I transfer my code from Cincom VW (VW is not available now for Russia due to politic situation) to Pharo and is very interested in simple internationalization mechanism. I don't want to reinvent the wheel but sometimes it seems to me that pharo developers are forced to do it. >> >> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. >> >> best regards, >> Vikenti Potapov. >> >> > <GetTextNewTools.png>

Nov. 9, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Tim Mackinnon

Thanks Denis - I'll try my simple TDD test case in Pharo 7 (I haven't tried it yet - probably time to). I think it is correct to show green if you fix your problem in the debugger and then proceed and it passes all assertions. But it should equally fail if you proceed and it asserts false or craps out. Strange it would vary in 6.1 - but I'll check. Tim Sent from my iPhone Sent from my iPhone > On 9 Nov 2017, at 19:54, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > In Pharo 7 it works. > > 2017-11-09 18:29 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >> Thanks for looking at this - there is an issue however - when you apply that change (at least in a Pharo 6.1 image) - it shows green even when a test fails? So I think its turned one problem into the opposite one. >> >> Unfortunately I havenât got a chance to look a bit deeper to help - but it might be worth rolling back this change for now. We should fix it though - and the answer must be in the area you have identified. >> >> tim >> >>> On 9 Nov 2017, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> And now it is in latest Pharo >>> >>> 2017-11-09 12:16 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> Hi Tim. >>>> >>>> Fix is here 20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed . >>>> Thank's for reporting. It forces me to fix. I always noticed it but never take it seriously :) >>>> >>>> 2017-11-09 11:32 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >>>>> Hi - I really like the build in test runner in the Pharo browsers, and I was preparing a talk to show how great TDD is in Pharo and how we arenât ashamed of our debugger when testing (it augments the experience in fact - letting you poke around and get your thoughts straight). >>>>> >>>>> However - if I pick rerun in the test runner debugger - and step through a test and then correct the failing code, and hit resume - the browser always shows a red failure, even though the execution is now correct. I have to run the test again. >>>>> >>>>> This doesnât seem right to me - are we missing a success event or something? >>>>> >>>>> >>>>> Tim >

Nov. 9, 2017

Re: [Pharo-users] I18n in pharo

by Torsten Bergmann

The Pharo 7/8 roadmap does not (yet) include I18N: https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… and the Pharo core image still includes the "NaturalLanguageTranslator" solution still from Squeak. See this class for more details and all senders of #translated message. So far the whole Pharo UI is in English and while books, the mooc or others were translated the Pharo image so far is not. I guess some more work would be needed also on the font frontier to provide an internationalized image and the different languages. But for own applications (like web applications) there are some more (external) solutions: 1. I once wrote and announced an own I18N framwork: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… which is fully documented on http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely proprietary solution. 2. There is also some stuff from Jan van de Sandt: https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h… 3. And there is GetText (from Seaside web framework) which I guess is either here http://smalltalkhub.com/#!/~PharoExtras/Gettext or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext Unfortunately back at the time this one was not independently loadable and had other trouble which I critisized on http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html Maybe situation for this project has improved. But so far nobody pushed I18N really into Pharo ... 4. Therefore back in 2014 I started with a consolidation by starting a clean room implementation of Gettext - based on code from 3. but now with tests and Pharo Spec based tools (see screenshot attached). I did it in an own repo to be able to experiment and not break the Seaside solution right in the beginning. My code is on STHub http://smalltalkhub.com/#!/~TorstenBergmann/Gettext and it is not yet fully usable and so far still unfinished But one can load the project still in Pharo 7 using Gofer it smalltalkhubUser: 'TorstenBergmann' project: 'Gettext'; configuration; load. (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load All 11 Tests are green so at least what is there should work. Check the world menu and the code. Load the "Foo" package from the same repository to see something in the tools. The idea was to have support for MO and PO files completely written in Smalltalk as well as tools that allow you to find and translate internationalized text. But as always: this would require more work. I would still favour a fully in Pharo written solution (following the gettext formats) but maybe for performance reasons then also bind to libgettext using UFFI. Hope this gives some insights on the current existing solutions/status. Thanks Torsten > Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr > Von: "ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²" <vikenti.potapov(a)gmail.com> > An: pharo-users(a)lists.pharo.org > Betreff: [Pharo-users] I18n in pharo > > > Will Pharo 7 be ready for i18n of applications? > I mean some simple and useful way like in Cincom Visual Works, where translation dictionaries are separated from code and could be dinamycally changed without changing my application. > > It is very important for huge commercial applications, especially with lots of UI forms, dialogs and user-messages. > > I transfer my code from Cincom VW (VW is not available now for Russia due to politic situation) to Pharo and is very interested in simple internationalization mechanism. I don't want to reinvent the wheel but sometimes it seems to me that pharo developers are forced to do it. > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. > > best regards, > Vikenti Potapov. > > >

Nov. 9, 2017

Re: [Pharo-users] I18n in pharo

by Denis Kudriashov

In my experience I used my own custom implementation to support multiple languages. It was based on super simple dictionary of lang->labelName->text. I loaded it from custom xml file. My problem was that I never understood how gettext is supposed to be used on Windows. 2017-11-09 21:29 GMT+01:00 ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com>: > > Will Pharo 7 be ready for i18n of applications? > I mean some simple and useful way like in Cincom Visual Works, where > translation dictionaries are separated from code and could be dinamycally > changed without changing my application. > > It is very important for huge commercial applications, especially with > lots of UI forms, dialogs and user-messages. > > I transfer my code from Cincom VW (VW is not available now for Russia due > to politic situation) to Pharo and is very interested in simple > internationalization mechanism. I don't want to reinvent the wheel but > sometimes it seems to me that pharo developers are forced to do it. > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 > installation ("UTF8InvalidText: Invalid utf8 input detected" on image load > - error caused by cyrillic path to application folder) didn't solved and i > had no feedback from community. > > best regards, > Vikenti Potapov. > > >

Nov. 9, 2017

Re: [Pharo-users] I18n in pharo

by Denis Kudriashov

Hi 2017-11-09 22:15 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi vikenti > > I would love. Now if nobody using a different alphabet does not give > us feedback and help we will not really make progress. > Denis how do you it? > I got this kind of errors in past with Pharo 1 on Windows XP. Now I was sure that it was fixed. I checked it with Pharo 3 (I guess). Now I have no such environment to test. > Hilaire is using gettext or something like that in DrGeo. > > Vikenti did you check the Entreprise Pharo book because it contains > nice chapters from svn on cahracter encoding. > > > > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 > installation ("UTF8InvalidText: Invalid utf8 input detected" on image > load - error caused by cyrillic path to application folder) didn't > solved and i had no feedback from community. > > Did you report it? > We are slowly deprecating the old streams (because they are messy) and > replacing then with ZnStreams. > Now if you want to help this would be useful to produce a better Pharo. > > Stef > > > > On Thu, Nov 9, 2017 at 9:29 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² > <vikenti.potapov(a)gmail.com> wrote: > > > > Will Pharo 7 be ready for i18n of applications? > > I mean some simple and useful way like in Cincom Visual Works, where > translation dictionaries are separated from code and could be dinamycally > changed without changing my application. > > > > It is very important for huge commercial applications, especially with > lots of UI forms, dialogs and user-messages. > > > > I transfer my code from Cincom VW (VW is not available now for Russia > due to politic situation) to Pharo and is very interested in simple > internationalization mechanism. I don't want to reinvent the wheel but > sometimes it seems to me that pharo developers are forced to do it. > > > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 > installation ("UTF8InvalidText: Invalid utf8 input detected" on image load > - error caused by cyrillic path to application folder) didn't solved and i > had no feedback from community. > > > > best regards, > > Vikenti Potapov. > > > > > >

Nov. 9, 2017

Re: [Pharo-users] I18n in pharo

by Stephane Ducasse

Hi vikenti I would love. Now if nobody using a different alphabet does not give us feedback and help we will not really make progress. Denis how do you it? Hilaire is using gettext or something like that in DrGeo. Vikenti did you check the Entreprise Pharo book because it contains nice chapters from svn on cahracter encoding. By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. Did you report it? We are slowly deprecating the old streams (because they are messy) and replacing then with ZnStreams. Now if you want to help this would be useful to produce a better Pharo. Stef On Thu, Nov 9, 2017 at 9:29 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: > > Will Pharo 7 be ready for i18n of applications? > I mean some simple and useful way like in Cincom Visual Works, where translation dictionaries are separated from code and could be dinamycally changed without changing my application. > > It is very important for huge commercial applications, especially with lots of UI forms, dialogs and user-messages. > > I transfer my code from Cincom VW (VW is not available now for Russia due to politic situation) to Pharo and is very interested in simple internationalization mechanism. I don't want to reinvent the wheel but sometimes it seems to me that pharo developers are forced to do it. > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. > > best regards, > Vikenti Potapov. > >

Nov. 9, 2017

FileReference basename of current dir

by Norbert Hartl

is there a good explanation why âfooâ asFileReference parent basename gives â/â ?

Nov. 9, 2017

Re: [Pharo-users] Soup bug(fix)

by Stephane Ducasse

Indeed the interaction with the inspector is great. Now could you still improve soup? What is your smalltalkhub account? Stef On Thu, Nov 9, 2017 at 11:12 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > > On Wed, Nov 8, 2017 at 10:45 PM, PBKResearch <peter(a)pbkresearch.co.uk> > wrote: >> >> Siemen >> >> Stef should have added that XPath depends on using Monty's XMLParser >> suite. I tried your snippet on XMLDOMParser, and it parses correctly. I >> always use XMLHTMLParser for parsing HTML, because I can always see the >> exact relationship between the parsed structure and the original HTML. With >> Soup I often found the match difficult or even impossible. > > > Thanks Stef & Peter. I'm going with XMLHTMLParser, it is indeed nicer to > work with in the inspector. I'm scraping my own html files (to create a mock > DOM object of my HTML to work with in Pharo) so I think I will switch to > xhtml too to reduce the complexity. > > Nice chapter, I only saw it briefly before and didn't realize that > XMLHTMLParser is a newer replacement for Soup. > > -- Siemen

Nov. 9, 2017