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

Re: [Pharo-project] ArchiveViewer rescue to Pharo

by StÃ©phane Ducasse

The idea under the little experiment was to see also how the metacello map for pharo can be updated to add package that we remove from the core :) It seems straighforward. Now this is more the infrastructure of the scriptloader that should be updated. Stef > Hi folks: Yesterday with Stef we rescued ArchiveViewer from Squeak 3.9. This little tool is integrated to the FileList browser and let you unzip and zip files and stuff like this. > > The only thing we have to change in the core is this: http://code.google.com/p/pharo/issues/detail?id=1701 > > To use it, you need PharoCore version 11118 which integrates that fix (you can take and old image and load that slice). > > and you must download the package ArchiveViewer from 'http://www.squeaksource.com/PharoMorphicExtras' > It will then be part of the pharo dev I guess. > > Example: > > 1) Open the File Browser > 2) Select a zip file and you will see the options "Open zip" and "extract all" > 3) After opening the zip you have a pop up with different options. > > I have a problem here that is using the ugly fonts instead of the StrikeFonts or even TrueType. Does someone know how can I fix this? > > The ArchiveViewer repository is global read/write so you can commit :) > > Thanks! > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

[Pharo-project] ArchiveViewer rescue to Pharo

by Mariano Martinez Peck

Hi folks: Yesterday with Stef we rescued ArchiveViewer from Squeak 3.9. This little tool is integrated to the FileList browser and let you unzip and zip files and stuff like this. The only thing we have to change in the core is this: http://code.google.com/p/pharo/issues/detail?id=1701 To use it, you need PharoCore version 11118 which integrates that fix (you can take and old image and load that slice). and you must download the package ArchiveViewer from ' http://www.squeaksource.com/PharoMorphicExtras' It will then be part of the pharo dev I guess. Example: 1) Open the File Browser 2) Select a zip file and you will see the options "Open zip" and "extract all" 3) After opening the zip you have a pop up with different options. I have a problem here that is using the ugly fonts instead of the StrikeFonts or even TrueType. Does someone know how can I fix this? The ArchiveViewer repository is global read/write so you can commit :) Thanks! Mariano

Dec. 28, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

we are in sync but this is always good to reassess the not so basics. > I counting, because i want smaller kernel (including image size) and > memory footprint. > And sure thing, i don't think that 1 class with tons of custom methods > better than 18 ones. It depends. classes are active vocabulary. >>>> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing >>>> NanoTraits there will be many other methods removed in Behavior and friends >>>> which are only the result of unnecessary complexity in Berned traits. It >>>> will be *significantly* simpler by any measures and unloadable. >> >> >> I'm really interested in a cleaner/smaller/less intrusive trait implementations. >> Contrary to what some not so clever guys thought it was always the case. ;D > > i hope i'm not in that list :) :) During sandwich lunch I will load it.... too curious :) Stef

Dec. 28, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by Igor Stasenko

2009/12/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >>> Package Â Â Â Â Â Â Â Â Classes Â Â Â Â Methods >>> Traits Â Â Â Â Â Â Â Â Â 59 Â Â Â Â Â Â Â 873 >>> Traits-Kernel Â Â Â Â Â 22 Â Â Â Â Â Â Â 343 >>> Traits-Kernel-Traits Â Â 17 Â Â Â Â Â Â Â 215 >>> Traits-Composition Â Â Â 7 Â Â Â Â Â Â Â 127 >>> NanoTraits-Kernel Â Â Â 9 Â Â Â Â Â Â Â 190 >>> NanoTraits-Tests Â Â Â Â 9 Â Â Â Â Â Â Â 122 >>> >> >> oh, that's quite a big difference. >> I am curious, is it because of simpler implementation or because of >> smaller feature set? > > First two remarks > Â Â Â Â -we should remove the old infrasturcture for requirements computation that has not > Â Â Â Â much with traits. > Â Â Â Â - second counting number of classes is not a good measure. > Â Â Â Â Do you think that this is better to have one Refactoring class or 18 Refactoring classes? > I counting, because i want smaller kernel (including image size) and memory footprint. And sure thing, i don't think that 1 class with tons of custom methods better than 18 ones. It depends. >>> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing >>> NanoTraits there will be many other methods removed in Behavior and friends >>> which are only the result of unnecessary complexity in Berned traits. It >>> will be *significantly* simpler by any measures and unloadable. > > This is probably true. > This is why I want to see the result of nano traits. > >>>> >>> (Installer repository: 'http://www.squeaksource.com/NanoTraits') >>> Â Â Â Â install: 'NanoTraits-Kernel'; >>> Â Â Â Â install: 'NanoTraits-Tests'. >>> >>> then install it using: >>> >>> Â Â Â Â NanoTrait install. >>> >>> (WARNING: Be prepared to throw the image away if something goes wrong) >>> >>>> I just have some concerns about common protocols, so developers could >>>> use traits in both pharo & squeak without need of refactoring. >>> >>> Fair enough. I don't think there's much difficulty as far as extending the >>> existing protocols go. We could even add compatibility traits >>> (TCompilingBehavior etc) that model the old structure if people want to add >>> extension methods to those. >>> >> >> And hey, my code is always MIT, so if the Pharo folks are interested, tell >>> them they're more than welcome to use and enhance it. The squeaksource >>> repository is world-writable. > > > I'm really interested in a cleaner/smaller/less intrusive trait implementations. > Contrary to what some not so clever guys thought it was always the case. ;D i hope i'm not in that list :) > Just no time right now. shit..... back project wirting > >> Aye, i CC this conversation to pharo list. >> Personally, amount of code is the major criteria for me to choose >> from. Especially for things in Kernel. >> And especially, if it doesn't having heavy tradeoffs. > > Igor please rephrase your thoughts! :) > Â Â Â Â amount of complexity !!! > Â Â Â Â not amount of code!!! > Â Â Â Â Come on number of classes is not a decent measure in presence of late binding! > hehe.. i hope that Andreas writing short methods, not a fat ones which trying to do everything at once :) I just pointing out, that it is much easier to study & comprehend a smaller code base. Less methods, less classes => less code to read & understand. I can't say anything about complexity of nano-traits comparing to Berne ones. Its just my guess, that less code is a sign of less complex model, or better code reuse, and so i welcome it :) > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 28, 2009

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

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 1:57 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > > Adrian: Can I still bother you with new requirements ? jajaja > > Your welcome :) > > > First of all, thank you very much for putting a context menu when you > press > > "right button" over a failing or error test. I really hate when it was > run > > again instead of opening a context menu. Now, I noticed that you open a > menu > > with the options "History" "Store..." and "Show progress". > > The history menu should *only* show up when you right-click in the colored > status bar, but not on failure and error list. Can you conform that? > I think that yes :) I attach an screenshot. Tell me is that's fine. In that screenshot you can see also the error tests that actually are expectedFailures and with the previous version of Sunit, the were green. > > > I really love one item more called "browse it" and that opens a System > > Browser with that class, with that test method selected. What do you > think? > > Awesome idea, I'll add that. > > Excellent :) > PS, I was also thinking about a 'step through test' option that open a > debugger > at the start of the test, rather than at the failing assertions. Will add > that > to the same menu... > > Yes, that's cool also. Many times I have to go to the assertion and then a restart in the debugger. Thank you very much. Mariano --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] about DependencyBrowser

by StÃ©phane Ducasse

mariano We are porting packageBlueprint from moose VW to moose pharo. Have a look at the ICSM paper 2007 on my web page because we really want this to work Stef On Dec 28, 2009, at 12:07 AM, Mariano Martinez Peck wrote: > I have another idea to implement :) > > It would be really cool not only to see the dependencies of a XXX package but also, who depends on that package. > > Suppose I am evaluating the package RoelTyper I would like to know which dependencies I have (what you have already implemented) but also "who depends on RoelTyper" > > Cheers > > Mariano > > On Sat, Dec 26, 2009 at 11:58 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > 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 > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] Issue with gofer/metacello

by StÃ©phane Ducasse

On Dec 27, 2009, at 11:38 PM, Dale Henrichs wrote: > Gofer-dkh.105 or whichever later version predates the move of the instance variable would get Metacello back into a bootable form for all versions of Pharo. > > I agree that for 1.0 a stable version of Gofer be chosen ... I'm trying to restrict the current Metacello changes to avoid significant API changes, but every time Gofer moves out from under me, I'm forced into making fundamental changes. Yes! I would like to have gofer stable in 1.0 and the same in 1.1 Sorry for the moving sands ;( Stef > Dale > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: > > | >> | | >> After proceeding these warnings, I have a rollback: MNU > | >> | | >> GoferPackageReference class>>name:repository: > | >> | | > > | >> | | > Can you evaluate > | >> | | > > | >> | | > [ Gofer gofer load ] > | >> | | > on: Error > | >> | | > do: [ :err | err retry ]. > | >> | | > Gofer gofer recompile. > | >> | | > > | >> | | > ? I don't have any senders of #name:repository: to > | >> | | > GoferPackageReference. > | > | We can remove the deprecated warnings, but that will not solve the > | real problem. Metacello is using some internal parts of Gofer that > | had > | to be changed to properly support fetch/push operations on multiple > | repositories. > | > | People have to stick with an old version of Gofer/Monticello. That's > | the same as with Pharo 1.1: Do not use the latest one. > | > | Lukas > | > | -- > | Lukas Renggli > | http://www.lukas-renggli.ch > | > | _______________________________________________ > | 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. 28, 2009

Re: [Pharo-project] When writing comment, do you use 1st person?

by StÃ©phane Ducasse

In SBE we pay extreme attention between message and methods. You send messages, execute a method. > Adrian Kuhn wrote: >> Martin McClure <martin@...> writes: >> >>> Actually, I usually do prefer to use first person when writing Smalltalk >>> comments. I find that anthropomorphizing objects helps to think in an >>> object-oriented way. >> >> Thanks everyone for all the answers so far! >> >> One of the things that keep confusing me is whether the I refers to the class, >> the object or (in a method comment) to the method or even the method >> activation? For example in Randal's example, there it is the the behavior >> *class* speaking in first person. Whereas to my understanding in >> *object*-oriented programming the objects should talk be first person (not the >> classes). >> >> Even more confusing, I have also seen comments where the it was the object or >> the methods. Or most confusing, an amalgamation of both, as eg in "I return my >> first element" where to be precise the method activation returns the first >> element of the object. So shouldn't it either be "(When activiated) Returns my >> first element" or "I return the first element of my reciever"? >> >> This is not an academic example. When I started to write comments for SUnit, I >> got actually confused. When writing (instance/class) methods comments, to whom >> does the "I" refer to? >> > > Good points. Existing comments are not always consistent. > > In my opinion, "I" should always refer to an object. Which object? > "Self" within the current context. In an instance-side method comment, > "I" is the receiver of the message. In a class-side method comment, "I" > is the class. In a class comment, it's a little less clear, but probably > "I" should be the class in that case. > > I'd probably write the above example imperatively, something like > "Answer my first element". > > In Smalltalk, I also tend to prefer "answer" over "return", and I tend > to talk about "messages" instead of "methods" unless explicitly dealing > with method objects. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

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

by StÃ©phane Ducasse

Adrian I would love to see a videos of the new features you did :) Stef (back writing and closing mail) On Dec 28, 2009, at 1:57 AM, Adrian Kuhn wrote: > Mariano Martinez Peck <marianopeck@...> writes: > >> Adrian: Can I still bother you with new requirements ? jajaja > > Your welcome :) > >> First of all, thank you very much for putting a context menu when you press >> "right button" over a failing or error test. I really hate when it was run >> again instead of opening a context menu. Now, I noticed that you open a menu >> with the options "History" "Store..." and "Show progress". > > The history menu should *only* show up when you right-click in the colored > status bar, but not on failure and error list. Can you conform that? > >> I really love one item more called "browse it" and that opens a System >> Browser with that class, with that test method selected. What do you think? > > Awesome idea, I'll add that. > > PS, I was also thinking about a 'step through test' option that open a debugger > at the start of the test, rather than at the failing assertions. Will add that > to the same menu... > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

>> >> >> Package Classes Methods >> Traits 59 873 >> Traits-Kernel 22 343 >> Traits-Kernel-Traits 17 215 >> Traits-Composition 7 127 >> NanoTraits-Kernel 9 190 >> NanoTraits-Tests 9 122 >> > > oh, that's quite a big difference. > I am curious, is it because of simpler implementation or because of > smaller feature set? First two remarks -we should remove the old infrasturcture for requirements computation that has not much with traits. - second counting number of classes is not a good measure. Do you think that this is better to have one Refactoring class or 18 Refactoring classes? >> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing >> NanoTraits there will be many other methods removed in Behavior and friends >> which are only the result of unnecessary complexity in Berned traits. It >> will be *significantly* simpler by any measures and unloadable. This is probably true. This is why I want to see the result of nano traits. >>> >> (Installer repository: 'http://www.squeaksource.com/NanoTraits') >> install: 'NanoTraits-Kernel'; >> install: 'NanoTraits-Tests'. >> >> then install it using: >> >> NanoTrait install. >> >> (WARNING: Be prepared to throw the image away if something goes wrong) >> >>> I just have some concerns about common protocols, so developers could >>> use traits in both pharo & squeak without need of refactoring. >> >> Fair enough. I don't think there's much difficulty as far as extending the >> existing protocols go. We could even add compatibility traits >> (TCompilingBehavior etc) that model the old structure if people want to add >> extension methods to those. >> > > And hey, my code is always MIT, so if the Pharo folks are interested, tell >> them they're more than welcome to use and enhance it. The squeaksource >> repository is world-writable. I'm really interested in a cleaner/smaller/less intrusive trait implementations. Contrary to what some not so clever guys thought it was always the case. ;D Just no time right now. shit..... back project wirting > Aye, i CC this conversation to pharo list. > Personally, amount of code is the major criteria for me to choose > from. Especially for things in Kernel. > And especially, if it doesn't having heavy tradeoffs. Igor please rephrase your thoughts! :) amount of complexity !!! not amount of code!!! Come on number of classes is not a decent measure in presence of late binding! Stef

Dec. 28, 2009