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

[Pharo-project] [ANN] Pharo VM for Ubuntu moved!
by Damien Cassou April 24, 2013

April 24, 2013

After a request from Esteban, I changed the Pharo VM PPA location from ppa:cassou/pharo to ppa:pharo/stable. Please issue the following commands to update your system: $ sudo rm -f /etc/apt/sources.list.d/cassou-emacs-quantal.list $ sudo add-apt-repository ppa:pharo/stable $ sudo apt-get update Sorry for the additional effort -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

1 0

[Pharo-project] Metacello Preview
by DeNigris Sean April 24, 2013

April 24, 2013

[cross posted to pharo-project and squeak-dev] Dale has done some really cool work on Metacello! From the original announcement at http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-td4642064.html : > The Metacello Preview release provides the following features: > > - Metacello Scripting API (user guide[1] and reference[2]) > - Metacello-Base package for inclusion in Squeak/Pharo base images > - support for git and GitHub (filetree:// and github:// repository loaded) In typical Dale fashion, he wants to provide our community with as much value as possible, so he's been tentative to release his "preview" version until he gets feedback from users and can tailor it to our real-world needs. I feel, after checking with Dale, that integrating the preview into Pharo and Squeak trunk now will provide a balance between exposure and malleability, to make sure we have an API we'll all love by the next respective releases. Cheers, Sean

3 2

[Pharo-project] Processes, what are they doing?
by Igor Stasenko April 24, 2013

April 24, 2013

Have you ever seen the list of processes running under your OS? There's many, isn't? The operating systems may be different, but i'd like to tell, what is common between all of them: - by looking at list of processes you have no idea what each of them there for, nor what are they doing. For instance, my home windows machine has strange peaks of disk activity (when it supposed to be idle, since it is not touched more than a hour)... now this is annoying that i cannot ask system in easy way, what is going on and why such heavy disk activity is needed, and disable such "very important feature".. Today's systems grown too large and too clever, where user more and more feels like a passenger (which request to stop the train can be silently ignored), rather than driver of the train who can stop it at any moment. Since i cannot tell, what each process doing on my machine.. i cannot control them. There's of course a solution: i should spend hours with google , read docs & manuals and in general, look for anywhere else, rather than simply ask a process: what are you doing, what is your responsibility and who runs you and why. Besides, if i cannot ask the process, my study of a system is more or less just a waste of time, because even if i learn everything, tomorrow it will be different OS version or different OS, where everything will be completely different, and there we starting over again: having a list of processes and no clue which is responsible for what and do you need it or not. Sure thing, i am not proposing to change the world and fix today's operating systems, but what i thought that at least in Pharo we have a good opportunity to fix that. I think it would be beneficial to establish a quality standard (or at least make an attempt to move closer to it): - each running process should have a description what its purpose and who/what running it, as well as how to terminate it in non-abrupt way. In practice it means that one should not write: [ ... ] fork but [ ... ] forkWithDescription: 'i doing this that and there' or even: [ ... ] forkWithDescription: 'i doing this that and there' toTerminateDo: [.. block for graciously terminating this process regardless in which state it currently is ] So, my question are you with me or not? :) And how far? 0 - keep things as they are ... 1 - deprecate all protocols which allow anonymous process creation, and force developers to always put a description for every #fork in their code. (or simply refuse to #resume the process unless its description is not nil ;) There is already field in Process - name. But it is not enforced by system that it should be never nil. I am not sure if we need both name and description or we need just one field (which will serve for both). What i am sure about is that anonymous processes are BAD. -- Best regards, Igor Stasenko.

4 3

[Pharo-project] NativeBoost label call
by Guido Chari April 23, 2013

April 23, 2013

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.

2 1

[Pharo-project] the future of #stable in Metacello
by Dale Henrichs April 23, 2013

April 23, 2013

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

1 0

[Pharo-project] User account on Jenkins
by Guido Chari April 23, 2013

April 23, 2013

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

3 2

[Pharo-project] Your earlier problems accessing Monticello
by Sven Van Caekenberghe April 23, 2013

April 23, 2013

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

4 7

Re: [Pharo-project] (was: Moose-dev) #stable and Metacello
by Diego Lont April 23, 2013

April 23, 2013

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

2 1

[Pharo-project] [update 3.0] #30056
by Esteban Lorenzano April 23, 2013

April 23, 2013

30056 ----- 10363 Boolean clean up https://pharo.fogbugz.com/f/cases/10363 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/NativeBoost-Core-EstebanLore…

1 0

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

April 23, 2013

1 0