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

Re: [Pharo-dev] GTInspector and huge arrays issue

by kilon alios

"In that case, this will translate in self select: [:each | each isMatchingSomething]" ah ok, I see, so it does not search based on a string but based on expression.

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Tudor Girba

Hi, I think Kilon refers to the search in the Items presentation of a collection. If so, that search field accepts a Pharo expression of the form: each isMatchingSomething In that case, this will translate in self select: [:each | each isMatchingSomething] If you hover with the mouse over the search input you should get this info. Cheers, Doru On Thu, Dec 4, 2014 at 12:26 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > > On Thu, Dec 4, 2014 at 12:15 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> "Did you try this script in the discussion that shows the other >> possibility of list scrolling in Morph without talking about GT-*: This >> covers your requirement of omnipresent buttons and a list showing a fix >> number of items (in your case 50)." >> >> I did try but was giving me an error . The code you provide here works. >> Yes its as I assumed you want to go down the route of pages, but as I said >> again its not related to my issue. >> >> Yes I really like your solution. I wonder why Tudor prefer continuous >> scroll , is there any advantage ? >> >> Just a side note here even paging is very limited and unsuitable for big >> data, I think in the end a search facility on steroids would be an ideal >> solution, possible one supporting regex like finder tool already does. >> > > It is already possible to search in lists by sending filterOn:/searchOn: > message to the list presentation in Glamour. An example: > | finder | > finder := GLMFinder new. > finder show: [:a | > a list > beMultiple; > title: 'Simple'. > a list > title: 'With filter'; > beMultiple; > filterOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') > value: each]; > helpMessage: 'Enter a filtering request (e.g., "each > 10")'. > a list > title: 'With search'; > beMultiple; > searchOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') > value: each]; > helpMessage: 'Enter a search request (e.g., "each > 10")' ]. > ^ finder openOn: (1 to: 100) > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Usman Bhatti

On Thu, Dec 4, 2014 at 12:15 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > "Did you try this script in the discussion that shows the other > possibility of list scrolling in Morph without talking about GT-*: This > covers your requirement of omnipresent buttons and a list showing a fix > number of items (in your case 50)." > > I did try but was giving me an error . The code you provide here works. > Yes its as I assumed you want to go down the route of pages, but as I said > again its not related to my issue. > > Yes I really like your solution. I wonder why Tudor prefer continuous > scroll , is there any advantage ? > > Just a side note here even paging is very limited and unsuitable for big > data, I think in the end a search facility on steroids would be an ideal > solution, possible one supporting regex like finder tool already does. > It is already possible to search in lists by sending filterOn:/searchOn: message to the list presentation in Glamour. An example: | finder | finder := GLMFinder new. finder show: [:a | a list beMultiple; title: 'Simple'. a list title: 'With filter'; beMultiple; filterOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') value: each]; helpMessage: 'Enter a filtering request (e.g., "each > 10")'. a list title: 'With search'; beMultiple; searchOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') value: each]; helpMessage: 'Enter a search request (e.g., "each > 10")' ]. ^ finder openOn: (1 to: 100)

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Tudor Girba

Hi Kilon, We started to explore a new list implementation that is more scalable and whose goal is to support smooth scrolling, but it will take a while. Until then, you can still increase the paging size (the 50 is editable). Cheers, Doru On Thu, Dec 4, 2014 at 12:15 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > "Did you try this script in the discussion that shows the other > possibility of list scrolling in Morph without talking about GT-*: This > covers your requirement of omnipresent buttons and a list showing a fix > number of items (in your case 50)." > > I did try but was giving me an error . The code you provide here works. > Yes its as I assumed you want to go down the route of pages, but as I said > again its not related to my issue. > > Yes I really like your solution. I wonder why Tudor prefer continuous > scroll , is there any advantage ? > > Just a side note here even paging is very limited and unsuitable for big > data, I think in the end a search facility on steroids would be an ideal > solution, possible one supporting regex like finder tool already does. > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by kilon alios

"Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50)." I did try but was giving me an error . The code you provide here works. Yes its as I assumed you want to go down the route of pages, but as I said again its not related to my issue. Yes I really like your solution. I wonder why Tudor prefer continuous scroll , is there any advantage ? Just a side note here even paging is very limited and unsuitable for big data, I think in the end a search facility on steroids would be an ideal solution, possible one supporting regex like finder tool already does.

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Usman Bhatti

On Thu, Dec 4, 2014 at 11:56 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > "So I am not the only one grumbling about the scrolling in lists. > My suggestion was to use paging for this purpose. > > See the discussion here on moose-list. > > > https://code.google.com/p/moose-technology/issues/detail?id=1099&can=4&cols… > > > regards, > > usman > " > > I cannot understand your problem and your solution to it. I am afraid I am > not familiar with the library you use or with GTInspector. If I could > assume I would say you dont like the continuous scroll solution currently > implemented in GTInspector but that is not my problem. > > My problem is that next 50 items icon button disappears each time I press > it and for me that makes no sense. Without changing the current > implementation at a fundamental level the button should be always visible > and allow you to press it multiple times and send you to the last first of > 50. So if I press it lets say 4 times, it will be nice if it would send the > cursor of the list display to the item 200 and the list be able to scroll > down to 250 assuming that the list was already at cursor 1 displaying 50 > items. > Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50). | treeMorph aWindow aModel | aModel := PaginatedMorphTreeModel new rootItems: (1 to: 100) asArray. aWindow := aModel theme newWindowIn: World for: aModel title: 'test'. treeMorph := aModel defaultTreeMorph. treeMorph pageSize: 30. treeMorph buildContents. aWindow addMorph: treeMorph fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1) offsets: (0 @ 0 corner: 0 @ 0)). aWindow open. aModel expandItemPath: {50}.

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by phil＠highoctane.be

On Thu, Dec 4, 2014 at 11:56 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 04 Dec 2014, at 11:45, phil(a)highoctane.be wrote: > > > > But further than that I want to edit values in inspectors. > > Yes ! > Is there a way to get back an old trusty inspector on something? (like anObject inspectClassic / anObject exploreClassic) Live yes, but live behind a wall of glass isn't that interactive. Phil > And auto refresh ! > > Both of these could be depending on presentation, so that heavy > presentations can opt out. > > > >

Dec. 4, 2014

Re: [Pharo-dev] Meaning of VirtualMachine>>incrementalGCCount

by Jan Vrany

On Thu, 2014-12-04 at 11:43 +0100, ClÃ©ment Bera wrote: > Hello Jan, > > > An incrementalGC, in the sense of the V3 memory manager, is a scavenge > (unrelated to what other people call an incremental GC). With the new > memory manager Spur the names were updated to match common vocabulary. > I thought so :-) but wanted to be sure. Thanks for explanation! > > Please ask such questions on vm-dev Right, that would have been better. I'm sorry. Best, Jan > > 2014-12-04 10:30 GMT+01:00 Jan Vrany <jan.vrany(a)fit.cvut.cz>: > Hi there, > > what's exact meaning of VirtualMachine>>incrementalGCCount? > Comment says: "Answer the total number of incremental GCs > since startup > (read-only)." But what exactly is called 'incremental CG' in > context of > PharoVM? > > Again, thanks for any clarification :-) > > Jan > > > > > >

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by kilon alios

"So I am not the only one grumbling about the scrolling in lists. My suggestion was to use paging for this purpose. See the discussion here on moose-list. https://code.google.com/p/moose-technology/issues/detail?id=1099&can=4&cols… regards, usman " I cannot understand your problem and your solution to it. I am afraid I am not familiar with the library you use or with GTInspector. If I could assume I would say you dont like the continuous scroll solution currently implemented in GTInspector but that is not my problem. My problem is that next 50 items icon button disappears each time I press it and for me that makes no sense. Without changing the current implementation at a fundamental level the button should be always visible and allow you to press it multiple times and send you to the last first of 50. So if I press it lets say 4 times, it will be nice if it would send the cursor of the list display to the item 200 and the list be able to scroll down to 250 assuming that the list was already at cursor 1 displaying 50 items.

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Sven Van Caekenberghe

> On 04 Dec 2014, at 11:45, phil(a)highoctane.be wrote: > > But further than that I want to edit values in inspectors. Yes ! And auto refresh ! Both of these could be depending on presentation, so that heavy presentations can opt out.

Dec. 4, 2014