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

[Pharo-project] Issue 3547 in pharo: Have a look at the new match: implementation

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3547 by stephane...(a)gmail.com: Have a look at the new match: implementation http://code.google.com/p/pharo/issues/detail?id=3547 Collections-ul.420 Hi Squeakers, Latest trunk version broke the Aida/web and Herbert managed to find the reason in new behavior of String>>match: which doesn't allow two '**' in pattern anymore. In Aida the matching patterns are usually composed out of many strings and as it happens two stars occurs in Aida's default installation already. Because this new match behavior (not allowing two '**') is new only in Squeak but allowed in all other Smalltalks, I propose to reconsider this decision and better retract back to old behavior. answer: ------ The old behavior was definitely wrong. Here are two examples with the old behavior from the corresponding issue (http://bugs.squeak.org/view.php?id=6841 ): '*#' match: 'e'. "false" '**' match: 'e'. "false" If you look at the previous version of the method from 2004 (I don't know if this is the original or not), then you'll see that it tried to raise an error if the string contained '**', but it failed to do so because of this bug. So the intended behavior - to disallow ** in the pattern - is not new at all. IMHO the best solution to this problem is to rewrite the method to allow any combination of * and # in the pattern.

Jan. 18, 2011

[Pharo-project] Issue 3546 in pharo: Have a look at SystemReporter

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3546 by stephane...(a)gmail.com: Have a look at SystemReporter http://code.google.com/p/pharo/issues/detail?id=3546 In the SystemReporter you can chose what system information should be gathered. So you could have a compact overview of the image and the VM or a full length/all details report. Add the repository SystemReporter to Monitcello. MCHttpRepository location: 'http://www.squeaksource.com/SystemReporter' user: '' password: '' Load the package SystemReporter and do SystemReporter open in a workspace. This very simple and needs to be polished further. License is MIT and everybody is invited to add code. It's easy to extend the reporter and it is explained in the class comment. This works with Squeak Trunk and Pharo 1.1.1 (needs to get rid of the deprecation warning) Alex

Jan. 18, 2011

Re: [Pharo-project] [SPAM] Re: Xtreams-Xtras: hashing and HMAC

by Sven Van Caekenberghe

On 18 Jan 2011, at 21:24, mkobetic(a)gmail.com wrote: > "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: >>> I didn't find a way to browse a "package" in Pharo 1.2 so I'm struggling a bit to keep the categories in line. >> >> Hmm, click the 'Browse' button in either the Monticello Browser or the Repository Browser with the correct package selected ? But I guess you know that as well... > > Well, those seem to be "read-only", i.e. any edits I try to make in those seem to disappear, so I've been ignoring those browsers. Interestingly, the one-click image (Pharo 1.1.1) seems to have 'browse package' in the SystemBrowser menus which seems to be more functional, but that doesn't seem present in the PharoCore 1.2, so I'm just getting by with the basic SystemBrowser atm. Indeed, they are a read only view on what Monticello thinks the package is (the same browser is used to look at MC packages not loaded). And you are right, going between that browser and the regular one is a bit hard, if possible at all. >> The problem is the one I reported earlier: XTFileReadingWritingTest expecting a read stream to be aware of data written to a file after it was opened. This does not seem to work on Mac OS X. > > Yeah I have your previous report still in my inbox, but I'm kinda stuck there. As I said I don't have OSX to work with so I can't dig in to figure out what's going on. Given that it works on OSX in VW, I'm inclined to say that it should work on OSX in Squeak too. I wonder if there's some mixup in terms of file descriptors, maybe we're not talking to the same one or something such. I think Nicolas has OSX available so I'm hoping he might be able to find the time to look into it at some point. OK. Thx for the responses, Sven

Jan. 18, 2011

Re: [Pharo-project] list on he fly selection :)

by Benjamin

You must have tried between two commits on squeaksource (I hope ^^) I will refactor that because the inst var is named lastKeystrokes but the method is named lastKeyStrokes ... Thanks for your feedback :) Ben On Jan 18, 2011, at 8:34 PM, Tudor Girba wrote: > I am not sure where it should work, but I tried in Pharo 1.2 and it does not work. First, there is a "self self". Second, even if I fix this one, I still get a DNU for OnTheFlySelectionPluggableListMorph>>lastKeystrokes. > > Cheers, > Doru > > > On 18 Jan 2011, at 20:21, StÃ©phane Ducasse wrote: > >> close your eyes and imagine that you can just type as to get all the methods starting with as* >> without extra shortcut whatever.... >> same for classes, packages... of course. >> >> Stef >> >> On Jan 18, 2011, at 4:16 PM, Alexandre Bergel wrote: >> >>> Just tried. I could not immediately figure out what is the difference with the "Find Class" panel (pressing Cmd-f in OB)? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 18 Jan 2011, at 12:00, StÃ©phane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> I'm sure that some of you will really like to type on that list and see it auto selectioning its elements.... >>>> >>>> Gofer it >>>> squeaksource: 'DirtyExperiments'; >>>> package: 'DirtyExperiments'; >>>> load >>>> >>>> | test | >>>> test := DummyTest on: (Smalltalk allClasses). >>>> test openInWorld >>>> >>>> Of course I would love to have that for a lot of lists..... :) >>>> >>>> Thanks Benjamin for this first version :) >>>> Stef >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > >

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Sean P. DeNigris

Tudor Girba wrote: > > The WeakAnnouncement are already on the agenda for 1.3. > Ah, very good! Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3223939.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 18, 2011

Re: [Pharo-project] should the PharoDev hudson image be buld using the baseline instead?

by Dale Henrichs

Mariano, This isn't quite as bad as it sounds ... I suggest that you do load the baseline version of PharoDev, but in the project references of the baseline version use #stable or a specific version or #bleedingeEdge as a last resort. If a #stable version has been defined for a project, then you should be getting the 'latest stable version' as the project is updated. If no #stable version is defined, then you should use a literal version that is known to work. Use #bleedingEdge if that is the only way to get a project to load correctly ... Over time, you'd like to migrate all of the project references to #stable (in the baseline version) so that you will always be building hudson with the "latest version". When you release a one-click or hit another similar milestone where'd you'd like to record the state of the PharoDov system, then you can snap off the literal version of PharoDev where you record the literal version for each of the projects ... recording "in stone" the state of PharoDev... Dale On 01/18/2011 12:14 PM, Mariano Martinez Peck wrote: > Hi. A trade-off here. Right now, the PharoDev image from Hudson is > being built using ConfigurationOfPharo project lastestVersion. > This is more or less good because we have the last version of the > ConfigurationOfPharo. But at the same time, updating the versions of > ConfigurationOfPharo is tedious. So, what about loading the baseline > istead? So that metacello automatically load the latest version of each > package/project ? > The good thing is that every change in external configurations/packages > will be automatically included. But at the same time this is a > disavtange because we can build crap (someone commits something that > doesn't work). When updating ConfigurationOfPharo by hand we usually > test it before.... > > anyway, isn't this the idea if hudson? if it builds crap, we want to > know it, as soon as possible. NOBODY should use a Hudson image (as it > is now) for a stable Pharo1.2 image. > > what do you think? > > cheers > > mariano

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Sean P. DeNigris

Henrik Sperre Johansen wrote: > > AFAICT, #outOfWorld: might be the one you're looking for, it's called on > self and submorphs as part of #removeMorph: > So I THINK you'd get away with: > :) Good thought, and thanks for looking into it! However, that was my idea too; and it doesn't work. #outOfWorld: is also called when you embed a Morph in another Morph, for instance. So, even if the Morph is still open in the world, the subscriber list is hosed. Also, when #outOfWorld: is called, there is not enough context to tell whether it is being deleted or embedded, because the actual move happens after. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3223934.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 18, 2011

Re: [Pharo-project] splitters in table layout

by Andreas Wacknitz

Am 18.01.2011 um 20:58 schrieb Tudor Girba: > Yes, you missed a changeset Gary sent in the aligning morphs thread (he actually sent two, and you should pick the second one). > > Cheers, > Doru > Ah, thank you. I have found two messages with changesets from January 11th, 2011. After I filein the second changeset alas I will get a DNU Morph>>doFastWindowReframe: when I move the splitter... Regards, Andreas

Jan. 18, 2011

Re: [Pharo-project] Xtreams-Xtras: hashing and HMAC

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > > I didn't find a way to browse a "package" in Pharo 1.2 so I'm struggling a bit to keep the categories in line. > > Hmm, click the 'Browse' button in either the Monticello Browser or the Repository Browser with the correct package selected ? But I guess you know that as well... Well, those seem to be "read-only", i.e. any edits I try to make in those seem to disappear, so I've been ignoring those browsers. Interestingly, the one-click image (Pharo 1.1.1) seems to have 'browse package' in the SystemBrowser menus which seems to be more functional, but that doesn't seem present in the PharoCore 1.2, so I'm just getting by with the basic SystemBrowser atm. > The problem is the one I reported earlier: XTFileReadingWritingTest expecting a read stream to be aware of data written to a file after it was opened. This does not seem to work on Mac OS X. Yeah I have your previous report still in my inbox, but I'm kinda stuck there. As I said I don't have OSX to work with so I can't dig in to figure out what's going on. Given that it works on OSX in VW, I'm inclined to say that it should work on OSX in Squeak too. I wonder if there's some mixup in terms of file descriptors, maybe we're not talking to the same one or something such. I think Nicolas has OSX available so I'm hoping he might be able to find the time to look into it at some point.

Jan. 18, 2011

[Pharo-project] should the PharoDev hudson image be buld using the baseline instead?

by Mariano Martinez Peck

Hi. A trade-off here. Right now, the PharoDev image from Hudson is being built using ConfigurationOfPharo project lastestVersion. This is more or less good because we have the last version of the ConfigurationOfPharo. But at the same time, updating the versions of ConfigurationOfPharo is tedious. So, what about loading the baseline istead? So that metacello automatically load the latest version of each package/project ? The good thing is that every change in external configurations/packages will be automatically included. But at the same time this is a disavtange because we can build crap (someone commits something that doesn't work). When updating ConfigurationOfPharo by hand we usually test it before.... anyway, isn't this the idea if hudson? if it builds crap, we want to know it, as soon as possible. NOBODY should use a Hudson image (as it is now) for a stable Pharo1.2 image. what do you think? cheers mariano

Jan. 18, 2011