November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Cyril Ferlicot D.

On 11/11/2016 15:58, Stephan Eggermont wrote: > Revert and first do a deprecation phase > > Stephan > > > +1 It would be cool to go by a deprecation phase indeed. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 11, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Stephan Eggermont

On 11/11/16 10:55, Pavel Krivanek wrote: > Hi, > > the API of Pragma was changed in quite dangerous way. > In past we had: > - #selector to access to method selector > - #keyword to access to pragma selector > > now we have: > - #methodSelector to access to method selector > - #selector to access to pragma selector Revert and first do a deprecation phase Stephan

Nov. 11, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Cyril Ferlicot D.

Le 11/11/2016 Ã 10:55, Pavel Krivanek a Ã©crit : > Hi, > > the API of Pragma was changed in quite dangerous way. > In past we had: > - #selector to access to method selector > - #keyword to access to pragma selector > > now we have: > - #methodSelector to access to method selector > - #selector to access to pragma selector > > That means that the meaning of the message #selector was changed and it > can cause some problems (like some currently failing tests [1]). The > #selector message was deprecated in the middle of the transition process > so most of usages should be already rewritten to #methodSelector but we > need to be aware of it. > > [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to-MockSe… > > Cheers > -- Pavel Hi! Thank you for the report. This broke the latest Metacello. I opened an issue: https://github.com/dalehenrich/metacello-work/issues/424 -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 11, 2016

Re: [Pharo-dev] LMDB

by Jan van de Sandt

Hi, On OSX you can use Homebrew to install LMDB. This will install the 64bit version. If you want the 32bit version you will have to tweak the recipe. Jan. On Fri, Nov 11, 2016 at 11:32 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 05/11/16 13:55, Jan van de Sandt wrote: > >> LMDB is a lean, mean and very fast storage engine. One limitation is >> that you need a 64bit proces before you can store more than 2GB of data. >> That was a downside for me until very recently :-) >> >> LMDB is a low level key-value storage engine that runs on a single host. >> But if that is what you are looking for it seems pretty good. I haven't >> used it in any production systems yet. But it is used as a storage >> engine in quite a few open source projects. For example OpenLDAP. >> > > Do I really need to compile LMDB myself? > > Stephan > > >

Nov. 11, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Thierry Goubier

Le 11/11/2016 Ã 11:29, Stephan Eggermont a Ã©crit : > On 10/11/16 21:35, Igor Stasenko wrote: >> No, no, no! This is simply not true. >> It is you, who writes the code that generates a lot of statistical >> data/analysis data, and its output is fairly predictable.. else you are >> not collecting any data, but just a random noise, isn't? > > That would be green field development. In brown field development, I > only get in when people start noticing there is a problem (why do we > need more than 4GBytes for this?). At that point I want to be able to > load everything they can give me in an image so I can start analyzing > and structuring it. > >> I mean, Doru is light years ahead of me and many others in field of data >> analysis.. so what i can advise to him on his playground? > > Well, the current FAMIX model implementation is clearly not well > structured for analyzing large code bases. And it is difficult to > partition because of unpredictable access patterns and high > interconnection. This is why you look for a general purpose, efficient off-loading scheme, trying to optimize a general case and get reasonable performance out of it (a.k.a fuel, but designed for partial unloading / loading: allow dangling references in a unit of load, focus on per-page units to match the underlying storage layer or network). I wrote one such layer for VW a long time ago, but didn't had time to experiment / qualify some of the techniques in it. There was an interesting attempt (IMHO ... wasn't qualified) at combining paging and automatic refinement of application working set, based on previous experience implementing a hierarchical 2D object access scheme for large datasets on slow medium (decreased access time from 30 minutes to about a few seconds). The other approach I would look is take some of the support code for such an automatic layer and use it to unload parts of my model;, and I'm pretty sure that, if I don't bench intensively, I'll get the partitioning wrong :( Overall, an interesting subject, totally not valid from a scientific point of view (the database guys have already solved everything). Only valid as a hobby, or if a company is ready to pay for a solution. Thierry

Nov. 11, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Tudor Girba

Hi, The discussion on this thread had nothing to do with FAMIX or Moose. It had to do with peopleâs ability to load larger pieces of data in the image without the VM imposing a low limit on it. There are clear scenarios where this is desirable, and I do not understand why this is a topic of conversation these days. The move to 64bit is a significant advantage in this area and we should applaud it. Doru > On Nov 11, 2016, at 11:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 10/11/16 21:35, Igor Stasenko wrote: >> No, no, no! This is simply not true. >> It is you, who writes the code that generates a lot of statistical >> data/analysis data, and its output is fairly predictable.. else you are >> not collecting any data, but just a random noise, isn't? > > That would be green field development. In brown field development, I only get in when people start noticing there is a problem (why do we need more than 4GBytes for this?). At that point I want to be able to load everything they can give me in an image so I can start analyzing and structuring it. > >> I mean, Doru is light years ahead of me and many others in field of data >> analysis.. so what i can advise to him on his playground? > > Well, the current FAMIX model implementation is clearly not well structured for analyzing large code bases. And it is difficult to partition because of unpredictable access patterns and high interconnection. > > Stephan > > -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

Nov. 11, 2016

LMDB

by Stephan Eggermont

On 05/11/16 13:55, Jan van de Sandt wrote: > LMDB is a lean, mean and very fast storage engine. One limitation is > that you need a 64bit proces before you can store more than 2GB of data. > That was a downside for me until very recently :-) > > LMDB is a low level key-value storage engine that runs on a single host. > But if that is what you are looking for it seems pretty good. I haven't > used it in any production systems yet. But it is used as a storage > engine in quite a few open source projects. For example OpenLDAP. Do I really need to compile LMDB myself? Stephan

Nov. 11, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Stephan Eggermont

On 10/11/16 21:35, Igor Stasenko wrote: > No, no, no! This is simply not true. > It is you, who writes the code that generates a lot of statistical > data/analysis data, and its output is fairly predictable.. else you are > not collecting any data, but just a random noise, isn't? That would be green field development. In brown field development, I only get in when people start noticing there is a problem (why do we need more than 4GBytes for this?). At that point I want to be able to load everything they can give me in an image so I can start analyzing and structuring it. > I mean, Doru is light years ahead of me and many others in field of data > analysis.. so what i can advise to him on his playground? Well, the current FAMIX model implementation is clearly not well structured for analyzing large code bases. And it is difficult to partition because of unpredictable access patterns and high interconnection. Stephan

Nov. 11, 2016

Pragma keyword / selector / methodSelector

by Pavel Krivanek

Hi, the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector now we have: - #methodSelector to access to method selector - #selector to access to pragma selector That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it. [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to- MockSettings-class-Object-doesNotUnderstand-mocksystemsettings- SettingTreeBuilder-mocksystemse Cheers -- Pavel

Nov. 11, 2016

[pharo-project/pharo-core] c45285: 60289

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: c452852ec93afaf5e1f8b1fec8b94d27cefd2122 https://github.com/pharo-project/pharo-core/commit/c452852ec93afaf5e1f8b1fe… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-11 (Fri, 11 Nov 2016) Changed paths: A BaselineOfBasicTools.package/BaselineOfBasicTools.class/README.md A BaselineOfBasicTools.package/BaselineOfBasicTools.class/definition.st A BaselineOfBasicTools.package/BaselineOfBasicTools.class/instance/actions/postload_package_.st A BaselineOfBasicTools.package/BaselineOfBasicTools.class/instance/baseline/baseline_.st A BaselineOfBasicTools.package/BaselineOfBasicTools.class/instance/baseline/project.st A BaselineOfDisplay.package/BaselineOfDisplay.class/README.md A BaselineOfDisplay.package/BaselineOfDisplay.class/definition.st A BaselineOfDisplay.package/BaselineOfDisplay.class/instance/actions/installBitmap.st A BaselineOfDisplay.package/BaselineOfDisplay.class/instance/actions/postload_package_.st A BaselineOfDisplay.package/BaselineOfDisplay.class/instance/actions/preload_package_.st A BaselineOfDisplay.package/BaselineOfDisplay.class/instance/baseline/baseline_.st A BaselineOfIDE.package/BaselineOfIDE.class/README.md A BaselineOfIDE.package/BaselineOfIDE.class/definition.st A BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/additionalInitialization.st A BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/postload_package_.st A BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/preload_package_.st A BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st A BaselineOfMorphic.package/BaselineOfMorphic.class/README.md A BaselineOfMorphic.package/BaselineOfMorphic.class/definition.st A BaselineOfMorphic.package/BaselineOfMorphic.class/instance/actions/cleanUpAfterMorphicInitialization.st A BaselineOfMorphic.package/BaselineOfMorphic.class/instance/actions/postload_package_.st A BaselineOfMorphic.package/BaselineOfMorphic.class/instance/actions/preload_package_.st A BaselineOfMorphic.package/BaselineOfMorphic.class/instance/baseline/baseline_.st A BaselineOfMorphic.package/BaselineOfMorphic.class/instance/baseline/project.st A BaselineOfMorphicCore.package/BaselineOfMorphicCore.class/README.md A BaselineOfMorphicCore.package/BaselineOfMorphicCore.class/definition.st A BaselineOfMorphicCore.package/BaselineOfMorphicCore.class/instance/actions/postload_package_.st A BaselineOfMorphicCore.package/BaselineOfMorphicCore.class/instance/baseline/baseline_.st A BaselineOfSUnit.package/BaselineOfSUnit.class/README.md A BaselineOfSUnit.package/BaselineOfSUnit.class/definition.st A BaselineOfSUnit.package/BaselineOfSUnit.class/instance/baseline/baseline_.st A BaselineOfUI.package/BaselineOfUI.class/README.md A BaselineOfUI.package/BaselineOfUI.class/definition.st A BaselineOfUI.package/BaselineOfUI.class/instance/actions/postload_package_.st A BaselineOfUI.package/BaselineOfUI.class/instance/actions/preload_package_.st A BaselineOfUI.package/BaselineOfUI.class/instance/baseline/baseline_.st A BaselineOfUI.package/BaselineOfUI.class/instance/baseline/project.st A BaselineOfUnifiedFFI.package/BaselineOfUnifiedFFI.class/README.md A BaselineOfUnifiedFFI.package/BaselineOfUnifiedFFI.class/definition.st A BaselineOfUnifiedFFI.package/BaselineOfUnifiedFFI.class/instance/actions/postload_package_.st A BaselineOfUnifiedFFI.package/BaselineOfUnifiedFFI.class/instance/actions/preload_package_.st A BaselineOfUnifiedFFI.package/BaselineOfUnifiedFFI.class/instance/baseline/baseline_.st M Flashback-Decompiler.package/FBDDecompiler.class/instance/initialize/pragmasForMethod_.st M Kernel-Tests.package/ClassDescriptionTest.class/instance/tests/testClassDescriptionRespectsPolymorphismWithTraitDescription.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60288.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60289.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60288.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60289.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60289 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions https://pharo.fogbugz.com/f/cases/18760 19327 failing tests testClassDescriptionRespectsPolymorphismWithTraitDescription https://pharo.fogbugz.com/f/cases/19327 19314 integrate basic baselines https://pharo.fogbugz.com/f/cases/19314 http://files.pharo.org/image/60/60289.zip

Nov. 11, 2016