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

Re: [Pharo-project] NativeBoost label call

by Igor Stasenko

Hi, Guido, hmm... as far as i remember, there should be already support for that in asmjit. I remember we did something about it not long ago. But i will check. On 23 April 2013 22:02, Guido Chari <charig(a)gmail.com> wrote: > Hi Igor, > > I need support to call labels in Waterfall. I used to have a changeset with > this changes. > > But now i want to put Waterfall on Jenkins. So it would be easier if NB > already has the implementation. Otherwise i would need to load a changeset > after loading WF code through Metacello. > > I attach you my changes so you can check if you want to integrate them. If > you prefer not to integrate them just tell me so i check for the other > solution. > > Cheers, > Guido. > > -- Best regards, Igor Stasenko.

April 23, 2013

[Pharo-project] NativeBoost label call

by Guido Chari

Hi Igor, I need support to call labels in Waterfall. I used to have a changeset with this changes. But now i want to put Waterfall on Jenkins. So it would be easier if NB already has the implementation. Otherwise i would need to load a changeset after loading WF code through Metacello. I attach you my changes so you can check if you want to integrate them. If you prefer not to integrate them just tell me so i check for the other solution. Cheers, Guido.

April 23, 2013

[Pharo-project] the future of #stable in Metacello

by Dale Henrichs

I've cross-posted to pharo and metacello mailing list ... I'd prefer that the ongoing (possibly gory discussion:) take place on the metacello list, but since symbolic versions have been discussed on the pharo list it might make sense to keep the discussion in the pharo list ... First a bit of background. Symbolic versions were introduced because we were facing a situation where developers were breaking projects that were working fine in Pharo1.3 while porting them to Pharo1.4 and breaking Pharo1.4 behavior while fixing bugs in Pharo1.3 ... Metacello was pretty new then and an attempt was being made to have folks use Pharo1.4 while it was still in development and there were enough changes in Pharo1.4 that some code would break in Pharo1.4 while working in Pharo1.3 ... The real problem though was that project dependencies became difficult to manage in a number of different dimensions: - projects would change existing versions to work on the new platform version and break the old platform version - projects would create a new version that would run on both platforms, so dependent projects would to depend pon a new version - projects would create a new version that would run on only one platform, so dependent projects would have to depend upon 2 different versions based on platform version These types of things in isolation would be manageable, but the rate of change was high and changes propogated faster than configuration managers could keep up with. Oh and don't forget the projects where the maintainers were not even using Metacello at all and a third party developer had to translate the projects changes to a configuration to keep things working... Symbolic versions were introduced as a stopgap measure that made it possible for folks to easily declare which versions of the project were intended to be used on a particular platform. Dependent projects could depend upon the #stable version and the whole dependency management universe became simpler. Symbolic versions made it practical to port code to Pharo1.4 without impacting Pharo1.3 and so on. Which brings us to the present and a slightly different situation, but first let's step back a bit and look at what we have in Metacello today. In Metacello, a version is a label applied to a specific collection of mcz files. The collection of mcz files may be different depending upon which platform you happen to be loading the project into, but in the end, the same version on different platforms should give one the same set of functionality. Once a version has been released (indicated by a #release blessing) the contents of that collection of mcz files should never change ... If a change _is_ made, once should create a new version of the project to reflect that something has changed. In Metacello there are platform attributes (i.e., #'pharo1.x', #'pharo1.4.x', #'pharo1.4.1.x', #'pharo2.x', etc.). The platform attributes can provide very fine-grained control over which mcz files need to be loaded into a particular version of a platform, but the mechanism only works if the underlying platform is consistently naming versions ... In Metacello symbolic versions are simply a tagging mechanism. Versions and symbolic versions can be used interchangeably. Any name/platform/version combination can be created. We have been using the #stable convention for several years and it is definitely time to revisit it's use. However, we cannot drop the #stable convention without replacing it with another convention... otherwise we risk chaos, again:) In Metacello one can specify dependencies in terms of specific version numbers (tight coupling) or a tag (very loose coupling). Allowing one to specify dependencies based on version ranges would provide an intermediate coupling that avoids the tight coupling of specific version numbers while avoiding the ambiguity of a convention based on the name of a tag (symbolic version). If we introduce version range dependencies then individual projects can use a variety symbolic version names to properly represent their desired semantics. If we introduce version range dependencies then we must adopt a convention for how versions are named and that convention must be used pretty consistently within the community otherwise we may just have to return to the world of using #stable in self defense again ... As an alternative to a version numbering convention like Semantic Versioning[1], we could adopt a convention defining the semantics of a collection of symbolic version names .... I am a fan of Semantic Versioning, but it has some pretty specific rules that "must" be followed and all projects including the Smalltalk platforms (GemStone, Pharo and Squeak). Scan through the discussions surrounding Semantic Versions[2] to see what I'm talking about... In the grand scheme of things I don't want Metacello to be locked into any one convention. I am willing to have Metacello to support multiple conventions if called for. I have support for the Semantic Versioning version numbering scheme in Metacello, but other schemes can be added. I have anticipated the need to support version number ranges and have already built in a certain level of support and am willing to expand the capabilities in this area as needed ... Whatever the convention is, it has to be ADOPTED and SUPPORTED by the community. Metacello cannot enforce conventions, it can only support conventions ... So in closing, I would say that the future of #stable is in your hands... Dale [1] http://semver.org/ [2] https://github.com/mojombo/semver/issues

April 23, 2013

Re: [Pharo-project] User account on Jenkins

by Camillo Bruni

On 2013-04-23, at 20:15, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > You can register there by yourself, then there is a list of projects, pick the one you are interested in, Admins will then get a mail to add you you can do that here: https://ci.inria.fr/users/new > On Apr 23, 2013, at 7:45 PM, Guido Chari <charig(a)gmail.com> wrote: > >> Who can add me to Jenkins server so i can add a project to the infrastructure? >

April 23, 2013

Re: [Pharo-project] Your earlier problems accessing Monticello

by Sven Van Caekenberghe

OK, thx. On 23 Apr 2013, at 19:42, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > If a slice is proposed, you should "resolve" the case which flags the issue as Fix Review Needed > > :) > > Ben > > On Apr 23, 2013, at 7:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 23 Apr 2013, at 19:18, Guido Chari <charig(a)gmail.com> wrote: >> >>> Sorry for the delay, but yes i confirm this solves my issue. >> >> Thanks, that is good to know ! >> >>> What i see is that it is not yet integrated into 3.0 >> >> Yeah, it is ready for inclusion, maybe I gave it the wrong status. >> >> https://pharo.fogbugz.com/default.asp?10102 >> https://pharo.fogbugz.com/f/cases/10102/SocketStream-next-should-not-signal… >> >>> Cheers, >>> Guido. >>> >>> >>> 2013/3/23 Guido Chari <charig(a)gmail.com> >>> Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back home i will send you the confirmation. >>> >>> Thanks >>> >>> >>> 2013/3/23 Camillo Bruni <camillobruni(a)gmail.com> >>> Guido is right now in Lille :P so you have to wait for a week. >>> From what I recall it was exactly that bug we had over in Argentina :) >>> >>> On 2013-03-23, at 11:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Hi Guido, >>>> >>>> Some time ago you were unable to access Monticello from inside your particular network situation. >>>> >>>> http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-… >>>> >>>> We just were able to solve a similar case. >>>> >>>> http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Sma… >>>> >>>> Would it be possible to verify, first that your old problem still exists, and then try again with the following patch. >>>> >>>> SocketStream>>next: count >>>> "Read count elements and return them in a collection. >>>> If the receiver is #atEnd before count elements were read, return a smaller collection." >>>> >>>> ^ self nextInto: (self streamBuffer: count) >>>> >>>> That would be most helpful. >>>> >>>> Thx, >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>>> >>> >>> >>> >>> >> >> >

April 23, 2013

Re: [Pharo-project] User account on Jenkins

by Benjamin

You can register there by yourself, then there is a list of projects, pick the one you are interested in, Admins will then get a mail to add you Ben On Apr 23, 2013, at 7:45 PM, Guido Chari <charig(a)gmail.com> wrote: > Who can add me to Jenkins server so i can add a project to the infrastructure?

April 23, 2013

[Pharo-project] User account on Jenkins

by Guido Chari

Who can add me to Jenkins server so i can add a project to the infrastructure?

April 23, 2013

Re: [Pharo-project] Your earlier problems accessing Monticello

by Benjamin

If a slice is proposed, you should "resolve" the case which flags the issue as Fix Review Needed :) Ben On Apr 23, 2013, at 7:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 23 Apr 2013, at 19:18, Guido Chari <charig(a)gmail.com> wrote: > >> Sorry for the delay, but yes i confirm this solves my issue. > > Thanks, that is good to know ! > >> What i see is that it is not yet integrated into 3.0 > > Yeah, it is ready for inclusion, maybe I gave it the wrong status. > > https://pharo.fogbugz.com/default.asp?10102 > https://pharo.fogbugz.com/f/cases/10102/SocketStream-next-should-not-signal… > >> Cheers, >> Guido. >> >> >> 2013/3/23 Guido Chari <charig(a)gmail.com> >> Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back home i will send you the confirmation. >> >> Thanks >> >> >> 2013/3/23 Camillo Bruni <camillobruni(a)gmail.com> >> Guido is right now in Lille :P so you have to wait for a week. >> From what I recall it was exactly that bug we had over in Argentina :) >> >> On 2013-03-23, at 11:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Hi Guido, >>> >>> Some time ago you were unable to access Monticello from inside your particular network situation. >>> >>> http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-… >>> >>> We just were able to solve a similar case. >>> >>> http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Sma… >>> >>> Would it be possible to verify, first that your old problem still exists, and then try again with the following patch. >>> >>> SocketStream>>next: count >>> "Read count elements and return them in a collection. >>> If the receiver is #atEnd before count elements were read, return a smaller collection." >>> >>> ^ self nextInto: (self streamBuffer: count) >>> >>> That would be most helpful. >>> >>> Thx, >>> >>> Sven >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >>> >> >> >> >> > >

April 23, 2013

Re: [Pharo-project] Your earlier problems accessing Monticello

by Sven Van Caekenberghe

On 23 Apr 2013, at 19:18, Guido Chari <charig(a)gmail.com> wrote: > Sorry for the delay, but yes i confirm this solves my issue. Thanks, that is good to know ! > What i see is that it is not yet integrated into 3.0 Yeah, it is ready for inclusion, maybe I gave it the wrong status. https://pharo.fogbugz.com/default.asp?10102 https://pharo.fogbugz.com/f/cases/10102/SocketStream-next-should-not-signal… > Cheers, > Guido. > > > 2013/3/23 Guido Chari <charig(a)gmail.com> > Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back home i will send you the confirmation. > > Thanks > > > 2013/3/23 Camillo Bruni <camillobruni(a)gmail.com> > Guido is right now in Lille :P so you have to wait for a week. > From what I recall it was exactly that bug we had over in Argentina :) > > On 2013-03-23, at 11:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Guido, > > > > Some time ago you were unable to access Monticello from inside your particular network situation. > > > > http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-… > > > > We just were able to solve a similar case. > > > > http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Sma… > > > > Would it be possible to verify, first that your old problem still exists, and then try again with the following patch. > > > > SocketStream>>next: count > > "Read count elements and return them in a collection. > > If the receiver is #atEnd before count elements were read, return a smaller collection." > > > > ^ self nextInto: (self streamBuffer: count) > > > > That would be most helpful. > > > > Thx, > > > > Sven > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > > >

April 23, 2013

Re: [Pharo-project] (was: Moose-dev) #stable and Metacello

by Dale Henrichs

Diego, I realize that you may not like the name #stable, but the mechanism behind #stable is what you want. In current usage, the #stable version is the 'recommended version'..... Dale ----- Original Message ----- | From: "Diego Lont" <diego.lont(a)delware.nl> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Monday, April 22, 2013 5:39:19 AM | Subject: Re: [Pharo-project] (was: Moose-dev) #stable and Metacello | | Dale, Stef, | | I like to have "a recommended version" as default and not #'stable'. Because | I still want to recommend a version, even is this isn't stable. I can use | the blessings to mark it as "development" or "release". | | Using a 'recommended version' also makes it clear, that it depends on the | project (both using as used) wether is is wise to use this version or not. | For Moose 4.8 the 'recommended version' is the release candidate. | | Diego | | On Apr 18, 2013, at 9:55 PM, stephane ducasse wrote: | | > | > On Apr 18, 2013, at 6:29 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > | >> Stef, | >> | >> I think it is clear that #stable is not the right name, but I also think | >> it is better to have one "badly named," commonly used symbolic version | >> rather than a bunch of different names for the same thingâ¦ | > | > yes | > but this can be confusing. | >> Eventually we should change the convention, but I don't think we need to | >> hurry and do so:) | > | > first we need a tool to manage configuration for real. | > | > Stef | > | >> | >> Dale | >> | >> ----- Original Message ----- | >> | From: "stephane ducasse" <stephane.ducasse(a)free.fr> | >> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> | >> | Sent: Wednesday, April 17, 2013 10:04:50 PM | >> | Subject: [Moose-dev] Re: #stable and Metacello (was Re: | >> | ConfigurationOfGlamourSeaside) | >> | | >> | Dale | >> | | >> | I thought that stable should be called milestoneDevelopment. | >> | I will add a note to the metacello chapter and versionner will handle | >> | the | >> | patterns we see. | >> | | >> | Stef | >> | |

April 23, 2013