December 2015 - Pharo-users

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

by Ben Coman

This is great news. Thanks Eliot and Esteban. From the 2GB limit I take this to be 32-bit Spur? 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. 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

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

by Dimitris Chloupis

even more good news , thank you :) On Mon, Dec 14, 2015 at 1:15 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > On 14 Dec 2015, at 12:07, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > 30% - 100% wow thats quite a speed boost, well done guys! > And 2GB images are more than welcomed , especially for me that I have to > deal with 3d data. > > Does that ThreadedFFIPlugin means we can now use C libraries that use > threading ? > > > not yetâ¦ but that is the path :) > > > On Mon, Dec 14, 2015 at 1:01 PM Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Thanks! >> >> > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> > >> >> On 14 Dec 2015, at 11:24, 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). >> >> >> > >> > ah, I forget it! >> > >> > 6) Some changes to the VM accumulated during the time of transition >> (some months now). So, some changes introduced there will not be present in >> new VM. I will merge this changes in the next weeks. >> > >> > cheers! >> > Esteban >> >> >>

Dec. 14, 2015

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

by Esteban Lorenzano

> On 14 Dec 2015, at 12:07, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > 30% - 100% wow thats quite a speed boost, well done guys! > And 2GB images are more than welcomed , especially for me that I have to deal with 3d data. > > Does that ThreadedFFIPlugin means we can now use C libraries that use threading ? not yetâ¦ but that is the path :) > > On Mon, Dec 14, 2015 at 1:01 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Thanks! > > > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > > > >> On 14 Dec 2015, at 11:24, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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). > >> > > > > ah, I forget it! > > > > 6) Some changes to the VM accumulated during the time of transition (some months now). So, some changes introduced there will not be present in new VM. I will merge this changes in the next weeks. > > > > cheers! > > Esteban > >

Dec. 14, 2015

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

by Guillermo Polito

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

Dec. 14, 2015

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

by Dimitris Chloupis

30% - 100% wow thats quite a speed boost, well done guys! And 2GB images are more than welcomed , especially for me that I have to deal with 3d data. Does that ThreadedFFIPlugin means we can now use C libraries that use threading ? On Mon, Dec 14, 2015 at 1:01 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Thanks! > > > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > >> On 14 Dec 2015, at 11:24, 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). > >> > > > > ah, I forget it! > > > > 6) Some changes to the VM accumulated during the time of transition > (some months now). So, some changes introduced there will not be present in > new VM. I will merge this changes in the next weeks. > > > > cheers! > > Esteban > > >

Dec. 14, 2015

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

by Guillermo Polito

Thanks! > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 14 Dec 2015, at 11:24, 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). >> > > ah, I forget it! > > 6) Some changes to the VM accumulated during the time of transition (some months now). So, some changes introduced there will not be present in new VM. I will merge this changes in the next weeks. > > cheers! > Esteban

Dec. 14, 2015

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

by Esteban Lorenzano

> On 14 Dec 2015, at 11:24, 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). > ah, I forget it! 6) Some changes to the VM accumulated during the time of transition (some months now). So, some changes introduced there will not be present in new VM. I will merge this changes in the next weeks. cheers! Esteban

Dec. 14, 2015

Re: [Pharo-users] PharoJVM

by EuanM

I think the market for cross-platform apps is large - but the market for apps that you can't sell is small. Being able to sell the cross-platform apps via the iOS and Android app stores is key, imo. As it is, I target Nintendo 2DS & 3DS, and Blackberry tablet and all Windows as well as iPads, iPhones, Android phones and Android tablets. Bit I still hanker after Cordova just to target the iPhone store. Plus iPhone deals with web-sites awkwardly. You have to present as native, *or* the user has to bookmark each individual page they use. On 14 December 2015 at 01:13, horrido <horrido.hobbies(a)gmail.com> wrote: > I thought so, too, which is why I wrote this tutorial > <https://medium.com/smalltalk-talk/amber-alert-we-can-do-mobile-apps-34b2d4d…> > for app development. However, there is some question surrounding Amber's > viability in the longer term. > > And the demand for cross-platform apps may not be as big as we believe... > > > > tblanchard wrote >> Where do I get this? >> >> I have to say I kind of think Pharo is missing the boat with regards to >> mobile devices. There is a huge demand for a mobile development platform >> that allows one to write a mobile app that runs the same on Android and >> iOS. >> >>> On Dec 12, 2015, at 03:51, Dimitris Chloupis < > >> kilon.alios@ > >> > wrote: >>> >>> Pharo can already run on iOS > > > > > > -- > View this message in context: http://forum.world.st/PharoJVM-tp4866633p4866874.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 14, 2015

[IMPORTANT] Starting migration to Spur VM

by Esteban Lorenzano

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

Dec. 14, 2015

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

by Nicolai Hess

2015-12-14 11:16 GMT+01:00 Stephan Eggermont <stephan(a)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. > I stumbled across this too, I don't think it is supposed to work that way. > > Stephan > > > >

Dec. 14, 2015