- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Metacello configuration conventions

by Johan Brichau

On 22 Apr 2013, at 17:37, Dale Henrichs <dhenrich(a)vmware.com> wrote: > 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. We're using the scripting api since almost a year and it seems to behave :-) Btw, I also did some work to make it run in Pharo2.0 but it's not yet working entirely. What is the location of your code changes on this so I can merge in when I get back to it? Btw, I did run into some load problems where strange conflicts got reported in gemstone... you might be getting that bug report sooner than you want ;-) Cheers Johan

April 22, 2013

[Pharo-project] A Pharo launcher

by Damien Cassou

I think the idea to have a Pharo launcher that lets the user pick a Pharo template (either bare pharo 2.0, pharo+seaside, pharo+seaside+mongodb+ magritte+voyage, pharo+pier, ...) and then create a new image the user must save somewhere is important. I want people to have one Pharo icon on their desk and just click it (like in Eclipse, word processors, virtual box...). Here is a set of requirements for such an application, please comment. - must be implemented in Pharo 2.0 with maintained technology (spec or glamour) - must be cross-platform (we want 1 application for all Pharo users) - must download the list of templates from internet (so that we don't have to update the application all the time) - must propose different kinds of template (stable/unstable, desktop/web) - must rapidly create an image out of the selected template (either by downloading Fueled packages, or by downloading ready-made images) - must cache the created images so that they do not have to be recreated all the time (except when a newer version is available) - must force the user to copy the created image so he can freely change it and crash it without impacting the cache of created images. - must present a list of recently launched images so that the user can just pick a recent image instead of creating a new one Please comment (and implement this idea) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

April 22, 2013

[Pharo-project] [ANN] Pharo VM for Ubuntu updated

by Damien Cassou

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

April 22, 2013

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