- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Text for 1.3 announcement?

by Marcus Denker

On Oct 27, 2011, at 9:33 PM, Bernhard Pieber wrote: >> > What I always wanted to ask and did not dare until now: What is the meaning of a 1.3 tag? It *could* mean the following: > a) Those are the issues that are show stoppers before a release can be done. Yes, this is the meaning before the release is released. When a release gets close, we start to tag just the very important issues. With 1.2, we really managed to release when there where no issues tagged 1.2. With 1.3, there was just not enough energy left to do that. (yet, the issues left after the release where not of the kind of real show-stoppers, either.) We start with the next release at the point when a version gets frozen. Because lots of "trivial" changes accumulate in the tracker that can not be added to the to-be-stable version, yet not integrating will lead to a *huge* and unmanagable backlog. Thus even though 1.3 with 315 updates was released this week, there is a 1.4 with already 215 updates... (Or another number: 1.4 is 412 closed issues... the overall open issues is 427) But 1.3 is special, as we should have release it 4 months ago. > b) Those are known issues in 1.3. After the release, the issues tagged 1.3 are bugs found in 1.3 that are deemed to be fixed in 1.3. two cases are possible: 1) The bug is really something that lots of people will see, so we should fix it. 2) The reporter of the bug provides a perfect fix that can be harvested for 1.3 without any more work *and* where is is clear that it will not lead to more problems later *and* where the issue is deemed important If a company says "we use this in production" (e.g. Netstyle/CMSbox provides fixes of that sort, as an example) > At first I thought it meant a). When you removed the "release candidate" status from the 1.3 download page I started to doubt this. ;-) > My next assumption was it meant b). Hence my humble suggestion. Now it seems it must mean something completely different. No, it means both, depending on if the release is done or not. In a perfect world, the release is done without any open issues (by moving them to the next release, mostly). We missed that window for 1.3, mostly because of the problem of having two images (full and core). With the maintainers of the non-core packages only looking at released pharo versions, this was doomed to fail (to release both core and full at the same time). With 1.4, this is fixed. There is only one image, so we will just release 1.4 when a) all tests are green b) there are no issues tagged 1.4 Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Clara Allende

I use a Set because I want to ensure there will not be duplicates. And because I doesn't make sense to me to have the same student twice, hehe :D So, if nobody uses sets nowadays, why have them? I guess this example is not a cool one, but maybe I really have a good reason to use aSet, and if then I want to use collect I have to be careful on what I expect it to return, and what it *actually* returns... I don't like it very much. But perhaps it's just me :) On 27 October 2011 16:54, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/10/27 Clara Allende <clari.allende(a)gmail.com>: > > Ok, but this means I have to worry of the receiver's class before I send > > collect:, so as I don't fuck it all up.... and I don't want to think > about > > that!!! See, if I want the collection of grades of the students, I would > > like to do this: > > grades > > ^self students collect: [.aStudent | aStudent grades] > > regardless of whatever is the class of students... This does the trick > for > > all the collections, except for Set. And I donÂ´t know if students is an > > instance of Set, and I really don't want to think if it is or not. If I > > don't want repeated students and I create my collection as an instance of > > Set, an i.e.; I want to calculate the average, then I'm screwed because > the > > collection I get from the collect: wasn't the want that I wanted. > > So, I have to know previously that my collection is an instance of Set, > or > > if it isn't, so as to know if I have to convert it first.... > > And if I use collect: as:, as you suggest, this means the collections are > no > > longer polymorphic for me :( > > Sorry, maybe I'm really stupid, but I don't know how that message solves > > best the problem than redefining collect: for Set. For the particular > case I > > don't want the repeated objects (which AFAIK is not so common) I could > send > > asSet. > > > > > Hi Clara. > IMHO, collect: [:e | e even] snippet makes not much sense, because Set > are Unordered. > Thus you won't be able to map the order of original Set with produced > collection... > So what will you do of this collection of true and false ? > > If you want to count the elements matching your predicate, just tell > your intentions so > (Set with: 1 with: 2 with:3 with:4 with:5) count:[:e | e even] > > Collecting grade is more interesting, but we can also answer to you by > another question: > Why the hell are your students stored in a Set? > Do you fear duplicates? or do you want to filter homozygotes out? > Why should the choice of collection class be neutral? > They all behave differently w.r.t. a message or another... > And to me, #collect: is polymorphically suspect, did you try > > 'bogito ergo sum' collect: [:e | e isVowel]. > #[ 0 1 2] collect: [:e | 1 - e ]. > > Nicolas > > > On 27 October 2011 11:05, Henrik Sperre Johansen > > <henrik.s.johansen(a)veloxit.no> wrote: > >> > >> On 27.10.2011 15:40, Clara Allende wrote: > >>> > >>> I know, but our students don't :) So they ran into problems because the > >>> message send didn't answer what they were specting.... because it > makes > >>> sense that if I want to transform the objects in my collection, I might > get > >>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm > just > >>> putting myself on student's shoes :P > >> > >> The consistency rule to remember for #collect:/#select:/#reject: is that > >> they will return a collection of the receiver's species. > >> #collect:as: was added as a general answer to the situation your > students > >> ran into :) > >> > >> set := Set withAll: #(1 2 3 4 5 6 7 8). > >> result := set collect: #even as: Bag. > >> > >> Cheers, > >> Henry > >> > >> > >> > > > > > > > > -- > > > > "Most good programmers do programming not because they expect to get paid > or > > get adulation by the public, but because it is fun to program." > > > > Linus Torvalds > > > > -- "*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*" Linus Torvalds

Oct. 27, 2011

Re: [Pharo-project] the moose call

by Alexandre Bergel

Hi! Happy to see that Moose has shined! Having a scientific (or even "half-scientific" with IEEE Software) would help (me at least) promote humane assessment. Side note: last week I started to teach Pharo and Moose to 14 students. I am quite happy to see them pharoing. Delightful sensation to see them browsing, coding and reading pharo by example. Alexandre On 27 Oct 2011, at 16:40, Tudor Girba wrote: > Hi, > > The other week I was at GOTO Aarhus. This was a great conference. And I got to talk about humane assessment with Moose. > > The presentation seemed to have captured some attention:http://martinfowler.com/bliki/gotoAarhus2011.html > > I think it's great that a project that was built mostly on the research side of the world can capture industry attention. This shows what can be achieved when innovation is married with long-term engineering effort. And it's not that we did not publish anything in the meantime either -- some more than 200 publications stand witness that science was not neglected. > > Even if I was the one presenting, the value of the work comes from many contributors. If we were to count, the effort around Moose totals more than 200 man-years of research and development. Moose has long passed the research prototype state. > > The philosophy behind Moose is to reinvent software and data analysis by making it accessible and tailorable. We lived this philosophy in one way or another, but it was never quite explicit. Now we have name for it: humane assessment. This is a new approach in the software engineering arena, and it can have a significant practical impact. > > So, here is my call. Invest in Moose. Let's change the status quo. Again from Smalltalk. > > How? > â¢ Just play with it. Take an afternoon and load your system into Moose, build a browser, play with a visualization. And get back to us with questions, suggestions, documentation or code. > â¢ Take an hour to read through humane-assessment.com. And get back to us. > â¢ Help us reshape the http://moosetechnology.org webpage. > â¢ Just get involved. There is always room for a contribution. You do not have to be a specialist. In fact, given that we aim to invent what does not yet exist, none of us are. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Nicolas Cellier

2011/10/27 Clara Allende <clari.allende(a)gmail.com>: > Ok, but this means I have to worry of the receiver's class before I send > collect:, so as I don't fuck it all up.... and I don't want to think about > that!!! See, if I want the collection of grades of the students, I would > like to do this: > grades > ^self students collect: [.aStudent | aStudent grades] > Â regardless of whatever is the class of students... This does the trick for > all the collections, except for Set. And I donÂ´t know if students is an > instance of Set, and I really don't want to think if it is or not. If I > don't want repeated students and I create my collection as an instance of > Set, an i.e.; I want to calculate the average, then I'm screwed because the > collection I get from the collect: wasn't the want that I wanted. > So, I have to know previously that my collection is an instance of Set, or > if it isn't, so as to know if I have to convert it first.... > And if I use collect: as:, as you suggest, this means the collections are no > longer polymorphic for me :( > Sorry, maybe I'm really stupid, but I don't know how that message solves > best the problem than redefining collect: for Set. For the particular case I > don't want the repeated objects (which AFAIK is not so common) I could send > asSet. > Hi Clara. IMHO, collect: [:e | e even] snippet makes not much sense, because Set are Unordered. Thus you won't be able to map the order of original Set with produced collection... So what will you do of this collection of true and false ? If you want to count the elements matching your predicate, just tell your intentions so (Set with: 1 with: 2 with:3 with:4 with:5) count:[:e | e even] Collecting grade is more interesting, but we can also answer to you by another question: Why the hell are your students stored in a Set? Do you fear duplicates? or do you want to filter homozygotes out? Why should the choice of collection class be neutral? They all behave differently w.r.t. a message or another... And to me, #collect: is polymorphically suspect, did you try 'bogito ergo sum' collect: [:e | e isVowel]. #[ 0 1 2] collect: [:e | 1 - e ]. Nicolas > On 27 October 2011 11:05, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> >> On 27.10.2011 15:40, Clara Allende wrote: >>> >>> I know, but our students don't :) So they ran into problems because the >>> message send didn't answer what they were specting.... Â because it makes >>> sense that if I want to transform the objects in my collection, I might get >>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm just >>> putting myself on student's shoes :P >> >> The consistency rule to remember for #collect:/#select:/#reject: is that >> they will return a collection of the receiver's species. >> #collect:as: was added as a general answer to the situation your students >> ran into :) >> >> set := Set withAll: #(1 2 3 4 5 6 7 8). >> result := set collect: #even as: Bag. >> >> Cheers, >> Henry >> >> >> > > > > -- > > "Most good programmers do programming not because they expect to get paid or > get adulation by the public, but because it is fun to program." > > Linus Torvalds >

Oct. 27, 2011

[Pharo-project] the moose call

by Tudor Girba

Hi, The other week I was at GOTO Aarhus. This was a great conference. And I got to talk about humane assessment with Moose. The presentation seemed to have captured some attention:http://martinfowler.com/bliki/gotoAarhus2011.html I think it's great that a project that was built mostly on the research side of the world can capture industry attention. This shows what can be achieved when innovation is married with long-term engineering effort. And it's not that we did not publish anything in the meantime either -- some more than 200 publications stand witness that science was not neglected. Even if I was the one presenting, the value of the work comes from many contributors. If we were to count, the effort around Moose totals more than 200 man-years of research and development. Moose has long passed the research prototype state. The philosophy behind Moose is to reinvent software and data analysis by making it accessible and tailorable. We lived this philosophy in one way or another, but it was never quite explicit. Now we have name for it: humane assessment. This is a new approach in the software engineering arena, and it can have a significant practical impact. So, here is my call. Invest in Moose. Let's change the status quo. Again from Smalltalk. How? â¢ Just play with it. Take an afternoon and load your system into Moose, build a browser, play with a visualization. And get back to us with questions, suggestions, documentation or code. â¢ Take an hour to read through humane-assessment.com. And get back to us. â¢ Help us reshape the http://moosetechnology.org webpage. â¢ Just get involved. There is always room for a contribution. You do not have to be a specialist. In fact, given that we aim to invent what does not yet exist, none of us are. Cheers, Doru -- www.tudorgirba.com "Don't give to get. Just give."

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Milan Mimica

On 27 October 2011 20:32, Ben Coman <btc(a)openinworld.com> wrote: > ** > Interval - result := self species new: self size. > > b. Interval diverges from the Blue Book, to follow the general collection > protocol > Interval >> species returns Array. -- Milan Mimica http://sparklet.sf.net

Oct. 27, 2011

Re: [Pharo-project] Text for 1.3 announcement?

by Bernhard Pieber

Hi Marcus, Thanks for replying to my suggestion. I am a relative newbie to Pharo, i.e. I did not use it much so far. Therefore, I am sure missing some obvious things. See further comments below. Cheers, Bernhard Am 26.10.2011 um 08:54 schrieb Marcus Denker: > On Oct 25, 2011, at 8:24 PM, Bernhard Pieber wrote: >> May I humbly suggest to at least add a link to known open issues for 1.3 right next to the release download? Then at least a newbie knows what to expect. > There is nothing different with 1.3 than with any other release we did. I am not sure I understand what you are trying to tell me. I hope you don't get the impression that I am criticizing you. That is the last thing I want, because you are one of those putting the most effort into Pharo! Thanks for that! > And the discussion was more about unknown bugs, not known ones. "You can not release because maybe I found a bug > yesterday that I have not yet reported". > > To make is clear: there are 7 (seven) open issues tagged for 1.3: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 > Most of which are not even show stoppers (are already a bug in 1.2, just cosmetic...) > None is important enough to have seen any work done since the last sprint. What I always wanted to ask and did not dare until now: What is the meaning of a 1.3 tag? It *could* mean the following: a) Those are the issues that are show stoppers before a release can be done. b) Those are known issues in 1.3. c) ... At first I thought it meant a). When you removed the "release candidate" status from the 1.3 download page I started to doubt this. ;-) My next assumption was it meant b). Hence my humble suggestion. Now it seems it must mean something completely different. > In a way of course many reports on the issue tracker are describing an improvement or problem that could > be related to 1.3: > > http://code.google.com/p/pharo/issues/list > > These are 421 issues.

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Clara Allende

Hi, On 27 October 2011 15:32, Ben Coman <btc(a)openinworld.com> wrote: > ** > Clara Allende wrote: > > Ok, but this means I have to worry of the receiver's class before I send > collect:, so as I don't fuck it all up.... and I don't want to think about > that!!! See, if I want the collection of grades of the students, I would > like to do this: > > grades > ^self students collect: [.aStudent | aStudent grades] > > regardless of whatever is the class of students... This does the trick > for all the collections, except for Set. And I donÂ´t know if students is an > instance of Set, and I really don't want to think if it is or not. If I > don't want repeated students and I create my collection as an instance of > Set, an i.e.; I want to calculate the average, then I'm screwed because the > collection I get from the collect: wasn't the want that I wanted. > So, I have to know previously that my collection is an instance of Set, or > if it isn't, so as to know if I have to convert it first.... > > And if I use collect: as:, as you suggest, this means the collections are > no longer polymorphic for me :( > Sorry, maybe I'm really stupid, but I don't know how that message solves > best the problem than redefining collect: for Set. For the particular case I > don't want the repeated objects (which AFAIK is not so common) I could send > asSet. > > On 27 October 2011 11:05, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> On 27.10.2011 15:40, Clara Allende wrote: >> >>> I know, but our students don't :) So they ran into problems because the >>> message send didn't answer what they were specting.... because it makes >>> sense that if I want to transform the objects in my collection, I might get >>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm just >>> putting myself on student's shoes :P >>> >> The consistency rule to remember for #collect:/#select:/#reject: is that >> they will return a collection of the receiver's species. >> #collect:as: was added as a general answer to the situation your students >> ran into :) >> >> set := Set withAll: #(1 2 3 4 5 6 7 8). >> result := set collect: #even as: Bag. >> >> Cheers, >> Henry >> > Applying the Principle Of Least Surprise (you may notice, a favourite > of mine) to newcomers would support what you're saying. However the flip > side of POLS is the behavior expected by old hands, existing code and code > from other Smalltalk systems. I imagine there are subtle dependencies > through the system for the convention from the Blue Book [1] which says: > > "collect: aBlock ... Answer a new collection like that of the receiver... > This phrase means that the new collection is an instance of the same class > as that of the receiver... The only exception is class Interval, which > returns a new OrderedCollection...[since] elements of an Interval are > created when the Interval is first created; it is not possible to store > elements into an existing Interval." > > I got interested in how this was achieved in Pharo and as an overview > pulled the following lines from all implementors of #collect: > > Collection - newCollection := self species new. > DependentsArray - selection := self species new: size. > Dictionary - newCollection := self species new. > OrderedCollection - newCollection := self species new: self size. > SequenceableCollection - newCollection := self species new: self size. > Set - newSet := Set new: self size. > SmallDictionary - newCollection := self species new. > WeakSet - newSet := self species new: self size. > Matrix - ^self class rows: nrows columns: ncols contents: > (contents collect: aBlock) > Interval - result := self species new: self size. > > Heap - ^self collect: aBlock as: Array > SortedCollection - newCollection := OrderedCollection new: self > size. > > PragmaCollector - ^self collected collect: aBlock -&- collected := > OrderedCollection new > MetacelloMemberListSpec - newCollection := OrderedCollection new. > RBProgramNode - ^aBlock value: self "Hacked to fit > collection protocols" > > ...from which it can be seen that: > a. Collection to Matrix holds to the Blue Book > b. Interval diverges from the Blue Book, to follow the general collection > protocol > c. Heap and SortedCollection diverge from the collection protocol > d. PragmaCollector to RBProgramNode don't descend from Collection, so need > to turn an individual object into a collection. > > Someone advise me better, but I'm not sure that polymorphism implies "exact > behaviour" between objects. Otherwise #collect:as: might be considered more > polymorphic as the result _will_ be more similar regardless of the receiving > object. > > I think of polymorphism in terms that I can't treat aSet in the same way I treat any other collection, at least when sending collect: > You mention sending #asSet "as needed" when you don't want repeated > items. Knowing when that was "needed" seems not much different from knowing > when #collect:as: was "needed", so I think this is one of those quirks that > all languages have. Its only a surprise until you are used to it and work > around it without noticing. > Yes, I know. Perhaps thinking of this as we do in maths this behavior makes sense, giving that there isn't the posibility of having repeated elements in sets... But because that concept doesn't exist :) And a mathematical function shouldn't give me repeated elements, because of its very definition... Here we don't have this concepts, and a message send to each element of a collection without repeated elements could return repeated objects, and in most cases I want this to be like that... So for particular cases in which I don't care, I could use asSet... And as you say, maybe this doesn't seem as different as sending asBag before sending collect:, but to me there is a huge difference: when I send collect:, I don't have to worry about the class of the collection. I care about the behavior of the result :) And in the particular case of Set, I think (maybe I'm wrong) that generally you wouldn't want to get aSet as a result of a collect: There may be other ways to do something. For the specific example you > suggested of averaging the grades, perhaps the following would be suitable. > ^(students inject: 0 into: [ :subTotal :eachStudent | subTotal + > (eachStudent grade) ] ) ) / (size students) > Yes, maybe that was not the coolest example... I know I can do that in several different ways, but if I want to use this one, I have to take all this into account... > > ----------8<------------ > [1] The Blue Book, 1983, section "Protocol for All Collection Classes", > p137, > http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf > -- "*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*" Linus Torvalds

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Ben Coman

Oct. 27, 2011

[Pharo-project] Porting to newer image

by Brian Brown

Hello all, It's been a while since I showed my digital face around here ;) I've got a number of Seaside based web applications that I would like to move into newer pharo images and take advantage of the VM advances that have been made. My stuff is all running under Seaside 2.8/Kom/Dynamic Bindings, etc.... which presents several problems when trying to load into a 1.3 Pharo Core. For example, Dynamic Bindings extends BlockContext, but now BlockClosure is the class that is receiving messages previously intended for BlockContext. I'm sure there will be many more issues like this, so I'm looking for advice on how to proceed. Is there a new Kom/DynamicBindings that works with the newer closure images? Have folks gone to a different web server, and if so, can it work with 2.8? If I can get this all running in a newer image, then my next step would be to port it Seaside 3, but I'm playing serious catchup in the incredible amount of changes since I was using Seaside/Pharo. Thanks for any advice you can give me! - Brian

Oct. 27, 2011