- Pharo-dev - lists.pharo.org

debugger evaluator tab for temporary variables

by Ben Coman

A minor irritation with the debugger is that the [Evaluator] tab is only for the object of the selected instance variable. IIUC, to write a snippet of code using a local variable you must edit the code of the method, which dirties it. I've lived with this, but thinking of newcomer first impressions for Pharo 6, an [Evaluator] tab next to the existing [Variables] tab with access to the whole method scope would be really nice. cheers -ben

Feb. 17, 2017

debugger highlighting objects up the stack

by Ben Coman

Just a brief throw away idea to share before it floats off on its own, it could be useful from the debugger being able to select a variable, and for the object it contains, ask the debugger to highlight up the stack where that object exists in variables and in code. Could be complicated - may need to: * autoscroll the debugger's inspector pane * annotate previously sent messages with the identity hash of the object returned cheers -ben

Feb. 17, 2017

Re: [Pharo-dev] FastTableModel switched from default single-select to multi

by Stephan Eggermont

On 16/02/17 20:37, Martin Dias wrote: > I set the case to "Milestone Later"... I reproduced the bug in Pharo 5 It is somewhat more complex. I have the problem with doubleClick, but not if only adding a doubleClick handler. In SpecGenerator I set some more properties. Stephan

Feb. 17, 2017

Re: [Pharo-dev] Pharo Papers

by Alexandre Bergel

But you will not get the papers not stored on HAL. And I suspect there are more papers about Pharo outside the HAL world. Alexandre > On Feb 16, 2017, at 11:13 AM, denker <marcus.denker(a)inria.fr> wrote: > > One idea on my TODO that I got from colleagues here working on another OpenSource/Research > system (Sofa3D): to add all publication to the website automatically using HAL (the national french > paper database). > > It looks like this on the website: > https://www.sofa-framework.org/applications/publications/ > > and here âhow to add a paperâ: > > https://www.sofa-framework.org/applications/publications/add-a-publication-… > > I will definitely set this up for Pharo later this year (read: as soon as possible) > > Marcus > > >> On 16 Feb 2017, at 14:30, Ben Coman <btc(a)openinworld.com> wrote: >> >> And now for your regularly scheduled random trivia show... >> I was mildly curious about how many papers touched on Pharo. >> >> 1,110 on google scholar for... >> "pharo" "programming" >> http://tiny.cc/pharo-scholar >> >> 1,630 on normal google for... >> "pharo" "programming" "abstract" "introduction" "conclusion" >> "references" filetype:pdf >> http://tiny.cc/pharo-papers >> >> Probably a lot of overlap between them. >> cheers -ben >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 16, 2017

Re: [Pharo-dev] FastTableModel switched from default single-select to multi

by Martin Dias

I set the case to "Milestone Later"... I reproduced the bug in Pharo 5 On Wed, Feb 15, 2017 at 2:01 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Reported as https://pharo.fogbugz.com/f/cases/19715/FastTableModel- > Can-t-enable-multiple-selection > > I checked that multiple selection works with ListModel (the superclass of > FastTableModel). > > Martin > > > On Wed, Feb 15, 2017 at 1:56 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Hi, >> >> I can't reproduce in #60394. In fact I *want* multiple selection and only >> get single selection: >> >> FastTableModel new beMultipleSelection; items: (1 to: 10) asArray; >> openWithSpec. >> >> Martin >> >> >> >> On Mon, Feb 13, 2017 at 9:03 PM, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >> >>> On 13/02/17 12:52, Andrei Chis wrote: >>> >>>> Is this in the Glamour model or in the Spec one? >>>> >>> >>> In the Spec one, so I might be a bit late in noticing. >>> >>> Stephan >>> >>> >>> >>> >> >

Feb. 16, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by Sven Van Caekenberghe

Thanks, ClÃ©ment, for this update, really exciting news. Is the new GC faster too ? > On 16 Feb 2017, at 17:16, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi all, > > A temporary solution had been integrated in the VM a year ago, but only part of the problem was solved. > > This issue has been entirely solved in the VM through the implementation of a new compactor for the full GC. The new compactor (called the planning compactor) has been marked as the default full GC compactor for further VM builds yesterday, replacing the existing Pig compactor. However it seems that the new compactor has not yet passed all the validation infrastructure (several builds are currently marked as 'error'). > > I would expect VM builds in the incoming days to feature the new compactor. This problem should therefore be solved very soon in the latest pharo VMs. > > In any case, this problem does not require any image-side changes. It will be in Pharo 6 if the Pharo 6 release VM features the new compactor. > > Best, > > Clement > > On Thu, Feb 16, 2017 at 4:26 PM, denker <marcus.denker(a)inria.fr> wrote: > > > On 16 Feb 2017, at 16:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 16 Feb 2017, at 16:16, denker <marcus.denker(a)inria.fr> wrote: > >> > >> No, > >> > >> Our image is not 47 MBâ¦ more like 28. > >> > >> My understanding is: > >> -> Cog works with âpagesâ (is that the term?) of memory. > >> -> if a page is empty, it gets cleaned up and does not cost space when saving. > >> -> if there is some object still allocated, the whole page will be saved (partly empty) > >> > >> Not sure if that is completely right, but it explains why the image with > >> lots of objects allocated new can shrink again, while the 47MB never shrinks, even though the > >> image for sure is much smaller. > >> > >> => what is missing is a âcleanupâ phase that sweeps together all the half-empty pages. > >> > >> What is fun is that we now ship a 47MB image and nobody ever complains. (or even asks) > > > > Yeah, that proves it is not such a big deal, today. > > But still, we have to fix this discrepancy between 28 and 47. > > > > > As I tried to explain: the VM is missing a âcondenserâ that cleans up half allocated pages. > > > Is the 'release cleanup' done on this image each time ? > > Yes. > > Marcus >

Feb. 16, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by Ben Coman

On Thu, Feb 16, 2017 at 11:16 PM, denker <marcus.denker(a)inria.fr> wrote: > > What is fun is that we now ship a 47MB image and nobody ever complains. (or even asks) > yes thats strange. 640KB ought to have been enough for anyone! cheers -ben

Feb. 16, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by ClÃ©ment Bera

Hi all, A temporary solution had been integrated in the VM a year ago, but only part of the problem was solved. This issue has been entirely solved in the VM through the implementation of a new compactor for the full GC. The new compactor (called the planning compactor) has been marked as the default full GC compactor for further VM builds *yesterday,* replacing the existing Pig compactor. However it seems that the new compactor has not yet passed all the validation infrastructure (several builds are currently marked as 'error'). I would expect VM builds in the incoming days to feature the new compactor. This problem should therefore be solved very soon in the latest pharo VMs. In any case, this problem does not require any image-side changes. It will be in Pharo 6 if the Pharo 6 release VM features the new compactor. Best, Clement On Thu, Feb 16, 2017 at 4:26 PM, denker <marcus.denker(a)inria.fr> wrote: > > > On 16 Feb 2017, at 16:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 16 Feb 2017, at 16:16, denker <marcus.denker(a)inria.fr> wrote: > >> > >> No, > >> > >> Our image is not 47 MBâ¦ more like 28. > >> > >> My understanding is: > >> -> Cog works with âpagesâ (is that the term?) of memory. > >> -> if a page is empty, it gets cleaned up and does not cost space > when saving. > >> -> if there is some object still allocated, the whole page will be > saved (partly empty) > >> > >> Not sure if that is completely right, but it explains why the image with > >> lots of objects allocated new can shrink again, while the 47MB never > shrinks, even though the > >> image for sure is much smaller. > >> > >> => what is missing is a âcleanupâ phase that sweeps together all the > half-empty pages. > >> > >> What is fun is that we now ship a 47MB image and nobody ever complains. > (or even asks) > > > > Yeah, that proves it is not such a big deal, today. > > But still, we have to fix this discrepancy between 28 and 47. > > > > > As I tried to explain: the VM is missing a âcondenserâ that cleans up half > allocated pages. > > > Is the 'release cleanup' done on this image each time ? > > Yes. > > Marcus >

Feb. 16, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by denker

> On 16 Feb 2017, at 16:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 16 Feb 2017, at 16:16, denker <marcus.denker(a)inria.fr> wrote: >> >> No, >> >> Our image is not 47 MBâ¦ more like 28. >> >> My understanding is: >> -> Cog works with âpagesâ (is that the term?) of memory. >> -> if a page is empty, it gets cleaned up and does not cost space when saving. >> -> if there is some object still allocated, the whole page will be saved (partly empty) >> >> Not sure if that is completely right, but it explains why the image with >> lots of objects allocated new can shrink again, while the 47MB never shrinks, even though the >> image for sure is much smaller. >> >> => what is missing is a âcleanupâ phase that sweeps together all the half-empty pages. >> >> What is fun is that we now ship a 47MB image and nobody ever complains. (or even asks) > > Yeah, that proves it is not such a big deal, today. > But still, we have to fix this discrepancy between 28 and 47. > As I tried to explain: the VM is missing a âcondenserâ that cleans up half allocated pages. > Is the 'release cleanup' done on this image each time ? Yes. Marcus

Feb. 16, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by Sven Van Caekenberghe

> On 16 Feb 2017, at 16:16, denker <marcus.denker(a)inria.fr> wrote: > > No, > > Our image is not 47 MBâ¦ more like 28. > > My understanding is: > -> Cog works with âpagesâ (is that the term?) of memory. > -> if a page is empty, it gets cleaned up and does not cost space when saving. > -> if there is some object still allocated, the whole page will be saved (partly empty) > > Not sure if that is completely right, but it explains why the image with > lots of objects allocated new can shrink again, while the 47MB never shrinks, even though the > image for sure is much smaller. > > => what is missing is a âcleanupâ phase that sweeps together all the half-empty pages. > > What is fun is that we now ship a 47MB image and nobody ever complains. (or even asks) Yeah, that proves it is not such a big deal, today. But still, we have to fix this discrepancy between 28 and 47. Is the 'release cleanup' done on this image each time ? > Marcus > >> On 16 Feb 2017, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> What Ben says that he thinks it might already be solved. >> >> Maybe not on all platforms. >> >>> On 16 Feb 2017, at 15:59, denker <marcus.denker(a)inria.fr> wrote: >>> >>> Yes, this has to be solved on the VM level and will be read when it is ready. >>> The release should bot be hold up due to this, therefore I removed the milestone. >>> >>>> On 16 Feb 2017, at 15:50, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> @Marcus, I was reviewing this issue before I noticed you flipped the >>>> milestone from Pharo 6.0 to Later. >>>> >>>> But is it solved already? >>>> In a fresh image 47.7MB in size >>>> I did the following a bunch of times to grow the image file to 400MB >>>> o ifNil: [o := OrderedCollection new]. >>>> 100 timesRepeat: [ o add: (Array new: 100000) ]. >>>> Smalltalk saveSession >>>> >>>> then I did this >>>> o := nil. >>>> Smalltalk saveSession. >>>> >>>> and the image file returned to 47.7MB. >>>> >>>> Version info... >>>> Linux Debian 8 Jessie 32-bit >>>> Latest update: #60391 >>>> CoInterpreter VMMaker.oscog-eem.1855 uuid: >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>>> https://github.com/pharo-project/pharo-vm.git Commit: >>>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 >>>> +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >>>> >>>> https://pharo.fogbugz.com/f/cases/17240/Spur-When-saving-an-image-it-never-… >>>> >>>> cheers -ben >>>> >>> >>> >> >> > >

Feb. 16, 2017