July 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.2] #12046

by StÃ©phane Ducasse

12046 ----- - Issue 2665: Fixed broken string in selection evaluation. - Add System-Installers as package (empty but code is coming) Stef

July 11, 2010

Re: [Pharo-project] Sequential Dictionary

by StÃ©phane Ducasse

Hi Joel On Jul 11, 2010, at 5:00 PM, Joel Turnbull wrote: > > What is the group's recommendation for creating a sequential Dictionary? i.e. A Dictionary who's associations are ordered. look at the one in Seaside :) Lukas told me that they implemented one where the order of traversal using do: is the order of key/val addition. > Is there any precedent for this? Or does it sound like I'm barking up the wrong tree? > > In my model, I've subclassed Dictionary into QuantityDictionary to store line items, where the key is the item and the value is the quantity of the item. It validates that the value is always a numeric, removes the association when the value goes below zero, and other stuff specific to my application. > > Now I'm finding it makes sense to be able to order these associations. Imagine a recipe ingredient list, where you add and edit quantities of ingredients, and you want to put the ingredients that you use earliest in the recipe at the top of the ingredient list. > > Before I put any more work into it, I just wanted to make sure that a sequential dictionary makes sense, and get your ideas on how to generally go about implementing that? > > Thanks. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 11, 2010

[Pharo-project] Sequential Dictionary

by Joel Turnbull

What is the group's recommendation for creating a sequential Dictionary? i.e. A Dictionary who's associations are ordered. Is there any precedent for this? Or does it sound like I'm barking up the wrong tree? In my model, I've subclassed Dictionary into QuantityDictionary to store line items, where the key is the item and the value is the quantity of the item. It validates that the value is always a numeric, removes the association when the value goes below zero, and other stuff specific to my application. Now I'm finding it makes sense to be able to order these associations. Imagine a recipe ingredient list, where you add and edit quantities of ingredients, and you want to put the ingredients that you use earliest in the recipe at the top of the ingredient list. Before I put any more work into it, I just wanted to make sure that a sequential dictionary makes sense, and get your ideas on how to generally go about implementing that? Thanks.

July 11, 2010

Re: [Pharo-project] Issue 2658 - Integration of WebClient on Pharo 1.2

by GermÃ¡n Arduino

Sorry the late response Mariano, but I'm doing a gazillion of different things :( I think that the idea is as on squeak, retain an extremely simple HTTPSocket to basic operations (as keep MC working) and have a well done client with all the functionalities.) GermÃ¡n. 2010/7/8 Mariano Martinez Peck <marianopeck(a)gmail.com> > I thought I was the only idiot, but it seems I am not. So, I am not shame > to asking... > > What WebClient really is ? Http client ? Several times people say it > should replace something in pharo...what exactly should be replaced in Pharo > by this WebClient ? > > Why it needs to be in PharoCore and not as an external package? are there > (or will be) users of it inside the core? > > Thanks and sorry for the ignorance. > > Cheers > > mariano > > 2010/7/8 GermÃ¡n Arduino <garduino(a)gmail.com> > > >> >> 2010/7/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> I will include the packages in the release. >>> >>> >>> I loaded all the packages available >>> WebClientServerTest>>testServerDestroy is red >>> >>> Now we will need to pay attention that we should have a look >>> - WebClient-Pharo and fix that >>> - pay attention to push back fixes to the package for squeakers >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> The ConfigurationOf is outdated. >> >> The packages to load are the latest of core-tests-help and http. >> >> The pharo package is not longer necesary. >> >> I did these steps yesterday and all tests are green (In Linux). >> >> Cheers. >> >> >> >> >> _______________________________________________ >> 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 >

July 11, 2010

[Pharo-project] removing MethodTempsNode?

by StÃ©phane Ducasse

It was only used by syntaxMorph :) Stef

July 11, 2010

[Pharo-project] PSMCOrganizationChangeWrapper???

by StÃ©phane Ducasse

Apparently this class is totally empty so I do not really understand its purpose. Stef

July 11, 2010

Re: [Pharo-project] Pragmas/Annotations for classes

by StÃ©phane Ducasse

ok I see I was thinking using methods (instance or class) with pragmas. Stf

July 11, 2010

Re: [Pharo-project] Pragmas/Annotations for classes

by Guillermo Polito

Haha yeah :). I only was telling that if we chose a non-pragma way to add metadata to a class, we cannot be benefited (simply) with a pragma collector, hehe. But that's because I didn't understand what you meant about using class methods to add metadata. On Sat, Jul 10, 2010 at 4:46 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guille > > > > I didn't understand if you want to replace the class pragmas with a > simple class method for adding metadata, or to add the pragmas in a class > method. > > > > In the first case I think I would like to have class pragmas because: > > > > - we can have a single, well known way, or concept, to generate metadata, > which can allow us to: > > - build tools that can work with class and method pragmas in the same way > (not only frameworks, a pragma browser can be benefited by this). > > > > If the metadata is disperse we have to know a lot of ways to do the same, > or each one will define it's own. And we can't (or it should be difficult > to) have tools to work with that metadata uniformly. > > Did you check setting? > Did you check how pragma collection is done? > Because it can help me to understand your answer. > > > > I don't know why this should be less cheaper than a class method. I > don't think this is reaaally hard to do also... :S. It's even simpler than > the method pragmas, because we don't have to change the compiler :P. > > > > Cheers, > > Guille > > > > On Fri, Jul 9, 2010 at 9:25 PM, <csrabak(a)bol.com.br> wrote: > > Stef, > > > > > > Just to have a better grasp of your reasoning: Are you suggesting we put > annotations in a method and just have it/them lumped in an 'Annotations' > protocol or are you suggesting a more radical change which will require the > toolset to have changes in sync to them? > > > > > > > > > > Em 08/07/2010 11:48, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > > escreveu: > > May be using a class method? > > But yes this would be important. > > > > Alex if we use comment we would have to parse them and this is not good. > > > > Stef > > > > On Jul 8, 2010, at 3:35 PM, Torsten Bergmann wrote: > > > > > Hi, > > > > > > while it is possible to annotate methods using Pragmas, > > > what about classes? > > > > > > Thx > > > T. > > > -- > > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > > > _______________________________________________ > > > 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 >

July 10, 2010

Re: [Pharo-project] Lost some classes

by StÃ©phane Ducasse

(((Smalltalk globals allClasses reject: [:each | each inheritsFrom: Error]) reject: [:each | each inheritsFrom: Exception]) reject: [:each | each inheritsFrom: Announcement]) select: [:each | each methods size = 0 and: [each class methods size = 0] ] an OrderedCollection(DirectoryURI FT2BitmapSize MCMockAPoolDictionary MCMockClassF MCMockClassG MCMockClassH MCMockClassI MethodTempsNode MockForCompilation MorphicTextEditor NameOfSubclass PSMCOrganizationChangeWrapper PanelStub PasteUpMorphTest SARInstaller SketchMorph SoundService TarArchiveMember TestDynamicVariable TestRunnerBrowser WebBrowser WeightedAverageCost) Will check and fix that as soon as I can Stef On Jul 11, 2010, at 12:05 AM, stephane ducasse wrote: > Apparently we lost some classes.... probably trying to changes packages with MC.... bad bad bad idea. > We lost MczInstaller for example. ;) > > Bad bad bad. > We will not change package structure before fixing MC else we are doomed to lose classes. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 10, 2010

[Pharo-project] Lost some classes

by stephane ducasse

Apparently we lost some classes.... probably trying to changes packages with MC.... bad bad bad idea. We lost MczInstaller for example. ;) Bad bad bad. We will not change package structure before fixing MC else we are doomed to lose classes. Stef

July 10, 2010