September 2014 - Pharo-users

Re: [Pharo-users] How can I help make installing Pharo easier (on Debian Wheezy)?

by Esteban Lorenzano

hi, you need to use this one: http://files.pharo.org/vm/pharo/linux/old-libc/pharovm-ubuntu804.tar.gz it will do the work :) and yes, there is no 64bits version (yet) of the VM. It is planned for some point of next year (hopefully spring). cheers, Esteban On Mon, Sep 15, 2014 at 10:09 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I have never compiled the VM myself so take any advice with a big grain of > salt. First there is no 64 bit version of Pharo, there is work to port the > VM to 64 bit and some first goals have been met but still a work in > progress. > > Second in order to build the VM you will need firs VMMaker, basically what > Squeak and Pharo do VM wise is use a special language called Slang which > basically a C like smalltalk that compiles to ... well .... C , then you > take the generate C source and compile the VM together with some hand made > C code again for the VM. There is a post of Mariano for the Stack VM which > is the old vm and the Cog VM which is the VM currently used by Squeak and > Pharo that has the added advantage of JIT compiler which means much more > speed. Mariano's post is old but it may still work for compiling for VM so > here it is > > https://marianopeck.wordpress.com/tag/vmmaker/ > > I am still a newcomer to Pharo so if you want more help wait for some of > the experienced pharo coders to reply > > On Mon, Sep 15, 2014 at 10:51 PM, Sloane Simmons <sloanes.k(a)gmail.com> > wrote: > >> Hi all, >> >> Apologies if this is not the right place for this - I'm just getting >> started with Smalltalk and I had a lot of trouble when first trying to >> get going since the binaries on pharo.org don't work with Debian >> Wheezy's glibc (2.13, whereas Pharo is compiled against 2.15 IIRC). I >> tried compiling from the Github repository >> (https://github.com/pharo-project/pharo-vm) but it looks this needs >> an existing binary version of pharo to work in order to bootstrap the >> compilation. I eventually just used a virtualbox Ubuntu environment >> (14.04) and was able to install there. >> >> For learning Smalltalk, running in a virtualbox VM absolutely works >> (for me), but I'd like to try and compile for Debian stable (or >> statically link glibc(?)) and then add to the official repositories so >> that it's easier to install. Bonus points would be making a 64-bit >> version... ;) >> >> Thanks, >> Sloane Simmons >> >> >

Sept. 15, 2014

Re: [Pharo-users] How can I help make installing Pharo easier (on Debian Wheezy)?

by kilon alios

I have never compiled the VM myself so take any advice with a big grain of salt. First there is no 64 bit version of Pharo, there is work to port the VM to 64 bit and some first goals have been met but still a work in progress. Second in order to build the VM you will need firs VMMaker, basically what Squeak and Pharo do VM wise is use a special language called Slang which basically a C like smalltalk that compiles to ... well .... C , then you take the generate C source and compile the VM together with some hand made C code again for the VM. There is a post of Mariano for the Stack VM which is the old vm and the Cog VM which is the VM currently used by Squeak and Pharo that has the added advantage of JIT compiler which means much more speed. Mariano's post is old but it may still work for compiling for VM so here it is https://marianopeck.wordpress.com/tag/vmmaker/ I am still a newcomer to Pharo so if you want more help wait for some of the experienced pharo coders to reply On Mon, Sep 15, 2014 at 10:51 PM, Sloane Simmons <sloanes.k(a)gmail.com> wrote: > Hi all, > > Apologies if this is not the right place for this - I'm just getting > started with Smalltalk and I had a lot of trouble when first trying to > get going since the binaries on pharo.org don't work with Debian > Wheezy's glibc (2.13, whereas Pharo is compiled against 2.15 IIRC). I > tried compiling from the Github repository > (https://github.com/pharo-project/pharo-vm) but it looks this needs > an existing binary version of pharo to work in order to bootstrap the > compilation. I eventually just used a virtualbox Ubuntu environment > (14.04) and was able to install there. > > For learning Smalltalk, running in a virtualbox VM absolutely works > (for me), but I'd like to try and compile for Debian stable (or > statically link glibc(?)) and then add to the official repositories so > that it's easier to install. Bonus points would be making a 64-bit > version... ;) > > Thanks, > Sloane Simmons > >

Sept. 15, 2014

How can I help make installing Pharo easier (on Debian Wheezy)?

by Sloane Simmons

Hi all, Apologies if this is not the right place for this - I'm just getting started with Smalltalk and I had a lot of trouble when first trying to get going since the binaries on pharo.org don't work with Debian Wheezy's glibc (2.13, whereas Pharo is compiled against 2.15 IIRC). I tried compiling from the Github repository (https://github.com/pharo-project/pharo-vm) but it looks this needs an existing binary version of pharo to work in order to bootstrap the compilation. I eventually just used a virtualbox Ubuntu environment (14.04) and was able to install there. For learning Smalltalk, running in a virtualbox VM absolutely works (for me), but I'd like to try and compile for Debian stable (or statically link glibc(?)) and then add to the official repositories so that it's easier to install. Bonus points would be making a 64-bit version... ;) Thanks, Sloane Simmons

Sept. 15, 2014

Re: [Pharo-users] BootstrapMagritte load Error

by Stephan Eggermont

Hi Udo, Thanks. That is part of what is needed. In the ConfigurationOfBootstrap, 0.12.0 refers directly to Seaside 3.1.3. I updated it to 0.12.1 Stephan

Sept. 15, 2014

Re: [Pharo-users] BootstrapMagritte load Error

by Udo Schneider

Hi Stephan, I "fixed" it in my fork. Not sure if it's working as you intended but it seems to work: https://www.dropbox.com/s/o0id4mo63ps1jld/ConfigurationOfBootstrapMagritte-… CU, Udo On 15.09.2014 21:02, Stephan Eggermont wrote: > Hi Udo, > > Thanks for the update. > > The current stable BootstrapMagritte loads version090, and works. > Changing groups indeed breaks all users and forces them to upgrade. > > I'm not sure why version0110 and version0120 no longer refer to release versions > of Seaside, nor why there is a baseline0130 > > Stephan >

Sept. 15, 2014

Re: [Pharo-users] [ANN] Easy I18N for Pharo

by Esteban A. Maringolo

2014-09-15 15:35 GMT-03:00 Johan Brichau <johan(a)inceptive.be>: > On 15 Sep 2014, at 19:31, Stephan Eggermont <stephan(a)stack.nl> wrote: >> The main problems I have with external tools is the lack of translation context and the >> slow feedback cycle. That is killing for translation speed and quality. > I can understand that in-app tools work well for developers but when you start working with translators (humans) that are not developers (and certainly not Smalltalkers), you want to export the translation work. Now, Gettext is certainly not the walhalla, but I see a lot of things to do in-app before even getting to the level of those external tools. +1 We used a Gettext like (custom dev) approach in the past, and it was the analyst and expert users who did the translations and customizations (regional dialects). It involved 3 languages and several dialects of Spanish. Some specific terms are different in different countries and/or each corporation has a different jargon which THEY WANT to see on the screen/reports. It worked very well. And because the files were plain text it was even easier to integrate different modifications to the master file using standard tools like git/diff. Regards!

Sept. 15, 2014

Re: [Pharo-users] BootstrapMagritte load Error

by Stephan Eggermont

Hi Udo, Thanks for the update. The current stable BootstrapMagritte loads version090, and works. Changing groups indeed breaks all users and forces them to upgrade. I'm not sure why version0110 and version0120 no longer refer to release versions of Seaside, nor why there is a baseline0130 Stephan

Sept. 15, 2014

Re: [Pharo-users] [ANN] Easy I18N for Pharo

by Johan Brichau

On 15 Sep 2014, at 19:31, Stephan Eggermont <stephan(a)stack.nl> wrote: > The main problems I have with external tools is the lack of translation context and the > slow feedback cycle. That is killing for translation speed and quality. I can understand that in-app tools work well for developers but when you start working with translators (humans) that are not developers (and certainly not Smalltalkers), you want to export the translation work. Now, Gettext is certainly not the walhalla, but I see a lot of things to do in-app before even getting to the level of those external tools. Also, there is translation context exported to Gettext (but this does not help actually) and whenever a translator changes the file, we immediately read it again in the app, so I donât really understand the slow feedback cycle issue. There are other tools btw: - http://translate-toolkit.readthedocs.org/en/latest/index.html - http://www.arizona-software.ch/ilocalize/ Iâm all for an approach where Pharo explicitly caters for multiple possible translators, where Gettext would just be one possible option. This is more or less what exists today, except that itâs ad-hoc and deserves a cleaned implementation and design. Gettext and other translators can plugin to the Locale and Translator class hierarchies that are there. Johan

Sept. 15, 2014

BootstrapMagritte load Error

by Udo Schneider

Hi Stephan, hi Thorsten, the current stable version of ConfigurationOfBootstrapMagritte doesn't load anymore. It seems that the stable version of ConfigurationOfBootstrap changed some group names ('core' -> 'Core', 'widgets' -> 'Widgets') which are referenced in ConfigurationOfBootstrapMagritte and not yet updated. Hope this helps. CU, Udo

Sept. 15, 2014

Re: [Pharo-users] [ANN] Easy I18N for Pharo

by Stephan Eggermont

Johan wrote: >I also agree 100% with Hilaire: Gettext is a standard where plenty of external tools can work with. Though itâs nice to have translation tools in the image, you will have to do everything yourself. Just take a look at >everyhting that is done by poedit [1]. Do we really want to implement everything ourselves? The main problems I have with external tools is the lack of translation context and the slow feedback cycle. That is killing for translation speed and quality. Stephan

Sept. 15, 2014