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

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

by Nicolas Cellier

2010/3/17 stephane ducasse <stephane.ducasse(a)free.fr>: > in Squeak > > Â Â Â Â (aDateAndTime offset: '0:12:00:00') = Â '1901-01-01T00:00:00+12:00' > Â Â Â Â true > > in pharo > > Â Â Â Â (aDateAndTime offset: '0:12:00:00') = Â '1901-01-01T00:00:00+12:00'. > Â Â Â Â false. > > Apparently the false in pharo comes from a bug in readFrom: in DateAndTime > > Now the question is does it make sense to have a DateAndTime = to its string representation. > For me I would prefer not > > Â Â Â Â (aDateAndTime offset: '0:12:00:00') = Â '1901-01-01T00:00:00+12:00' > Â Â Â Â -> false > Â Â Â Â (aDateAndTime offset: '0:12:00:00') printString Â = Â '1901-01-01T00:00:00+12:00' > Â Â Â Â -> true > > DateAndTime>>= comparand > Â Â Â Â "comparand conforms to protocol DateAndTime, > Â Â Â Â or can be converted into something that conforms." > Â Â Â Â | comparandAsDateAndTime | > Â Â Â Â self == comparand > Â Â Â Â Â Â Â Â ifTrue: [^ true]. > Â Â Â Â comparandAsDateAndTime := [comparand asDateAndTime] > Â Â Â Â Â Â Â Â on: MessageNotUnderstood > Â Â Â Â Â Â Â Â do: [^ false]. > Â Â Â Â ^ self offset = comparandAsDateAndTime offset > Â Â Â Â Â Â Â Â ifTrue: [self hasEqualTicks: comparandAsDateAndTime ] > Â Â Â Â Â Â Â Â ifFalse: [self asUTC ticks = comparandAsDateAndTime asUTC ticks] > > > What do you think > > 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 > Stef > _______________________________________________ > 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] packages :)

by Lukas Renggli

>> No, this is not true. RPackage does not have a cache. Please, have a >> look at the code. > > Strongly speaking, it is a cache, because you can recreate a full > package info by searching through different places in system. > This is a main difference to what i have proposed, i think. Only if you keep the category and protocols up-to-date with all operations. I don't think that this is done/planned with RPackage. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 12:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 March 2010 12:45, Lukas Renggli <renggli(a)gmail.com> wrote: >>> RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. >> >> No, this is not true. RPackage does not have a cache. Please, have a >> look at the code. >> > > Strongly speaking, it is a cache, because you can recreate a full i meant 'strictly speaking'. Sorry, my english fails me sometimes :) > package info by searching through different places in system. > This is a main difference to what i have proposed, i think. > > >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

March 17, 2010

[Pharo-project] [update 1.1] #11276

by StÃ©phane Ducasse

11276 ----- - Issue 2157: Squeak font rendering cleanup. Thanks nicolas Stef

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 12:45, Lukas Renggli <renggli(a)gmail.com> wrote: >> RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. > > No, this is not true. RPackage does not have a cache. Please, have a > look at the code. > Strongly speaking, it is a cache, because you can recreate a full package info by searching through different places in system. This is a main difference to what i have proposed, i think. > 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 > -- Best regards, Igor Stasenko AKA sig.

March 17, 2010

Re: [Pharo-project] Code Freeze 1.1?

by Damien Cassou

On Tue, Mar 16, 2010 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Now with 1.0 done, I think we should think about freezing 1.1. What about getting 1.0 completely done/released/advertised before thinking about freezing 1.1? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

Sorry, i was felt like you are at stage of 'making a first-class packages'. 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.

March 17, 2010

Re: [Pharo-project] packages :)

by Lukas Renggli

> RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. No, this is not true. RPackage does not have a cache. Please, have a look at the code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 12:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I fail to see how this is relevant to a in-image representation. >> I can choose any file-out/in format i want - binary, xml, .st , whatever... >> So, i really don't understand what you talking about 'off-line' here. > > Because we could browse squeaksource mc file using the same browser. > Just need to have the representation. > Ah, i see. And what about it? Instantiate a class object an put everything you need there. You can avoid compiling methods, but put a 'NotYetLoadedMethod' instances into its dict. Look, i can do similar things to what is MethodReference or PseudoClass is used for in current implementation, means that instead of reifying a real object, put a proxies to unreal ones. And then you can browse it and do same things. Where is the problem? > Lukas pointed to the problems if we go for real living objects we will have to pay attention > to a lot of places and may be this is something to do in a second step. > Right. Introducing my idea will require a lot of changes in various places. So, if your only argument, that we're not ready for it yet, i accepting that :) > I would prefer to have classes and methods but this is more brittle. > Nope. Explicit control is always less brittle than implicit. > 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.

March 17, 2010

Re: [Pharo-project] packages :)

by Lukas Renggli

> Explicitly only! Because package is in control and should govern all > of such operations: > > package remove: someclass. > > how do you removing a class from a system? > Right: > > Smalltalk removeClassNamed: aName > > so, what is wrong with that? Nothing is wrong. It sounds great, but unfortunately we have an existing system that doesn't work like this. And big-bang changes like you propose don't work. There will be thousands of lines of code to be adapted in the image and in external packages. >> 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. Yes, but we don't build a new system. We fix and improve an existing one. >>>> RPackage is about a PackageInfo replacement, not about a namespace >>>> implementation. Arguably namespacing is something entirely different. >>>> >>> As i said, it doesn't implements a new model, but a different view on >>> existing one. >> >> RPackage does not implement a different view: PackageInfo is implicit, >> it takes all information from elsewhere (category and protocol names). > > 'Elsewhere' is a key word here, which means that PackageInfo Â is a > view, and nothing more. Yes, PackageInfo is a view. I am just saying that RPackage is not a view. > 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.. The question is if we really want to have that. You're proposal seems to try to solve too many problems: packaging, namespaces, import, export, serialization, ... RPackage aims to solve one thing only, packaging. > 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 am not talking about PackageInfo. I think we agree that PackageInfo is not ideal. What I am saying is that Package.st is no better than PackageInfo, because it iterates over a large set of objects to select the interesting parts. That slows tools down. RPackage has a structural model and can return the classes without having to filter. > 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. You need to be able to generate thousands of (small) lists for classes, protocols and methods when you for example scroll through a package tree. Select a package in O2 or a category in OB and scroll down using the down arrow to see what I mean. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 17, 2010