- Pharo-dev - lists.pharo.org

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

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

by Pharo4Stef

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

Re: [Pharo-dev] Is there a Smalltalk way to lock a file?

by David T. Lewis

> Hi Mariano, > > It is supported directly in OSProcess. See the unit test for examples. > > Dave Sorry, I should have been more clear about this. The classes in the OSProcess package are OSFileLock and OSFileRegionLock, as well as the methods in category 'file locking' of class UnixOSProcessAccessor. You can look at the unit tests to see how these are used, but you will not be able to actually run any of the tests that depend on #forkSqueak because these rely on a feature not present in Cog. So look at the tests as examples, but do not expect them to run. The actual file locking support should work fine on Pharo (but let me know if that is not true). HTH, Dave > >> Hi guys, >> >> Do we have a method to lock a file at the OS level? I searched in image >> but >> I cannot find anything. If it would work in gemstone too that would be >> nice. >> >> Thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

March 13, 2014

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

by phil＠highoctane.be

> > 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) [image: Inline image 1] > > . > > > > 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 Sebastian Sastre

yeah, and saw what happens when you use the keyboard? try this: 1. selecting in a workspace 2. cmd+shift+i 3. when it opens, press 3 ro 4 times the right arrow you navigate the class instead of the instace not great I miss the old explorer On Mar 13, 2014, at 4:30 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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

RPackage... not quite licked

by Sean P. DeNigris

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 13, 2014