April 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] Metacello for Pharo 2 and Pharo 3 ?
by Goubier Thierry April 23, 2013

April 23, 2013

Hi, is there already a #'pharo3.0.x' tag in metacello when we want to have different package version in Pharo 3.0 instead of 2.0 ? I tried spec for: #'pharo3.0.x' version: '0.2' and it didn't work. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

3 2

[Pharo-project] [update 3.0] #30054
by Marcus Denker April 23, 2013

April 23, 2013

30054 ----- 10107 SimpleButtonMorph inconsistency for label: and label:font: https://pharo.fogbugz.com/f/cases/10107 10190 Failing test: Code critics / Manifest (Workaround to get green tests: failing test is in the tracker) https://pharo.fogbugz.com/f/cases/10190 10372 remove CustomParserTest https://pharo.fogbugz.com/f/cases/10372 10364 remove allowBlockArgumentAssignment setting https://pharo.fogbugz.com/f/cases/10364 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Core-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Settings-Compiler-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1400 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Manifest-Tests-MarcusDenker.… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.384 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/CompilerTests-MarcusDenker.1…

1 0

[Pharo-project] [ANN] Pharo VM for Ubuntu updated
by Damien Cassou April 22, 2013

April 22, 2013

Installing the pharo vm under Ubuntu is just a matter of: sudo add-apt-repository ppa:cassou/pharo sudo apt-get update sudo apt-get install pharo-vm Recent changes: - latest VM packaged - separation between pharo-vm-core (few dependencies) and pharo-vm-desktop (depends on pharo-core + opengl + x11 + cairo) - no more warnings from the packaging systems - pharo man page - no more embedded libraries (pcre and libjpeg) (thanks to Esteban Lorenzano) Todo list: - make Pharo a graphical executable that lets user create and launch images (more on that in my next email) - see if Debian would be interested in including this package -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

2 1

[Pharo-project] Metacello configuration conventions
by Stephan Eggermont April 22, 2013

April 22, 2013

Hi, While working with Diego on some configurations, we noticed two different styles of describing the latest non-baseline versions. In one, the versionString version of a dependency is used. That is a defensive strategy, where you want to specify the exact version that will be loaded (and has been tested). In the other the #stable version is used. That is an optimistic strategy. This is much less brittle (but might suddenly not work anymore). Seaside uses defensive/mixed, while Magritte uses optimistic Based on what criteria should I choose which one to use (in a Pharo context)? Stephan & Diego

9 25

[Pharo-project] bug in nautilus?
by Alexandre Bergel April 22, 2013

April 22, 2013

Hi! Just wondering. I see the following in a 2.0 How could it be? The icon of Spy-Core indicates that the package is empty. According to Monticello, I have only one package, called Spy. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence
by Frank Shearar April 22, 2013

April 22, 2013

I've added https://code.google.com/p/xtreams/issues/detail?id=2, so interested people please reply there. Thanks! On 18 April 2013 18:35, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Martin, > I recently ported some of the VW fixes to Squeak, but with a fully manual > mode: > - open a VW image and track the diffs > - try to understand the motivation of changes, the implementation and > analyze which change apply or not (no UninterpretedBytes in Squeak for > example, ...) > - update VW image > - copy/paste the code in Squeak, manually correct a XT prefix here and there > > Since not all features can be ported (differences in sockets/pipes etc...) > this process is fragile and somehow open to randomness, but that's what you > can get from a human ;) > > Ideally, we should proceed with test driven updates, first update/merge the > tests, then the implementation, but since a test can span several packages, > that's not always easy to deal with and following the history of commits is > not that easy in VW... > Maybe a well structured feature branch/bugfix branch policy coupled with bug > reports and using git support might indeed help sifting. > Anyway, I'm still a few months back in change history, so that leave some > place for experimentation > > > 2013/4/18 <mkobetic(a)gmail.com> > >> As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily >> just experimenting with Cypress. However the master branch there is >> misleading, it contains a very early port of Xtreams to ST/X (there's a much >> more up to date version in Jan's ST/X project @ >> https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/) >> >> However if you look at some of the other branches in the github project >> you can find a fairly up to date, Cypress formatted dump from VW as well as >> the results of Sean's ESUG effort to add namespace-prefix mapping to >> Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea >> to maintain a cross-dialect project as parallel branches in git. However we >> still need to iron out various dialect differences in terms of what they >> emit as Cypress formatted output. BTW, does anyone know if git/github can >> handle absence of a master branch? I'd be inclined to just delete the master >> from the repository if that works well. >> >> I've been planning to ping Sean about his Filetree fixes for a while, but >> I need to find the time to be able to actually act on it :-). The >> prefix-namespace mapping is crucial to make the parallel branch approach at >> all feasible. There's also the Environment effort on Squeak side which may >> obviate the prefix mapping need, but it seems to be still in fairly early >> stages. >> >> So far it was mostly Nicolas' manual effort that brought VW updates over >> the Squeak/Pharo side. I think it was a while since the last time he's done >> that, so the VW port is probably ahead somewhat. But Xtreams development >> isn't that active anymore. Most of our Xtreams related efforts are about >> using them for various things, so any changes are mostly fixes or small >> improvements driven by that use. So in some sense a manual update could be a >> feasible approach at this point. But I would really like to turn the project >> into a more collaborative effort, where updates can flow reasonably in any >> direction. >> >> While I'm on the topic, I'm considering some API changes and am not sure >> how to go about discussing it. I don't want to cross post discussions to a >> number of mailing lists, so I think I'm inclined to just cross-post an >> invitation to anyone interested to subscribe to the Issues on the project >> site (https://code.google.com/p/xtreams/) and have those discussions there. >> Any thoughts on that? >> >> "Frank Shearar"<frank.shearar(a)gmail.com> wrote: >> > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely >> > not the "canonical" repository, which would be in the Cincom Smalltalk >> > Public Repository. I think? Anyway, assuming it's up to date, one >> > promising approach to using Martin Kobetic's repository directly is: >> > * have a way of importing chunk format stuff from a GitHub repository >> > (see Squeak's inbox for my >> > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub >> > (and I plan to submit a Gofer patch to do the same)) >> > * load into an Environment (Squeak 4.5 can do this, modulo its alpha >> > state). >> > >> > It might even be possible to import into an Environment with the >> > prefix-adding import and then fileout/monticelloise the resulting >> > things as a prefix-using, non-Environments-requiring blob ready for >> > everyone to use. >> > >> > frank >> > >> >> > > > >

1 0

[Pharo-project] Date comparison broken
by Milan Mimica April 22, 2013

April 22, 2013

Hello | yesterday | yesterday := Date yesterday. yesterday < yesterday On Phalo 2.0, this evaluates to 'false'. I'ts not a joke. -- Milan Mimica http://sparklet.sf.net

4 8

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:
by Tudor Girba April 22, 2013

April 22, 2013

Hi, I am CC-ing the pharo mailing list because it can be of interest. I agree with Guillaume that there is a legitimate need for a generic solution. However, at the same time we lose the convenience of simply adding numbers, which is likely to be the most encountered use case. I see a couple of possibilities: - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue as the default. - add Collection>>sumNumbers: aBlock that takes 0 as default rather than anyOne. What do you think? Cheers, Doru On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque < guillaume.larcheveque(a)gmail.com> wrote: > For example, in Artefact we use Units and I have tried to use sum but it > doesn't works because Units doesn't allow to do 0 + 4 cm which is > inconsistent. > > > 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> > >> Thanks for letting us know. I cannot see a case where having 0 as the >> initial value does not work as expected. >> >> Cheers, >> Alexandre >> >> >> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >> >> > Hi, >> > >> > Pharo 2.0 comes with Collection>>sum: >> > >> > Collection>>sum: aBlock >> > "This is implemented using a variant of the normal inject:into: >> pattern. >> > The reason for this is that it is not known whether we're in the >> normal >> > number line, i.e. whether 0 is a good initial value for the sum. >> > Consider a collection of measurement objects, 0 would be the unitless >> > value and would not be appropriate to add with the unit-ed objects." >> > | sum sample | >> > sample := aBlock value: self anyOne. >> > sum := self inject: sample into: [ :previousValue :each | >> previousValue + (aBlock value: each) ]. >> > ^ sum - sample >> > >> > To some extent, this is more generic than the one we had in Moose that >> considered only numbers: >> > Collection>>sum: aSymbolOrBlock >> > ^ self >> > inject: 0 >> > into: [:sum :each | sum + (aSymbolOrBlock value: each)] >> > >> > >> > However, with the Pharo 2.0 implementation the collection must not be >> empty, while the other implementation we get 0. If the collection is empty, >> you get an exception due to anyOne. >> > >> > This induced several errors in metric computations (like number of >> methods of a package when the package had no classes). These are now fixed, >> but I thought I would let you know just in case you want to rely on this >> method. >> > >> > I actually still believe we would benefit from a robust but more >> limited sum:. Perhaps we could have sumNumbers:. >> > >> > Cheers, >> > Doru >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "If you can't say why something is relevant, >> > it probably isn't." >> > >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev(a)iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > *Guillaume Larcheveque* > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

5 6

[Pharo-project] Software Integration Survey
by Martin Dias April 22, 2013

April 22, 2013

Hi all, We are conducting an academic research to improve tools for software integration. If you maintain a project with multiple contributors, we will greatly appreciate your participation. Your answers will be used for research purposes and to support the development of new tools. You can later access the results of this study, make free use of our tools to support the integration of changes, and maybe receive a gift. https://sondages.inria.fr/index.php/667625/lang-en Best regards, MartÃn Dias, Nicolas Anquetil, VerÃ³nica Isabel Uquillas, StÃ©phane Ducasse and the RMOD Inria team

1 0

[Pharo-project] [update 3.0] #30053
by Marcus Denker April 22, 2013

April 22, 2013

1 0