Re: [Pharo-dev] [squeak-dev] Re: Crypto plugins for ubuntu 32-bits

[Robert Withers]

Awesome! Thank you. I lost a cylinder today but gained 27500% through 
your looking out for me, Dave, and, of course, the Panthers. It's 
archangel Michael's NFL football team.


Have a good recursive week, Dave, on point. Does that mean scientific 
software explorations and explanations. Do you know much about 
scientific software in squeak, Dave?


best,
robert

goPanthers . .. ...  ^^

On 12/14/2015 06:52 PM, David T. Lewis wrote:

Hi Robert,

Attached is a copy of the tgz that I downloaded from your dropbox link
on December 5.

Dave

On Mon, Dec 14, 2015 at 06:08:52PM -0500, Robert Withers wrote:

If not my zip, could someone zip up their crypto plugins and send them
to me, please. This would make me happy after more bad news.

regards,
robert

On 12/14/2015 11:46 AM, Robert Withers wrote:

On 12/04/2015 09:57 PM, Robert Withers wrote:

I loaded the CryptographyPlugins package, from the Cryptography
repository into a VMMaker image, and generated the crypto plugins
externally. Although I have not measured it rigorously, there is a
noticeable performance improvement with SqueakElib tests.

Untar these Ubuntu 32-bit crypto plugins into
/usr/local/lib/squeak/5.0...

https://www.dropbox.com/s/v502zudwsbtr243/CryptoPlugins.ubuntu32.12.4.15.tgz?dl=0


Let me know any issues.


Good morning,

Did anyone happen to grab this tgz file? I have since deleted the file
and I don't have a copy. If you did grab it, could you email it to me,
out of band? I am unable to build it again, bright now.


---
...  ^,^ best, robert


Regards,
Robert

--
... ^,^ best, robert


--
... ^,^ best, robert

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

[Thierry Goubier]

Cool, important and challenging!

Thierry

Le 14/12/2015 11:32, Esteban Lorenzano a écrit :



On 14 Dec 2015, at 11:24, Esteban Lorenzano  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

[Pharo-dev] [pharo-project/pharo-core] 86a94d: 50498

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 86a94ddd77eadb08dced6c8e034387eee77098ca
  
https://github.com/pharo-project/pharo-core/commit/86a94ddd77eadb08dced6c8e034387eee77098ca
  Author: Jenkins Build Server 
  Date:   2015-12-14 (Mon, 14 Dec 2015)

  Changed paths:
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50497.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50498.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50497.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50498.st

  Log Message:
  ---
  50498
17241 ffi-nb is not cleaning compiled methods. then they fail when platform 
changes
https://pharo.fogbugz.com/f/cases/17241

http://files.pharo.org/image/50/50498.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[Sven Van Caekenberghe]

> On 14 Dec 2015, at 14:14, Tudor Girba  wrote:
> 
> Thank you Eliot & Esteban for making this happen!

Yes!

> Exciting times :)

Yes!

> Cheers,
> Doru
> 
> 
> 
>> On Dec 14, 2015, at 11:24 AM, Esteban Lorenzano  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."
> 
> 

Re: [Pharo-dev] Windows compilation performance issues

[Mariano Martinez Peck]

Check this long thread: *[Pharo-users] Slow compilation on one of my
Windows PCs*

As I said it there, besides the final conclusions, I have found many times
that it could be a problem of an anti-virus program scanning the .changes
file which is changing all the time while loading and so the performance
slowdown.


On Mon, Dec 14, 2015 at 3:24 PM, Thierry Goubier 
wrote:

> Hi all,
>
> I just did a teaching lab session today in Brest, and I noticed that Pharo
> on Microsoft Windows compiles very slowly (loading Roassal2 stable on
> Pharo4).
>
> What Windows tools shows is a very low cpu load, and a high disk load with
> very low bandwidth (0.1Mbit/s instead of 16Mbit/s).
>
> Does anybody knows why?
>
> Thierry
>
>


-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-dev] Windows compilation performance issues

[Thierry Goubier]

Hi all,

I just did a teaching lab session today in Brest, and I noticed that 
Pharo on Microsoft Windows compiles very slowly (loading Roassal2 stable 
on Pharo4).


What Windows tools shows is a very low cpu load, and a high disk load 
with very low bandwidth (0.1Mbit/s instead of 16Mbit/s).


Does anybody knows why?

Thierry

Re: [Pharo-dev] Compact representation of source code history

[Stephan Eggermont]

For the part of the Roassal2 repo that I could read before getting a 400 
response:


19.665 unique definitions in the following # of versions
(later versions of Raossal2 have 6,5K definitions)

3 ProfilerCPP
2 Roassal2EventCollector
2 Roassal2Spec
81 Trachel
19 ConfigurationOfRoassal2
1 Glamour-Roassal2-presentations
7 Roassal2GT
105 VersionOfRoassal2
273 Roassal2

compressed into 18.7 MB

Stephan

Re: [Pharo-dev] doing stupid things (image will become unusable)

[Richard Sargent]

Nicolai Hess-3 wrote
> Object := nil
> 
> you can evaluate that piece of code, but afterwards 
> 
> Opal checks for assignments to read only variables (method arguments for
> example)
> and signals an error if you try to modify those vars.
> But it does not check globals.
> 
> Should all Globals (OCLiteralVariable with isGlobalVar == true) be read
> only ?
> or can we distinguish global vars and class bindings?

I hope you will distinguish between class bindings and variable bindings (to
classes).

e.g. *StringClass :=String.* and *StringClass := Unicode.* should continue
to be usable.
(Assuming that classes named #String and #Unicode do exist, of course.)





--
View this message in context: 
http://forum.world.st/doing-stupid-things-image-will-become-unusable-tp4866090p4866994.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Compact representation of source code history

[Stephan Eggermont]

The current format we use for storing source code is not optimal for 
archival and analysis purposes. Each mcz stores all source code. That 
makes it difficult and slow. Today I've experimented with an archive 
format that combines many mcz's and should be able to reconstruct all 
individual ones.


I defined a MCProject, representing a project repository. The 
definitions are stored in an OCLiteralSet


Object subclass: #MCProject
instanceVariableNames: 'location infos definitions repository'
classVariableNames: ''
package: 'MonticelloProjects'

For each filename found in the repository I load the MCVersion and its 
snapshot.


MCProject>>read
| filenames |
repository := MCHttpRepository location: location user: '' password: ''.
filenames := repository readableFileNames.
filenames do: [ :each | self read: each ]

MCproject>>read: aFileName
"Needs a rate limiter!!!"
|mcVersion|
mcVersion := repository loadNotCachedVersionFromFileNamed: aFileName.
mcVersion snapshot.
self parse: mcVersion.
repository flushCache



For each unique package in those MCVersions, I add a MCPackageInfo, 
defined as


Object subclass: #MCPackageInfo
instanceVariableNames: 'packageName packageVersions'
classVariableNames: ''
package: 'MonticelloProjects'

MCProject>>parse: aVersion
|info|
info := self ensureInfo: aVersion package.
info addVersion: aVersion in: self

a MCPackageVersion then stores the info and the unique definition
that is stored in the project, eliminating the duplicates.

MCPackageInfo>>addVersion: aMcVersion in: aProject
|packageVersion|
packageVersion := MCPackageVersion new
info: aMcVersion info;
yourself.
self packageVersions add: packageVersion.
aMcVersion snapshot definitions do: [ :aDefinition |
packageVersion definitions add:
(aProject definitions add: aDefinition) ].

As long as #= and #hash are correctly defined for all MCDefinitions, 
this should make it possible too eliminate all duplicate definitions and 
have a full history. On my Documentation repo this already saves
a factor 7, when saving this compressed as a Fuel file. On large 
repositories with a high change rate (Roassal2?) the compression will be 
significantly higher. There are several other normalizations that can 
reduce the size further:

- make recategorization explicit
- normalize MCVersionInfo  data: explicit author, compact timestamp.

I'd be interested in further ideas for this, and situations where this 
approach wouldn't work.


Stephan

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

[Richard Sargent]

EuanM wrote
> Hi Todd, it's taken me til now to put my thoughts into words on this
> issue.
> 
> I think we should make it work first.  This will allow us to gain more
> insight into the issues, and create documentation about the process
> that we, as a community, understand.
> 
> If ICU is the right way to go, we can *then* "make it right".

One way to cross the Grand Canyon is to climb down the wall, assemble the
materials to build a bridge, build the bridge, cross it, then clamber up the
wall. One would learn a lot about climbing and bridge building, worthwhile
if the goal is to learn about those subjects.

Alternatively, you could use the highway bridge that was built long ago and
just cross to the other side. This is definitely my inclination.



> On 8 December 2015 at 22:36, Todd Blanchard <

> tblanchard@

> > wrote:
>> I just want to second Dale's endorsement of the ICU library.  It has been
>> around a long time (originally developed by Taligent) and it provides the
>> base unicode capabilities for an awful lot of software.
>>
>> I think it would make more sense to bring icu into Smalltalk as a
>> NativeBoost library than to spend resources reimplementing and
>> maintaining
>> it.
>>
>> -Todd Blanchard
>>
>> On Dec 8, 2015, at 11:20, Dale Henrichs <

> dale.henrichs@

> >
>> wrote:
>>
>> On 12/07/2015 11:31 PM, H. Hirzel wrote:
>>
>> Dale
>>
>> Thank you for your answer with links to the ICU library and the notes
>> about classes in Gemstone. Noteworthy that you have a class Utf8 as a
>> subclass of ByteArray.
>>
>> I understand that Gemstone uses the ICU library and thus does not
>> implement the algorithms in Smalltalk.
>>
>> I am currently looking into what the  ICU  library provides.
>>
>>





--
View this message in context: 
http://forum.world.st/Sorting-Unicode-strings-Re-Unicode-collation-sequences-Re-squeak-dev-Unicode-Support-tp4865876p4866992.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[Damien Cassou]

Torsten Bergmann  writes:

> Would it make sense to close down the Pharo 5 line and start with the 
> Spur thing as Pharo 6 as this would make it more easily distinguishable?
> Especially since Pharo 5 is very stable, already really usuable and
> with Spur we do not follow our mantra of small steps. 
>
> This would really avoid confusion afterwards within and outside of the
> community.


this makes a lot of sense in my opinion and I vote +1. But releasing a
new Pharo currently is a lot of work, both technical and non-technical
(announces, changelog, ...).

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

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

[Dimitris Chloupis]

Pharo 5 your mission should you choose to accept it is to integrate with
Spur

this image will self destruct in

5

4

3

2

1

JAVA !

On Mon, Dec 14, 2015 at 4:15 PM Johan Fabry  wrote:

>
> Excellent work, thanks a lot !!
>
> > On Dec 14, 2015, at 07:24, Esteban Lorenzano 
> 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).
> >
> >
> >
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University
> of Chile
>
>
>

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

[Johan Fabry]

Excellent work, thanks a lot !!

> On Dec 14, 2015, at 07:24, Esteban Lorenzano  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).
> 
> 
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

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

[Torsten Bergmann]

Exciting times indeed! Many thanks to all who work on this/prepare this.

But we should also be aware:

 1. many people already use Pharo 5 as it is very usable and stable
I think this deserves a better naming/closing before the integration 
than just a simple update number.

Would it make sense to close down the Pharo 5 line and start with the 
Spur thing as Pharo 6 as this would make it more easily distinguishable?
Especially since Pharo 5 is very stable, already really usuable and
with Spur we do not follow our mantra of small steps. 

This would really avoid confusion afterwards within and outside of the
community.

 2. the VM change might affect PharoLauncher images as well. 
It would be good to still have a PharoLauncher that can launch
old non-spur (up to now) and new spur-based images

Thanks
T.

Re: [Pharo-dev] [Pharo-users] New web tutorial

[Norbert Hartl]

Looks good but I don't understand it :)

Norbert

> Am 13.12.2015 um 22:13 schrieb stepharo :
> 
> Hi guys
> 
> with Olivier Auverlot we did several attempts (over the year) and we are 
> happy to release a first draft of a web tutorial
> around Pharo. We ask the user to build a simple blog engine.
> 
> It goes over
>- Mongo
>- Seaside
>- Magritte
> 
> https://ci.inria.fr/pharo-contribution/job/TinyBlogTutorial/5/artifact/book-result/output.pdf
> 
> Soon Rest/Deployment/Garage?/NeoJSON/XML
> 
> If you want to participate (translate it to english) or improve it you are 
> welcome.
> 
> We hope that it will serve as a basis to a lot of Seaside applications.
> 
> This tutorial will be used in the lecture I'm giving next weeks in Togo and 
> will be edited as a lulu book.
> 
> Stef and Olivier.
> 
> 
> 
> 

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

[Esteban A. Maringolo]

2015-12-14 10:14 GMT-03:00 Tudor Girba :
> Thank you Eliot & Esteban for making this happen!

+1

I look forward to see this in action! :)

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

[Tudor Girba]

Thank you Eliot & Esteban for making this happen!

Exciting times :)

Cheers,
Doru



> On Dec 14, 2015, at 11:24 AM, Esteban Lorenzano  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."

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

[Esteban Lorenzano]

> On 14 Dec 2015, at 12:07, Dimitris Chloupis  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  > wrote:
> Thanks!
> 
> > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano  > > wrote:
> >
> >
> >> On 14 Dec 2015, at 11:24, Esteban Lorenzano  >> > 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
> 
> 

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

[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 
wrote:

> Thanks!
>
> > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano 
> wrote:
> >
> >
> >> On 14 Dec 2015, at 11:24, Esteban Lorenzano 
> 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
>
>
>

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

[Guillermo Polito]

Thanks!

> On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano  wrote:
> 
> 
>> On 14 Dec 2015, at 11:24, Esteban Lorenzano  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

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

[Esteban Lorenzano]

> On 14 Dec 2015, at 11:24, Esteban Lorenzano  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

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

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

[Pharo-dev] [pharo-project/pharo-core] 8812a3: 50496

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 8812a3ea1d836dff057c7f915ffc1fed9b473e6b
  
https://github.com/pharo-project/pharo-core/commit/8812a3ea1d836dff057c7f915ffc1fed9b473e6b
  Author: Jenkins Build Server 
  Date:   2015-12-14 (Mon, 14 Dec 2015)

  Changed paths:
A 
Collections-Sequenceable.package/Interval.class/instance/copying/shuffled.st
A 
Collections-Tests.package/IntervalTest.class/instance/tests/testShuffled.st
A 
OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitArgumentNode_.st
M 
OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitBlockNode_.st
M 
OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitMethodNode_.st
A 
OpalCompiler-Tests.package/OCASTClosureAnalyzerTest.class/instance/testing - 
variables/testBlockArgumentIsArgumentVariable.st
A 
OpalCompiler-Tests.package/OCASTClosureAnalyzerTest.class/instance/testing - 
variables/testInlinedBlockArgumentIsArgumentVariable.st
A 
OpalCompiler-Tests.package/OCASTClosureAnalyzerTest.class/instance/testing - 
variables/testMethodArgumentIsArgumentVariable.st
A 
OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-variables/exampleForBlockArgument.st
A 
OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-variables/exampleForInlinedBlockArgument.st
A 
OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-variables/exampleWithArgument_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50495.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50496.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50495.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50496.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50496
17233 Interval cannot be "shuffled"
https://pharo.fogbugz.com/f/cases/17233

17179 Semantic analysis doesnt compute RBArgumentNode instances
https://pharo.fogbugz.com/f/cases/17179

http://files.pharo.org/image/50/50496.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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