- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

> On 04 Dec 2014, at 14:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are working on the edit values. Could you open a ticket in the meantime to not forget about it? Here you go: https://pharo.fogbugz.com/f/cases/14568/GTInspector-should-allow-slots-valu… > As for auto refresh, we will probably have to wait until we get the ability to listen to an individual object. https://pharo.fogbugz.com/f/cases/14569/GTInspector-should-do-live-updates-… I understand the performance argument, but we had this before and it worked well enough, so it should be possible to bring this back in some form (like maybe only for Raw and Items). BTW, it would also feel like a regression if the solution would be that you have to activate this explicitly... > Doru > > 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 ! > > And auto refresh ! > > Both of these could be depending on presentation, so that heavy presentations can opt out. > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 4, 2014

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

by Tudor Girba

Hi, We are working on the edit values. Could you open a ticket in the meantime to not forget about it? As for auto refresh, we will probably have to wait until we get the ability to listen to an individual object. Doru 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 ! > > And auto refresh ! > > Both of these could be depending on presentation, so that heavy > presentations can opt out. > > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 4, 2014

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

by kilon alios

thanks Doru and keep the awesome job. You guys really improved the inspector feature wise, I love to see efforts to modernize Smalltalk :) On Thu, Dec 4, 2014 at 2:15 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > In that presentation, yes. > > Doru > > On Thu, Dec 4, 2014 at 1:09 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> "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. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Dec. 4, 2014

Re: [Pharo-dev] tests coverage of minimal Pharo

by Alexandre Bergel

Wow! Having a vm support would be great Alexandre > Le 02-12-2014 Ã 11:39, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > >>> On 01 Dec 2014, at 15:58, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Would Hapao benefit from using reflectivity as it's intercession framework instead of using method wrappers? Maybe in such a way it can also instrument classes such as Array, Objectâ¦ >> >> May be. But I am wondering whether it will really solve the problem. I guess reflectivity is using the same kind of transformation as we do. > What we do is to model recursionâ¦ a link is active at a certain âmeta levelâ, calling the meta object switches the meta level, which means that > it will not take the link again â> meta recursion is stopped. > >> In Java, the JVM provides an interface, to which you can connect a debugger. With such interface, you can literally profile anything. > The idea is to integrate it with the VM (to some extend) via Sista next year. > >> Alexandre >> >> >>> >>>> On Mon, Dec 1, 2014 at 2:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> Right. Some tests ended with out-of-memory errors or vm crash. One >>>> problem was in a trait so I had to put all users of it on the >>>> blacklist. >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> 2014-12-01 14:21 GMT+01:00 Alejandro Infante <alejandroinfante91(a)gmail.com>: >>>> > Hapao works using method wrappers, and do some stuff for every method >>>> > execution. If Hapao use something you are instrumenting, you are start >>>> > looping endlessly. So blacklisted classes are classes you are not going to >>>> > instrument. >>>> > >>>> > But, I was trying to understand all the classes you blacklisted, and I donât >>>> > understand why you have some tests blacklisted, any reason for them? >>>> > >>>> > Cheers, >>>> > Alejandro >>>> > >>>> > On Dec 1, 2014, at 7:57 AM, Guillermo Polito <guillermopolito(a)gmail.com> >>>> > wrote: >>>> > >>>> > ignorant question: What is a black listed class? :) >>>> > >>>> > On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> Hi, >>>> >> >>>> >> I set the job for tests coverage testing of the mimimal Pharo using Hapao: >>>> >> >>>> >> >>>> >> https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2… >>>> >> >>>> >> To load results you should load ConfigurationOfSUnit and >>>> >> ConfigurationOfKernelTests from Pharo/SystemConfigurations repository >>>> >> into an image with Hapao. Then inspect: >>>> >> >>>> >> FLMaterializer materializeFromFileNamed: 'hapao.fuel'. >>>> >> >>>> >> Do not try to visualise it ;-) >>>> >> >>>> >> Currently blacklisted classes are: >>>> >> >>>> >> Array Association ArrayedCollection Behavior BlockClosure ByteSymbol >>>> >> ByteString ClassDescription CompiledMethod Class Dictionary >>>> >> Hapao2Package HashedCollection IdentityDictionary Integer LookupKey >>>> >> FileStream Magnitude Object ProtoObject Process ProcessLocalVariable >>>> >> ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage >>>> >> SmalltalkImage SequenceableCollection Set Semaphore SmallInteger >>>> >> Symbol String SourceFileArray VirtualMachine OCCompilerTest >>>> >> SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest >>>> >> BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest >>>> >> LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod >>>> >> S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage >>>> >> S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method >>>> >> S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin >>>> >> S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack >>>> >> S2StringNewPlugin S2TestException S2Tester S2TesterClass >>>> >> S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB >>>> >> S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod >>>> >> S2pySenderStubPackage >>>> >> >>>> >> Cheers, >>>> >> -- Pavel >>>> >> >>>> > >>>> > >

Dec. 4, 2014

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

by Tudor Girba

In that presentation, yes. Doru On Thu, Dec 4, 2014 at 1:09 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > "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. > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 4, 2014

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