- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] A reset question

by Henrik Johansen

On Jan 20, 2011, at 2:54 40PM, Alexandre Bergel wrote: > I think you have a good point. #reset is ambiguous here. > > Maybe we should have two methods: #resetIndex and #resetContent > > Cheers, > Alexandre Hehe, I have a sense others must have thought the same, I missed them first time around: PositionableStream>>resetContents "Set the position and limits to 0." position := 0. readLimit := 0 WriteStream>>resetToStart readLimit := position := 0. Cheers, Henry

Jan. 20, 2011

Re: [Pharo-project] ConfigurationOf Question

by Mariano Martinez Peck

> > Yes that is correct. > > #latestVersion filters out versions with #baseline, #broken, or > #development blessings... > > If you want the really LAST version (regardless its blessing), you can use #lastVersion instead of #latestVersion Mariano > >

Jan. 20, 2011

Re: [Pharo-project] A reset question

by Alexandre Bergel

I think you have a good point. #reset is ambiguous here. Maybe we should have two methods: #resetIndex and #resetContent Cheers, Alexandre On 20 Jan 2011, at 10:40, Henrik Johansen wrote: > |writeStream| > writeStream := String new writeStream. > writeStream nextPut: $a. > writeStream reset. > writeStream isEmpty. > > What would you expect? > > Cheers, > Henry > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2011

Re: [Pharo-project] Issue 1249 in pharo: Debugger fails to launch after stacktrace is dumped to SqueakDebug file

by pharo＠googlecode.com

Updates: Status: Closed Comment #7 on issue 1249 by marcus.d...(a)gmail.com: Debugger fails to launch after stacktrace is dumped to SqueakDebug file http://code.google.com/p/pharo/issues/detail?id=1249 i think this has been fixed. (at least I can not reproduce)

Jan. 20, 2011

Re: [Pharo-project] A reset question

by laurent laffont

false. PositionableStream>>#reset "Set the receiver's position to the beginning of the sequence of objects." position := 0 Laurent On Thu, Jan 20, 2011 at 2:40 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > |writeStream| > writeStream := String new writeStream. > writeStream nextPut: $a. > writeStream reset. > writeStream isEmpty. > > What would you expect? > > Cheers, > Henry > >

Jan. 20, 2011