- Pharo-dev - lists.pharo.org

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

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