January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Package loader question

by Trussardi Dario Romano

Thanks Max, > Hi Dario, > >> On 15 Jan 2016, at 16:58, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: >> >> Ciao, >> >> i have some packages with some class definition. >> >> Now the package1 define Class1 and Class2 with some reference to classA and classB defined into pachageA. >> >> packageA other hand, have some reference to class1 and class2. >> >> Now my question is: >> >> i can load the package1 and packageA without other considerations, >> >> leaving the system to resolve references as classes are loaded? >> > > No, I donât think so. You will receive a warning and can then proceed. That will compile the methods but the class references will have been compiled as nil references. So you will need to recompile those methods afterwards. But if i used the Metacello baseline or configuration definition i can load with #atomic load types? With this load types i solve my problematic? Now when i load a baseline definition with : | pathToPackageDirectory | "edit to match the path to your chosen package directory" pathToPackageDirectory := '/DTRDevelopment'. Metacello new baseline: 'DtrBase'; repository: 'filetree://', pathToPackageDirectory; load. how i can define the load types? Thanks, Dario > > If these classes need each other, then they probably belong into the same package. > > Just to be clear, what do you mean by âpackageâ? If you are referring to something like âMY-Coreâ and âMY-Viewâ but both are loaded when loading the Monticello package âMYâ then it will work. If you load âMY-Coreâ and âMy-Viewâ as separate Monticello packages the above will happen. > > Cheers, > Max > >> >> Thanks for any considerations, >> >> Dario > >

Jan. 15, 2016

Re: [Pharo-dev] Color yzw

by Nicolai Hess

2016-01-15 13:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > No, you are right. It isn't shown in red, even if it is a unknown symbol. > > I'll have a look. Oh, that is bad. The check for existing Symbols always succeeds, because Parsing an expression with RBParser creates RBMethod- and RBMessageNodes And they use always #asSymbol for its selectors. That means, as soon as we parse an expression, we add all new Symbols. And as the parser is now used for syntax highlighting as well, this means new symbols will be added on compiling new methods and expressions or just highlighting them. That's bad. anyone an idea? > > > > > 2016-01-15 13:28 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> 2016-01-15 13:10 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>> Hi >>> >>> In the past in Pharo when a message was not matching an existing selector the selector was turned into red >> >> >> I think this only happened for names not known as a symbol, regardless whether this symbol exists as a message selector or just a symbol. >> >> If no symbol table includes the symbol yzw >> >> Color yzw >> >> will show yzw red, >> >> Color yello >> will print yello in italic >> Color yellow >> will print yellow normal >> Color jaune >> will print jaune red, as long it is not in a SymbolTable. >> >> >>> >>> So we could see immediately that you typed an error. >>> >>> Right now, the behavior only exists for Class >>> so >>> >>> Po is italiczec >>> Pox is red >>> >>> I played with the blueStyleTable but I cannot get it working on selector. >>> Does anybody know? >>> >>> Such kind of glitch is slowing me when shooting new pharo videos. >>> >>> Stef >>> >>> >> >

Jan. 15, 2016

Re: [Pharo-dev] Package loader question

by Max Leske

Hi Dario, > On 15 Jan 2016, at 16:58, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > > Ciao, > > i have some packages with some class definition. > > Now the package1 define Class1 and Class2 with some reference to classA and classB defined into pachageA. > > packageA other hand, have some reference to class1 and class2. > > Now my question is: > > i can load the package1 and packageA without other considerations, > > leaving the system to resolve references as classes are loaded? > No, I donât think so. You will receive a warning and can then proceed. That will compile the methods but the class references will have been compiled as nil references. So you will need to recompile those methods afterwards. If these classes need each other, then they probably belong into the same package. Just to be clear, what do you mean by âpackageâ? If you are referring to something like âMY-Coreâ and âMY-Viewâ but both are loaded when loading the Monticello package âMYâ then it will work. If you load âMY-Coreâ and âMy-Viewâ as separate Monticello packages the above will happen. Cheers, Max > > Thanks for any considerations, > > Dario

Jan. 15, 2016

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

by Mariano Martinez Peck

Luc, Damien, et all. I implemented the kind of API Luc suggested, which was a great idea. I took also his API to answer Damien question of could we do a "tail -f" example. So I made a little example where I run "tail -f system.log" and I keep a Playground updated with the stdout :) Here is the video: https://dl.dropboxusercontent.com/u/6980943/tailExample.mov Let me know what do you think. Cheers, On Fri, Jan 15, 2016 at 10:51 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > >> >> defaultReadStreamCreationBlock: [ process >> createTempFileToBeUsedAsReadStreamOn: '/tmp' ]; >> >> In the readme, the piece of code containing that is a bit suspicious >> because it depends on the fact that the block is evaluated after the >> variable 'process' is assigned. >> > > Thanks, fixed! > I always hated the instance side nature of those methods, so I moved them > to class side. > > > > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Jan. 15, 2016

Package loader question

by Trussardi Dario Romano

Ciao, i have some packages with some class definition. Now the package1 define Class1 and Class2 with some reference to classA and classB defined into pachageA. packageA other hand, have some reference to class1 and class2. Now my question is: i can load the package1 and packageA without other considerations, leaving the system to resolve references as classes are loaded? Thanks for any considerations, Dario

Jan. 15, 2016

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

by Esteban Lorenzano

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

Jan. 15, 2016

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

by Alexandre Bergel

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

Jan. 15, 2016

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

by Nicolai Hess

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

Jan. 15, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 15, 2016

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

by GitHub

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

Jan. 15, 2016