- Pharo-dev - lists.pharo.org

Re: [Pharo-project] bug on dictionary?

by Esteban Lorenzano

maybe :) I use #with: a lot, but I agree that one of the two approaches is wrong... it should be a coherent API. Esteban On Mon, May 14, 2012 at 3:54 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Mon, May 14, 2012 at 3:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > Dictionary withAll: {#one->1 with: #two->2} > > your #with: is suspicious :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > >

May 14, 2012

Re: [Pharo-project] bug on dictionary?

by Damien Cassou

On Mon, May 14, 2012 at 3:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dictionary withAll: {#one->1 with: #two->2} your #with: is suspicious :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 14, 2012

Re: [Pharo-project] Singleton access selector

by Esteban Lorenzano

On Mon, May 14, 2012 at 3:43 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > Indeed. For me it depends in the case. > > Fair enough, but let's have a protocol. For example, UIManager default... > From Mac dictionary: > default: "a preselected option... when no alternative is specified by the > user" > Is that really what we mean? I don't think so. It should be current. > > SystemAnnouncer is a very special class. It gets two identically > implemented > methods, #announcer and #current ;-) > > So how about: > uniqueInstance -> There can be only one > (http://www.youtube.com/watch?v=4AoOa-Fz2kw) > current -> There are many like it, but this one is mine (couldn't find the > clip from Full Metal Jacket) > default -> Use this if you don't have any better ideas > +1 > -- > View this message in context: > http://forum.world.st/Singleton-access-selector-tp4630062p4630137.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 14, 2012

Re: [Pharo-project] Singleton access selector

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Indeed. For me it depends in the case. Fair enough, but let's have a protocol. For example, UIManager default... >From Mac dictionary: default: "a preselected option... when no alternative is specified by the user" Is that really what we mean? I don't think so. It should be current. SystemAnnouncer is a very special class. It gets two identically implemented methods, #announcer and #current ;-) So how about: uniqueInstance -> There can be only one (http://www.youtube.com/watch?v=4AoOa-Fz2kw) current -> There are many like it, but this one is mine (couldn't find the clip from Full Metal Jacket) default -> Use this if you don't have any better ideas -- View this message in context: http://forum.world.st/Singleton-access-selector-tp4630062p4630137.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

[Pharo-project] bug on dictionary?

by Esteban Lorenzano

Hi, I have this issue: Dictionary with: #one->'ONE' with: #two->'TWO' "This gives me a correct Dictionary with keys #one, #two and values 'ONE', 'TWO'" Dictionary withAll: {#one->1 with: #two->2} "This gives me a Dictionary with keys 1,1 and values #one->'ONE', #two->'TWO' So... I think one of both is incorrect... or at least, the API sucks because is too confusing. cheers, Esteban

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Sean P. DeNigris wrote > > Issue 5874: [ENH]: Notify progress with Announcements instead of > Exceptions > Why do we measure progress #from: a value? Has anyone ever put a value other than 0 here? -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] FileBrowser/FileList rant

by Benjamin

We will have to reimplement it using Spec so :) Ben On May 14, 2012, at 3:02 PM, Camillo Bruni wrote: > well the previous implementation was so horrible I didn't really feel > to fix too much. besides, drag and drop works pretty nicely, so I personally > don't see why using a shitty file browser in pharo when I can do the same thing > 100 times faster in my OS :/ > > but I think we will reimplement it from scratch in 2.0. The whole implementation > is almost orthogonal to the new FileSystem... > > > On 2012-05-13, at 16:56, Nicolas Cellier wrote: > >> Hi, >> it seems that FileBrowser/FileList is never used... >> And I absolutely don't understand some design choices. >> >> 1) Having a single reference inst var for both selectedDirectory and >> selectedFile : this is a bug factory, see >> http://code.google.com/p/pharo/issues/detail?id=5881 and >> http://code.google.com/p/pharo/issues/detail?id=5884 for example of >> bugs (I could open 1 bug entry per menu item I guess) >> >> 2) auto-selecting the file item under pop-up menu click >> This is a windows thing and anti-Smalltalk-UI-custom >> This is not at all uniform in the rest of Pharo UI (not even on the >> directory list) >> The implementation is buggish (see >> ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate >> of ttp://code.google.com/p/pharo/issues/detail?id=5625) >> >> There was (and still is) a specific menu when no file is selected... >> fileListMenu: aMenu >> reference >> ifNil: [^ self noFileSelectedMenu: aMenu] >> ifNotNil: [^ self fileSelectedMenu: aMenu]. >> >> I don't want to argue whether or not FileList did deserve a clean-up, >> I'm quite sure it did. >> And I also agree that we can temporarily break things in development images. >> But when the clean-up is so far from anything functional, I just >> wonder who do you want to eat the dog food? >> I'm a bit sick of it ;) >> >> Nicolas >> > >

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Sean P. DeNigris wrote > > * String>>displayProgressAt:from:to:during: has "deprecated" in the > comment, but is not in a deprecated category. The timestamp is 9/7/11 > which puts it either 1.2 or early 1.3, but either way, it should be > removed for 2.0, right? There is only one sender in the image, which can > easily be fixed to call #displayProgressFrom:to:during: > Steph, this one's yours, do you know why it was deprecated and why it was done in the comment instead of using deprecated:on:in:? Is wanting to place a progress bar in a specific location not ever needed? If not, we should remove it from all the UIManagers also, right? Thanks. Sean -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] FileBrowser/FileList rant

by Camillo Bruni

well the previous implementation was so horrible I didn't really feel to fix too much. besides, drag and drop works pretty nicely, so I personally don't see why using a shitty file browser in pharo when I can do the same thing 100 times faster in my OS :/ but I think we will reimplement it from scratch in 2.0. The whole implementation is almost orthogonal to the new FileSystem... On 2012-05-13, at 16:56, Nicolas Cellier wrote: > Hi, > it seems that FileBrowser/FileList is never used... > And I absolutely don't understand some design choices. > > 1) Having a single reference inst var for both selectedDirectory and > selectedFile : this is a bug factory, see > http://code.google.com/p/pharo/issues/detail?id=5881 and > http://code.google.com/p/pharo/issues/detail?id=5884 for example of > bugs (I could open 1 bug entry per menu item I guess) > > 2) auto-selecting the file item under pop-up menu click > This is a windows thing and anti-Smalltalk-UI-custom > This is not at all uniform in the rest of Pharo UI (not even on the > directory list) > The implementation is buggish (see > ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate > of ttp://code.google.com/p/pharo/issues/detail?id=5625) > > There was (and still is) a specific menu when no file is selected... > fileListMenu: aMenu > reference > ifNil: [^ self noFileSelectedMenu: aMenu] > ifNotNil: [^ self fileSelectedMenu: aMenu]. > > I don't want to argue whether or not FileList did deserve a clean-up, > I'm quite sure it did. > And I also agree that we can temporarily break things in development images. > But when the clean-up is so far from anything functional, I just > wonder who do you want to eat the dog food? > I'm a bit sick of it ;) > > Nicolas >

May 14, 2012

Re: [Pharo-project] Nautilus feedback - format of history pulldown combo box

by Benjamin

You are right. It was because it used to be package->class->protocol->method Fix in Nautilus-BenjaminVanRyseghem.277 in PharoInbox Ben On May 14, 2012, at 2:40 PM, Ben Coman wrote: > In Nautilus there is a combo box spanning and underneath the protocol and method panes which I shall presume to call the 'history pulldown' > where items are display like: MyObject -> myMethod: (1) > > The usual convention in most documentation seems to be: MyObject >> myMethod: (2) > > Now it strangely feels uncomfortable to getting used to (1). Is there a strong directive to move away from (2), or could this be used instead of (1). > > cheers -ben >

May 14, 2012