- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [IMPORTANT] Starting migration to Spur VM

by Esteban Lorenzano

> On 15 Jan 2016, at 16:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Could this be the cause of Johan crashes since Spur? this what? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jan 15, 2016, at 12:16 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> 2015-12-14 11:24 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> We will start migration to Spur today. >> To complete it, we will require some time, specially to adapt the CI and check everything is ok. >> >> Spur will allow us to do a big step forward in Pharo development, in the concrete you will see it immediately for this: >> - We have noticed a speed increment of 100% in tiny benchmarks (and according to Eliot, it will be at least 35% in general on the system). >> - No more GC stops (noticeable when running large systems) >> - We will be able to scale our systems up to 2G memory consumption without loosing performance. >> >> But, this will have some drawbacks in the first times: >> >> 1) VM will not be compatible between versions anymore: Pharo 5.0 will have a Pharo Spur VM associated (and they are not compatible). >> - There WILL NOT be a "non-spur" version of Pharo 5.0. Once completed the transitions, this will be the only one. >> >> 2) NativeBoost-FFI implementation has been replaced with a new implementation who relies in ThreadedFFIPlugin and IA32Plugin. While we worked a lot to do this transition as painless as possible and we achieve a good level of backward compatibility (most uses of #nbCall: should work out of the box), there are some problems we cannot solve: >> - there are some stuff not possible to compatibilise, notably: >> - Structures now need to inherit from FFIExternalStructure >> - Arrays now are now shadowed >> - in general is a bit slower (impossible to compete with ASM) but in general is not perceptible. >> - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current implementation is validated with Athens and even Roassal was working, but of course that does not covers all cases. >> 2.1) ASMJIT will be removed from system and put in a separated packages. >> NOTE: There will be a blog post explaining FFI-NB architecture during the week. >> >> 3) There are more or less 70 new failing tests, some of them important than we need to fix as soon as possible. Please, please, please, help us with them :) >> >> 4) In general we foresee the system will became unstable some weeks, before it gets back to normal. Please be patient. >> >> 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to take care about new VM). Some programs will stop work at all (for example, I think Pharo-launcher will need to be adapted). >> >> >> >> >> Some more information about lost instvars for some classes >> Character https://pharo.fogbugz.com/f/cases/17393/prepare-integration-of-session-mana… <https://pharo.fogbugz.com/f/cases/17393/prepare-integration-of-session-mana…> >> Athens 17357 <https://pharo.fogbugz.com/f/cases/17357/Lost-instance-variables-AthensCairo…> Lost instance variables (AthensCairoPatternSurfacePaint) >> >> Is it right that they are gone (new immediate character class and new FFI base for Athens) >> or what happened? >> >> >> >

Jan. 15, 2016

Re: [Pharo-dev] [IMPORTANT] Starting migration to Spur VM

by Alexandre Bergel

Could this be the cause of Johan crashes since Spur? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 15, 2016, at 12:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-14 11:24 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > We will start migration to Spur today. > To complete it, we will require some time, specially to adapt the CI and check everything is ok. > > Spur will allow us to do a big step forward in Pharo development, in the concrete you will see it immediately for this: > - We have noticed a speed increment of 100% in tiny benchmarks (and according to Eliot, it will be at least 35% in general on the system). > - No more GC stops (noticeable when running large systems) > - We will be able to scale our systems up to 2G memory consumption without loosing performance. > > But, this will have some drawbacks in the first times: > > 1) VM will not be compatible between versions anymore: Pharo 5.0 will have a Pharo Spur VM associated (and they are not compatible). > - There WILL NOT be a "non-spur" version of Pharo 5.0. Once completed the transitions, this will be the only one. > > 2) NativeBoost-FFI implementation has been replaced with a new implementation who relies in ThreadedFFIPlugin and IA32Plugin. While we worked a lot to do this transition as painless as possible and we achieve a good level of backward compatibility (most uses of #nbCall: should work out of the box), there are some problems we cannot solve: > - there are some stuff not possible to compatibilise, notably: > - Structures now need to inherit from FFIExternalStructure > - Arrays now are now shadowed > - in general is a bit slower (impossible to compete with ASM) but in general is not perceptible. > - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current implementation is validated with Athens and even Roassal was working, but of course that does not covers all cases. > 2.1) ASMJIT will be removed from system and put in a separated packages. > NOTE: There will be a blog post explaining FFI-NB architecture during the week. > > 3) There are more or less 70 new failing tests, some of them important than we need to fix as soon as possible. Please, please, please, help us with them :) > > 4) In general we foresee the system will became unstable some weeks, before it gets back to normal. Please be patient. > > 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to take care about new VM). Some programs will stop work at all (for example, I think Pharo-launcher will need to be adapted). > > > > > Some more information about lost instvars for some classes > Character https://pharo.fogbugz.com/f/cases/17393/prepare-integration-of-session-mana… <https://pharo.fogbugz.com/f/cases/17393/prepare-integration-of-session-mana…> > Athens 17357 <https://pharo.fogbugz.com/f/cases/17357/Lost-instance-variables-AthensCairo…> Lost instance variables (AthensCairoPatternSurfacePaint) > > Is it right that they are gone (new immediate character class and new FFI base for Athens) > or what happened? > > >

Jan. 15, 2016

Re: [Pharo-dev] [IMPORTANT] Starting migration to Spur VM

by Nicolai Hess

2015-12-14 11:24 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > We will start migration to Spur today. > To complete it, we will require some time, specially to adapt the CI and > check everything is ok. > > Spur will allow us to do a big step forward in Pharo development, in the > concrete you will see it immediately for this: > - We have noticed a speed increment of 100% in tiny benchmarks (and > according to Eliot, it will be at least 35% in general on the system). > - No more GC stops (noticeable when running large systems) > - We will be able to scale our systems up to 2G memory consumption without > loosing performance. > > But, this will have some drawbacks in the first times: > > 1) VM will not be compatible between versions anymore: Pharo 5.0 will have > a Pharo Spur VM associated (and they are not compatible). > - There WILL NOT be a "non-spur" version of Pharo 5.0. Once > completed the transitions, this will be the only one. > > 2) NativeBoost-FFI implementation has been replaced with a new > implementation who relies in ThreadedFFIPlugin and IA32Plugin. While we > worked a lot to do this transition as painless as possible and we achieve a > good level of backward compatibility (most uses of #nbCall: should work out > of the box), there are some problems we cannot solve: > - there are some stuff not possible to compatibilise, notably: > - Structures now need to inherit from FFIExternalStructure > - Arrays now are now shadowed > - in general is a bit slower (impossible to compete with ASM) but > in general is not perceptible. > - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current > implementation is validated with Athens and even Roassal was working, but > of course that does not covers all cases. > 2.1) ASMJIT will be removed from system and put in a separated packages. > NOTE: There will be a blog post explaining FFI-NB architecture during the > week. > > 3) There are more or less 70 new failing tests, some of them important > than we need to fix as soon as possible. Please, please, please, help us > with them :) > > 4) In general we foresee the system will became unstable some weeks, > before it gets back to normal. Please be patient. > > 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to > take care about new VM). Some programs will stop work at all (for example, > I think Pharo-launcher will need to be adapted). > > > Some more information about lost instvars for some classes Character https://pharo.fogbugz.com/f/cases/17393/prepare-integration-of-session-mana… Athens 17357 <https://pharo.fogbugz.com/f/cases/17357/Lost-instance-variables-AthensCairo…> Lost instance variables (AthensCairoPatternSurfacePaint) Is it right that they are gone (new immediate character class and new FFI base for Athens) or what happened?

Jan. 15, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 15, 2016

[pharo-project/pharo-core] 600ec5: 50528

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 600ec593e3899e60ae0faa71728ce5aef839b062 https://github.com/pharo-project/pharo-core/commit/600ec593e3899e60ae0faa71… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-15 (Fri, 15 Jan 2016) Changed paths: M Nautilus.package/NautilusUI.class/instance/private/updatePackageGroupAndClassList.st M Rubric.package/RubScrolledTextMorph.class/instance/model protocol/drawHighlightsOn_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50527.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50528.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50527.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50528.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/extension/ToolDockingBarMorph/instance/buildButtonFor_.st Log Message: ----------- 50528 17388 OSEnvironment current returns Unix environment on Windows https://pharo.fogbugz.com/f/cases/17388 17201 Marking Diffs broken in Pharo5 https://pharo.fogbugz.com/f/cases/17201 16488 Dropping a class from one browser to another package in another browser updates selected package+class in both https://pharo.fogbugz.com/f/cases/16488 17207 Spec (Toolbar)Menu buttons shouldnt look active by default https://pharo.fogbugz.com/f/cases/17207 http://files.pharo.org/image/50/50528.zip

Jan. 15, 2016

Re: [Pharo-dev] PluggableButtonMorph does not respect font size :(

by Tudor Girba

Hi, > On Jan 14, 2016, at 11:19 AM, stepharo <stepharo(a)free.fr> wrote: > > For the Pharo Mooc we need to use large font and we end up with this visual glitch :( > I tried to dive into PluggableButtonMorph and I failed to found how to make sure it computes the bound correctly. > Any help is welcome. > I really think that in Brick we should really be picky on such problems. Indeed. Actually, Alex Syrel spent 2 weeks to get this âlittleâ thing of computing the bounds of a string right (I think it works well now hopefully) :). Doru > Stef > > > <djbhggee..png> -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Jan. 15, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] OSSubprocess first milestone

by Mariano Martinez Peck

> > > Quick feedback: > > - the API seems great > - thank you very much for the documentation > Thanks! > - I wonder why you pass strings for stdout and stderr instead of streams > In which part exactly? In the method like #runAndWaitOnExitDo: ? if that was the question, then I simply thought it would be easier for the user to receive strings. In fact, internally I use streams, but just when I evaluate the closure I pass #contents. I think it's more common for users wanting a string than a stream. In either case, if they received a string they can do #readStreamDo:[] or whatever, and if they receive a stream they can do #contents. > - it would be nice to be able to subclass OSSUnixProcessExitStatus for > some commands. E.g., GitProcessExitStatus could have a method > isMergeConflict > That would be nice. > - how can I implement something like tail --follow > I think it would be nice to how an example of this type of streaming API. Note that this goes very similar to what Luc proposes below. Thanks for the feedback! -- Mariano http://marianopeck.wordpress.com

Jan. 15, 2016

Re: [Pharo-dev] How can we flush the remembered expressions of Playground?

by Tudor Girba

Hi, For manipulating the active bindings, you have a menu item on the top right: Doru > On Jan 15, 2016, at 12:09 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > For remembered expressions: Delete the folders play-cache and play-stash from the directory of the image and run 'GTPlayBook cleanUp' before opening the playground. > For the bindings: in the list of displayed binding each binding has an action that removes it from the list (It has an X icon) > > > Andrei > > On Fri, Jan 15, 2016 at 12:02 PM, stepharo <stepharo(a)free.fr> wrote: > Because when I turn videos I want to control the starting state of the system.... > Then how do I reset the binding list? > I could not find a menu entry. > I found the resetBindings but it is not simple to grab the correct object. > > > Stef > > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Jan. 15, 2016

Re: [Pharo-dev] spotter much slower (GTools 3.6)

by Nicolai Hess

2016-01-15 14:02 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Oh, I got it. Your test does not test inside a class, but the top search. > > I now committed GT-SpotterExtensions-Core-TudorGirba.187 to only search > for exact references. Could you check? > Yes! Much better :) > > Before, searching for Morphs took 58s: > > > > Cheers, > Doru > > > On Jan 15, 2016, at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Nice catch! > > I looked at it, and I cannot understand where the slowness comes from > because there is essentially no change in the processors of a Behavior. Now > I am intrigued. > > Please open an issue. > > Cheers, > Doru > > > > On Jan 15, 2016, at 10:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > since pharo 50524 spotter is much slower. > > Most probably related to search results from classes with many subclasses > Morph / Object / Error / Announcement. > > For example, search for Announcement > and dive into the result for the Announcement class. > It takes about ~ 10 seconds to build the result page (instance methods / > super instance methods....) > > Testcase > > GTSpotterStepTest>>timeClassTest:aClassName > [ self basicSearch:aClassName ] timeToRun logCr. > > "Pharo 50523" > timeClassTest:'Announcement' > 0:00:00:00.539 > timeClassTest:'Morph' > 0:00:00:01.448 > > "Pharo 50524" > timeClassTest:'Announcement' > 0:00:00:06.936 > timeClassTest:'Morph' > 0:00:00:49.044 > > Or open SUnit Testrunner and run tests for package: > GT-Tests-Spotter-Scripting > > nicolai > > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > >

Jan. 15, 2016

Re: [Pharo-dev] spotter much slower (GTools 3.6)

by Tudor Girba

Hi, Oh, I got it. Your test does not test inside a class, but the top search. I now committed GT-SpotterExtensions-Core-TudorGirba.187 to only search for exact references. Could you check? Before, searching for Morphs took 58s: Now, searching for Morphs takes 1s: Cheers, Doru > On Jan 15, 2016, at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Nice catch! > > I looked at it, and I cannot understand where the slowness comes from because there is essentially no change in the processors of a Behavior. Now I am intrigued. > > Please open an issue. > > Cheers, > Doru > > > >> On Jan 15, 2016, at 10:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> since pharo 50524 spotter is much slower. >> >> Most probably related to search results from classes with many subclasses >> Morph / Object / Error / Announcement. >> >> For example, search for Announcement >> and dive into the result for the Announcement class. >> It takes about ~ 10 seconds to build the result page (instance methods / super instance methods....) >> >> Testcase >> >> GTSpotterStepTest>>timeClassTest:aClassName >> [ self basicSearch:aClassName ] timeToRun logCr. >> >> "Pharo 50523" >> timeClassTest:'Announcement' >> 0:00:00:00.539 >> timeClassTest:'Morph' >> 0:00:00:01.448 >> >> "Pharo 50524" >> timeClassTest:'Announcement' >> 0:00:00:06.936 >> timeClassTest:'Morph' >> 0:00:00:49.044 >> >> Or open SUnit Testrunner and run tests for package: >> GT-Tests-Spotter-Scripting >> >> nicolai > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

Jan. 15, 2016