December 2015 - Pharo-users

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

by Tudor Girba

Thank you Eliot & Esteban for making this happen! Exciting times :) Cheers, Doru > On Dec 14, 2015, at 11:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 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). > > -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Dec. 14, 2015

Re: [Pharo-users] Keymapping, shift vs non-shift

by Guillermo Polito

> On 14 dic 2015, at 12:38 p.m., Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > ve, I would propose to > actually use "$= ctrl" for zooming in. But that is layout dependent :).

Dec. 14, 2015

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

by Esteban Lorenzano

> On 14 Dec 2015, at 13:15, Ben Coman <btc(a)openInWorld.com> wrote: > > On Mon, Dec 14, 2015 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> again, harder than it seems (because releasing a version is stupidly-hard)â¦ >> Iâm thinking on move all 50 pre-spur into a 49 directory (4.9), then all is >> correctly separated in file server. >> This is the easiest I can do itâ¦ I think :) > > That sounds fine, but maybe the directory can be "50preSpur" (if possible) ? yeah, it could. > cheers -ben >

Dec. 14, 2015

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

by Ben Coman

On Mon, Dec 14, 2015 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > again, harder than it seems (because releasing a version is stupidly-hard)â¦ > Iâm thinking on move all 50 pre-spur into a 49 directory (4.9), then all is > correctly separated in file server. > This is the easiest I can do itâ¦ I think :) That sounds fine, but maybe the directory can be "50preSpur" (if possible) ? cheers -ben

Dec. 14, 2015

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

by Esteban Lorenzano

> On 14 Dec 2015, at 13:03, Ben Coman <btc(a)openInWorld.com> wrote: > > On Mon, Dec 14, 2015 at 7:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> On 14 Dec 2015, at 12:21, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> This is great news. Thanks Eliot and Esteban. From the 2GB limit I >>> take this to be 32-bit Spur? >> >> yes of course. >> We are already working on 64bits spur but is not ready yet (it will be some point of 2016) >> >>> >>> Is it feasible to jump the image build numbers to make that first >>> image requiring a new VM align on a 100s build numbers. I see we are >>> currently 50496. 50500 is nice and distinctive, but even even 50600 >>> would be fine if the last few 400s are consumed in the meantime. >> >> mmmâ¦ that I donât knowâ¦ correlation of version numbers is usually important for us (for statistics purposes)â¦ also changing number generation is more annoying than you would think (thatâs why we donât have 4.1, 4.2, etc.). >> but wellâ¦ everything is possible, weâll see :) > > Or do we just append "-spur" to the build number - but there will be > no new builds without the "-spur" tag, and continue this up to Pharo 5 > Release. I am just thinking of making it easy to distinguish the > required VM when I want to open old builds to bisect which build > instorduced a bug. again, harder than it seems (because releasing a version is stupidly-hard)â¦ Iâm thinking on move all 50 pre-spur into a 49 directory (4.9), then all is correctly separated in file server. This is the easiest I can do itâ¦ I think :) Esteban > > cheer -ben

Dec. 14, 2015

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

by Ben Coman

On Mon, Dec 14, 2015 at 7:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 14 Dec 2015, at 12:21, Ben Coman <btc(a)openinworld.com> wrote: >> >> This is great news. Thanks Eliot and Esteban. From the 2GB limit I >> take this to be 32-bit Spur? > > yes of course. > We are already working on 64bits spur but is not ready yet (it will be some point of 2016) > >> >> Is it feasible to jump the image build numbers to make that first >> image requiring a new VM align on a 100s build numbers. I see we are >> currently 50496. 50500 is nice and distinctive, but even even 50600 >> would be fine if the last few 400s are consumed in the meantime. > > mmmâ¦ that I donât knowâ¦ correlation of version numbers is usually important for us (for statistics purposes)â¦ also changing number generation is more annoying than you would think (thatâs why we donât have 4.1, 4.2, etc.). > but wellâ¦ everything is possible, weâll see :) Or do we just append "-spur" to the build number - but there will be no new builds without the "-spur" tag, and continue this up to Pharo 5 Release. I am just thinking of making it easy to distinguish the required VM when I want to open old builds to bisect which build instorduced a bug. cheer -ben

Dec. 14, 2015

Re: [Pharo-users] Keymapping, shift vs non-shift

by Stephan Eggermont

On 14-12-15 12:38, Peter Uhnak wrote: > But since that's how most applications behave, I would propose to > actually use "$= ctrl" for zooming in. That's an interesting bug. I notice Safari, FireFox and Chromium have the bug. They explicitly state in the menu that the key combination is ctrl-+, resp. cmd-+. ctrl-= doesn't exist on a german keyboard (but ctrl-+ looks fine) Stephan

Dec. 14, 2015

Re: [Pharo-users] Keymapping, shift vs non-shift

by Peter Uhnak

On 12/14, Guillermo Polito wrote: > > > On 14 dic 2015, at 11:23 a.m., Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2015-12-14 11:16 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>>: > > On my keyboard I have '+' in two positions: once over the '=' in the alphanumeric part,and once as a separate key on the numeric part. > > When I do a > > > > self bindKeyCombination: $+ command mac | $+ ctrl win | $+ ctrl unix > > toAction: [ self increaseFontSize ]. > > > > that only works for the numeric '+'. > > Is that supposed to be the case? The problem is that it forces me to know about the keyboard layout to define shortcuts. > > > So you mean that in order to make + in your +/= key you must press shift? And then (ctrl +) does not match (ctrl shift +)? > > Then Iâd say it is a bug/unimplemented feature... > > Hmm, maybe shift only has to work as a modifier for alphanumeric characters... > > > > > I stumbled across this too, I don't think it is supposed to work that way. > > > > > > Stephan > > > > > > > > > How is this a bug? The only + key that you can press with just ctrl is the numeric one, otherwise it would clash with "$= ctrl". But since that's how most applications behave, I would propose to actually use "$= ctrl" for zooming in. -- Peter

Dec. 14, 2015

Re: [Pharo-users] Keymapping, shift vs non-shift

by Stephan Eggermont

On 14-12-15 12:13, Guillermo Polito wrote: > So you mean that in order to make + in your +/= key you must press > shift? And then (ctrl +) does not match (ctrl shift +)? Indeed. > Then Iâd say it is a bug/unimplemented feature... > > Hmm, maybe shift only has to work as a modifier for alphanumeric > characters... That sounds like a good first step. It might be even more difficult than that, though. On many non-english keyboards there are other key combinations with modifiers like AltGr to get to other characters, and dead keys. German and French have [] and {}. I don't know what characters are beneath the shifted versions of them. Stephan

Dec. 14, 2015

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

by Esteban Lorenzano

> On 14 Dec 2015, at 12:21, Ben Coman <btc(a)openinworld.com> wrote: > > This is great news. Thanks Eliot and Esteban. From the 2GB limit I > take this to be 32-bit Spur? yes of course. We are already working on 64bits spur but is not ready yet (it will be some point of 2016) > > Is it feasible to jump the image build numbers to make that first > image requiring a new VM align on a 100s build numbers. I see we are > currently 50496. 50500 is nice and distinctive, but even even 50600 > would be fine if the last few 400s are consumed in the meantime. mmmâ¦ that I donât knowâ¦ correlation of version numbers is usually important for us (for statistics purposes)â¦ also changing number generation is more annoying than you would think (thatâs why we donât have 4.1, 4.2, etc.). but wellâ¦ everything is possible, weâll see :) Esteban > > > On Mon, Dec 14, 2015 at 6:24 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 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). > > Maybe PharoLauncher can be a special hardcoded rule to have two > template headings... > * Pharo 5.0 Spur (beta); and > * Pharo 5.0 Pre-Spur (beta) > Enhanced multi-VM support perhaps based off the template headings would be nice. > > cheers -ben >

Dec. 14, 2015