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

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

by Julian Fitzell

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 >

Dec. 26, 2009

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

by Julian Fitzell

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 >

Dec. 26, 2009

[Pharo-project] Simple question about NewInspector

by Mariano Martinez Peck

Hi Frederic. I am trying to see if it make sense to create a metacello configuration for NewInspector. The only external (not in PharoCore) dependency I saw using the DependencyBrowser is RoelTyper, which is used in the class NICompiledMethodNode >> configuration you use the class TypeCollector which is from RoelTyper. So, the question is, is this dependency correct? I ask because I took a PharoCore image, load NewINspector WITHOUT RoelTyper and it "seemed" to work. Thank you very much. Mariano

Dec. 26, 2009

Re: [Pharo-project] about DependencyBrowser

by Mariano Martinez Peck

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

[Pharo-project] Set>>collectAll: aBlock

by Bart Gauquie

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

Dec. 26, 2009

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

by Bart Gauquie

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

Dec. 26, 2009

Re: [Pharo-project] OBDependencyWalker for Pharo

by HernÃ¡n Morales Durand

Hi Mariano, To install the Dependency Browser in the 1.0 dev image, please evaluate: Gofer new squeaksource: 'DependencyWalker'; package: 'DependencyWalker'; package: 'OBDependencyWalker'; package: 'DWTraitsFix'; load; recompile. and then open from the world menu, Tools -> More -> Dependency Browser Cheers, HernÃ¡n 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > HernÃ¡n: I would like to use this tools to detect dependencies between > packages and with that write the metacello configurations for Pharo. > > Do you know how can I manage to install it in the latests 1.0 dev image? > > thanks > > mariano > > On Sun, Aug 16, 2009 at 10:04 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> I imagine that david did that because he could not touch the code. >> I hope that with the new OB release things will get clarified and >> better. >> >> Stef >> >> On Aug 15, 2009, at 3:11 PM, HernÃ¡n Morales Durand wrote: >> >> > Hi Cesar, >> > Â Please update to the latest version of the DependencyBrowser. I was >> > using a ClassSortFilter for filtering packages (which is wrong), and >> > there are two different implementations of this message from David and >> > Lukas: >> > >> > OBClassSortFilter>>nodesFrom:forNode: >> > >> > The one from David was preventing to send #theClass >> > >> > Â Â Â classNodes := nodes select: [ :ea | ea respondsTo: #theClass ]. >> > >> > but I don't know which one is the right one, the implementation from >> > Lukas is newer and usually his releases works pretty fine. Recently >> > Colin posted another OB version, I hope the work done in OB gets a >> > better coordination, it would be such a sad thing to have good >> > incompatible versions of the framework. >> > Cheers, >> > >> > HernÃ¡n >> > >> > 2009/8/14 Â <csrabak(a)bol.com.br>: >> >> HernÃ¡n, >> >> >> >> I also don't have the expertise to debug it, but could you get more >> >> info if >> >> you put a #theClass method in OBClassSort with a sefl halt on it? >> >> >> >> It will avoid the sending of messages upstream in the "food chain"... >> >> >> >> Em 14/08/2009 09:05, HernÃ¡n Morales Durand < >> >> hernan.morales(a)gmail.com > >> >> escreveu: >> >> >> >> Ok, I found this could be related with an OB installation using this >> >> script: http://code.google.com/p/pharo/wiki/ImageBuildScripts >> >> I've loaded "AST", "Refactoring", "OmniBrowser" and "Tools". Then >> >> loaded the DependencyBrowser, selected a package and gotcha, the >> >> #theClass MNU was raised. >> >> However I wasn't able to debug it (please see the attachement), the >> >> stack isn't displayed in the debugger and some operations (Out, Over, >> >> etc) hang the image and I have interrupt with Alt+. >> >> Cheers >> >> >> >> HernÃ¡n >> >> >> >> 2009/8/14 StÃ©phane Ducasse : >> >>> apparently there was a change in OB and it would be good to >> >>> understand >> >>> because >> >>> we have some open issues that are related to that. >> >>> >> >>> Stef >> >>> >> >>> >> >>>> Oh, that page was obsolete sorry about that, working with PHP >> >>>> pages is >> >>> &g t; so... fuckin horrible! >> >>>> However that's not the issue here. I need to do a little research >> >>>> to >> >>>> see why the Dependency Browser breaks with mysterious OB stuff? I >> >>>> will >> >>>> update the repository as soon as I find the cause. >> >>>> Thanks for reporting >> >>>> >> >>>> HernÃ¡n >> >>>> >> >>>> 2009/8/13 Â : >> >>>>> Em 13/08/2009 21:34, HernÃ¡n Morales Durand >> >>>>> escreveu: >> >>>>> >> >>>>>> Hi csrabak, >> >>>>>> Thanks for the feedback. I wonder how you've installed the DW? >> >>>>> >> >>>>> I followed >> >>>>> >> >>>>> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-fr.php >> >>>>> Â (Overture Pharo) tab (but I bet you _knew_ that ;-)! >> >>>>> >> >>>>> Notice I installed on Pharo1.0beta image. . . and use only >> >>>>> "default" settings. . . >> >>>>> >> >>>>>> Anyone else experi mented this trouble? >> >>>>> >> >>>>> This is something I cannot answer :-( >> >>>>> >> >>>>>> That MNU is fine, the problem is that message should never be >> >>>>>> sent >> >>>>>> to >> >>>>>> an OBInheritanceDependencyNode. Please note the two leftmost >> >>>>>> panes >> >>>>>> (columns) in the DependencyBrowser contains system categories or >> >>>>>> "packages", not classes. >> >>>>>> So I've tried to reproduce your problem with the three OB >> >>>>>> installations from Pharo: >> >>>>>> >> >>>>>> ScriptLoader loadOB. >> >>>>>> ScriptLoader loadSuperOB. >> >>>>>> ScriptLoader loadOBAlpha. >> >>>>>> >> >>>>>> selected every system category, gathering all dependencies in >> >>>>>> your >> >>>>>> Pharo version, and still cannot find that MNU. Can you provide me >> >>>>>> further details about it? >> >>>>>> >> >>>>>> Are you using latest OmniBrowser? >> >>>>> >> >>>>> I do supose so as at the time I wrote the e-mail I had the image >> >>>>> uptodate (#10413). >> >>>>> >> >>>>>> Have you installed the DependencyBrowser with the script of my >> >>>>>> previous e-mail? >> >>>>> >> >>>>> I ran the script of your page. >> >>>>> >> >>>>>> This is happening when you select a particular package? >> >>>>> >> >>>>> Any package will do, but to stick to a simple one I click in >> >>>>> "OmniBrowser" and kaboom! >> >>>>> >> >>>>>> Have you installed additional OB packages? >> >>>>> >> >>>>> I lost the control of what is considered "aditional" wrt to OB. So >> >>>>> I attach the browser of the image I'm testing it: >> >>>>> >> >>>>> HTH >> >>>>> >> >>>>> -- >> >>>>> Cesar Rabak >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > 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

[Pharo-project] about DependencyBrowser

by Mariano Martinez Peck

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 :( 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 :( Thank you very much. Mariano

Dec. 26, 2009

Re: [Pharo-project] OBDependencyWalker for Pharo

by Mariano Martinez Peck

HernÃ¡n: I would like to use this tools to detect dependencies between packages and with that write the metacello configurations for Pharo. Do you know how can I manage to install it in the latests 1.0 dev image? thanks mariano On Sun, Aug 16, 2009 at 10:04 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I imagine that david did that because he could not touch the code. > I hope that with the new OB release things will get clarified and > better. > > Stef > > On Aug 15, 2009, at 3:11 PM, HernÃ¡n Morales Durand wrote: > > > Hi Cesar, > > Please update to the latest version of the DependencyBrowser. I was > > using a ClassSortFilter for filtering packages (which is wrong), and > > there are two different implementations of this message from David and > > Lukas: > > > > OBClassSortFilter>>nodesFrom:forNode: > > > > The one from David was preventing to send #theClass > > > > classNodes := nodes select: [ :ea | ea respondsTo: #theClass ]. > > > > but I don't know which one is the right one, the implementation from > > Lukas is newer and usually his releases works pretty fine. Recently > > Colin posted another OB version, I hope the work done in OB gets a > > better coordination, it would be such a sad thing to have good > > incompatible versions of the framework. > > Cheers, > > > > HernÃ¡n > > > > 2009/8/14 <csrabak(a)bol.com.br>: > >> HernÃ¡n, > >> > >> I also don't have the expertise to debug it, but could you get more > >> info if > >> you put a #theClass method in OBClassSort with a sefl halt on it? > >> > >> It will avoid the sending of messages upstream in the "food chain"... > >> > >> Em 14/08/2009 09:05, HernÃ¡n Morales Durand < > >> hernan.morales(a)gmail.com > > >> escreveu: > >> > >> Ok, I found this could be related with an OB installation using this > >> script: http://code.google.com/p/pharo/wiki/ImageBuildScripts > >> I've loaded "AST", "Refactoring", "OmniBrowser" and "Tools". Then > >> loaded the DependencyBrowser, selected a package and gotcha, the > >> #theClass MNU was raised. > >> However I wasn't able to debug it (please see the attachement), the > >> stack isn't displayed in the debugger and some operations (Out, Over, > >> etc) hang the image and I have interrupt with Alt+. > >> Cheers > >> > >> HernÃ¡n > >> > >> 2009/8/14 StÃ©phane Ducasse : > >>> apparently there was a change in OB and it would be good to > >>> understand > >>> because > >>> we have some open issues that are related to that. > >>> > >>> Stef > >>> > >>> > >>>> Oh, that page was obsolete sorry about that, working with PHP > >>>> pages is > >>> &g t; so... fuckin horrible! > >>>> However that's not the issue here. I need to do a little research > >>>> to > >>>> see why the Dependency Browser breaks with mysterious OB stuff? I > >>>> will > >>>> update the repository as soon as I find the cause. > >>>> Thanks for reporting > >>>> > >>>> HernÃ¡n > >>>> > >>>> 2009/8/13 : > >>>>> Em 13/08/2009 21:34, HernÃ¡n Morales Durand > >>>>> escreveu: > >>>>> > >>>>>> Hi csrabak, > >>>>>> Thanks for the feedback. I wonder how you've installed the DW? > >>>>> > >>>>> I followed > >>>>> > http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-fr.php > >>>>> (Overture Pharo) tab (but I bet you _knew_ that ;-)! > >>>>> > >>>>> Notice I installed on Pharo1.0beta image. . . and use only > >>>>> "default" settings. . . > >>>>> > >>>>>> Anyone else experi mented this trouble? > >>>>> > >>>>> This is something I cannot answer :-( > >>>>> > >>>>>> That MNU is fine, the problem is that message should never be > >>>>>> sent > >>>>>> to > >>>>>> an OBInheritanceDependencyNode. Please note the two leftmost > >>>>>> panes > >>>>>> (columns) in the DependencyBrowser contains system categories or > >>>>>> "packages", not classes. > >>>>>> So I've tried to reproduce your problem with the three OB > >>>>>> installations from Pharo: > >>>>>> > >>>>>> ScriptLoader loadOB. > >>>>>> ScriptLoader loadSuperOB. > >>>>>> ScriptLoader loadOBAlpha. > >>>>>> > >>>>>> selected every system category, gathering all dependencies in > >>>>>> your > >>>>>> Pharo version, and still cannot find that MNU. Can you provide me > >>>>>> further details about it? > >>>>>> > >>>>>> Are you using latest OmniBrowser? > >>>>> > >>>>> I do supose so as at the time I wrote the e-mail I had the image > >>>>> uptodate (#10413). > >>>>> > >>>>>> Have you installed the DependencyBrowser with the script of my > >>>>>> previous e-mail? > >>>>> > >>>>> I ran the script of your page. > >>>>> > >>>>>> This is happening when you select a particular package? > >>>>> > >>>>> Any package will do, but to stick to a simple one I click in > >>>>> "OmniBrowser" and kaboom! > >>>>> > >>>>>> Have you installed additional OB packages? > >>>>> > >>>>> I lost the control of what is considered "aditional" wrt to OB. So > >>>>> I attach the browser of the image I'm testing it: > >>>>> > >>>>> HTH > >>>>> > >>>>> -- > >>>>> Cesar Rabak > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > 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. 26, 2009

Re: [Pharo-project] [squeak-dev] Re: freetype plugin on os-x squeak v5.0 -> goes to 5.1

by David T. Lewis

On Fri, Dec 25, 2009 at 08:23:53PM -0800, John M McIntosh wrote: > Ok after a day of slugging thru bits between way too much turkey I reworked the freetype plugin code so that it now works with 64bit VMs running 32bit images. > Excellent! > Now in order to make this all work I had to recompile the Squeak VM so that it exposes the object memory base memory address so the plugin can find it. > So you'll find 5.1 at... > > http://smalltalkconsulting.com/squeak.html Please feel free to add this to SqS/VMMaker, and bump VMMaker class>>versionString up by one minor number. Or if you prefer, I can add it if you point me to a change set. Thanks, Dave

Dec. 26, 2009