September 2010 - Pharo-users

Re: [Pharo-users] Recent Submissions

by Mariano Martinez Peck

Same question.....this RecenSubmissions will be part of PharoCore isn't it? is it already integrated? There is no need to update PharoDev building? thanks Mariano On Mon, Jul 19, 2010 at 11:31 PM, Benjamin Van Ryseghem < benjamin.vanryseghem(a)gmail.com> wrote: > Ok Stef, so i've separated my work from the Tool-Browser class (there is a > bug to fix into the RecentMessageSet class in order to remove useless > multiples entries) > > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'RecentSubmissions'; > load > > A way to open the alternate viewer is by doing: > > RecentSubmissions openInWorld > > Ben > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

Sept. 21, 2010

Re: [Pharo-users] Support for SCIM on Linux

by Mariano Martinez Peck

David, can you try with both Pharo1.0 and Pharo1.1 ? In Pharo1.1 by default installed Bitmap fonts, which dosen't contains unicode glyphs. In Pharo1.0 we used TrueType fonts so that you can choose the one you like, which will correctly diaplays cyrillic glyphs. Please let us know if that works. And in such case you can use TrueType in 1.1 also if you want. cheers mariano On Tue, Sep 21, 2010 at 11:50 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Ahh and you can open a ticket :) > > > On Tue, Sep 21, 2010 at 11:50 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi David. I have no idea. I just cc'ed pharo-dev in case someone can help >> you. >> >> Cheers >> >> Mariano >> >> >> On Fri, Sep 17, 2010 at 6:23 PM, DavidWilson <djwilson(a)bluewin.ch> wrote: >> >>> >>> Hi >>> >>> I'm trying to input Tibetan (i.e. Unicode) characters using the SCIM >>> input >>> method (Wylie tibetan aka EWTS) on Ubuntu (10.4). >>> (N.B. That's not the same as a different keyboard layout!) >>> >>> SCIM works ok for OpenOffice and even for gedit, but not in Pharo, ie it >>> is >>> installed correctly and working. >>> >>> I suspect it's because Pharo consumes the keyboard input directly, and >>> doesn't let SCIM do its stuff (essentially aggregating keystrokes before >>> sending the unicode on to application). >>> >>> It would be nice to hear from a) anyone who's got this to work in Pharo, >>> or >>> b) someone who can confirm what I suspect. >>> >>> The equivalent works fine on Mac! >>> >>> David >>> -- >>> View this message in context: >>> http://forum.world.st/Support-for-SCIM-on-Linux-tp2544095p2544095.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >

Sept. 21, 2010

Re: [Pharo-users] Hello and Mac OS X question

by Mariano Martinez Peck

Hi Marc and welcome!! Maybe you should read: http://book.pharo-project.org/book/introduction/ that is a chapter for basic stuff. It explains image, vm, etc... Cheers Mariano On Fri, Sep 17, 2010 at 7:25 AM, Marc Hanisch <marc.hanisch(a)googlemail.com>wrote: > Hello Stanislav, hello StÃ©phane, > > thank you very much! I didn't realized that I can install the VM > seperately :-) I really like the way of programming with > Smalltalk/Pharo and I like the intelligent IDE (although I'm a > die-hard vim-user ;-))... > > Best regards! > Marc > > 2010/9/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > > On Sep 16, 2010, at 3:16 PM, Stanislav Paskalev wrote: > > > >> Hi Marc, > >> I'm basically in the same situation like you, I'm a B2B Java developer > >> by the day and I'm using Pharo for personal projects at night. :) > > > > I hope that one day you will be able to do the inverse :) > > > >> I believe it's best to install the virtual machine separately and just > >> associate the .image files with it. (I've done this under Windows, > >> under Linux I have squeak-vm installed from my distro and I just run > >> squeak my-pharo.image.) Therefore whenever you open an image (with the > >> coresponding .changes file available as well as .sources) - the vm > >> will launch with it. > > > > Yes > > One click are just bundle to let people work with the system in two > minutes. > > > >> Stanislav Paskalev > >> > >> > >> > >> On Thu, Sep 16, 2010 at 3:40 PM, Marc Hanisch > >> <marc.hanisch(a)googlemail.com> wrote: > >>> Hello List, > >>> > >>> my name is Marc, I'm a programmer from Germany developing B2B PHP-Web > >>> applications as my profession. > >>> In my spare time I try to discover Smalltalk and I'm very impressed > >>> and somewhat overstrained about the big range of different Smalltalk > >>> distributions, tools and possibilities. > >>> > >>> So I decided to look at Pharo by reading Pharo By Example. I'm using > >>> Pharo on my Ubuntu-Box and on my MacBook, too. Now I'm wondering, how > >>> to load an previously saved image on Mac OS X? On Linux I copy & > >>> change the ./pharo.sh file. Is there any best practice to open such an > >>> image? There is no facility to open an image from within the > >>> Pharo-IDE. > >>> > >>> Sorry for that newbee question, I'm somewhat confused ;-) > >>> > >>> Thank you very much and best regards, > >>> Marc > >>> > >>> -- > >>> http://twitter.com/dubst3pp4 > >>> http://dubst3pp4.wordpress.com > >>> > >>> _______________________________________________ > >>> Pharo-users mailing list > >>> Pharo-users(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >>> > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 21, 2010

Re: [Pharo-users] Support for SCIM on Linux

by Mariano Martinez Peck

Ahh and you can open a ticket :) On Tue, Sep 21, 2010 at 11:50 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi David. I have no idea. I just cc'ed pharo-dev in case someone can help > you. > > Cheers > > Mariano > > > On Fri, Sep 17, 2010 at 6:23 PM, DavidWilson <djwilson(a)bluewin.ch> wrote: > >> >> Hi >> >> I'm trying to input Tibetan (i.e. Unicode) characters using the SCIM input >> method (Wylie tibetan aka EWTS) on Ubuntu (10.4). >> (N.B. That's not the same as a different keyboard layout!) >> >> SCIM works ok for OpenOffice and even for gedit, but not in Pharo, ie it >> is >> installed correctly and working. >> >> I suspect it's because Pharo consumes the keyboard input directly, and >> doesn't let SCIM do its stuff (essentially aggregating keystrokes before >> sending the unicode on to application). >> >> It would be nice to hear from a) anyone who's got this to work in Pharo, >> or >> b) someone who can confirm what I suspect. >> >> The equivalent works fine on Mac! >> >> David >> -- >> View this message in context: >> http://forum.world.st/Support-for-SCIM-on-Linux-tp2544095p2544095.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >

Sept. 21, 2010

Re: [Pharo-users] Support for SCIM on Linux

by Mariano Martinez Peck

Hi David. I have no idea. I just cc'ed pharo-dev in case someone can help you. Cheers Mariano On Fri, Sep 17, 2010 at 6:23 PM, DavidWilson <djwilson(a)bluewin.ch> wrote: > > Hi > > I'm trying to input Tibetan (i.e. Unicode) characters using the SCIM input > method (Wylie tibetan aka EWTS) on Ubuntu (10.4). > (N.B. That's not the same as a different keyboard layout!) > > SCIM works ok for OpenOffice and even for gedit, but not in Pharo, ie it is > installed correctly and working. > > I suspect it's because Pharo consumes the keyboard input directly, and > doesn't let SCIM do its stuff (essentially aggregating keystrokes before > sending the unicode on to application). > > It would be nice to hear from a) anyone who's got this to work in Pharo, or > b) someone who can confirm what I suspect. > > The equivalent works fine on Mac! > > David > -- > View this message in context: > http://forum.world.st/Support-for-SCIM-on-Linux-tp2544095p2544095.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 21, 2010

Re: [Pharo-users] Ffi in Pharo 1.1

by Mariano Martinez Peck

On Mon, Sep 20, 2010 at 9:18 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Thanks for the reply Mariano, > > 2010/9/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Mon, Sep 20, 2010 at 6:08 PM, HernÃ¡n Morales Durand > > <hernan.morales(a)gmail.com> wrote: > >> > >> Hi Mariano, > >> > >> One thing I don't understand of Metacello is why don't you use > >> #latestVersion (or #latestReleaseVersion, #latestDevelopementVersion, > >> etc) instead of specifying the version number (e.g. '1.3'). How do you > >> keep updated about the latest version numbers? > > > > This is an excellent question :) > > > > In summary, there is a current problem with Metacello and Pharo: a user > of a > > project doesn't know which is the stable version for a pharo specifc > > version. For example, in this case suppose FFI 1.1 is the stable for > Pharo > > 1.0 and FFI 1.3 for Pharo 1.1. How can the user know that? there is no > easy > > solution. This is why Dale, me, stef, marcus, esteban, etc, have been > > discussed last week in ESUG. I will then send a summary about the > possible > > solution. > > > > Do I need to know the version numbers? > Depends on your needs. If you want to be able to recreate/reproduce it, then yes (at least right now). > > As an user I don't want to know the version number until extremely > necessary, i.e. I'm not switching everyday from 1.0 to 1.1 to 1.2 then > back to 1.1, etc. Eventually I try newer versions of Pharo to see what > I'm missing, and I choose to update acoordingly to the stability of > the whole set of packages concerning my application. It's not like I > evaluate the same "install base packages" script I've evaluated 6 > months ago :) > Ok, that's your use-case. OThers need exactly that :) > > By the way if you want to support internally the package status you > may try the Specifications pattern? > > > Anyway, if I use latestVersion, I am not sure you will load that again. > > I'm sure I will never load it again. Got it? :) > > yes. That's a use-case. Fortunatly Metacello is flexible enough to support both. Anyway, did you read my email about stable versions? I think that will clarify everything....since we will be able to use #stableVersion. Cheers Mariano > > Ok....I assumed he was using Pharo 1.1 (because is the current latest > stable > > release). Then, I KNOW that FFI 1.3 works well with Pharo 1.1. If he > takes > > the same image, and in 6 months someone releases FFI 1.4 that doesn't > work > > anymore with Pharo 1.1, then it will fail. > > > > Cheers > > > > Mariano > > > >> > >> 2010/9/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > Hi Bruce. The recommended way to install external packages in Pharo is > >> > now > >> > using Metacello. > >> > > >> > To install FFI in Pharo, evaluate: > >> > > >> > Gofer new > >> > squeaksource: 'MetacelloRepository'; > >> > package: 'ConfigurationOfFFI'; > >> > load. > >> > > >> > ((Smalltalk at: #ConfigurationOfFFI) project version: '1.3') load. > >> > > >> > > >> > For more information about Metacello: > >> > > >> > http://code.google.com/p/metacello/ > >> > > >> > or you can see the talk we give with Dale last week at ESUG. > >> > > >> > Cheers > >> > > >> > Mariano > >> > > >> > On Sun, Sep 19, 2010 at 9:27 PM, Bruce Haugland > >> > <bruce.haugland(a)gmail.com> > >> > wrote: > >> >> > >> >> I noticed in Pharo 1.1 that the loadFFI script in the script loader > is > >> >> no > >> >> longer there. How can I load FFI into Pharo 1.1. I noticed that the > >> >> shared > >> >> library is there but that there are no supporting FFI Classes. > >> >> Thanks for the Help. > >> >> Bruce > >> >> _______________________________________________ > >> >> Pharo-users mailing list > >> >> Pharo-users(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Pharo-users mailing list > >> > Pharo-users(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> > > >> > > >> > >> > >> > >> -- > >> HernÃ¡n Morales > >> Information Technology Manager, > >> Institute of Veterinary Genetics. > >> National Scientific and Technical Research Council (CONICET). > >> La Plata (1900), Buenos Aires, Argentina. > >> Telephone: +54 (0221) 421-1799. > >> Internal: 422 > >> Fax: 425-7980 or 421-1799. > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 21, 2010

Re: [Pharo-users] oh i forgot to say

by HwaJong Oh

Animated MindMap(which is not correct package name) is not ready in SqueakSource. Will be uploaded soon. ToolDAD is in SqueakSource (check the wiki tab of the project site for more information) http://www.squeaksource.com/ToolDad.html -- View this message in context: http://forum.world.st/oh-i-forgot-to-say-tp2546902p2547777.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 20, 2010

Re: [Pharo-users] [Metacello] Metacello as a package management system for Pharo

by Miguel CobÃ¡

El lun, 20-09-2010 a las 22:31 +0200, Mariano Martinez Peck escribiÃ³: > 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. ok > > 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' ]. > ..... This implies that the stableVersion method will be heavily modified as the software is ported to new platforms and new releases. Not a big deal. Sometimes will imply that a merge will be needed when 2 developers want to maintain the configuration. Also, I feel that disconnects the version method from the version string declaration/publication. again, not a big issue either. > > 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) As you say they are equivalent ways to state the same information. I like this because it is only a place to modify the new version number. I personally like this, but also I can imagine that this could lead to big methods with conditionals for functionality that applies to more than one release. Maybe the first option requires less work for Dale to support this functionality. > > 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). I like it. Now, when traversing dependencies, wouldn't be good to also rewrite the repositories they point to so that they point to self (repository). This way the problem 3 is solved too, because the configuration already points to self and not the original repo? This maybe could be easier if Metacello could have a way to indirect repository names from the configuration so that the metacello version projects only referred a keyworkd and not the real package and then on commiting the package to the repo, it would be rewritten or overriden with the container repository? For example, instead of: spec for: #squeakCommon do: [ spec project: 'OSProcess' with: [ spec className: 'ConfigurationOfOSProcess'; loads: #('default'); file: 'ConfigurationOfOSProcess'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. spec repository: 'http://www.squeaksource.com/Magma'; package: 'WriteBarrier' with: [ spec repository: 'http://www.squeaksource.com/WriteBarrier' ]; you'll write a baseline like: spec for: #squeakCommon do: [ spec project: 'OSProcess' with: [ spec className: 'ConfigurationOfOSProcess'; loads: #('default'); file: 'ConfigurationOfOSProcess'; repository: #osProcessRepository ]. spec repository: 'http://www.squeaksource.com/Magma'; package: 'WriteBarrier' with: [ spec repository: #writeBarrierRepository ]; and will define the repositories somewhere else: ConfigurationOfXXX>>repositoryFor: aSymbol ^ repoMap at: #aSymbol "This will return the real repo" And when commiting, maybe the GoferProjectManager will create a subclass with a method overriding the repository map to ConfigurationOfXXX>>repositoryFor: aSymbol ^ 'http://www.squeaksource.com/PharoPackagesContainerXX' I haven't used repositoryOverrides so maybe this is nonsense and not necessary and can be handled cleanly and better by Metacello itself. :) > > 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 Overall I agree. The less the user has to type and know from where the packages come the better for we all. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 20, 2010

Metacello as a package management system for Pharo

by Mariano Martinez Peck

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

Sept. 20, 2010

Re: [Pharo-users] Ffi in Pharo 1.1

by HernÃ¡n Morales Durand

Thanks for the reply Mariano, 2010/9/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Sep 20, 2010 at 6:08 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> >> Hi Mariano, >> >> One thing I don't understand of Metacello is why don't you use >> #latestVersion (or #latestReleaseVersion, #latestDevelopementVersion, >> etc) instead of specifying the version number (e.g. '1.3'). How do you >> keep updated about the latest version numbers? > > This is an excellent question :) > > In summary, there is a current problem with Metacello and Pharo: a user of a > project doesn't know which is the stable version for a pharo specifc > version. For example, in this case suppose FFI 1.1 is the stable for Pharo > 1.0 and FFI 1.3 for Pharo 1.1. How can the user know that? there is no easy > solution.Â This is why Dale, me, stef, marcus, esteban, etc, have been > discussed last week in ESUG. I will then send a summary about the possible > solution. > Do I need to know the version numbers? As an user I don't want to know the version number until extremely necessary, i.e. I'm not switching everyday from 1.0 to 1.1 to 1.2 then back to 1.1, etc. Eventually I try newer versions of Pharo to see what I'm missing, and I choose to update acoordingly to the stability of the whole set of packages concerning my application. It's not like I evaluate the same "install base packages" script I've evaluated 6 months ago :) By the way if you want to support internally the package status you may try the Specifications pattern? > Anyway, if I use latestVersion, I am not sure you will load that again. I'm sure I will never load it again. Got it? :) > Ok....I assumed he was using Pharo 1.1 (because is the current latest stable > release). Then, I KNOW that FFI 1.3 works well with Pharo 1.1. If he takes > the same image, and in 6 months someone releases FFI 1.4 that doesn't work > anymore with Pharo 1.1, then it will fail. > > Cheers > > Mariano > >> >> 2010/9/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi Bruce. The recommended way to install external packages in Pharo is >> > now >> > using Metacello. >> > >> > To install FFI in Pharo, evaluate: >> > >> > Gofer new >> > Â Â Â squeaksource: 'MetacelloRepository'; >> > Â Â Â package: 'ConfigurationOfFFI'; >> > Â Â Â load. >> > >> > ((Smalltalk at: #ConfigurationOfFFI) project version: '1.3') load. >> > >> > >> > For more information about Metacello: >> > >> > http://code.google.com/p/metacello/ >> > >> > or you can see the talk we give with Dale last week at ESUG. >> > >> > Cheers >> > >> > Mariano >> > >> > On Sun, Sep 19, 2010 at 9:27 PM, Bruce Haugland >> > <bruce.haugland(a)gmail.com> >> > wrote: >> >> >> >> I noticed in Pharo 1.1 that the loadFFI script in the script loader is >> >> no >> >> longer there. Â How can I load FFI into Pharo 1.1. Â I noticed that the >> >> shared >> >> library is there but that there are no supporting FFI Classes. >> >> Thanks for the Help. >> >> Bruce >> >> _______________________________________________ >> >> Pharo-users mailing list >> >> Pharo-users(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> > >> > >> > _______________________________________________ >> > Pharo-users mailing list >> > Pharo-users(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> > >> >> >> >> -- >> HernÃ¡n Morales >> Information Technology Manager, >> Institute of Veterinary Genetics. >> National Scientific and Technical Research Council (CONICET). >> La Plata (1900), Buenos Aires, Argentina. >> Telephone: +54 (0221) 421-1799. >> Internal: 422 >> Fax: 425-7980 or 421-1799. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Sept. 20, 2010