December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Set>>collectAll: aBlock

by StÃ©phane Ducasse

Over the years we made a little library with collection extensions We reevaluated when porting Moose to Pharo. May be this is the time for people to have a look Moose/CollectionExtensions or something like that We use it daily for moose. some of the problems we got where that Stream sucked.... could only work on array and strings. So we use Nile. Now we should evaluate. flatCollect: is a cool one. Normally we even have tests :) Stef On Dec 26, 2009, at 11:30 PM, Julian Fitzell wrote: > Fyi, PackageInfo (and thus base Pharo currently) defines > Collection>>gather: which has basically this behaviour (minus the nil > check). I had this marked as a method for discussion when going > through the VASt/Pharo collection protocols. > > I think #collectAll: is problematic as a selector because "All:" > suggests a collection passed as a parameter. > > Another possible pattern would be to model after :flatten in Ruby, > though it operates recursively, so it might not be the best name here. > Maybe #gather: is actually fine. > > Julian > > 2009/12/26 Bart Gauquie <bart.gauquie(a)gmail.com>: >> Dear all, >> Another one was: >> Set>>collectAll: aBlock >> | newSet | >> newSet := Set new: self size. >> array do: [:each | each ifNotNil: [newSet addAll: (aBlock value: each)]]. >> ^ newSet >> >> In analogy with addAll: aCollection. If useful, maybe we should provide a >> more general implementation for Collection instead of only Set I needed so >> far. >> Kind Regards, >> Bart >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you everywhere - >> Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The important thing >> is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - Albert >> Einstein >> Gravitation is not responsible for people falling in love. - Albert Einstein >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

Re: [Pharo-project] Collection>>select: aBlock ifNoneTakeAsDefault: aDefaultValue

by StÃ©phane Ducasse

I forgot open a bug tracker entry because we should not lose the suggestion. On Dec 26, 2009, at 11:44 PM, Julian Fitzell wrote: > Personally, I would rather see #ifEmpty: modified to return self in > the false case like #ifNil: does. The only in-image sender I can find > that even uses the return value seems to actually expect this > behaviour anyway. :) > > Then you could simply write: > > (aCollection select: [:ea | ...]) ifEmpty: [ ... ] > > Julian > > 2009/12/26 Bart Gauquie <bart.gauquie(a)gmail.com>: >> Dear all, >> >> While developing some code, I made following extension of the Collection >> protocol: >> select: aBlock ifNoneTakeAsDefault: aDefaultValue >> |result| >> result := self select: aBlock. >> (result isEmpty) >> ifTrue: [^self class with: aDefaultValue] >> ifFalse: [^result]. >> >> Maybe this could be added to the Pharo 1.1 Collection clazz? Or do we want >> to keep the interface of Collection as small as possible (which is also a >> good idea!). >> Kind Regards, >> Bart >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you everywhere - >> Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The important thing >> is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - Albert >> Einstein >> Gravitation is not responsible for people falling in love. - Albert Einstein >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

Re: [Pharo-project] Collection>>select: aBlock ifNoneTakeAsDefault: aDefaultValue

by StÃ©phane Ducasse

On Dec 26, 2009, at 11:44 PM, Julian Fitzell wrote: > Personally, I would rather see #ifEmpty: modified to return self in > the false case like #ifNil: does. The only in-image sender I can find > that even uses the return value seems to actually expect this > behaviour anyway. :) what is the behavior in other dialects ? :) Do you have some nice tests to cover the semantics? Did you do the change and see what break? Stef > > Then you could simply write: > > (aCollection select: [:ea | ...]) ifEmpty: [ ... ] > > Julian > > 2009/12/26 Bart Gauquie <bart.gauquie(a)gmail.com>: >> Dear all, >> >> While developing some code, I made following extension of the Collection >> protocol: >> select: aBlock ifNoneTakeAsDefault: aDefaultValue >> |result| >> result := self select: aBlock. >> (result isEmpty) >> ifTrue: [^self class with: aDefaultValue] >> ifFalse: [^result]. >> >> Maybe this could be added to the Pharo 1.1 Collection clazz? Or do we want >> to keep the interface of Collection as small as possible (which is also a >> good idea!). >> Kind Regards, >> Bart >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you everywhere - >> Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The important thing >> is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - Albert >> Einstein >> Gravitation is not responsible for people falling in love. - Albert Einstein >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

[Pharo-project] Happy new year in advance :)

by StÃ©phane Ducasse

Hi guys I just want to thank you for your positive energy. We had a dream with marcus about a better Smalltalk and this is happening. This is cool. It was not easy but the community is moving - more than we would ever thought after all these years trying to push with less success. Our vision for pharo is described on the pharo web site :) http://www.pharo-project.org/about Now my personal challenge/vision is the following: - I want Pharo to be a cool vehicule for innovation. - I want Pharo to be a solid vehicule for companies to succeed making a living with "Smalltalk" --- I put "" because I would like to avoid to get bound until the end of my life with just a Smalltalk :) but I would love to see companies starting in France around Pharo if you are interested contact me :) Let us really invent the future building on the past. If you want to help, check the mailing-list - you can see our open-process: open and pragmatic communication, discussing and learning are key for us -- sorry for the volume of mails. Spread the word: Pharo is what we will make it to be. Don't always trust what others write between the lines on us. ;-D Check by yourself (drink a beer with us before) and study history - all is in there. Stef

Dec. 27, 2009

Re: [Pharo-project] Set>>collectAll: aBlock

by Bart Gauquie

Hi, Gather seems excellent. Could not find it. Don't need the nil check. Thanks, Kind Regards, Bart On Sat, Dec 26, 2009 at 11:30 PM, Julian Fitzell <jfitzell(a)gmail.com> wrote: > Fyi, PackageInfo (and thus base Pharo currently) defines > Collection>>gather: which has basically this behaviour (minus the nil > check). I had this marked as a method for discussion when going > through the VASt/Pharo collection protocols. > > I think #collectAll: is problematic as a selector because "All:" > suggests a collection passed as a parameter. > > Another possible pattern would be to model after :flatten in Ruby, > though it operates recursively, so it might not be the best name here. > Maybe #gather: is actually fine. > > Julian > > 2009/12/26 Bart Gauquie <bart.gauquie(a)gmail.com>: > > Dear all, > > Another one was: > > Set>>collectAll: aBlock > > | newSet | > > newSet := Set new: self size. > > array do: [:each | each ifNotNil: [newSet addAll: (aBlock value: > each)]]. > > ^ newSet > > > > In analogy with addAll: aCollection. If useful, maybe we should provide a > > more general implementation for Collection instead of only Set I needed > so > > far. > > Kind Regards, > > Bart > > -- > > imagination is more important than knowledge - Albert Einstein > > Logic will get you from A to B. Imagination will take you everywhere - > > Albert Einstein > > Learn from yesterday, live for today, hope for tomorrow. The important > thing > > is not to stop questioning. - Albert Einstein > > The true sign of intelligence is not knowledge but imagination. - Albert > > Einstein > > Gravitation is not responsible for people falling in love. - Albert > Einstein > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Dec. 27, 2009

Re: [Pharo-project] Collection>>select: aBlock ifNoneTakeAsDefault: aDefaultValue

by Bart Gauquie

Hi, that seems like a very good suggestion. Is more general usable also. Regards, Bart On Sat, Dec 26, 2009 at 11:44 PM, Julian Fitzell <jfitzell(a)gmail.com> wrote: > Personally, I would rather see #ifEmpty: modified to return self in > the false case like #ifNil: does. The only in-image sender I can find > that even uses the return value seems to actually expect this > behaviour anyway. :) > > Then you could simply write: > > (aCollection select: [:ea | ...]) ifEmpty: [ ... ] > > Julian > > 2009/12/26 Bart Gauquie <bart.gauquie(a)gmail.com>: > > Dear all, > > > > While developing some code, I made following extension of the Collection > > protocol: > > select: aBlock ifNoneTakeAsDefault: aDefaultValue > > |result| > > result := self select: aBlock. > > (result isEmpty) > > ifTrue: [^self class with: aDefaultValue] > > ifFalse: [^result]. > > > > Maybe this could be added to the Pharo 1.1 Collection clazz? Or do we > want > > to keep the interface of Collection as small as possible (which is also a > > good idea!). > > Kind Regards, > > Bart > > -- > > imagination is more important than knowledge - Albert Einstein > > Logic will get you from A to B. Imagination will take you everywhere - > > Albert Einstein > > Learn from yesterday, live for today, hope for tomorrow. The important > thing > > is not to stop questioning. - Albert Einstein > > The true sign of intelligence is not knowledge but imagination. - Albert > > Einstein > > Gravitation is not responsible for people falling in love. - Albert > Einstein > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Dec. 27, 2009

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Adrian Kuhn

s/chrismas/christmas/

Dec. 27, 2009

[Pharo-project] akuhn/SUnit, chrisma edition :)

by Adrian Kuhn

Cleanup of SUnit is almost done. There are 179 tests with 75% coverage. Missing are tests for the new resource setup and tests for the new history storage. Changes - uses announcements - new class factory DSL - does not print 'unexpected/expected' when empty - factored all assertions into TAssertable - copied Niall's 3-valued setup logic for test resources - new expectation matcher DSL - replaced history dictionary with proper class - keeps history as TestResult in memory - stores history as array in compiled methods - unexpected/expected linked with stored history - migrates #expectedDefects to stored history on the fly - bug fix: 'run failures/errors' updates history - bug fix: coverage is now able to cover itself - added flags for compatibility and deprecation - removed *a lot of* code duplication I tried to run *all* tests in the latest image with akuhn/SUnit and it seems to run fine. There are 5 failures and 2 errors (both with akuhn/SUnit and pharo/SUnit). The new test suite starts faster. You click and tests start running immediately! Progress: numClasses: 13 -> 19 numKLOC: 965 -> 1209 numMethods: 224 -> 291 numStatements: 3086 -> 3903 numTestCases: 51 -> 177 numTestKLOC: 591 -> 1200 numTestStatements: 2175 -> 4663 testCoverage: 61% -> 75% eventually, a SUnit with more test than production code! Give it a try and lemme know whether it runs with your tests. All your tests should still run. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load cheers, AA

Dec. 27, 2009

Re: [Pharo-project] Nicolas tests for MultiByteFileStreamTest

by Nicolas Cellier

2009/12/26 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Nicolas: I was trying to integrate your changes from here: >> http://source.squeak.org/trunk/MultilingualTests-nice.4.mcz >> >> in the latest Pharo Core 11116Â and I have 2 failures and 2 errors. I just >> load the MultiByteFileStreamTest from that version. >> >> The question is, should I integrate some changes from MultiByteFileStream >> that are in squeak trunk so that the tests are green ? >> >> Thanks >> >> Mariano >> > > Hmm, don't remember... > BackChunk problem seems related to Damien changes (oldBack vs back) > ByteConverter problem seems connected to lazy initialization of latin1Map > 1) You must pick TextConverter>>initialize 2) one test uses #collect:as you must pick from trunk (a very nice message to have in Pharo too http://code.google.com/p/pharo/issues/detail?id=1698 ) 3) Pharo use Unicode for example for converting MacRoman, while Squeak use CP1252 (the windows extended latin1) Pharo changes are using more advanced Sophie refactorings, so don't touch without asking authority :) Is the test too simplistic ? Nonetheless, my expectations are broken... I expect that If I can decode a char, It will then be encoded the same. 4) for UTF16, I don't know what's going on... 5) lineEnding problem comes from wantsLineEndConversion inst var in MultiByteFileStream which is not initialized correctly In squeak it is initialized automatically when setting #lineEndConvention: in Pharo it requires an explicit #wantsLineEndConversion: send... either change the test or update Pharo (by the way, this was an enhancement from Keith findable in mantis) 6) for backChunk, ask Damien and Nile maintainers for advice. oldBack was replaced by back, and this is not clear to me if it should be so or not... I don't know if my TestCase is a valid specification for backCunk too. That's what I would expect... but anyway, backChunk sounds like shit-to-be-removed - it has no clear definition / TestCase - implementation is inefficient - it is clearly broken by MultiByteFileStream (the expected failure) unfortunately, it is used... Nicolas >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Dec. 26, 2009

Re: [Pharo-project] about DependencyBrowser

by Mariano Martinez Peck

On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Dec 26, 2009 at 10:06 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Hi Mariano! >> Nice to see you liked the Dependency Browser, let's clarify some >> points about it then, >> >> 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi HernÃ¡n: First let me say that this tool is really great and useful. >> It is >> > helping me a lot to build the metacello configurations. Now, I have a >> couple >> > of questions: >> > >> > 1) What do the colors mean ? (red, orange, etc). I read here >> > >> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php >> > but found nothing :( >> >> Colors were originally for idenfitying dependency types of external >> packages, but the package infos names aren't normalized, E.g. >> Normalized name = "Collections", Un-normalized name = >> "Collections-Strings", hence you will see a lot of false external >> packages colorized. >> >> Orange -> Dependecy of class reference of "external" package, or class >> reference in un-normalized package name. >> Brown -> Dependency of external package loose method, or loose method >> in un-normalized package name. >> Red -> Dependency of inheritance, or inheritance in un-normalized package >> name. >> Blue -> Dependency of a unsolved binding (like a class not present in >> the image). >> > > Thanks for the explanation. Now, as a good programmer you can reuse this > explanation and put it in the website :) > > >> >> > >> > 2) It would be EXCELLENT to be able to distinguish between PharoCore or >> > exernal packages. Suppose you are building a tool or whatever, it would >> be >> > useful to know if it all what it is required is already on a PharoCore >> or if >> > it is external (it will require to install also another packages). >> However, >> > I am not sure how implement this :( >> >> Yes, it would be cool for a new package system to implement a protocol >> for asking if a package is distributed originally in a release or not, >> like: >> >> aPackage isOfficial >> >> With so many forks around, I found difficult to find a single way to >> detect official packages installed in an image, and there should be an >> easier solution than scanning though all package dates. Maybe this has >> changed now? >> > > I really don't know. Maybe we can send a separate thread asking about this. > > > Hey! I have more questions :) > > 3) Please, take a Pharo dev image and you will see that the package OCForOB > for example, only depends on OmniBrowser and OB-Standard (using dependency > browser). However, that package also depends on OCompletion I think. Look > for example the method > > OBTextPanel >> createCompletionController (category ocforob) > > and you will see that it uses the class OController which is from the > package OCompletion....So, shouldn't be OCompletion a dependency ? > > 4) There are certain packages that are not listed in the dependency > browser. Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them > (maybe all) seem to have the pattern XXX-YYY. Do you know what can be the > problem here? Maybe something related to what you told me about normalized > and un-normalized? I would really like to see these packages also. > > Even more: AST-Core, Refactoring-Core and Refactoring-Spelling :( > 5) Why there are some packages that have their self as dependency ? For > example, take OmniBrowser and you will see that has a dependency OmniBrowser > also (as Inheritance and Reference). > > Thank you very much. > > Mariano > > > >> Kind regards, >> >> HernÃ¡n >> >> > >> > Thank you very much. >> > >> > Mariano >> > >> > >

Dec. 26, 2009