February 2017 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60400 Home: https://github.com/pharo-project/pharo-core

Feb. 17, 2017

[pharo-project/pharo-core] 358123: 60400

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 35812356035b31d7143acab90c36026291ed5976 https://github.com/pharo-project/pharo-core/commit/35812356035b31d7143acab9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-17 (Fri, 17 Feb 2017) Changed paths: R Collections-Abstract.package/SequenceableCollection.class/instance/private/checkedAt_.st R Collections-Abstract.package/SequenceableCollection.class/instance/private/errorFirstObject_.st R Collections-Abstract.package/SequenceableCollection.class/instance/private/errorLastObject_.st R Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/instance/accessing/setMultipleSelection_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/setMultipleSelection_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60399.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60400.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60399.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60400.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60400 19723 Nuke SequenceableCollection>>#checkedAt: https://pharo.fogbugz.com/f/cases/19723 19722 Move setMultipleSelection to FTTableMorph https://pharo.fogbugz.com/f/cases/19722 http://files.pharo.org/image/60/60400.zip

Feb. 17, 2017

Re: [Pharo-dev] FileTree

by Jonathan Khalil

Oh really ? My school is Ecole SupÃ©rieur Polytechnique (ESP). I want to rewrite the pharoCandle in the FileTree format but i don't know where to start. Jonathan 2017-02-17 16:37 GMT+01:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Fri, Feb 17, 2017 at 3:06 PM, Jonathan Khalil <jonathan(a)esp.sn> wrote: > > Hi everyone, > > > > I'm Jonathan, student in master, from Dakar, SÃ©nÃ©gal and i will be > working > > with stephane ducasse's team for my internship. > > Great Jonathan. Where are you located ? My research team is working in > Senegal in Dakar and St-Louis. > > > I need some lectures on FileTree. > > Someone know how can i get it ? > > What kind of information you are looking for FileTree ? > I'm not sure that there is that much information about it except the code > :-) > > https://github.com/dalehenrich/filetree > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Feb. 17, 2017

Re: [Pharo-dev] FileTree

by Serge Stinckwich

On Fri, Feb 17, 2017 at 3:06 PM, Jonathan Khalil <jonathan(a)esp.sn> wrote: > Hi everyone, > > I'm Jonathan, student in master, from Dakar, SÃ©nÃ©gal and i will be working > with stephane ducasse's team for my internship. Great Jonathan. Where are you located ? My research team is working in Senegal in Dakar and St-Louis. > I need some lectures on FileTree. > Someone know how can i get it ? What kind of information you are looking for FileTree ? I'm not sure that there is that much information about it except the code :-) https://github.com/dalehenrich/filetree Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 17, 2017

FileTree

by Jonathan Khalil

Hi everyone, I'm Jonathan, student in master, from Dakar, SÃ©nÃ©gal and i will be working with stephane ducasse's team for my internship. I need some lectures on FileTree. Someone know how can i get it ? Thanks Jonathan

Feb. 17, 2017

Metacello and big Github repositories

by Pavel Krivanek

Hi, as already mentioned in GT Event Recorder help, current Pharo version does not support ZIP signature that is used for large files. That starts to be Metacello issue as soon as you need to work with some large Git repository because Metacello firstly downloads the repository working copy in the form of ZIP file. To reproduce try: Metacello new baseline: 'Moose'; repository: 'github://pavel-krivanek/Moose/repository'; load. or: ZnClient new url: 'https://github.com/pavel-krivanek/Moose/zipball/master'; downloadTo: 'archive.zip'. ZipArchive new readFrom: 'archive.zip' asFileReference. The workaround is to work with a local clone of the repository. Cherrs, -- Pavel

Feb. 17, 2017

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

by ClÃ©ment Bera

On Fri, Feb 17, 2017 at 1:48 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 17/02/2017 Ã 13:31, ClÃ©ment Bera a Ã©crit : > > > > > > It may solve part of the problem. > > > > Another problem is that tenure heuristics needs to be changed when > > allocating lots of long-lived objects. One needs to implement a GCPolicy > > object in the image and use it from the application code... > > > > > > What would be needed in order to make this work? I don't know the GC > enough to know what this imply. > Basically you need to have a look at the GC heuristics and analyse how they impact GC performance. Based on that, you can have a GCPolicy instance to which you can send messages such as #changePolicyForLargeHeap, #changePolicyForSmallHeaps or #growingPolicyDuring: aBlock. Internally the GCPolicy object changes GC heuristics. Some heuristics are already present in the vmParameter primitive (Smalltalk vm parameterAt: 46 for example), but some of them currently require the VM to be restarted. A first step would be to investigate those parameters. For example, the GCPolicy could read those parameters to know what is the current status: *2 size of young/new-space (read-only)* * 3 size of heap (read-only)* * 6 survivor count tenuring threshold (read-write)* * 7 full GCs since startup (read-only)* * 8 total milliseconds in full GCs since startup (read-only)* * 9 scavenges since startup (read-only)* * ...* * 55 ratio of growth and image size at or above which a GC will be performed post scavenge* * 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)* Based on this and the message sent to the GCPolicy, one can set new GC heuristics through those parameters: *6 survivor count tenuring threshold (read-write)* * ...* * 45 desired size of eden, in bytes (stored in image file header)* * 55 ratio of growth and image size at or above which a GC will be performed post scavenge* What has to be done is: - create a GCPolicy object with methods such as #changePolicyForLargeHeap, #changePolicyForSmallHeaps or #growingPolicyDuring: aBlock. - use the VM parameters in those methods to analyse the current state and define new heuristics - define a range in which the parameters can be changed without crashing the VM - add new parameters on heuristics that are important but not configurable right now - add the possibility to change several heuristics without restarting the image (for example change of Eden size or existing memory segment size) For example, let's say you grow your image from 30 Mb to 8Gb (I think one of our larger user in 64 bits use 8 Gb images right now and the default Pharo image is around 30 Mb). An uncommonly high rate of objects are promoted from young space to old space and the memory is expected to grow by 26667%. So you may want to: - decrease the survivor count for tenures. This way your objects are promoted earlier to old objects. - increase the ratio of growth. Instead of doing a full GC each time the image size grow by 33% you may want to do it each time the image size is increased by 900%. This way instead of having 20 fullGC while growing you have only 3. You switch back the policy at the end and trigger manually a fourth fullGC and everything's fine. Maybe we don't need a GCPolicy object, but more a VMPolicy object, so we can conveniently tweak the stack (number and size of stack page) and machine code zone. If somebody wants to have fun :-) > > > > > No one is working on this right now, but it's next step to improve the > GC. > > > > When the development starts on this feature I can give you more > > information. If a paying customer requests it, it should be done in a > > couple months. > > > > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Feb. 17, 2017

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

by Cyril Ferlicot D.

Le 17/02/2017 Ã 13:31, ClÃ©ment Bera a Ã©crit : > > > It may solve part of the problem. > > Another problem is that tenure heuristics needs to be changed when > allocating lots of long-lived objects. One needs to implement a GCPolicy > object in the image and use it from the application code... > > What would be needed in order to make this work? I don't know the GC enough to know what this imply. > > No one is working on this right now, but it's next step to improve the GC. > > When the development starts on this feature I can give you more > information. If a paying customer requests it, it should be done in a > couple months. > > -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 17, 2017

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

by ClÃ©ment Bera

On Fri, Feb 17, 2017 at 12:05 PM, Cyril Ferlicot D. < cyril.ferlicot(a)gmail.com> wrote: > Le 17/02/2017 Ã 07:17, ClÃ©ment Bera a Ã©crit : > > The full GC is indeed much faster as the previous compaction algorithm > > was very slow. But unless you were executing memory intensive code in > > very large heaps, you won't see much difference as full GC are uncommon. > > We still need to make the GC incremental to avoid pauses ... > > > > > > > > Can this fix the problem that MSE materialization takes 4 time longer > with spur memory management? It would be really cool :) > It may solve part of the problem. Another problem is that tenure heuristics needs to be changed when allocating lots of long-lived objects. One needs to implement a GCPolicy object in the image and use it from the application code... > > Do you have an idea of when the first incr GC without pause will be > available? (No rush, it's just for info to know if it's in months or > years :) ) > > No one is working on this right now, but it's next step to improve the GC. When the development starts on this feature I can give you more information. If a paying customer requests it, it should be done in a couple months. -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Feb. 17, 2017

[Issue Tracker][Pharo5] Please check issues tagged Pharo5

by Marcus Denker

Hello, We have still 9 issues that are tagged with the Pharo5 Milestone. Please everyone who either submitted the issue or was involved in the discussions: - Is this issue still relevant? - Is it maybe fixed in Pharo6? - Is is important enough to require a backport to Pharo5? https://pharo.fogbugz.com/f/filters/125/5-0-All <https://pharo.fogbugz.com/f/filters/125/5-0-All> Marcus

Feb. 17, 2017