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

Re: [Pharo-project] Metacello configuration conventions

by Dale Henrichs

Sean, When Cami refers to "automatic dependencies" he's referring to the fact that with ruby-gems one can specify a range of versions that will satisfy the dependencies for your project instead of a single version as is done with Metacello today. "automatic dependencies" actually only work (and you'll like this Sean) if the project is using Semantic Versioning[1]. If a project doesn't follow the semantic version specification for version numbering, then version ranges are also meaningless. One MUST be able to look at a version number and be able to distinguish between API changes, backwards compatible functionality changes and backwards compatible bugfixes ... If a project follows this convention, then one can specify a dependency that allows for updating only for bugfixes ... In the absence of any version name convention, one must be explicit ... I imagine that today, very few projects actually apply Semantic Versioning to their version numbering scheme, so we must start by adopting Semantic Versioning ... Metacello can handle the mechanics of Semantic Versioning, but it is up to the developers to adhere to the specification. Dale [1] http://semver.org/ ----- Original Message ----- | From: "Sean P. DeNigris" <sean(a)clipperadams.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Friday, April 19, 2013 5:27:55 AM | Subject: Re: [Pharo-project] Metacello configuration conventions | | > Metacello supports both, but not at the same time. Either you mark your | > configuration with fixed versions (best for patches) or with symbolic | > versions (best for releases). | I don't understand this. If you don't want your dependencies upgraded, you | don't change the versions referenced in your new version, if you do, you | manually change them. Either way, you make a new version, whether it's a | patch, enhancement, or total overhaul. | | The symbolic versions, OTOH, map your versions to their status on respective | platforms. You would do this for every new version. | | | | ----- | Cheers, | Sean | -- | View this message in context: | http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682563… | Sent from the Pharo Smalltalk mailing list archive at Nabble.com

April 22, 2013

Re: [Pharo-project] Metacello configuration conventions

by Dale Henrichs

Diego, You raise some good points here ... In the Metacello Scripting API, I have added some capabilities that just might fill the bill. For example you can write the following expression: Metacello image configuration: 'MyProject'; version: '1.0.1'; onUpgrade: [:ex | ex deny]; load. The onUpgrade block is evaluated whenever Metacello detects an upgrade of a project ... the exception is an instance of MetacelloResolveProjectUpgrade which is Notification that provides information about the current in-image project (version name, etc.) and the proposed incoming version, so you can be very fine grained in your control. In addition there are #onDowngrade: and #onConflict: variants as well.. The Metacello Scripting API needs to be ported to Pharo 2.0 (Christophe and I are working on this ... I am very busy right now so I won't be moving fast here:), but it does run fine in GemStone, Pharo1.1-1.4, and Squeak4.3-4.5 ... I haven't release the Metacello Scripting API, because I just haven't the kind of feedback that I'd like when introducing a new API like this (if you look closely at the above expression, you might have several questions about details of the API). There are a number of folks that are using the Metacello Scripting API, but I haven't gotten enough bug reports to tell me that folks are really beating on it:). I've been using it myself for about 8 months, but I work in a limited number of use cases. Now that folks like you are asking for features that I think I've addressed in the Scripting API, perhaps I can start getting some meaningful feedback. If your projects are on Pharo2.0, you'll have to wait for Christophe and I to finish the port, otherwise you can take it for a spin[1] (there is some documentation as well) and let me know what makes sense to you and what doesn't. I'm prepared for the fact that when folks take a look at the Scripting API, I will need to make significant changes to the API so you should be prepared for that as well:) Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/README.md ----- Original Message ----- | From: "Diego Lont" <diego.lont(a)delware.nl> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, April 19, 2013 1:36:37 AM | Subject: Re: [Pharo-project] Metacello configuration conventions | | Hi all, | | I just want to add another thought to the convention discussion. | | In my work process I have two different activities when deploying new code: | 1) I want to deploy a patch, that only includes the bugfix. | 2) I want to deploy a release, that includes all updates. | | In the first I usually do not want to upgrade dependencies. If dependencies | need upgrading I want to make this decision manually. | | In the second I usually want to upgrade dependencies. If dependencies need | upgrading this should be done automatically. | | Metacello supports both, but not at the same time. Either you mark your | configuration with fixed versions (best for patches) or with symbolic | versions (best for releases). | | Currently we have a baseline, a version, and groups that I can edit. I think | I want a third thing: the deployment, where I describe certain deployment | strategies. So that I can say: | ConfigurationOfMyProject project stableVersion patch load | ConfigurationOfMyProject project stableVersion loadRelease | or something like this. | | Cheers, | Diego |

April 22, 2013

Re: [Pharo-project] Metacello configuration conventions

by Dale Henrichs

April 22, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by Frank Shearar

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

April 22, 2013

Re: [Pharo-project] Date comparison broken

by Henrik Johansen

On Apr 20, 2013, at 8:51 PM, Milan Mimica wrote: > There you go > https://pharo.fogbugz.com/default.asp?10343 If you're up for it taking a wider look, it's really part of a family of errors still lingering after the refactoring: https://pharo.fogbugz.com/f/cases/10072/DateAndTime-instance-variable-access Cheers, Henry

April 22, 2013

[Pharo-project] bug in nautilus?

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 22, 2013

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Guillaume Larcheveque

In my opinion, having sum and sum: aBlock is a good point. The only problem to solve is to have an elegant solution working even if it's an empty collection. I think the solution proposed by Doru is really satisfying. 2013/4/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Or maybe sumEach: #squared... Anyway, current Squeak #detectSum: sounds > awful, so it shouldn't be hard to find a better name > > > 2013/4/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> Personnally, I like #sumOf:, like for example (1 to: 10) sumOf: #squared. >> Same with maxOf: minOf: productOf: ... >> >> >> 2013/4/22 Frank Shearar <frank.shearar(a)gmail.com> >> >>> On 22 April 2013 12:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > Hi, >>> > >>> > I agree with Frank on the processing block: it has nothing to do with >>> summing. >>> > >>> > Mathematically, defining adding (sum) leads to a neutral element >>> (zero). But you only need it if the collection is empty. >>> > >>> > The trick of the #zero selector is elegant, but not needed with the >>> #anyOne trick. >>> >>> That's a good point. I thought of #zero because my own hacking on >>> SqueakCheck led naturally to thinking of protocols: using a class-side >>> #zero means that I could work with "all objects that understand + and >>> have a zero". >>> >>> #collectAndSum: might be a good name for the method, actually. >>> >>> frank >>> >>> > Currently, #sum does not work with empty collections in Pharo, which >>> surprised me. >>> > >>> > I would add a >>> > >>> > Collection>>#sumFrom: value >>> > ^ self inject: value into: [ :sum :each | sum + each ] >>> > >>> > And change >>> > >>> > Collection>>#sum >>> > | sample sum | >>> > self isEmpty ifTrue: [ ^ self sumFrom: 0 ]. >>> > sample := self anyOne. >>> > sum := self inject: sample into: [ :sum :each | sum + each ]. >>> > ^ sum - sample >>> > >>> > A variant with an additional collect style processing block could be >>> added along these lines, #sum: and #sum:from: >>> > >>> > Sven >>> > >>> > On 22 Apr 2013, at 12:29, Frank Shearar <frank.shearar(a)gmail.com> >>> wrote: >>> > >>> >> "Sum" is usually well-defined, so I don't understand what the block's >>> >> for. With the block it's more like "take this collection, map the >>> >> values with some function, and sum the result". >>> >> >>> >> If so, it sounds like you're looking for a sugared form of >>> >> (myCollection collect: aBlock) inject: self first class zero into: #+. >>> >> ? >>> >> >>> >> (There's already Float class >> #zero and (in Squeak at least) Integer >>> >> class >> #zero, and so on. Just add MyUnit class >> #zero and you're >>> >> done.) >>> >> >>> >> frank >>> >> >>> >> On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> 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" >>> > >>> > >>> > -- >>> > Sven Van Caekenberghe >>> > Proudly supporting Pharo >>> > http://pharo.org >>> > http://association.pharo.org >>> > http://consortium.pharo.org >>> > >>> > >>> > >>> > >>> > >>> >>> >> > -- *Guillaume Larcheveque*

April 22, 2013

Re: [Pharo-project] bug in nautilus?

by Sven Van Caekenberghe

I love honest developers ;-) On 22 Apr 2013, at 14:56, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Happens, still do not know why :s > > Ben > > On Apr 22, 2013, at 3:49 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi! >> >> Just wondering. >> I see the following in a 2.0 >> >> <Screen Shot 2013-04-22 at 9.48.27 AM.png> >> >> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >

April 22, 2013

[Pharo-project] Software Integration Survey

by Martin Dias

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

April 22, 2013

Re: [Pharo-project] bug in nautilus?

by Benjamin

Happens, still do not know why :s Ben On Apr 22, 2013, at 3:49 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Just wondering. > I see the following in a 2.0 > > <Screen Shot 2013-04-22 at 9.48.27 AM.png> > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

April 22, 2013