- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now!

by denker

> On 16 Feb 2017, at 16:10, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Tue, Feb 14, 2017 at 03:17:42PM +0100, Marcus Denker wrote: >> Hi, >> >> The new Pharo Association website is up and running for some month. >> >> If you are a member, it will bug you once a year to renew. > > Maybe there should be information that the membership (and fee) is automatic due to contributing to the pharo salt or bounty program (or whatever it is called). I also assume that that will automatically update the membership when the due time comes. Yes, there is a hidden field with that info. At the start of the year I prolongated everyone after checking that the info is still valid. Salt is not well done, though. Eg. there is *no* way to get notified about new sponsors, and they do not anwer *any* support requests. e.g. changing the description of a level is impossible, basic things like that. (even though we pay 10% of all income for itâ¦) Marcus

Feb. 16, 2017

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

by denker

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) 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

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now!

by Peter Uhnak

On Tue, Feb 14, 2017 at 03:17:42PM +0100, Marcus Denker wrote: > Hi, > > The new Pharo Association website is up and running for some month. > > If you are a member, it will bug you once a year to renew. Maybe there should be information that the membership (and fee) is automatic due to contributing to the pharo salt or bounty program (or whatever it is called). I also assume that that will automatically update the membership when the due time comes. Peter > > If you were a member in the past and have not been bugged by the system to renew until now, > please subscribe now as a new member. > > (We added all active members, but as the old system was purely manual, people did not get > asked to renew very consistently and you might not be in the system anymore) > > See the website for more information: > > https://association.pharo.org <https://association.pharo.org/> > > > Marcus

Feb. 16, 2017