Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)
Hi Steff, Le 10/11/2017 à 19:17, Stephane Ducasse a écrit : Hi thierry we are working and soon we will have a much simpler installation and everything :) Out of a minimal image? That would be very cool. Now just commit and I will check and fix :) I committed, created a pull request and merged. It should be Ok apart from: - can hyphenating be desactivated in ==sequences==? It is allways strange to see a class name or a method name split by a hypen, like in SmaCC-Parser - how does one writes a reference to a section or a chapter? Thierry Stef On Fri, Nov 10, 2017 at 6:47 AM, Thierry Goubier wrote: 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 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
Re: [Pharo-users] I18n in pharo
There’s an online translation service for XLIff files (well, there’s quite a few but most I’ve found use human translators, and as a result cost a fair bit). It’s not free either, but for 2-3 languages it’s relatively reasonable at $19/mo., and a couple of months’ subscription would allow for a fair number of automated translations which could be quickly tweaked. https://lingohub.com/pricing/ Mojito allows you to integrate the Xliff translation as part of a Travis CI build. It’s written in Java but supports localization for a number of languages, which implies it wouldn’t take much modification to support Pharo. https://github.com/box/mojito There’s also a number of Xliff editors on GitHub, including a plugin for Oxygen XML, which I happen to use when I do edit XML rather than using IADS with SGML and exporting XML. Not sure if this is the kind of thing you’re looking for, but it might be a quick way to get key applications’ text translated and be used by a relatively simple Pharo / Seaside tool. It’s even possible that a decent modification of Mojito might allow semi-automated translations using LingoHub. Andrew Glynn From: Andrew Glynn Sent: Friday, November 10, 2017 6:09 PM To: Any question about pharo is welcome Subject: RE: [Pharo-users] I18n in pharo I’d think about porting the I18n Gem from Ruby but replacing Gettext with xliff to be a better, more generalized solution. Cascade in the Ruby Gem is a useful feature missing from other implementations I’ve used. https://github.com/svenfuchs/i18n/tree/master/test http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html It would also likely be easier and more reliable, since the XML support in Pharo is already quite good. Andrew Glynn Sent from Mail for Windows 10 From: Torsten Bergmann Sent: Thursday, November 9, 2017 4:59 PM To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] I18n in pharo 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: "Викентий Потапов" > An: pharo-users@lists.pharo.org > Betreff: [Pharo-users] I1
Re: [Pharo-users] I18n in pharo
Hi torsten
Thanks for your summary. I was lost with all the efforts around.
Two points:
- I do not think that Pharo IDE should be multilingual
- I would love to have one or two strong solutions for Application
internationalisation.
Now Questions:
- what do you mean by propretiary solution. The license is MIT.
- I think that it would be good to have your solution and getText
ready to be loaded and for me this would be nice.
Now I have a question how people developing seaside components manage
to have internationalised
version?
Stef
On Thu, Nov 9, 2017 at 10:58 PM, Torsten Bergmann 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: "Викентий Потапов"
>> An: pharo-users@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.
>>
>>
>>
Re: [Pharo-users] I18n in pharo
Hi Pavel
Does it make sense to have loaded by default?
Stef
On Fri, Nov 10, 2017 at 8:05 AM, Pavel Krivanek
wrote:
>
>
> 2017-11-09 23:50 GMT+01:00 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 :)
>
>
> Will we include it into the standard image?
>
> -- Pavel
>
>>
>> Esteban
>>
>> > On 9 Nov 2017, at 18:58, Torsten Bergmann 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: "Викентий Потапов"
>> >> An: pharo-users@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 in
Re: [Pharo-users] I18n in pharo
tx hiliare for the feedback. On Fri, Nov 10, 2017 at 11:10 AM, Hilaire wrote: > You can go with http://smalltalkhub.com/#!/~PharoExtras/Gettext > > For non latin language you will have to provide extra font at load time. > > It works fine on DrGeo based on P3, wtih Latin, Cyrilic, Korean, Chinese > ideogram, Japanese[1] messages. > > I have no idea regarding its compatibility with P7 however. > > Will not work with right to left languages, though. > > For asian input methods, a no go too. > > Hilaire > > [1] https://twitter.com/GNUDrGeo/status/832878470216691712 > > > Le 09/11/2017 à 21:29, Викентий Потапов a écrit : >> >> It is very important for huge commercial applications, especially with >> lots of UI forms, dialogs and user-messages. > > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-users] I18n in pharo
Marcus translate is incomplete and I would not focus on translating Pharo. I would prefer to improve the self documentation in english. Let us concentrate where we can get better. Stef On Fri, Nov 10, 2017 at 11:20 AM, Marcus Denker wrote: > > > On 10 Nov 2017, at 11:18, Esteban Lorenzano wrote: > > > > On 10 Nov 2017, at 04:05, Pavel Krivanek wrote: > > > > 2017-11-09 23:50 GMT+01:00 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 :) > > > Will we include it into the standard image? > > > No. The whole idea with PharoExtras was “there are packages we care about > and we want to make them available, but there is no reason to keep them *in* > image”. > I do not see why we should change that policy. > > Now, we definitively need better documentation about it. > > > But having I18 support is not bad… e.g. there are many programs out there > that provide translated menus. > It would not be completely a bad idea to do that for Pharo, too. > > Marcus >
Re: [Pharo-users] I18n in pharo
Hilaire I think that Pharo is getting a lot more modular. Do you imagine that we can reload Morphic? That we have a minimal image that does not rely on the compiler? and that we can reload the compiler, SUnit and more. We will start another pass because we will run an experience to get microPharo. Did you see the amazonLambda experience? Many people are telling to us that Pharo and that the system is improving and it is really improving. Now we do not make progress without breaking eggs. And we are cleaning but probably things that you do not care: such as startup list, streams, layouts We will throw away a lot of code with Bloc too. > A cleaner Pharo will help there. > > To be frank, I found later Pharo releases not inspiring. Bigger, bigger and > bigger with added code, protocol changes, and bugs at will. Hilaire - when did you report bugs that we did not consider? and that we did not fix if it was something that we could do fast? > It is becoming > too complicated for a hobby use of it. > > I decided I will not finish porting DrGeo to P6 or P7, and it will likely > die with P3. I'm sad that you decided that because we like DrGeo. Now we cannot do much if you do not want to do it. May be you should come to visit us from time to time. > Pharo should have been clean up to the bones before adding. It was the > initial moto, no? And this is what we are doing. But seriously do you think that it is easy? Did you look at the ESUG videos of Prague. I can tell you that christophe, pavel and guille worked several months and this is not just for hacking around. So you probably do not know what we did and what we are doing. Stef > > > Le 10/11/2017 à 11:14, Marcus Denker a écrit : >> >> It would be nice if someone who uses it would take the lead >> so we can improve the default that is shipped with Pharo. > > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-users] I18n in pharo
> > It’s quite a moving target with so many fundamental changes (GIT being one, > Bootstrap another huge one). I would not call it moving target. The API changes slowly and we deprecate most of them. > But I have the opposite impression (of course I don’t have to maintain a big > project like yours - I wouldn’t say you’re the hobby user :) ). But I really > find P6 more consistent than what I used to try in the past (last squeaks up > to 3.9 and firsts pharo). Me too. > And the bootstrapping of P7 will (I think) finally solve big image issues > (allowing to build cleaner distributions). I believe it will be a huge step > forward. At least for me and especially to convince others to try out Pharo. > I just dream of having a network of small images running and communicating, > eventually accessed and programmed by a larger developper image (with > TelePharo). Yes we want the same. > I haven’t tried the bootstrap yet but sure in the future. It is working already and you can use the Bootstrap. Pavel has been working on providing package and configurations that we can reload. > Plus I have the impression Morphic mess is about to be solved. Well I hope :) > What’s more problematic to me (as I guess for newcomers) is to find the > ‘good’ packages'. For instance, I’m still puzzled when I have to choose > between OSProcess and OSSubprocess (and sometimes depending on loaded > projects, we need both…). People should document their packages and publish them in the meta catalog. We cannot do more. We should publish a package market but we are behind our plans. > >> >> I decided I will not finish porting DrGeo to P6 or P7, and it will likely >> die with P3. >> >> Pharo should have been clean up to the bones before adding. It was the >> initial moto, no? > > I have the (naive) impression that bootstrap will help a lot here, so be > patient ;). Maybe porting to P7/P8 will be more appropriate. > What I would like, is a kind of notation for package to know its state and > usage possibilities. > We see for instance that several I18N exists already (but not 100% integrated > hence this post)... > > My 2 cents, > > Cédrick > > > OT question: Would it be possible in the future to generate a bootstrap image > of a given program from a bigger developer image containing running program > (like if running tests where activating all code dependancies ? … like > tracing usage… I guess this is not trivial at all ! I guess this is > particularly difficult to trace all use cases and as dynamically bound, it > sure must be hard). Yes guille did it with tornado. Now it was experiemental. You will be in better shape to take the miniimage and load what you need. > >> >> >> Le 10/11/2017 à 11:14, Marcus Denker a écrit : >>> It would be nice if someone who uses it would take the lead >>> so we can improve the default that is shipped with Pharo. >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > >
Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)
>> >> Hi thierry >> >> we are working and soon we will have a much simpler installation and >> everything :) > > > Out of a minimal image? That would be very cool. Uh? The problem is latex and not Pharo here. Guille removes the need for makefiles and clean the archetypes we will be able to move on. > >> Now just commit and I will check and fix :) > > > I committed, created a pull request and merged. It should be Ok apart from: > > - can hyphenating be desactivated in ==sequences==? It is allways strange to > see a class name or a method name split by a hypen, like in SmaCC-Parser No > - how does one writes a reference to a section or a chapter? *@xxx* > > Thierry > > >> >> Stef >> >> On Fri, Nov 10, 2017 at 6:47 AM, Thierry Goubier >> wrote: >>> >>> 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 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 >> >> > > >>> >>> >> >> > >
Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...
Hannes We will start to repackage pillar model so finding a mini pillar is interesting to us. Let let us know. Stef On Sat, Nov 11, 2017 at 7:51 AM, Tudor Girba wrote: > Hi, > > >> On Nov 10, 2017, at 9:20 PM, Sean P. DeNigris wrote: >> >> Tudor Girba-2 wrote >>> As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for >>> Pillar working on top of Bloc. >> >> Two questions after playing with it: >> 1. Can one save a live-edited file? > > The saving action is not implemented yet. > >> 2. Is it possible to make the markup codes invisible? That would seem more >> appropriate e.g. in a read-only context. > > That would be another renderer, but it is not difficult to build. That is > something we’ll do soon. > > Cheers, > Doru > >> >> >> - >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > >
[Pharo-users] RewriteTool maintained?
Hi, has Mark Rizun's Rewrite Tool been abandoned? Thanks, Peter
[Pharo-users] Why is compile: breaking my image?
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
Re: [Pharo-users] Why is compile: breaking my image?
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) On Sat, Nov 11, 2017 at 3:43 PM, Peter Uhnák 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 >
Re: [Pharo-users] Soup bug(fix)
On 9 November 2017 at 00:00, Kjell Godo wrote: > i like to collect some newspaper comics from an online newspaper > but it takes really long to do it by hand by hand > i tried Soup but i didn’t get anywhere > the pictures were hidden behind a script or something > is there anything to do about that? Most of the web pages I want to scrape use javascript to construct the DOM, which makes Soup. XMLHTMLParser, etc. useless. I've extended Torsten's Pharo-Chrome library and use that to navigate the DOM in a way similar to Soup: https://github.com/akgrant43/Pharo-Chrome This gets around the issue with javascript since it waits for the browser to load the page, run the javascript and construct the DOM. HTH, Alistair > i don’t want to collect them all > i have the XPath .pdf but i haven’t read it yet > > these browsers seem to gobble up memory > and while open they just keep getting bigger till the OS session crash > might there be a browser that is more minimal? > > Vivaldi seems better at not bloating up RAM
Re: [Pharo-users] Why is compile: breaking my image?
> On 11 Nov 2017, at 16:33, Peter Uhnák 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 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 >
Re: [Pharo-users] PharoLauncher directories
On 9 November 2017 at 10:18, Guillermo Polito 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-after-image-moved-to-a-new-folder). 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-defaultWorkingDirectory) 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 > wrote: >> >> Hi Stefan, >> >> > Le 8 nov. 2017 à 15:56, stephan 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 >> defa
[Pharo-users] RB refactoring rewrite variable to a symbol
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
Re: [Pharo-users] RB refactoring rewrite variable to a symbol
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
Re: [Pharo-users] I18n in pharo
2017-11-11 12:16 GMT+01:00 Stephane Ducasse : > 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 > wrote: > > > > > > 2017-11-09 23:50 GMT+01:00 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 :) > > > > > > Will we include it into the standard image? > > > > -- Pavel > > > >> > >> Esteban > >> > >> > On 9 Nov 2017, at 18:58, Torsten Bergmann 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: "Викентий Потапов" > >> >> An: pharo-users@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 witho
[Pharo-users] deployment of pharo applications
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.
Re: [Pharo-users] RB refactoring rewrite variable to a symbol
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
>
Re: [Pharo-users] I18n in pharo
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
Re: [Pharo-users] deployment of pharo applications
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
Re: [Pharo-users] I18n in pharo
On 11/11/17, stephan 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 > > >
Re: [Pharo-users] I18n in pharo
P6 is definitely a better IDE compare to previous version, and for coming Calypso looks fantastic, but P6 is a worst vehicle for a desktop application. There is much more code included and you are on your on to shrink/clean it to deploy your desktop application to make it looks and behave user friendly. May be for a specialized audience it could be just fine to deploy as is. About my perception on Pharo, from a distant POV, I see parallel/overlapping/contiguous layers like Morphic, Athens, Sparta, Bloc, Brick, Spec, GT, Polymorph all this looks confusing for me and I really don't know or understand where to put my eggs. When I took a look at Pharo keyboard shortcut, it seems to be -- without been sure 100% -- there are two different implementations. One from GT and another one, probably a legacy one. How can it happen? Then you wonder about other part of the system. It makes fells like changes/implementations are not coherent, and you don't really fell the environment as coherent or trustful. May be the twist is ontological, Pharo (and Squeak) taking too much responsibilities and not delegating enough to the host environment: GUI, Freetype, Canvas. The energy required is then out of reach or the needed coherence in teams works too complex. Don't know, just blind guesses, I will now shut up. Le 10/11/2017 à 12:23, Cédrick Béler a écrit : But I have the opposite impression (of course I don’t have to maintain a big project like yours - I wouldn’t say you’re the hobby user:) ). But I really find P6 more consistent than what I used to try in the past (last squeaks up to 3.9 and firsts pharo). -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] deployment of pharo applications
Le 11/11/2017 à 18:58, Викентий Потапов a écrit : Well, i've got very extensive feedback for i18n of applications, there are few You should use the gettext package from PharoExtra, this is the one Seaside developers maintain. I don't understand why there are alternative repo for it... [..] 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". Of course, you can completely automate your application build. You can take a look at the DrGeo build scripts there. Part of the image preparation is done inside the image. http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/build/ The application build will not be the part I worry about, but more on the GUI. I don't know how complex is your GUI application but Pharo is now on flux with several competitive GUI frameworks, all in the image (spec, Polymoprh, GT), and forth coming brick/bloc. And depending on the complexity you need, you may not have all you need. -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] I18n in pharo
On 11-11-17 21:18, H. Hirzel wrote: On 11/11/17, stephan 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? https://en.wikipedia.org/wiki/Microtypography Stephan
Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94
I want to get these esug videos, but i've searched through the whole pharo site and i haven't found them ... :( I appreciate if you point me where to find help on working with minimal image\deploying with Pharo. And i also think this very important information should be available on pharo site at conspicuous place. What about Dr.Geo - i've downloaded this program to test from official site (http://www.drgeo.eu/download#TOC-PC-Mac-GNU-Linux). I launched DrGeo.bat, as it noted in instruction. It shown me console window and Pharo command line options. That's all. It didn't start. I think, the reason is - also cyrillic paths, but ... who knows? And also i mean some simple and understandable deployment tool (as in Cincom VW exists) but not manual-written bash scripts. This tool asks me what class\accessor send open message, asks what to strip and how to pack my image. Few simple steps and i have perfectly cleaned minimal image with all image started methods tuned to load necessary class. It's really cool stuff. It's a pity, my low-level SmallTalk knowledge (VW + Pharo) is not enough to port this tool or create the new one. Please, understand me right, i don't criticize pharo, but i'm trying to understand what to do and how to do with less efforts for me. And these are the questions every developer asks. > 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
Re: [Pharo-users] deployment of pharo applications
2017-11-11 21:42 GMT+01:00 Hilaire : > Le 11/11/2017 à 18:58, Викентий Потапов a écrit : > >> Well, i've got very extensive feedback for i18n of applications, there >> are few >> > You should use the gettext package from PharoExtra, this is the one > Seaside developers maintain. I don't understand why there are alternative > repo for it... > > [..] > > 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". >> > Of course, you can completely automate your application build. > > You can take a look at the DrGeo build scripts there. Part of the image > preparation is done inside the image. > http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/fi > les/head:/build/ > > The application build will not be the part I worry about, but more on the > GUI. I don't know how complex is your GUI application but Pharo is now on > flux with several competitive GUI frameworks, all in the image (spec, > Polymoprh, GT), and forth coming brick/bloc. And depending on the > complexity you need, you may not have all you need. > > If you follow the standard bootstrapping process but instead of BaselineOfIDE you use BaselineOfMorphic, I will get a usable image without development tools. Good as basis for applications like DrGeo. We are still improving modularity. The recent step was an insclusion of tests that will reject any pull request that makes new package dependencies between system layers. -- Pavel > -- > Dr. Geo > http://drgeo.eu > > > >
Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94
check esugboard channel in youtube https://www.youtube.com/channel/UCO-vBhaKVZf0al-ISMMPvRw On Sat, Nov 11, 2017 at 6:29 PM, Викентий Потапов wrote: > > I want to get these esug videos, but i've searched through the whole pharo > site and i haven't found them ... :( > I appreciate if you point me where to find help on working with minimal > image\deploying with Pharo. > And i also think this very important information should be available on > pharo site at conspicuous place. > > What about Dr.Geo - i've downloaded this program to test from official > site (http://www.drgeo.eu/download#TOC-PC-Mac-GNU-Linux). I launched > DrGeo.bat, as it noted in instruction. It shown me console window and Pharo > command line options. That's all. It didn't start. I think, the reason is - > also cyrillic paths, but ... who knows? > > And also i mean some simple and understandable deployment tool (as in > Cincom VW exists) but not manual-written bash scripts. This tool asks me > what class\accessor send open message, asks what to strip and how to pack > my image. Few simple steps and i have perfectly cleaned minimal image with > all image started methods tuned to load necessary class. It's really cool > stuff. It's a pity, my low-level SmallTalk knowledge (VW + Pharo) is not > enough to port this tool or create the new one. > > Please, understand me right, i don't criticize pharo, but i'm trying to > understand what to do and how to do with less efforts for me. And these are > the questions every developer asks. > > > 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 > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.
Re: [Pharo-users] deployment of pharo applications
Pavel Krivanek-3 wrote > The recent step was an insclusion of tests that will > reject any pull request that makes new package dependencies between system > layers. Thanks for this :) - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...
Tudor Girba-2 wrote > That would be another renderer, but it is not difficult to build. That is > something we’ll do soon. It would be nice to be able to toggle codes on/off like WS Word - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94
Am 11.11.17 um 22:29 schrieb Викентий Потапов: I want to get these esug videos, but i've searched through the whole pharo site and i haven't found them ... :( ESUG and Pharo are still two separate entities, both legally and from the perspective of their goals. The ESUG conference was run by ESUG, not Pharo. Therefor you find the conference videos on the ESUG webiste. They are linked from this page: http://www.esug.org/wiki/pier/Conferences/2017/ .. or, as mentioned before, you can visit the youtube playlist directly. Joachim
Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94
Am 11.11.17 um 22:29 schrieb Викентий Потапов: Vikenti, And also i mean some simple and understandable deployment tool (as in Cincom VW exists) but not manual-written bash scripts. This tool asks me what class\accessor send open message, asks what to strip and how to pack my image. Few simple steps and i have perfectly cleaned minimal image with all image started methods tuned to load necessary class. It's really cool stuff. It's a pity, my low-level SmallTalk knowledge (VW + Pharo) is not enough to port this tool or create the new one. just out of curiosity and following my first reflex: if VisualWorks offers most of what you need and is essentially what you want - why do you want to switch to Pharo? This is not intended to be offensive or provoking. I just wonder if an open source project is the right thing for you. Pharo is emerging and has quite some pace doing so. This is both good and bad - at many levels. Commercial offerings may be a lot slower and thus less of a "moving target" (not sure I am citing you, but I know I read this in one of the threads about the current state of Pharo just these days), but they are pretty much focussed on issues like deployment and stable APIs. Joachim
