- Pharo-dev - lists.pharo.org

Re: [Pharo-project] urgent rpackage fix

by Camillo Bruni

On 2012-09-11, at 16:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > but that's with the "old new implementation" > > in the "new new implementation", TestFoo in "Test-Foo-Bar" will produce: > > lookup? 'Tests-Foo-Bar' => success! > lookup? 'Tests-Foo' => fail! > lookup? 'Tests' => fail! > > but... RPackageSet ("Tests" or "Tests-Foo") lookup will succeed. > > That's why I asked you to wait... all changes you do now could have no sense or change tomorrow :) indeed for that fix I will wait. first I thought it's a local problem of not properly updating tags, but behold! there is more to it ;)

Sept. 11, 2012

Re: [Pharo-project] SqueakSource3: ByteString(Object)>>doesNotUnderstand: #goferReferences

by Bernardo Ezequiel Contreras

Marten, see http://code.google.com/p/squeaksource3/issues/detail?id=20 and http://code.google.com/p/pharo/issues/detail?id=4708 to be short, you should use url instead Gofer new url: 'http://ss3.gemstone.com/ss/**ICU <http://ss3.gemstone.com/ss/ICU> '; package: 'ConfigurationOfICU'; package: 'ICU-Core'; package: 'ICU-NativeBoost-Core'; package: 'ICU-Tests-Core'; package: 'ICU-Tests-NativeBoost'; load On Tue, Sep 11, 2012 at 11:37 AM, Marten Feldtmann <marten(a)schrievkrom.de>wrote: > When I copy the Gofer source (listed on the project pages) to a Pharo 1.4 > and tries to execute stuff like: > > Gofer new > repository: 'http://ss3.gemstone.com/ss/**ICU<http://ss3.gemstone.com/ss/ICU> > '; > package: 'ConfigurationOfICU'; > package: 'ICU-Core'; > package: 'ICU-NativeBoost-Core'; > package: 'ICU-Tests-Core'; > package: 'ICU-Tests-NativeBoost'; > load > > I get an error message: > > ByteString(Object)>>**doesNotUnderstand: #goferReferences > > > Marten > -- Bernardo E.C.

Sept. 11, 2012

Re: [Pharo-project] urgent rpackage fix

by Esteban Lorenzano

but that's with the "old new implementation" in the "new new implementation", TestFoo in "Test-Foo-Bar" will produce: lookup? 'Tests-Foo-Bar' => success! lookup? 'Tests-Foo' => fail! lookup? 'Tests' => fail! but... RPackageSet ("Tests" or "Tests-Foo") lookup will succeed. That's why I asked you to wait... all changes you do now could have no sense or change tomorrow :) Esteban On Sep 11, 2012, at 4:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-09-11, at 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> camillo >> >> what is "added hierarchical RPackage lookup" ? >> Why do we need that beast? > > Because right now RPackageOrganizer does a wrong lookup for classes > see RPackageOrganizer>>#systemClassRenamedActionFrom: > which does a > #packageNamed: class category > which fails if the class is not in a toplevel package. > > Let's say I refactor a class TestFoo in the category 'Tests-Foo-Bar' > the message send to #packageNamed: will try to find a package named > 'Tests-Foo-Bar' but the actual existing package is only 'Tests' and > the rest is the tag part. > > => you have to find the RPackage with the most common name > lookup? 'Tests-Foo-Bar' => fail! > lookup? 'Tests-Foo' => fail! > lookup? 'Tests' => success! > 'Tests' => lookup tag? 'Foo-Bar' => success!

Sept. 11, 2012

Re: [Pharo-project] urgent rpackage fix

by StÃ©phane Ducasse

On Sep 11, 2012, at 4:47 PM, Camillo Bruni wrote: > > On 2012-09-11, at 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> camillo >> >> what is "added hierarchical RPackage lookup" ? >> Why do we need that beast? > > Because right now RPackageOrganizer does a wrong lookup for classes > see RPackageOrganizer>>#systemClassRenamedActionFrom: > which does a > #packageNamed: class category > which fails if the class is not in a toplevel package. I see. and probably class category is not mapped to the correct place. > Let's say I refactor a class TestFoo in the category 'Tests-Foo-Bar' > the message send to #packageNamed: will try to find a package named > 'Tests-Foo-Bar' but the actual existing package is only 'Tests' and > the rest is the tag part. Yes bitten by the pattern shit again. > => you have to find the RPackage with the most common name > lookup? 'Tests-Foo-Bar' => fail! > lookup? 'Tests-Foo' => fail! > lookup? 'Tests' => success! > 'Tests' => lookup tag? 'Foo-Bar' => success! I hate that! Fucking extra complexity. Tx that you fix it. This is exactly what I want to remove. So in Pharo 3.0 I will kill this lookup. Stef

Sept. 11, 2012

Re: [Pharo-project] [update 2.0] #20279

by StÃ©phane Ducasse

Thanks! Excellent. Continue. :) I like when we pass local maximum :) > 20279 > ----- > > Issue 6654: Make one RPackage maps one PackageInfo > http://code.google.com/p/pharo/issues/detail?id=6654 > > (pass 1) > > - Rollback Nautilus to a pre-tags version > - initialize RPackageOrganizer from PackageInfos as before > > WARNING: This does not restores 2.0 stability, but it makes it a bit more usable... I'm working on the other issues.

Sept. 11, 2012

Re: [Pharo-project] Refactoring Tests

by Camillo Bruni

On 2012-09-11, at 16:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ooops this is bad. > Now we never decided what to do with RB. > Remember my mail where I ask where do we save changes? No Problem, actually I can load all tests and except for the Environment tests everything passes (needed a minor refactoring to fix FileDirectory stuff)... So I'll propose a bug issue to integrate them. >> Cami, I think tests were never integrated in the image when RB was integrated. >> I would check the ConfigurationOf, see where the tests came from, load them in Pharo and then create an issue to integrate them. >> >> On Tue, Sep 11, 2012 at 3:29 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Are there anywhere refactoring tests? >> Cause in the latest image I don't find any (maybe I just don't see well)... >> >> >> best >> cami >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Sept. 11, 2012

Re: [Pharo-project] Event smell...

by StÃ©phane Ducasse

Henrik have a look at EventModel/EventModel because this is were we publish our vm event brain surgery. >> yes, that's the idea. but we didn't went further than passing events >> to HandMorph. >> At first stage we want to make sure a lower-level event handling >> (Sensor->World->HandMorph) >> can be replaced with new model, and then we can enter the morphic and >> clean it up more seriously. > Mmmmhmm, isn't it more accurate to say that events flow Sensor -> HandMorph -> World? > (Though, they get pulled in by the consuming world in a polling loop, rather than getting pushed from the flow source) > > Anyways, a proper input event modelling is really independent of Morphic, analogous to the WindowClosed/MorphicWindowClosed naming discussion. > (which also gives a third alternative to double dispatch/case, in that in use registering to them tend to look like case statements, but loosely coupled) > > Cheers, > Henry > > PS: Looking up an example WindowAnnouncement and ran across it; WTF does Nautilus need special NautilusWindowAnnouncement classes for? > As long as your announcer is a Nautilus-specific one rather than the default announcer, that's all the separation that's needed... > In other words; favour application-distinct announcers over duplicate Announcement types. Open a bug entry and send code. I'm sure ben will be happy > >

Sept. 11, 2012

Re: [Pharo-project] urgent rpackage fix

by Camillo Bruni

On 2012-09-11, at 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > camillo > > what is "added hierarchical RPackage lookup" ? > Why do we need that beast? Because right now RPackageOrganizer does a wrong lookup for classes see RPackageOrganizer>>#systemClassRenamedActionFrom: which does a #packageNamed: class category which fails if the class is not in a toplevel package. Let's say I refactor a class TestFoo in the category 'Tests-Foo-Bar' the message send to #packageNamed: will try to find a package named 'Tests-Foo-Bar' but the actual existing package is only 'Tests' and the rest is the tag part. => you have to find the RPackage with the most common name lookup? 'Tests-Foo-Bar' => fail! lookup? 'Tests-Foo' => fail! lookup? 'Tests' => success! 'Tests' => lookup tag? 'Foo-Bar' => success!

Sept. 11, 2012

Re: [Pharo-project] Event smell...

by StÃ©phane Ducasse

>> > I guess it's to be consistent with other types of events, and/or make it easy to add a type instvar in the future... > Right now all three combinations of type instvar checks (KeyboardEvent), subclassing (DropXEvents), or a mix of the two (MouseEvents) are in use during the double dispatching of input events. > You might think subclassing was only used if additional state was needed, but that's only true of MouseEvents, and not DropXEvents... > (So yeah, your observation that the type check in DropEvent is unneccesary is correct) > > It might be nice with a rewrite to rely on subclassing alone, albeit increaseing the number of event classes. (KeyUp, KeyDown, KeyPressed, MouseOver, MouseEnter and MouseLeave for sure, potentially more depending on what action in WindowEvent means) > > A benefit is you could rewrite processEvents loop to essentially read > event := MorphicEvent forBuffer: evtBuf. > self handleEvent: event yes this is something like that that I would like. > (What is recorded in recentModifiers should be queried directly from event during handling, not through HandMorph) > And it would also make rewriting handleEvent: to something less... intrusive wrt Event modelling a much simpler task later on. Yes I'm taking notes about these points. Now the first level for me is to handle raw VM events then after we will deal with morphic ones. > > Cheers, > Henry > >

Sept. 11, 2012

Re: [Pharo-project] Refactoring Tests

by StÃ©phane Ducasse

Ooops this is bad. Now we never decided what to do with RB. Remember my mail where I ask where do we save changes? Stef > Cami, I think tests were never integrated in the image when RB was integrated. > I would check the ConfigurationOf, see where the tests came from, load them in Pharo and then create an issue to integrate them. > > On Tue, Sep 11, 2012 at 3:29 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Are there anywhere refactoring tests? > Cause in the latest image I don't find any (maybe I just don't see well)... > > > best > cami > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 11, 2012