January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3520 in pharo: Workspaces do not recognize previously evaluated temps

by pharo＠googlecode.com

Comment #4 on issue 3520 by Benjamin...(a)gmail.com: Workspaces do not recognize previously evaluated temps http://code.google.com/p/pharo/issues/detail?id=3520 It's the same in any text zone ...

Jan. 20, 2011

[Pharo-project] Issue 3561 in pharo: Remove everything into PluggableShoutMorph

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3561 by Benjamin...(a)gmail.com: Remove everything into PluggableShoutMorph http://code.google.com/p/pharo/issues/detail?id=3561 Here a changeset which empties PluggableShoutMorph Attachments: FixPluggableShoutMorph.1.cs 1.1 KB

Jan. 20, 2011

[Pharo-project] Issue 3560 in pharo: Clean of RML

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3560 by Benjamin...(a)gmail.com: Clean of RML http://code.google.com/p/pharo/issues/detail?id=3560 A new pass on RML was done. Sources are in PharoInbox 1) - Open a Recent Messages List and directly click to change the ordering to "by version". You will get a "MessageNotUnderstood: TimeStamp>>isByteString" Done 2) If we sort by date, we cannot see the class names. Maybe put the date and next to it the class name . For example: "20 January 2011 (ScriptLoader)" Done 3) we should clean its history in #cleanUpForRelease or in #cleanUpForProduction I do not change such files Thanks Mariano

Jan. 20, 2011

Re: [Pharo-project] [squeak-dev] Re: Kinect and Etoys

by Ricardo Moran

I think I found the cause of the problem: I'm updating the position of each morph inside a WorldState>>#addDeferredUIMessage:. In Pharo, this seems to be really slow. You can test it by executing this: | rnd | rnd := Random new. 100 timesRepeat: [ WorldState addDeferredUIMessage: [ Morph new openInWorld; center: rnd next @ rnd next * Display extent. ] ]. You'll notice it takes a couple of seconds to finish opening all the morphs, but if you remove the #addDeferredUIMessage: send, it is instantaneous. In Squeak and Etoys both versions are equally fast. I looked at it a little, and I think Pharo has a bug in WorldState>>#runStepsMethodsIn:. It seems it only executes one deferred ui message per step. With the implementation below the problem is fixed. WorldState>>#runStepMethodsIn: aWorld "Perform periodic activity inbetween event cycles" | queue nextInQueue| "If available dispatch some deferred UI Message" queue := self class deferredUIMessages. [(nextInQueue := queue nextOrNil) isNil] whileFalse: [ nextInQueue value]. self runLocalStepMethodsIn: aWorld. Best regards, Richo On Wed, Jan 19, 2011 at 6:40 PM, Ricardo Moran <richi.moran(a)gmail.com>wrote: > The latest stable 1.1.1. I will look at it tomorrow and try to find out > more. > > On Wed, Jan 19, 2011 at 6:38 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> hi ricardo, >> >> which version are you using? >> >> Stef >> >> On Jan 19, 2011, at 10:32 PM, Ricardo Moran wrote: >> >> > I forgot to say it works in Squeak and Pharo (although in Pharo it's >> *painfully* slow, I don't know why yet...) >> > >> > Cheers >> > Richo >> > >> > On Wed, Jan 19, 2011 at 6:04 PM, Ricardo Moran <richi.moran(a)gmail.com> >> wrote: >> > Hi guys! >> > I want to tell you some exciting news. Thanks to the ESUG Innovation >> Technology Awards we've been able to buy ourselves a Microsoft Kinect. We >> don't have a Xbox 360 yet, but that doesn't mean we can't have a little fun >> with it. Who needs and Xbox if you can use Kinect with Etoys? :) >> > >> > After seeing Stephen Howell's great work using Kinect with Scratch, we >> followed his steps and made it available for Etoys as well. >> > See it for yourselves: http://www.youtube.com/watch?v=YnqqaHvbeqg >> > >> > You can find installation steps in our blog: >> http://tecnodacta.com.ar/gira >> > >> > Cheers! >> > Richo >> > >> > >> >> >

Jan. 20, 2011

Re: [Pharo-project] Finder question

by Benjamin

On Jan 20, 2011, at 3:52 PM, Mariano Martinez Peck wrote: > Hi. It would be cool if Finder could be a little similar to RecentMessagesList. For example, doing a double click on a Message can browse its implementors. Why not, but if you want the implementors, just expand the node :) But creating a menu is not difficult, so if you have idea of what items could be put, just let me now (you or everyone of course ^^) > In addition, in RecentMessages you can also select/unselect items. Here in Finder is not possible? What do you mean by select/unselect ? > > What about shortcuts? I would love to be able to do cmd+m, cmd+n, cmd+b, etc, both in RecentMessages and in Finder. I don't know how to add shortcuts "properly" on a tree, but I will take a look ;) > > cheers > > mariano Thanks again, Ben

Jan. 20, 2011

Re: [Pharo-project] Problems with Recent Messages List

by Benjamin

On Jan 20, 2011, at 3:41 PM, Mariano Martinez Peck wrote: > Hi, I found a couple of problems: > > 1) - Open a Recent Messages List and directly click to change the ordering to "by version". You will get a "MessageNotUnderstood: TimeStamp>>isByteString" Fixed > 2) If we sort by date, we cannot see the class names. Maybe put the date and next to it the class name . For example: "20 January 2011 (ScriptLoader)" Fixed, now the By date sort the references on three levels (like packages) > 3) we should clean its history in #cleanUpForRelease or in #cleanUpForProduction I do not change that by myself ^^ > For the rest, it is really cool. > > mariano Thank you :) Ben

Jan. 20, 2011

[Pharo-project] Finder question

by Mariano Martinez Peck

Hi. It would be cool if Finder could be a little similar to RecentMessagesList. For example, doing a double click on a Message can browse its implementors. In addition, in RecentMessages you can also select/unselect items. Here in Finder is not possible? What about shortcuts? I would love to be able to do cmd+m, cmd+n, cmd+b, etc, both in RecentMessages and in Finder. cheers mariano

Jan. 20, 2011

[Pharo-project] Problems with Recent Messages List

by Mariano Martinez Peck

Hi, I found a couple of problems: 1) - Open a Recent Messages List and directly click to change the ordering to "by version". You will get a "MessageNotUnderstood: TimeStamp>>isByteString" 2) If we sort by date, we cannot see the class names. Maybe put the date and next to it the class name . For example: "20 January 2011 (ScriptLoader)" 3) we should clean its history in #cleanUpForRelease or in #cleanUpForProduction For the rest, it is really cool. mariano

Jan. 20, 2011

Re: [Pharo-project] Issue 3506 in pharo: TextMorph's #autoFit: and #wrapFlag: are confusing

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3506 by marcus.d...(a)gmail.com: TextMorph's #autoFit: and #wrapFlag: are confusing http://code.google.com/p/pharo/issues/detail?id=3506 (No comment was entered for this change.)

Jan. 20, 2011

Re: [Pharo-project] RPackage

by Cyrille Delaunay

By looking a bit more at Monticello, this is how I think it works (if not tell me): => WorkingCopy is the first kind of objects we have. A workingCopy has informations about version, ancestors, ... (surely a lot of other things) of a package and has a reference to a MCPackage => a MCPackage does not know about the elements composing itself before calling the method MCPackage >> snapshot. This method will return a fresh MCSnapshot object. It is at this moment (I think), that monticello will use PackageInfo to retrieve all necessary informations. => a MCSnapshot contains a kind of 'modelisation' of the system, which basically is a collection composed by: => MCOrganizationDefinition, specifying what are the subcategories of the package => MCMethodDefinition(s), one for each method included in the package (both defined and extension methods). => MCClassDefinition(s), one for each class included in the package. So I think the point to focus on is, MCPackage >> snapshot, using the RPackage interface instead of PackageInfo interface to build the snapshot. I'm looking to do that. 2011/1/19 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Hello, > Currently I am working on integrate RPackage in pharo, and having it > working in parallel of PackageInfo. > What RPackage is already able to do (or at least until you find something > wrong;)) is: > - synchronize and initialize with the current MCPackages in the system > - update itself when changes are made in the system (new category, new > class, new method, ... ). > > Now I was wondering if there would be something to pay attention to with > Monticello. Maybe when saving or importing packages to/from a repository? I > don't know how monticello work, but after looking quickly, that's some > thoughts I had: > > > > > > 1) => *Saving from the image to a repository: *How monticello know if the > package we want to saved is extended by other classes? is there currently a > link between Monticello and Package Info to do that? > 2) => *import from a repository into the image: *How do we manage to > install the extension in the right package ? > > For the point 1) : > > MCPackageManager seems to directly listen to the system events (see > MCPackageManager class >> reregisterForNotificationsWith:), in a parallel > direction than RPackage (with its announcements system). So I guess > Monticello update itself all its packages and check itself when a protocol > is added to know if it's an extension. Therefore there would be nothing to > worry when replacing PackageInfo by RPackage > > For the point 2) : > > When monticello will import the code, it will create classes, create > methods in some protocols (that can be extensions or not), using the system > interface. Then, Normally each modification will raise the corresponding > event, for which RPackage is listening to (throught the announcement > system). Therefore RPackage will update itself and there would be still > nothing to worry. > > > For now the only link to make I see, is when creating or deleting a > MCPackage: we have to do the same with the RPackages. This is currently done > in RPackage, by listening to MC changes (look at RPackageOrganizer >> > update:). PackageInfo is directly updated in the MC code instead of > listening to changes. > > So I wonder if there is some big parts I totally forgot ? and In general > if you have something in mind that should be done for RPackage? > > 2010/12/6 <csrabak(a)bol.com.br> > > I think this small thread is an excellent example of the need we have to >> implement simpler practice: >> >> When we announce a package or project, it would nice if the first >> paragraph[s] could be a short description of what it's all about! >> >> We could even open another thread and agree upon a format for it, and >> look, we could even have the same text in some specific attribute in the >> package which could be collected, selected, etc.!! >> >> -- >> Cesar Rabak >> >> >> Em 06/12/2010 07:08, Tudor Girba < tudor.girba(a)gmail.com > escreveu: >> Good work, Cyrille! >> >> For people that might not know what RPackage is, this project aims to >> replace PackageInfo with a faster and cleaner implementation. At the moment, >> all categories are mapped one-to-one and in the end, we would like to remove >> class categories altogether. >> >> This infrastructure is also targeted to code browsers. >> >> Doru >> >> >> On 6 Dec 2010, at 09:58, Cyrille Delaunay wrote: >> >> > Hello, >> > >> > Recently I made some improvements about RPackage. What I mainly did, is >> to implement the 'SystemAnnounncements listening', to update the organizer >> when the system change. With that I implemented a set of tests that should >> all be green now (in RPackageMCSynchronisationTest (I should change the >> name)). >> > >> > You can load RPackage by evaluating: >> > >> > Gofer new >> > squeaksource: 'PharoInbox'; >> > package: 'ConfigurationOfRPackage'; >> > load. >> > (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. >> > >> > (I think it should work, but squeaksource is down for now, so I was not >> able to test it). >> > >> > In those tests I started to write some about traits, but after few, I >> realized that the events emitted when a trait change are the same that the >> one used for classes ? >> > Then if you have some ideas about what is still missing in RPackage, >> tell me, I can add it to my task list :) >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> >> >> >> >

Jan. 20, 2011