November 2017 - Pharo-users

Re: [Pharo-users] I18n in pharo

by H. Hirzel

On 11/11/17, stephan <stephan(a)stack.nl> wrote: > On 10-11-17 12:23, CÃ©drick BÃ©ler wrote: >> Plus I have the impression Morphic mess is about to be solved. > > There is still an awful lot of essential complexity in beautiful > graphics and typography that is not going away. Microsoft Word still > cannot layout a paragraph of text after 34 years of development Can you point to an example of this? --Hannes > Stephan > > >

Nov. 11, 2017

Re: [Pharo-users] deployment of pharo applications

by stephan

On 11-11-17 18:58, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² wrote: > Another stumbling block is application deployment. You want to start from a minimal image and load everything you need with a Metacello baseline/configuration. And you want to change some settings to run without sources. You will run into parts that are not modularized enough yet and need their baselines to be split up further than they are now. The minimal image is rather minimal. See the esug videos Stephan

Nov. 11, 2017

Re: [Pharo-users] I18n in pharo

by stephan

On 10-11-17 12:23, CÃ©drick BÃ©ler wrote: > Plus I have the impression Morphic mess is about to be solved. There is still an awful lot of essential complexity in beautiful graphics and typography that is not going away. Microsoft Word still cannot layout a paragraph of text after 34 years of development Stephan

Nov. 11, 2017

Re: [Pharo-users] RB refactoring rewrite variable to a symbol

by werner kassens

Hi Peter, i assume from your question "RewriteTool maintained?" that you want to make a RBTransformationRule, right? if yes, i once had a similar problem and overwrote only #checkMethod: checkMethod: aMethod Â Â Â | arg | Â Â Â arg := aMethod argumentNames first asString. Â Â Â self initialize. Â Â Â self rewriteRule Â Â Â Â Â Â replace: Â Â Â Â Â Â Â Â Â '| ``@temporaries1 | Â Â Â Â Â Â Â Â Â `.@Statement' Â Â Â Â Â Â with: Â Â Â Â Â Â Â Â Â ('| ``@temporaries1 | Â Â Â Â Â Â Â Â Â {1} blahblah ifTrue: [ ^ {1} adaptToNumber: self andSend: #{2}]. Â Â Â Â Â Â Â Â Â `.@Statement' Â Â Â Â Â Â Â Â Â Â Â Â format: {arg. aMethod selector}). Â Â Â ^ super checkMethod: aMethod not too elegant, but it works. you could strip ":" from the method selector and do something similar. werner On 11/11/2017 05:17 PM, Peter UhnÃ¡k wrote: > Hi, > > how can I rewrite a(n instance) variable to a symbol? > > E.g. > > [IN] > something: aSomething > Â Â something := aSomething > > [OUT] > something: aSomething > Â Â self write: aSomething into: #something > > > I can capute the input just fine... ``@var := ``@arg > but I have no idea how to convert the var into a symbol (or string). > > Thanks, > Peter >

Nov. 11, 2017

deployment of pharo applications

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

Well, i've got very extensive feedback for i18n of applications, there are few solutions i can use, despite there is no united way embedded into pharo view on application design. That's ok, i can do something for my one taste (i prefer it to be a part of SPEC framework or something like this). Another stumbling block is application deployment. I've heard about some "Launcher" but ... what is it? what it does? where to get it? In Cincom VW deployment means: - get rid of all we don't use in image. - test image for successful run - delete all sources (hide it from disassembler) - lock\hide all excessive menus, tools or any backdoor to launch Smalltalk IDE or execute smaltalk code presented as text. - pack image and VM together with specified name of main executable. What can i do with Pharo? Does it have unified method to deploy pharo applications? I didn't find that method, and i ought to do some messy stuff "by hand". It will be very useful to do some steps in that direction. I want Pharo to be comfortable tool for application development. Like Delphi or C++ (where i came from but don't want to get get back to, after Smalltalk any other platform seems imperfect for me). Faithfully yours, Vikenti Potapov.

Nov. 11, 2017

Re: [Pharo-users] I18n in pharo

by Pavel Krivanek

2017-11-11 12:16 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi Pavel > > Does it make sense to have loaded by default? > I'm not sure. For Pharo itself it does not make sense to be translated but the applications can use some standard Pharo services like inform/confirm dialogs, file dialog etc. So if they want to use some external translation mechanism, they will fight to two different frameworks. -- Pavel > > Stef > > On Fri, Nov 10, 2017 at 8:05 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: > > > > > > 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> > >> 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 :) > > > > > > Will we include it into the standard image? > > > > -- Pavel > > > >> > >> 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/ROADMAP.md > >> > > >> > 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/100247.html > >> > 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.html > >> > > >> > 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. 11, 2017

Re: [Pharo-users] RB refactoring rewrite variable to a symbol

by Thierry Goubier

Hi Peter, Hi Peter, you should try {:node :dic | ... } to handle that. Something like: RBParseTreeRewriter new replace: '`@var `{:node :dic | dic at: #varName put: node name} := `@arg' with: 'self write: `@arg into: `{:dic | RBParser parseExpression: ''#'', (dic at: #varName) }'. You need to adjust, I haven't checked if this is correct ;). Thierry Le 11/11/2017 Ã 17:17, Peter UhnÃ¡k a Ã©critÂ : > Hi, > > how can I rewrite a(n instance) variable to a symbol? > > E.g. > > [IN] > something: aSomething > Â Â something := aSomething > > [OUT] > something: aSomething > Â Â self write: aSomething into: #something > > > I can capute the input just fine... ``@var := ``@arg > but I have no idea how to convert the var into a symbol (or string). > > Thanks, > Peter >

Nov. 11, 2017

RB refactoring rewrite variable to a symbol

by Peter UhnÃ¡k

Hi, how can I rewrite a(n instance) variable to a symbol? E.g. [IN] something: aSomething something := aSomething [OUT] something: aSomething self write: aSomething into: #something I can capute the input just fine... ``@var := ``@arg but I have no idea how to convert the var into a symbol (or string). Thanks, Peter

Nov. 11, 2017

Re: [Pharo-users] PharoLauncher directories

by Alistair Grant

On 9 November 2017 at 10:18, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > An analysis of the situation so people out of context can understand better the forces in play here :) > > - Working directory and files constant property: files defined using a *relative path* are created relative to the working directory. > In other words: > File named: 'something/other/myfile.txt' > will be created in FileSystem workingDirectory. > This was always like this when we used the file primitives. > The diverging behaviour was introduced actually by FileSystem: FileSystem used to create by default all files relative to the image directory. And at some point all tools adapted to that and the correct behaviour was hidden. > > - Change in working directory: Before, pharo always satisfied the following property: > FileSystem workingDirectory = FileSystem imageDirectory I realise I'm being pedantic, so apologies in advance and I certainly don't mean to offend anyone. Just for completeness: This constraint was actually introduced in Pharo 6 around March 2017. I think it was issue #19717 (https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-a…) Before that the workingDirectory was held in an instance variable and could be changed (although it looks like no one actually did that). #20164 (https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDir…) put the workingDirectory back in to a class variable since the performance gain is significant (one application saved 12 seconds from the change). > This is no longer true for every case. > Now, the workingDirectory is aligned with the process' working directory (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash). Cheers, Alistair > I explained a couple of weeks ago in an email, this may break some eggs, specially for those tools that wrongly assume FileSystem workingDirectory = FileSystem imageDirectory. > Tools requiring imageDirectory should use imageDirectory explicit. At least that will keep backwards compatibility. > For other cases, we should probably study them case by case and provide a satisfying solution. > > This change does however not affect everybody, and most of the times it is backwards compatible: > > ** This does not affect in general people launching usually pharo from the command line and using zeroconf: > $ wget get.pharo.org/... > $ ./pharo Pharo.image > ## Here, FileSystem workingDirectory = FileSystem imageDirectory because I launched my image from the directory where my image is! > > ** This does affect people that are: > - launching Pharo doing double click. > In this case, we saw with Denis and Pavel a week ago that osx assigns as working directory the root directory "/" > Users of files should be aware of this and applications should not abuse the workingDirectory. If they want to enforce the imageDirectory, they should do so explicitly. > > - launching Pharo from the pharo launcher (taken from this thread) > Apparently the pharo launcher is launching the image from a directory internal to the launcher. This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher... > I find even strange that the launcher puts pharo-local where the image is... > > > Given this, possible solutions are: > - On fileout, chose a correct directory when launched from double click > - Make the pharo launcher set a well-known working directory when launching an image > - one possibility is to set $HOME > - another possibility is to set the image directory (this will keep backwards compatibility) > > @Stef: about the #fullname. It is not there because it is not implemented :). We did not have the possibility of calculating a correct full path until a couple of weeks ago (and before, even if we did so, it couldn't be done without introducing a dependency to a non-kernel package). > > On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> Hi Stefan, >> >> > Le 8 nov. 2017 Ã 15:56, stephan <stephan(a)stack.nl> a Ã©crit : >> > >> > I run into all kinds of issues with the directory structure used by the new PharoLauncher. pharo-local seems to be shared now for multiple images. >> >> I never saw this issue. >> PharoLauncher does not have influence on the pharo-local directory of launched images. pharo-local directory is located in the same directory as the image run. >> >> in a Pharo 6.1 image: >> localDirectory >> ^ self class userLocalDirectory >> ifNil: [ (self imageDirectory / self class defaultLocalDirectoryName) ensureCreateDirectory ] >> >> userLocalDirectory >> ^ UserLocalDirectory ifNil: [ >> FileLocator workingDirectory / self defaultLocalDirectoryName ] >> >> >> Maybe you run Pharo 7 images and this change Â« Build #203: 05723-Default-Working-Directory Â» has a side effect? >> >> > That makes using configurations practically impossible as they are not expecting to have to deal with pre-downloaded older and newer monticello files. The missing sources files is less of a problem. >> > >> > Stephan >> > >> > >> >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13

Nov. 11, 2017

Re: [Pharo-users] Why is compile: breaking my image?

by Sven Van Caekenberghe

> On 11 Nov 2017, at 16:33, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Never mind... I see now what is broken and I'll try to fix it (assuming my P7 image won't corrupt itself due to FreeType before I manage to push the changes... heh) You can now disable FreeType fonts and still use bitmapped Source Code fonts. > On Sat, Nov 11, 2017 at 3:43 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > This applies to P61 (for some time) and P7. > > Object compile: '^'. > > Syntax Error popup -> close > > now you have two morphic UI processes running and World starts to get corrupted with artifacts around. (and it also in one case manage to actually corrupt the image to the point that I was no longer able to even launch it). > > Peter >

Nov. 11, 2017