- Pharo-dev - lists.pharo.org

Re: [Pharo-project] badDirectoryPath

by Igor Stasenko

i think, if you rename #ifAbsent: to #ifNotAvail: then things can fit to their place :) Not available = due to error/permissions/not exists .. Absent = not exists/missing On 22 June 2012 03:12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > It seems like the primitive is not returning enough context. badDirectoryPath > is a catch-all for any error. > > For example, if you send #entries to aFileReference on a directory where you > don't have enough permissions, you get #badDirectoryPath. Besides being > misleading - the path is not really "bad" - it's hard to deal with the error > because it's so general. For example, > DiskStore>>directoryAt:ifAbsent:nodesDo: has a bug > (http://code.google.com/p/pharo/issues/detail?id=6122) > Â Â Â Â ... > Â Â Â Â entry := Primitives lookupEntryIn: encodedPathString index: index. > Â Â Â Â entry = #badDirectoryPath > Â Â Â Â Â Â Â Â ifTrue: [ ^ absentBlock value ]. > Â Â Â Â ... > > So if the entry exists but the primitive fails (e.g. not enough > permissions), the absentBlock is evaluated. It's easy enough to fix, but how > would you signal a helpful error? > > Cheers, > Sean > > -- > View this message in context: http://forum.world.st/badDirectoryPath-tp4635913p4636046.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 22, 2012

[Pharo-project] Some Nautilus feedback

by Torsten Bergmann

some feedback on Nautilus: 1. Having "Class/Instance" in one button is bad since the label can mean two things: "Im on the class/instance side" (state like) "Click here to go to class/instance side" (action like) After a while one knows it is the latter but this is really confusing anytime I come back to it. Especially since all Smalltalks I've used in the past have a clear and better distinction. Displaying the state on the title of the window is not enough. Possible solution: - reintroduce the two buttons (if layout space is a problem use "Instance" "?" "Class" where ? points to comment - use Tabs as in Dolphins browser http://www.stevewaring.net/blog/images/ssosxCHB.jpg - use a real toggle button which is not only changed but have a pressed "Instance" or non-pressed "Class" state - use two Radio Buttons as in VisualWorks http://linuxgazette.net/issue51/gx/steffler/classBrowser03.jpg 2. I like the hierarchy view ... and the double click "navigate to" functionality that is similar to VisuaWork. But still the inheritance tree view is not collapsible which is the most missing feature. You may ask why do we need that. Here is an example: navigate to class "StandardWindow" in Pharo 2.0 and click on "Hierarchy" to have a class hierarchy browser. Now you want to learn more about the direct subclasses of "StandardWindow" - hard to do in Nautilus: You will see class DialogWindow as the first subclass if SystemWindow - since the hierarchy of DialogWindow itself is very deep you can not see and easily navigate to the second subclass of SystemWindow which is "FontChooseMorph". It is hard to scroll down and since the tree has not lines it is also hard to follow indentation. With a collapsible tree you could collapse the "DialogWindow" subtree and would see - SystemWindow -- DialogWindow (collapsed) -- FontChooserMorph -- NautilusWindow Attached is a screenshot to show how easy it would be displayed with a collapsible browser (I used the SmalltalkMT class hierarchy browser to mock it) 3. The casing in the menue items is totally inconsistent. Here an example: "Find Method..." "Add class..." Nonetheless I like Nautilus a lot - thanks for it! Great tool Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

June 22, 2012

Re: [Pharo-project] compiled method inherits from Collection?

by Henrik Sperre Johansen

On 19.06.2012 22:01, Igor Stasenko wrote: > On 19 June 2012 14:33, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 19.06.2012 11:46, Fernando Olivero wrote: >>> Thanks for the info, its a shame we cant easily change the vm. >>> >>> Oh well, i should first ask for isCompiledMethod before isCollection >>> now... >>> >>> Fernando >> >> Why? >> I mean, each CompiledMethod IS a collection of bytes, even though those >> bytes hold a special meaning. >> What do you do when you encounter normal ByteArrays? >> > i think CM inherit from Collection is abuse, and makes little sense: > > (Object>>#yourself) do: > collect: > select: > add: > remove: > detect: > > so, only to reuse #at:/#at:put: ? > > but it could live with basicAt:/basicAt:put: just well. Well, I tried changing it (proceeding all warnings not to do it) to a variableByteSubclass: of Object (which implements at:/at:put:). After recompileAll'ing, and then using a 1.4 image normally only a single sender of #last (CodeHolder>>#didCodeChangeElsewhere, seemed like a candidate to rewrite using trailer instead anyways) was encountered as user of collection methods. At least it didn't crash the VM, so I guess it might be an option :) Cheers, Henry

June 22, 2012

[Pharo-project] Squeaksource down?

by phil＠highoctane.be

Cannot reach it from here (lots of other sites are fine). Annoying for getting the configs loaded for a fresh image... (testing 1.4 #441) Phil

June 22, 2012

Re: [Pharo-project] New System Progress Bar

by Camillo Bruni

You already have that igor (not as complete as you want, but it's there) Collection >> #do:displayingProgress: On 2012-06-22, at 02:37, Igor Stasenko wrote: > btw, about human readable.., > i don't understand, why we don't have something as simple as: > > collection do: [... ] showingProgress: 'Processing collection' > (1 to: 100) do: [ ...] showingProgress: 'Processing ' > > 1 to: 100 do: [ ...] showingProgress: 'Processing ' > > i don't care what happens inside, but this interface is IMO much simpler > and straightforward: > a user just adds showingProgress: at the end, and voila, his silent block > now showing a progress. > > -- > Best regards, > Igor Stasenko. >

June 22, 2012

Re: [Pharo-project] #assert:equals:

by Camillo Bruni

On 2012-06-22, at 09:39, Esteban Lorenzano wrote: > me neither. a=b is clear enough for me. If I want more detail, I add a description. > but perhaps I'm loosing something that I'm not seeing. > > Esteban error messages + inspect??? I hate to go and re-eavluate the code to see what was wrong during comparison... like that you keep the two arguments somewhere up in the stack and you can go and simply go and see what went wrong. consider self assert: self someExpressionReturningFalse = self someExpressionReturningTrue how the heck do you know what went wrong? assert:equals: is the thing to use. I don't like it particularly, it feels too java-ish, I prefer much more the "shoulder" framework written in bern. self someExpressionReturningFalse should = self someExpressionReturningTrue ËËËËËË that somehow feels much more natural to me :P

June 22, 2012

Re: [Pharo-project] #assert:equals:

by Esteban Lorenzano

me neither. a=b is clear enough for me. If I want more detail, I add a description. but perhaps I'm loosing something that I'm not seeing. Esteban On Jun 22, 2012, at 9:35 AM, StÃ©phane Ducasse wrote: > I never understood the problems :) > > Stef > > On Jun 22, 2012, at 3:53 AM, Sean P. DeNigris wrote: > >> This pattern is common in our tests: "self assert: a = b." >> >> I much prefer "self assert: a equals: b." >> >> It makes it easier to diagnose failing tests, especially if a or b are >> expressions with side-effects. Do you agree? >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/assert-equals-tp4636050.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

June 22, 2012

Re: [Pharo-project] #assert:equals:

by StÃ©phane Ducasse

I never understood the problems :) Stef On Jun 22, 2012, at 3:53 AM, Sean P. DeNigris wrote: > This pattern is common in our tests: "self assert: a = b." > > I much prefer "self assert: a equals: b." > > It makes it easier to diagnose failing tests, especially if a or b are > expressions with side-effects. Do you agree? > > Sean > > -- > View this message in context: http://forum.world.st/assert-equals-tp4636050.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 22, 2012

[Pharo-project] could metacello be hosted on ss3 or smalltalkhub or not load configurationOfHelp?

by StÃ©phane Ducasse

because right now we cannot load configurations because it requires configuration of Help and squeaksource is done. It would be good to have a small version of metacello just loading the bare minimum. Stef

June 22, 2012

Re: [Pharo-project] #assert:equals:

by Mariano Martinez Peck

On Fri, Jun 22, 2012 at 3:53 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > This pattern is common in our tests: "self assert: a = b." > > I much prefer "self assert: a equals: b." > > It makes it easier to diagnose failing tests, especially if a or b are > expressions with side-effects. Do you agree? > > I do. I use #assert:equals: in most of my tests. > Sean > > -- > View this message in context: > http://forum.world.st/assert-equals-tp4636050.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

June 22, 2012