September 2010 - Pharo-users

oh i forgot to say
by ë¬ë£ì¤íì¢ Sept. 20, 2010

Sept. 20, 2010

I am Korean hobby smalltalker first time Europe first time ESUG.

4 3

Metacello as a package management system for Pharo
by Mariano Martinez Peck Sept. 20, 2010

Sept. 20, 2010

Hi folks. First of all, sorry for the long email (I guess it will be long). After thinking and discussing hundred of times in the mailing lists, last week we all meet and talk about Metacello and Pharo. Dale, Stef, Marcus, Esteban, all were present. I want to write down all the ideas and solution in order to: not to forget them; and to get feedback and opinions from you. *Problems we want to face: * 1) Right now a user CANNOT know which version of a project is the stable for a specific Pharo version. For example, suppose ConfigurationOfXXX. The user cannot know that XXX 3.45 is the stable for 1.0 and that XXX 5.7.3 is the one for 1.1....etc...so users end up confused not knowing which version to download. In addition, #latestVersion is not enough, because that will answer you the latest version, but that may not be the correct one for older Pharo images. Suppose in the previous case, latestVersion may answer 5.7.3 which may not work in Pharo 1.0..... We want the user to be able to autaticallly load the stable version for each pharo version without needing to know that. 2) Have a repository for each Pharo version so that someone can easily browse the available configurations for that Pharo version, and load them. Not only one as it is now woth MetacelloRepository. 3) Be self contained. Sometimes developers removed packages of versions from their repositories. In such case, Metacello cannot do anything and the load may not work anymore. We want to be able to reproduce the load and be able to load the same 10 years after. *Solution proposed: * The proposed solution may not even involve Metacello. You may have heard about Metacello Project Loader developer by Esteban Lorenzano. See http://www.smallworks.com.ar/en/community/GoferProjectLoader The idea is rename that project to that it is a general name like GoferProjectManager or something like that, because now it will do load but also write :) I will call it GoferProjectManager in this email. The idea is that every developer of a configuration define the stable version for each Dialect version. There are two possible alternatives: a) That each Conf class implements #stableVersion: spec, which could be something like: ConfigurationOfXXX >> stableVersion: spec spec for: #Pharo1.0 do: [ ^ self version: '3.45' ]. spec for: #Pharo1.1 do: [ ^ self version: '5.7.3' ]. spec for: #Pharo1.2 do: [ self error: 'There is no stable version for Pharo 1.2' ]. spec for: #Gemstone do: [ ^ self version: '4.2' ]. ..... or something like that...the idea is that you define stable versions for each platform. The idea is that now the user could do something like this: ConfigurationOfXXX project stableVersion load but he won't do that ;) b) another approach is to specify something in each version, for example: ConfigurationOfXXX >> version345: spec <version: '3.45' imports: #('1.2-baseline')> spec for: #common do: [ spec blessing: #release. spec description: 'Blah balh...'. spec platformVersion: 'Pharo 1.0' and ConfigurationOfXXX >> version573: spec <version: '5.7.3' imports: #('1.2-baseline')> spec for: #common do: [ spec blessing: #release. spec description: 'Blah balh...'. spec platformVersion: 'Pharo 1.1' Now...any of those alternatives would solve problem 1) Now to solve 3) the idea is that GoferProjectManager could provide something like this: (Gofer project 'XXX') publishVersion: '3.45' for: 'Pharo 1.0' or then (Gofer project 'XXX') publishVersion: '5.7.3' for: 'Pharo 1.1' etc... Then this would do different things: a) Automatically take the conf class (it is important the name conventions!!) b) Commit it into the correct Pharo repository version. For example for 3.4.5 it will commit it in PharoMetacelloRepository10 and 5.7.3 to PharoMetacelloRepository11 c) Traverse all the dependencies of all needed packages and commit all of them to PharoPackagesContainer10 or PharoPackagesContainer11....etc Dale sent few weeks ago a script that does that: takes a conf, a version and a repo and commits all the files to that repo. With all this we solve 2). The idea is that for EACH pharo version we will have 2 repositories, one for the confs and another one for the packages (as a backup). The last point is that when loading we should load everything from the PharoPackagesContainer10 or PharoPackagesContainer11...but we don't want to change all our confs (for example, they are pointing to they own repos or MetacelloRepository)....so the solution is that we use GoferProjectManager to load. Example: Gofer project: 'XXX' loadStable and loadStable would be something like: self stableVersion repositoryOverrides: (self containerRepo); load The idea is that it can use #repositoriesOverride to override with the correct repository... So.....that's all. What do you think? does this make sense? Cheers Mariano

2 1

moose 4.1
by Tudor Girba Sept. 20, 2010

Sept. 20, 2010

Hello, We are happy to announce the Moose Suite version 4.1: http://moosetechnology.org/download What's new: â¢ Significant speed improvements of Mondrian and Glamour â¢ Improved Mondrian drawing of complex shapes â¢ Improved Glamour engine to handle cyclic updates â¢ New user interface look an feel â¢ Improved set of Glamour widgets â¢ Re-packaging to strengthen the naming convention â¢ Re-organization of the code to break unwanted dependencies â¢ Cleaning of FAMIX â¢ New extensible design of the Moose Finder â¢ New PetitParser-based parsers for MSE, Java, and MANIFEST.MF files â¢ New browser for meta-models described in MSE files â¢ Based on Pharo 1.1 A complete list of issues fixed in this release can be found at:http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fix… An incomplete set of future actions: â¢ Better browsers for various analyses use cases â¢ Improved FAMIX query API (MooseChic) â¢ Improved Glamour widgets â¢ EyeSee engine for drawing charts â¢ AST for Java Have fun, The Moose Team

2 1

hi
by ë¬ë£ì¤íì¢ Sept. 20, 2010

Sept. 20, 2010

i also subscribed in Pharo-users mailing list. Checking...

1 0

Pharocasts: Document with HelpSystem
by laurent laffont Sept. 20, 2010

Sept. 20, 2010

You will learn how to: - write an HelpSystem book - use PackageAPIHelpBuilder to generate the API documentation of a package - create your own builder to dynamically create a documentation from the system Starting from now, no excuses to not write documentation ;) http://pharocasts.blogspot.com/2010/09/document-with-helpsystem.html Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

2 1

A point about pharo: the red line
by StÃ©phane Ducasse Sept. 18, 2010

Sept. 18, 2010

Hi pharoers We want to stress something that may seem obvious for us but that can may be not for you and that people attending ESUG could discover live :) lucky them :) But you will be able to watch the video and get an idea soon. What is important is that it can explain a lot of our actions and future actions. Here is a list of statements that I tried to make short. - We do pharo because we want to create an ecosystem for companies and research/innovation. - We don't do pharo for fame and fans else we would do ruby or hard-rock. :) (ok probably ruby) - We want to build a powerful open-source community. - Every single node in the community is important. So yes you doing your little project in your corner you are important. Why? Because a community is a synergetic beast and we are all cool because the community is cool. So you are also important to us. For example if you want to give a lecture on pharo, we can help. if you want to do presentations, we can help, if you have problems/ideas let us know. - Often we do actions not because we want credit but just because somebody has to do it: seaside book, esug are to other examples of why we did pharo. Because we need a power rocking hyper cool beautifully designed system. (I know some of you think that I'm lousy and I use too much cool but this is what I mean) - We believe in strong elegant beautiful infrastructure: fix the stuff so that you can go faster to build the next one. We did that with Moose: offer to software engineering researchers a foundation to focus on problems versus rebuilding each time a clean source code meta model and importer. Infrastructure will give us the leverage to build the next generation. Stef and other pharoers

1 0

Community in the IDE
by laurent laffont Sept. 17, 2010

Sept. 17, 2010

Hi, an idea I haven't found the courage to implement but may not be hard and can have an impact (at least fun to code). - Write / put a chat server on seasidehosting|INRIA|whatever - Pharo image includes a chat client per default - uses Author as nickname So as soon as we open an image we are connected to other users. Can be interesting in courses as students are directly connected to *real* developpers while learning (and students love to chat :). So we can exchange snippets instantly, ask questions, ... Someone ? Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

2 1

About pharo book localisation chapter.
by Panu Suominen Sept. 12, 2010

Sept. 12, 2010

In localisation chapter people are asked to reload their image to enable translations. I think that NaturalLanguageTranslator privateStartUp is enough. It might be worth to mention because it speeds up testing. -- Panu

1 0

Re: [Pharo-users] i18n tools
by Panu Suominen Sept. 10, 2010

Sept. 10, 2010

2010/9/10 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Check with Philip Marchall, he did modification to use gettext code with > Seaside. Ok. Thanks to all for the help. Seaside and gettext are apparently the magic words that solves this problem. :) http://forum.world.st/Seaside-Gettext-sneak-peak-td2164600.html -- Panu

1 0

i18n tools
by Panu Suominen Sept. 10, 2010

Sept. 10, 2010

I am researching wether out team could start using Pharo. I have tried to locate some tools to do user interface translations but I did not find anything in time so I had to develop some rudimentary key-based translation tools my self. I would like to know is this lack of translation tools reality and if others are having same kind of problems? -- Panu

5 6