- Pharo-dev - lists.pharo.org

[Pharo-project] Remove Pen and PenPointRecorder ??

by Mariano Martinez Peck

Hi folks, what do you think about removing Pen and PenPointRecorder ? At least, to remove it from the core and let them somewhere in a repository. Cheers Mariano

March 17, 2010

[Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Esteban Lorenzano

Hi, I want to announce the immediate release of GoferProjectLoader, a Gofer extension to manage Metacello configurations. For all who want to know quickly what is this, here is a small synopsis: GoferProjectLoader is a loader for Metacello configurations (A metacello configuration is a full project load tool, including package/project dependencies with it corresponding versions). GoferProjectLoader automatically scan projects stored on MetacelloRepository, but you can add your private repositories as well. GoferProjectLoader responsibilities include: 1) Install project versions and keep track of them. 2) Update configurations and upgrade projects (if desired). GoferProjectLoader relies on Metacello and Gofer to perform this tasks (In fact, It can be thought as a Gofer extension to understand Metacello packages). To load GoferProjectLoader, you need to do: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGoferProjectLoader'; load. ConfigurationOfGoferProjectLoader project lastVersion load. With this... you'll never need again to perform once and again this repetitive configuration... instead, you can do things like: Gofer project load: 'Seaside30'; load: 'Pier2'. You can see the full documentation here: http://www.smallworks.com.ar/en/community/GoferProjectLoader Now I'm working on the promised page for configurations (Adrian: I really sorry for the delay... I know I promised this a lot of time ago... but time is the tyrant :( ) Cheers, Esteban

March 17, 2010

[Pharo-project] JPEGReadWriter and JPEGReadWriter2

by Mariano Martinez Peck

I read class comments and seem to be different, but I don't like the name at all. We should rename (or remove?) JPEGReadWriter2 to something better. we should merge them ? I have no idea...I just send a warning to you. Cheers Mariano

March 17, 2010

Re: [Pharo-project] packages :)

by Tudor Girba

Hi Stef, On 17 Mar 2010, at 11:09, StÃ©phane Ducasse wrote: > On Mar 17, 2010, at 10:05 AM, Tudor Girba wrote: > >> Hi Stef, >> >> On 17 Mar 2010, at 09:50, StÃ©phane Ducasse wrote: >> >>> On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote: >>> >>>>> It tries to work with methods and classes through symbolic >>>>> names.. and >>>>> you immediately end up with >>>>> gemmorage of a need to keep separate 'core' and 'extension' , >>>>> 'meta' >>>>> and 'instance-side' methods in your model. >>>> >>>> Yes, that's what I suggested, merge the extension and core >>>> dictionaries. >>> >>> I do not see how? >>> without first class class and no string match: '* class' ? >>> I'm curious >> >> >> The issue is not between instance side and meta side. The issue is >> with having two dictionaries for each: one for extensions and one >> for definitions. If we have the information about which classes are >> defined in this package, we only need to store the methods for the >> class and we know which are extensions and which are not. > > this is not that simple. > For each class I have to know the methods (defined | extended) > So I have to encode that information > why because not all the methods of a defined class are defined in a > package! > > The class point defined in package graphics can be extended by > myPackage and these methods should not be part of the Graphics. > > So I always need three information > Class * method * extended|defined Not quite. At this moment, for any given class in a package, you can either have entries in the defined or in the extension dictionaries, but not in both in the same time. So, this is an indication that you can simply merge the two dictionaries. As soon as you add a method to a package, you know exactly if that method is defined or not by knowing whether the class is defined in that package. Also, if you do have the methods in one dictionary, then you also won't have to care whether you moved the definition of a class between packages. Right now, if you move the definition of a class without touching the methods, you will have to ensure in the two packages that the methods that were defined are not extensions and the other way around. If you interpret the extension by looking at where the class is defined, then you do not lose anything. Yet another point is that I typically first want to know the methods of a class from a package. I do not want to know which is extended or which is not. So, I currently have to look it up in two dictionaries which is not necessarily optimal. Or am I missing something? Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

March 17, 2010

Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer

by StÃ©phane Ducasse

thanks oscar On Mar 17, 2010, at 1:35 PM, Oscar Nierstrasz wrote: > > Yes, we focused on getting a working version with all the tests running. > > Frankly we could not load the SetElement version, so we focused on the other approach, even if it is hackier. If we had had time, we would have then invested some effort into understanding how to get the other approach working without freezing the image, as it is certainly cleaner. > > There is still some work to do ... > > - on > > > On 15 Mar 2010, at 07:08, Levente Uzonyi wrote: > >> On Mon, 15 Mar 2010, StÃ©phane Ducasse wrote: >> >>> so may be the bug entry should have stated that because oscar and nico spend a day on it. >> >> The good news is that the tests are ready which is probably the larger part. The bad news is that integrating the tally hack is easier, than the SetElement version (which is also Igor's code, but that may not be clear from my previous mail). >> >> >> Levente >> >>> >>> Stef >>> >>> On Mar 15, 2010, at 12:56 AM, Henrik Sperre Johansen wrote: >>> >>>> On 15.03.2010 00:18, Igor Stasenko wrote: >>>>> 2010/3/14 Levente Uzonyi<leves(a)elte.hu>: >>>>>> On Sun, 14 Mar 2010, StÃ©phane Ducasse wrote: >>>>>> >>>>>>> during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil >>>>>>> entry. >>>>>>> Thanks. >>>>>>> http://code.google.com/p/pharo/issues/detail?id=1907 >>>>>> Why did you choose Igor's negative tally hack instead of the SetElement >>>>>> version? >>>>>> >>>>> I'd prefer to use SetElement, unless there was a decision made, to use >>>>> negative tally. >>>>> We had a quite big discussion around it on squeak-dev, and most >>>>> developers said that SetElement >>>>> is the way to go, because it is clean, OO-oriented, even if somewhat >>>>> slower comparing to other approaches. >>>>> >>>> +1 >>>> >>>> _______________________________________________ >>>> 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

March 17, 2010

Re: [Pharo-project] SystemDictionary and SmalltalkImage problem

by StÃ©phane Ducasse

No this is normal the duplication should be removed the migration from SystemDictionary to SmalltalkImage is not finished yet Stef On Mar 17, 2010, at 1:32 PM, Mariano Martinez Peck wrote: > Hi folks. I took a clean PharoCore-1.1-11268-UNSTABLE and I did a system update to 11276. > > I don't know why but it seems I have a lot of duplicated methods between those two classes. I don't know exactly all these changes that has been done last days in those classes. > But, take for example the category "shrinking" of both classes (SystemDictionary and SmalltalkImage) and you will notice both have the same methods implemented the same way. > > Maybe there was a problem with MC or system update ? > > Thanks > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer

by Oscar Nierstrasz

Yes, we focused on getting a working version with all the tests running. Frankly we could not load the SetElement version, so we focused on the other approach, even if it is hackier. If we had had time, we would have then invested some effort into understanding how to get the other approach working without freezing the image, as it is certainly cleaner. There is still some work to do ... - on On 15 Mar 2010, at 07:08, Levente Uzonyi wrote: > On Mon, 15 Mar 2010, StÃ©phane Ducasse wrote: > >> so may be the bug entry should have stated that because oscar and nico spend a day on it. > > The good news is that the tests are ready which is probably the larger part. The bad news is that integrating the tally hack is easier, than the SetElement version (which is also Igor's code, but that may not be clear from my previous mail). > > > Levente > >> >> Stef >> >> On Mar 15, 2010, at 12:56 AM, Henrik Sperre Johansen wrote: >> >>> On 15.03.2010 00:18, Igor Stasenko wrote: >>>> 2010/3/14 Levente Uzonyi<leves(a)elte.hu>: >>>>> On Sun, 14 Mar 2010, StÃ©phane Ducasse wrote: >>>>> >>>>>> during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil >>>>>> entry. >>>>>> Thanks. >>>>>> http://code.google.com/p/pharo/issues/detail?id=1907 >>>>> Why did you choose Igor's negative tally hack instead of the SetElement >>>>> version? >>>>> >>>> I'd prefer to use SetElement, unless there was a decision made, to use >>>> negative tally. >>>> We had a quite big discussion around it on squeak-dev, and most >>>> developers said that SetElement >>>> is the way to go, because it is clean, OO-oriented, even if somewhat >>>> slower comparing to other approaches. >>>> >>> +1 >>> >>> _______________________________________________ >>> 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

March 17, 2010

[Pharo-project] SystemDictionary and SmalltalkImage problem

by Mariano Martinez Peck

Hi folks. I took a clean PharoCore-1.1-11268-UNSTABLE and I did a system update to 11276. I don't know why but it seems I have a lot of duplicated methods between those two classes. I don't know exactly all these changes that has been done last days in those classes. But, take for example the category "shrinking" of both classes (SystemDictionary and SmalltalkImage) and you will notice both have the same methods implemented the same way. Maybe there was a problem with MC or system update ? Thanks Mariano

March 17, 2010

Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

by StÃ©phane Ducasse

> > I would expect = to be > "reflexive" self assert: (a = a). > "symmetric" self assert: (a = b) ==> (b = a). > "transitive" self assert: (a = b) & (b = c) ==> (a = c). > > Date>>= does not seem to meet my expectations Yes the more I think about it the more I'm against this automatic conversion. Stef

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

On Mar 17, 2010, at 11:52 AM, Igor Stasenko wrote: > Sorry, i was felt like you are at stage of 'making a first-class packages'. this is a first class package but not a module system nor a namespace. Stef > > I understand that we going slowly to that, i just wanted to be sure > that you doing right thing :) > Sure, if RPackage is just an improved implementation of PackageInfo , > i see nothing wrong with that. > > Thanks for listening my rants. :) > > > On 17 March 2010 12:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> Explicitly only! Because package is in control and should govern all >>> of such operations: >>> >>> package remove: someclass. >> >> in my first implementation I got >> package removeClassFromSystem:.... >> >> but it implies too much changes. So the goal is now. Let us have real >> Package objects, support the transition with PackageInfo, support MC >> and do the next steps when the next steps is needed. >> >>> >>> how do you removing a class from a system? >>> Right: >>> >>> Smalltalk removeClassNamed: aName >>> >>> so, what is wrong with that? >>> >>>> How does the package know when a class is deleted from within a >>>> #doSilently: block? >>>> >>> this is irrelevant. Because if you build a system from a first >>> principles, where a package is one of >>> the key concepts in it, instead of a hollow abstraction, sure thing >>> you taking care about all of it in proper manner. >> >> but there are more urgent things to fix: network and others. >> So let us be incremental. >> >>>> RPackage is explicit, it manages and knows its own contents. >>>> >>> Sure thing. In same way as i can write a brief description about something. >>> But description of a subject cannot replace a subject itself. Because >>> its missing a behavior and many other aspects. >> >> the behavior of RPackage is to let know if a class is extended, which are its participants. >> >> >>>>> you refer to a model, which doesn't takes this into account. Sure >>> thing, it wont work. >>> If you remember, i told about packages having policies, when any >>> modification of a package, such as adding or changing a method, >>> should go through package policy verification, and only then added to >>> package, or rejected. >>> This is what i think will be a cool thing. This is what i could easily >>> implement with a new model. >>> Now think how you could do that in yours. >> >> RPackage is not a namespace nor an hyper cool package system. It is a simple replacement >> of the bad packageInfo hack. Now just making sure replacement will take us a lot of energy >> and we will do it. >> >>> Another thing: your model allows only classes to be a real citizens of package. >>> While with mine, i can export any object which belongs to a package, >>> as long as it knows how to serialize/deserialize itself. >>> This means that i can define named variables in scope of package, like: >>> - Display, Sensor , World etc etc.. >> >> Good but this is not the purpose of RPackage. >> We need a good serializer in the future too. >> >>>> It is not practicable because its not complete. >>> Browser usually operating only with a small subset of a package - a >>> class and its methods. >>> I don't see how such organization could affect the performance. >>> >>> If you refer to things like #classes , compare mine: >>> >>> classes >>> ^ contents select: [:object | object isBehavior and: [ object isMeta not] ] >>> >>> and the old PackageInfo: >>> >>> classes >>> ^(self systemCategories gather: >>> [:cat | >>> (SystemOrganization listAtCategoryNamed: cat) >>> collect: [:className | Smalltalk at: className]]) >>> sortBy: [:a :b | a className <= b className] >>> >>> and you stating that mine will work slower? >>> I really doubt that, given how things like #listAtCategoryNamed: implemented. >> >> We are not talking about the old packageInfo >> >> >> In RPackage >> classes >> ^ definedClasses >> >> :) >> >>> Unless you want to generate a thousands lengthy lists in your tools. >>> But then it is impractical from either side - users can't cope with >>> such big amounts of information. >>> And this is where we using an automated things for refactoring. But >>> then, a performance in a mass-refactoring tools is not very relevant. >> >> It is with Moose PackageInfo nearly killed us we have to build a cache that takes 2 or 3 min >> to build before being able to work. >> >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010