November 2017 - Pharo-users

i18n in Pharo

by ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²

Thanks all for a feedback! I really feel that i'm not alone :) > Vikenti did you check the Entreprise Pharo book because it contains > nice chapters from svn on cahracter encoding. Thank you, i'll take a look at this chapter. And i'll look at gettext. > Did you report it? Yes, i reported it from Pharo IDE. If i need to create a ticket in some bugtracker please explain me where and how to do 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. I'll be glad to help to make Pharo better. I think there's some basic tasks every language\platform should do. For example, starting from windows 3.1 there was a way to put resources with application and load it - strings, images, bytearrays. Delphi goes further and created the advanced system to store almost any resource in simple standard way. And so on. Now, we live in 2017 year, XXIst century has come and for me it is very strange to solve such standard tasks every time i need it. I feel like i'm back to 90's - first of all, you waste your time to create libs for all your stadard needs, then you begin to create applications. I think, Pharo is very great system, but lacks of some basic things to create commercial applications (and to involve more people!). These things (in my case) are: 1. standard way to create UI. Spec is great, though it has some bugs (i put a treeview into tabbed view and have some unpredictable bugs with drag-n-drop while alone drag-n-drop works fine if not in tabbed view). If there will be a form constructor like in Cincom VW, Dolphin Smalltalk or ... QT designer - it will significantly lower time costs on constructing lots of forms and. This is the way that make Delphi popular, and now Lazarus goes this way. + there should be documentation on creating custom components. Pharo book contains more on this topic but not all. Lots of time is wasted to look for code and understand what is going on. 2. Common way to store resources. Like in Cincom VW - "install bytearray on accessor" or via text representation. It is simple but we always waste time to create some unique mechanism to load resources. We shouldn't waste this time, just need to make few calls using single simple api. 3. I18n. The app i working on now need english\french\german + russian + chineese\japaneese + (maybe arabic) languages. It was simple to do this with Cincom VW but it is hell with Pharo. Even Delphi from yearly 2000 could do this. 4. Deployment of applications. We don't play childish games, we are not students, we make serious applications for serious tasks, and we want to sell them, so we must have a common tool to delpoy: - strip code - maybe some cryptography on loaging code or hash-sum to check if code is changed by third side. - create a number of files for simple start of application. And this tool should work on all main systems: windows, *nix, MacOS. (+ optional additional functions to check license key\generate licenses etc). These tasks are always solved in commercial - oriented solutions. And while Pharo has no standard ways to do them ... there will be less big projects despite the fact Pharo is very powerful platform. It is only my opinion. best regards, Vikenti Potapov.

Nov. 10, 2017

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