- Pharo-dev - lists.pharo.org

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

by Robert Withers

I should mention I have never tested Mushroom performance on my new dual-core laptop with plugins, yet. I got to 20.1 Mbs on the old laptop so I am anxious. I hope I didn;t come across as such poorly. best, 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.tg… >> >> >> 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 > >> I should mention thRegards, >> Robert > -- ... ^,^ best, robert

Dec. 14, 2015

Windows compilation performance issues

by 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

Dec. 14, 2015

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

by Robert Withers

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.tg… > > > 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

Dec. 14, 2015

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

by 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

Dec. 14, 2015

Compact representation of source code history

by 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

Dec. 14, 2015

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

by 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-tp4866… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 14, 2015

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

by 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-sequence… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 14, 2015

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

by Damien Cassou

Torsten Bergmann <astares(a)gmx.de> 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

Dec. 14, 2015

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

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

Dec. 14, 2015

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

by Johan Fabry

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

Dec. 14, 2015