March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec double title or nil title

by Freemail

On Fri Mar 14 07:28:32 2014 roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Hi Guys, > > I noticed a weird behavior of Spec MenuModel, it has either a double > title or a #nil title. > > Please see > https://pharo.fogbugz.com/f/cases/13075/Spec-double-title-or-nil-title > > Cheers, > R There is a fix for issue 13064 "nil as menutitle (inspector menu)". It is ready for integration and just needs a review. Nicolai

March 14, 2014

Spec double title or nil title

by roberto.minelli＠usi.ch

Hi Guys, I noticed a weird behavior of Spec MenuModel, it has either a double title or a #nil title. Please see https://pharo.fogbugz.com/f/cases/13075/Spec-double-title-or-nil-title Cheers, R

March 14, 2014

Re: [Pharo-dev] RPackage... not quite licked

by Sean P. DeNigris

Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/RPackage-not-quite-licked-tp4749038p4749075.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 14, 2014

Re: [Pharo-dev] RPackage... not quite licked

by Esteban Lorenzano

damn! I will check it tomorrow :) Esteban On 13 Mar 2014, at 20:40, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > We're getting there! But... > > Issue 13074: Renaming a package -> Wrong MC Tags > https://pharo.fogbugz.com/default.asp?13074 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/RPackage-not-quite-licked-tp4749038.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 14, 2014

Re: [Pharo-dev] EyeTreeInspector not ready for prime-time

by phil＠highoctane.be

Looks like there is some shared fun with ZnClient and https then :-) ... on my way to ZnNinja (slowly). Sven, HTTPComponents is really Ubercool! Phil On Thu, Mar 13, 2014 at 11:00 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > On Mar 13, 2014, at 6:53 PM, phil(a)highoctane.be wrote: > > Not silly if what you do is creating a gateway that gets stuff back from a > REST api and you need to figure out some parts of what you get back (and > one things is a huge Base64-encoded file > > > that actually happened to me a couple of times, yeah > > > sebastian <https://about.me/sebastianconcept> > > o/ > > > > > >

March 13, 2014

Re: [Pharo-dev] EyeTreeInspector not ready for prime-time

by Sebastian Sastre

On Mar 13, 2014, at 6:53 PM, phil(a)highoctane.be wrote: > Not silly if what you do is creating a gateway that gets stuff back from a REST api and you need to figure out some parts of what you get back (and one things is a huge Base64-encoded file that actually happened to me a couple of times, yeah sebastian o/

March 13, 2014

Re: [Pharo-dev] EyeTreeInspector not ready for prime-time

by Sven Van Caekenberghe

On 13 Mar 2014, at 22:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree. For strings characters could then no longer be shown. Well, this does the trick, but it is getting uglier: EyeTreeInspector>>#childrenForObject: anObject anObject isString ifTrue: [ ^ #() ]. ^ anObject inspector elements reject: [ :element | (element isKindOf: SelfEyeElement) or: [ (element isKindOf: AllInstVarsEyeElement) or: [ element isKindOf: ClassEyeElement ] ] ] This gives you clean strings in the explorer/tree.

March 13, 2014

Re: [Pharo-dev] EyeTreeInspector not ready for prime-time

by phil＠highoctane.be

Good ideas. Not silly if what you do is creating a gateway that gets stuff back from a REST api and you need to figure out some parts of what you get back (and one things is a huge Base64-encoded file - open that in the EyeTreeExplorer.) Now, on the GB thing, sure but the EyeTreeExplorer suddenly feels sluggish, not matter how much RAM there is. Phil On Thu, Mar 13, 2014 at 10:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > But you have GB's of RAM, right ;-) > > See EyeInspector>>#limit1 and limit2 that control how much to show in > collections, maybe 100000 it too high ;-) > > But in general, I think maybe we could use a dedicated EyeStringInspector. > > I agree that viewing a bigger string in the explorer/tree view is a bit > silly, but it is correct though. > > Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree. > For strings characters could then no longer be shown. > > On 13 Mar 2014, at 20:49, phil(a)highoctane.be wrote: > > > I see that you haven't clicked on a 17K long string that opens a 17K > items long tree of characters with nice icons and makes your image bloat to > 200+MB in size. > > > > > > --> 223 162 288 bytes for XXXX.image > > > > Look: (in 2.0 the explorer just shows a piece of text) > > > > <13-03-14 20-47-35.png> > > > > > > . > > > > > > <Screen Shot 2014-03-13 at 20.28.45.png> > > > > <Screen Shot 2014-03-13 at 20.29.10.png> > > > > But I hate the 'all inst vars' field, who uses that and for what ?? > > > > On 13 Mar 2014, at 20:16, phil(a)highoctane.be wrote: > > > >> I agree with that. > >> > >> I was inspecting a ZnResponse yesterday and it was very hard to see the > contents etc. > >> > >> A general pain. I was clicking on the "inspect" option to see what the > real content was. I was cursing a lot. > >> > >> Phil > >> > >> > >> > >> > >> > >> On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris < > sean(a)clipperadams.com> wrote: > >> I'm glad we're re-inventing the tools! And, I'm struggling with this > tool in > >> its current form... > >> > >> As others have mentioned, the "class" pseudo-variable is confusing, but > here > >> are some that I find worse: > >> - The receiver does not change with the selection. For me, this was a > key > >> feature of the explorer. > >> - It does not properly update e.g. if you are inspecting a class > containing > >> a dictionary and add an item to the dictionary, collapsing and > expanding the > >> dictionary node does not show the added item. It seems you must open an > >> entirely new inspector. > >> - If you toggle from EyeTreeInspector to EyeInspector, your code in the > >> bottom pane is lost > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> View this message in context: > http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.h… > >> Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >> > >> > > > > > > >

March 13, 2014

Re: [Pharo-dev] EyeTreeInspector not ready for prime-time

by Sven Van Caekenberghe

But you have GB's of RAM, right ;-) See EyeInspector>>#limit1 and limit2 that control how much to show in collections, maybe 100000 it too high ;-) But in general, I think maybe we could use a dedicated EyeStringInspector. I agree that viewing a bigger string in the explorer/tree view is a bit silly, but it is correct though. Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree. For strings characters could then no longer be shown. On 13 Mar 2014, at 20:49, phil(a)highoctane.be wrote: > I see that you haven't clicked on a 17K long string that opens a 17K items long tree of characters with nice icons and makes your image bloat to 200+MB in size. > > > --> 223 162 288 bytes for XXXX.image > > Look: (in 2.0 the explorer just shows a piece of text) > > <13-03-14 20-47-35.png> > > > . > > > <Screen Shot 2014-03-13 at 20.28.45.png> > > <Screen Shot 2014-03-13 at 20.29.10.png> > > But I hate the 'all inst vars' field, who uses that and for what ?? > > On 13 Mar 2014, at 20:16, phil(a)highoctane.be wrote: > >> I agree with that. >> >> I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc. >> >> A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot. >> >> Phil >> >> >> >> >> >> On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> I'm glad we're re-inventing the tools! And, I'm struggling with this tool in >> its current form... >> >> As others have mentioned, the "class" pseudo-variable is confusing, but here >> are some that I find worse: >> - The receiver does not change with the selection. For me, this was a key >> feature of the explorer. >> - It does not properly update e.g. if you are inspecting a class containing >> a dictionary and add an item to the dictionary, collapsing and expanding the >> dictionary node does not show the added item. It seems you must open an >> entirely new inspector. >> - If you toggle from EyeTreeInspector to EyeInspector, your code in the >> bottom pane is lost >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.h… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> > >

March 13, 2014

Re: [Pharo-dev] EyeTreeInspector not ready for prime-time

by Sven Van Caekenberghe

Where is the old motto, 'Just doit' ? With this simple change the class field is gone from the explorer: EyeTreeInspector>>#childrenForObject: anObject self flag: 'Minor Ugliness to filter out the self and instavr node'. ^ anObject inspector elements reject: [ :element | (element isKindOf: SelfEyeElement) or: [ (element isKindOf: AllInstVarsEyeElement) or: [ element isKindOf: ClassEyeElement ] ] ] But I would change that to use something like #shouldShowInTree on AbstractEyeElement (unless we do the next one too, then I think we only have to filter the self element). In the following method, you could tune the regular inspector fields, I commented out the class and allInstVars: EyeInspector>>#generateElements "generate the collection of elements to show in the inspector for the object inspected" |elements| elements := OrderedCollection new. self addSelf: elements. "self addClass: elements." "self addAllInstVars: elements." self addSpecialFields: elements. self addInstancesVariable: elements. self addVariableFields: elements. ^elements Pretty readable code if you ask me. Should I make a slice ? On 13 Mar 2014, at 20:51, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > I would like to have a basic mode without class and all instvars because they get in my way. > > Stef > >> I went back to compare the explorer in 2.0, the only visible (not behaviour) difference that I see is the class field, it would probably be better to lose that: >> >> <Screen Shot 2014-03-13 at 20.28.45.png> >> >> <Screen Shot 2014-03-13 at 20.29.10.png> >> >> But I hate the 'all inst vars' field, who uses that and for what ?? >> >> On 13 Mar 2014, at 20:16, phil(a)highoctane.be wrote: >> >>> I agree with that. >>> >>> I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc. >>> >>> A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot. >>> >>> Phil >>> >>> >>> >>> >>> >>> On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> I'm glad we're re-inventing the tools! And, I'm struggling with this tool in >>> its current form... >>> >>> As others have mentioned, the "class" pseudo-variable is confusing, but here >>> are some that I find worse: >>> - The receiver does not change with the selection. For me, this was a key >>> feature of the explorer. >>> - It does not properly update e.g. if you are inspecting a class containing >>> a dictionary and add an item to the dictionary, collapsing and expanding the >>> dictionary node does not show the added item. It seems you must open an >>> entirely new inspector. >>> - If you toggle from EyeTreeInspector to EyeInspector, your code in the >>> bottom pane is lost >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.h… >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >>> >> >

March 13, 2014