- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: Morphic
by HernÃ¡n Morales Durand Sept. 21, 2010

Sept. 21, 2010

Hi Chris, The Tracing Messages Browser is an excellent tool, does it work in Pharo? Cheers, 2010/9/20 Chris Muller <asqueaker(a)gmail.com>: >> I turned it on, but I'm not seeing the difference. > > You didn't? Â I've attached a screen shot. Â I've been porting the > "Tracing Messages Browser" since the 90's. Â The one in Squeak 4.2 is > easily the most productive version of it ever.. > >> I'm stupid, I need it to draw the lines, ;-) > > If you tried traceMessages you might change your mind about wanting > lines... Â :-) > > Â - Chris -- 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.

2 1

[Pharo-project] running Magma tests in 1.1
by Chris Muller Sept. 21, 2010

Sept. 21, 2010

To run the test-suite for Magma 1.1r2 in Pharo: - Proceed past two warnings about "FlapTab" when loading Magma. - Revert FileDirectory>>#fileExists: to the prior version. - Remove #testClassSchemaUpgrades. - Load OSProcess. The second and third steps, above, I believe may be regressions in Pharo 1.1. In Pharo 1.1: FileDirectory default fileExists: '/bin/sh' "---> false" but the file does, indeed, exist as a soft-link. Squeak answers true and, I'll bet, so does Pharo 1.0, so I'm not sure if there is a problem here or not. #testClassSchemaUpgrades tests Magma's ability to keep up with class-schema changes in the image. Usually class-schemas change only in development, not production systems so maybe it's not a big deal. But still, it can be very convenient develop new class schemas while connected to a persistent Magma store. Magma makes use of the SystemChangeNotifier to do this. I don't know if Pharo cleaned something with SystemChangeNotifier or a regression happened, but I don't have time to debug it right now. Certainly, if there is a problem with Magma I will fix it, but I'm not convinced of that yet. - Chris

3 4

Re: [Pharo-project] [Pharo-users] Recent Submissions
by Marcus Denker Sept. 21, 2010

Sept. 21, 2010

On Sep 21, 2010, at 1:01 PM, Mariano Martinez Peck wrote: > Same question.....this RecenSubmissions will be part of PharoCore isn't it? Yes. No need to have yet another package. > is it already integrated? > I think not yet. > There is no need to update PharoDev building? > No. > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [Pharo-users] Recent Submissions
by Mariano Martinez Peck Sept. 21, 2010

Sept. 21, 2010

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 > >

1 0

[Pharo-project] Improving generate accessors for refactoring browser
by Bart Gauquie Sept. 21, 2010

Sept. 21, 2010

Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart

5 7

[Pharo-project] Metacello as a package management system for Pharo
by Mariano Martinez Peck Sept. 21, 2010

Sept. 21, 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 2

[Pharo-project] Parsing HTML
by Alberto Bacchelli Sept. 21, 2010

Sept. 21, 2010

Hi, Is there a package I can use to parse HTML? Thanks and ciao, Alberto

1 0

[Pharo-project] Squeak/Pharo Talk
by DeNigris Sean Sept. 20, 2010

Sept. 20, 2010

If anyone is in NYC Wednesday evening, I'll be giving a talk about Squeak and Pharo for the NYC Smalltalk group. Details are at http://www.nycsmalltalk.org/ Sean

2 1

[Pharo-project] #collect:displayingProgress:
by Sven Van Caekenberghe Sept. 20, 2010

Sept. 20, 2010

Hello, Is this a bug or am I looking at this the wrong way ? This usage of #collect:displayingProgress: works as expected: #(a b c d e f g) collect: [:each | (Delay forMilliseconds: 100) wait. each ] displayingProgress: 'Working' While this doesn't: #(a b c d e f g) collect: [:each | (Delay forMilliseconds: 100) wait. each ] displayingProgress: [:each | 'Collecting ', each asString] The similar #do:displayingProgress: does work. It seems the index is passed into the progress block, not the element. Maybe this is by design ? Sven

3 3

[Pharo-project] HwaJong Oh
by ë¬ë£ì¤íì¢ Sept. 20, 2010

Sept. 20, 2010

Hi, i joined this mailinglist. I am Korean Hobby Smalltalker first time Europe first time ESUG. Hope you remember me. - HwaJong -

8 8