- Pharo-dev - lists.pharo.org

TechTalk invite link

by Esteban Lorenzano

https://discord.gg/88sbn83 <https://discord.gg/88sbn83> It will start in 20min as preview. Esteban

Oct. 25, 2016

Re: [Pharo-dev] Notes about Pharo 6 release and new process for Pharo 7

by Esteban Lorenzano

> On 25 Oct 2016, at 15:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > 1) Builds will be bootstrap based. > This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. > But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working) > > > https://www.youtube.com/watch?v=_J6-3l3hCm0 <https://www.youtube.com/watch?v=_J6-3l3hCm0> > > That going to be even bigger than 64 bit, will make it easy to have Pharo distros :) > > I am very interested into hearing about this in the voice meeting . By the way what time is the meeting ? local time France is fine too. 18hs france.

Oct. 25, 2016

Re: [Pharo-dev] Notes about Pharo 6 release and new process for Pharo 7

by Dimitris Chloupis

> > 1) Builds will be bootstrap based. > This implies a change of mindset: pharo will be considered as a small > kernel plus a set of maintained packages. This is important to remark > because is a difference in our way of think: until now pharo is âthe > imageâ, now it will be different because there is the possibility of build > different images starting from the kernel and bootstrapping other packages. > But of course, the standard-distributed image will be still a compound of > the maintained packages (and tests will be ran against this amalgam to be > sure everything continues working) > > https://www.youtube.com/watch?v=_J6-3l3hCm0 That going to be even bigger than 64 bit, will make it easy to have Pharo distros :) I am very interested into hearing about this in the voice meeting . By the way what time is the meeting ? local time France is fine too.

Oct. 25, 2016

Re: [Pharo-dev] Notes about Pharo 6 release and new process for Pharo 7

by Esteban Lorenzano

> On 25 Oct 2016, at 14:27, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > and I will paste Stefâs clarification, because it seems my text was a bit obscure :) > > Pharo 6.0 will be with the old process. > - no bootstrap > - no git > - 64 bits > So Pharo 6 will be 64 bits? Pharo 6 will *have* 64bits version. We will continue having the 32bits version for some time (and some more versions), I guessâ¦ Esteban > > Yes! > > Thierry > > - stabilisation > > But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. > - with bootstrap > - process based on git > The idea is to have some months to get Pharo 70 alpha ready with the new process > when Pharo 60 gets out (or at least to get some cycles) > > > > On 25 Oct 2016, at 14:19, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > > Time to send this to dev list: > > (btw, this has to do with what we are going to talk today in TechTalk). > > > > Hi, > > > > Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today). > > > > The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. > > Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly. > > > > Anyway, this is what we think: > > > > We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: > > - Clements changes (full blocks, SISTA bytecode set, â¦) > > - 64bits > > - Bugfixes > > > > This way we can jump to work on the new process, that we think will take some months until we have it ready. > > > > NEW PROCESS: > > > > 1) Builds will be bootstrap based. > > This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. > > But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working) > > > > 2) Sources will be moved to git. > > Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodulesâ¦ > > Anyway I would like to have different source directories (to separate kernel from maintained packages :P) > > > > 3) Changes will be managed through Pull Requests (yay!) > > And of course there will be a validation process (travis based)â¦ > > - Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)â¦ I mean, the build images for validationâ¦ of course the âintegratedâ images will be pushed allways. > > > > This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. > > This way, when 7.0 starts in march, we are with the new process. > > > > So that. > > > > Opinions, suggestions? > > > > Esteban > > > > >

Oct. 25, 2016

Re: [Pharo-dev] Notes about Pharo 6 release and new process for Pharo 7

by Thierry Goubier

2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > and I will paste Stefâs clarification, because it seems my text was a bit > obscure :) > > Pharo 6.0 will be with the old process. > - no bootstrap > - no git > - 64 bits > So Pharo 6 will be 64 bits? Yes! Thierry > - stabilisation > > But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. > - with bootstrap > - process based on git > The idea is to have some months to get Pharo 70 alpha ready with the new > process > when Pharo 60 gets out (or at least to get some cycles) > > > > On 25 Oct 2016, at 14:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Time to send this to dev list: > > (btw, this has to do with what we are going to talk today in TechTalk). > > > > Hi, > > > > Last week we had a meeting where we tried to define current Pharo 6 > efforts and the next Pharo 7 goals (in particular, how to revamp our > process into something that fits better our numbers of today). > > > > The thing is there was no clear roadmap for Pharo 6 and we wanted to > precise it. > > Also, during last years we put some pieces in place and we are ready to > do the next big step (changing the Pharo process) but we need to work hard > until we have it working (and we just have a draft of how we would want to > work, I will talk about later), and we need to discuss, test, iterate > before is working properly. > > > > Anyway, this is what we think: > > > > We need to put Pharo 6.0 development in âfeature freeze statusâ right > now. Only things that needs to enter is: > > - Clements changes (full blocks, SISTA bytecode set, â¦) > > - 64bits > > - Bugfixes > > > > This way we can jump to work on the new process, that we think will take > some months until we have it ready. > > > > NEW PROCESS: > > > > 1) Builds will be bootstrap based. > > This implies a change of mindset: pharo will be considered as a small > kernel plus a set of maintained packages. This is important to remark > because is a difference in our way of think: until now pharo is âthe > imageâ, now it will be different because there is the possibility of build > different images starting from the kernel and bootstrapping other packages. > > But of course, the standard-distributed image will be still a compound > of the maintained packages (and tests will be ran against this amalgam to > be sure everything continues working) > > > > 2) Sources will be moved to git. > > Concrete structure is TBD, but it will be an unique project (no > submodules) for a start. This is because is hard to handle changes in > multiple submodulesâ¦ > > Anyway I would like to have different source directories (to separate > kernel from maintained packages :P) > > > > 3) Changes will be managed through Pull Requests (yay!) > > And of course there will be a validation process (travis based)â¦ > > - Iâm also thinking on push the built images into some place for people > to be able to verify their errors in the built image (also we could do > this)â¦ I mean, the build images for validationâ¦ of course the âintegratedâ > images will be pushed allways. > > > > This implies a lot of work to make it work, build the tools we need and > make us feel confortable with it, thatâs why we want to start as soon as > possible. > > This way, when 7.0 starts in march, we are with the new process. > > > > So that. > > > > Opinions, suggestions? > > > > Esteban > > > > >

Oct. 25, 2016

Re: [Pharo-dev] Notes about Pharo 6 release and new process for Pharo 7

by Esteban Lorenzano

and I will paste Stefâs clarification, because it seems my text was a bit obscure :) Pharo 6.0 will be with the old process. - no bootstrap - no git - 64 bits - stabilisation But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. - with bootstrap - process based on git The idea is to have some months to get Pharo 70 alpha ready with the new process when Pharo 60 gets out (or at least to get some cycles) > On 25 Oct 2016, at 14:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Time to send this to dev list: > (btw, this has to do with what we are going to talk today in TechTalk). > > Hi, > > Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today). > > The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. > Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly. > > Anyway, this is what we think: > > We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: > - Clements changes (full blocks, SISTA bytecode set, â¦) > - 64bits > - Bugfixes > > This way we can jump to work on the new process, that we think will take some months until we have it ready. > > NEW PROCESS: > > 1) Builds will be bootstrap based. > This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. > But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working) > > 2) Sources will be moved to git. > Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodulesâ¦ > Anyway I would like to have different source directories (to separate kernel from maintained packages :P) > > 3) Changes will be managed through Pull Requests (yay!) > And of course there will be a validation process (travis based)â¦ > - Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)â¦ I mean, the build images for validationâ¦ of course the âintegratedâ images will be pushed allways. > > This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. > This way, when 7.0 starts in march, we are with the new process. > > So that. > > Opinions, suggestions? > > Esteban >

Oct. 25, 2016

Notes about Pharo 6 release and new process for Pharo 7

by Esteban Lorenzano

Time to send this to dev list: (btw, this has to do with what we are going to talk today in TechTalk). Hi, Last week we had a meeting where we tried to define current Pharo 6 efforts and the next Pharo 7 goals (in particular, how to revamp our process into something that fits better our numbers of today). The thing is there was no clear roadmap for Pharo 6 and we wanted to precise it. Also, during last years we put some pieces in place and we are ready to do the next big step (changing the Pharo process) but we need to work hard until we have it working (and we just have a draft of how we would want to work, I will talk about later), and we need to discuss, test, iterate before is working properly. Anyway, this is what we think: We need to put Pharo 6.0 development in âfeature freeze statusâ right now. Only things that needs to enter is: - Clements changes (full blocks, SISTA bytecode set, â¦) - 64bits - Bugfixes This way we can jump to work on the new process, that we think will take some months until we have it ready. NEW PROCESS: 1) Builds will be bootstrap based. This implies a change of mindset: pharo will be considered as a small kernel plus a set of maintained packages. This is important to remark because is a difference in our way of think: until now pharo is âthe imageâ, now it will be different because there is the possibility of build different images starting from the kernel and bootstrapping other packages. But of course, the standard-distributed image will be still a compound of the maintained packages (and tests will be ran against this amalgam to be sure everything continues working) 2) Sources will be moved to git. Concrete structure is TBD, but it will be an unique project (no submodules) for a start. This is because is hard to handle changes in multiple submodulesâ¦ Anyway I would like to have different source directories (to separate kernel from maintained packages :P) 3) Changes will be managed through Pull Requests (yay!) And of course there will be a validation process (travis based)â¦ - Iâm also thinking on push the built images into some place for people to be able to verify their errors in the built image (also we could do this)â¦ I mean, the build images for validationâ¦ of course the âintegratedâ images will be pushed allways. This implies a lot of work to make it work, build the tools we need and make us feel confortable with it, thatâs why we want to start as soon as possible. This way, when 7.0 starts in march, we are with the new process. So that. Opinions, suggestions? Esteban

Oct. 25, 2016

Re: [Pharo-dev] MetaLink to conditionally skip a method execution based on an arg

by Nicolai Hess

2016-10-23 12:15 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > I was looking at this and ran into some very odd behavior: > > imagine we have some method: > > ``` > Object subclass: #MyClass. > MyClass compile: 'method: arg > Transcript crShow: ''executed '', arg asString'. > ``` > > and a simple metalink > > ``` > link := MetaLink new > metaObject: Halt; > selector: #now; > control: #instead. > > (MyClass >> #method:) ast link: link. > ``` > > Now I can do the following to execute the code: > > ``` > c := MyClass new. > (MyClass>>#method:) valueWithReceiver: c arguments: #(1). > (MyClass>>#method:) reflectiveMethod valueWithReceiver: c arguments: #(1). > (MyClass>>#method:) compiledMethod valueWithReceiver: c arguments: #(1). > MyClass rFwithArgs: #(1) executeMethod: (MyClass>>#method:) compiledMethod. > ``` > > There is only one way to "compile and install" the modified method and unless this is done, all the above messages are received on the ReflectiveMethod and delegated to the CompiledMethod (see ReflectiveMethod>>##doesNotUnderstand: > All of the statements above will call the method WITHOUT triggering the > metalink, which is odd. > > Now what's even stranger, if I instead do this > > ``` > c := MyClass new. > c method: 1. > (MyClass>>#method:) valueWithReceiver: c arguments: #(1). > (MyClass>>#method:) reflectiveMethod valueWithReceiver: c arguments: #(1). > (MyClass>>#method:) compiledMethod valueWithReceiver: c arguments: #(1). > MyClass rFwithArgs: #(1) executeMethod: (MyClass>>#method:) compiledMethod. > ``` > > by the first call "c method:1" this is the place where the ReflectiveMethod actually compiles and installs a modified compiled method. the magic happens with "objects as methods" and the method run:with:in: (if the vm looks up a message send, and the object in the method dictionary is *not* a CompiledMethod, it calls the object with the method run: aSelector with: anArray in: aReceiver This is implemented in ReflectiveMethod and will actually compile and install the new CompiledMethod. > Then ALL the statements (starting with `c method: 1`) will be suddenly > halting (triggering the metalinks). > Yes because the compiled method to be called is now the new one. (MyClass>>#method:) class -> " this is now a compiled method again, but the new, modified one". > > > So my questions are: > > 1) why in the first case the following two methods didn't trigger the > metalink? > > (MyClass>>#method:) valueWithReceiver: c arguments: #(1). > (MyClass>>#method:) reflectiveMethod valueWithReceiver: c arguments: #(1). > > 2) why in the second case these two methods did trigger the metalink? > > (MyClass>>#method:) compiledMethod valueWithReceiver: c arguments: #(1). > MyClass rFwithArgs: #(1) executeMethod: (MyClass>>#method:) compiledMethod. > > #rFwithArgs:executeMethod: even has comment "This method is used by > reflectivity internally. All meta-links are ignored". > > 3) why the class of (MyClass>>#method:) changed after calling `method:`? > > ``` > (MyClass >> #method:) ast link: link. > > c := MyClass new. > (MyClass>>#method:) class. "ReflectiveMethod" > (MyClass>>#method:) valueWithReceiver: c arguments: #(1). > (MyClass>>#method:) class. "ReflectiveMethod" > c method: 1. > (MyClass>>#method:) class. "CompiledMethod" > ``` > > 4) (unrelated to the above) I tried calling `link disable` from within the > #metaObject, but it was ignored, but maybe I don't understand its purpose. > You can enable / disable the condition without actually changing / reinstalling the link link condition:[:args | args first isNumber] arguments:#(arguments). c method:1. "<- will trigger halt" c method:'s'. "<- wont trigger halt" link disable. "<- disable the condition, like condition never holds" c method:1. "<- wont trigger halt" c method:'s'. "<- wont trigger halt" > > > Thanks, > Peter > > On Sun, Oct 23, 2016 at 09:21:59AM +0200, Yuriy Tymchuk wrote: > > Iâve also described the question with examples on SO: > https://stackoverflow.com/questions/40200546/conditionally-skip-a-method- > with-matalinks > > > > > On 22 Oct 2016, at 23:13, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > > > Hi. > > > > > > Imagine I have method a: and I want to skip the execution (return self > or nil or whatever) when a: is evaluated with parameter 0. I have tried to > add a meta link which will run instead of the method with a condition, but > the condition did not workâ¦ I have tried to implement the metallic method > to do nothing if the arg is 0 otherwise to perform the method, but I end up > with an infinite loopâ¦ > > > > > > Did anybody do something like that already? Any suggestions? > > > > > > Uko > > > >

Oct. 25, 2016

Re: [Pharo-dev] CI's down ?

by Sven Van Caekenberghe

They seem to fail to install new VM's ... Creating starter scripts pharo and pharo-ui On a 64-bit system? You must install the 32-bit libraries Try `sudo aptitude install ia32-libs` or see http://pharo.org/gnu-linux-installation#64-bit-System-Setup for more info ... Something must have changed (I know, lot's of moving parts) > On 25 Oct 2016, at 10:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > I have restarted the jenkins. > > Lets hope it works better. > > Marcus > >> On 24 Oct 2016, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> It seems that since a couple of days the CI's are down ? >> >> https://ci.inria.fr/pharo-contribution/ >> >> >> > >

Oct. 25, 2016

Re: [Pharo-dev] [ANN] Scale

by Santiago Bragagnolo

Hi Ben. Yes in deed, it's quite dangerous and it's not meant to be used without thinking about the impact. In any case you cannot even execute this command without sudo (since the installation is on /usr/local/bin). In a nutshell im using it for installing scale, and updating it. And a i leave it there believing that the user of this method is wise enough :). In any case, i'm not willing to ban #snapshot:andQuit:, what will save the image in the middle of the script execution and it will be really dirty. So, i give a cleaner way to do it. Any case this is meant to update the image in a way that import makes not sense. Like loading a new version of scale. punctually Import is something i want to have for the next version :). But there are many steps in the middle. Thanks for the feedback! Santiago. On Tue, 25 Oct 2016 at 06:01 Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > Really nice project, Santiago. > > > > I have few questions: > > > > - what "system saveAfterRun" actually do? > > > > As I understand it saves image when script completes. Imaging during > script > > I loaded Seaside. Does this command makes Seaside accessible from any > scale > > scripts? > > Image persistence is one of Pharo's most useful features, but I think > its a liability for a system scripting environment. As a > philosophical point, Python/Ruby (somewhat) guarantee scripts start > with the same state each time they are run. I believe this is an > important attribute for system scripting. "saveAfterRun" seems > detrimental to that because you can break the environment for other > scripts, and you can't just reset state by deleting you script. Also > its harder to share scripts since dependencies are not recorded in the > script if the system state has changed. Python/Ruby handle this via a > module import/require facility. Perhaps Scale could provide a > facility to install a Configuration, then export it via Fuel as a > "module" that could be imported into Scale scripts. Loading via Fuel > should be fast enough (??) that Seaside could be accessible from any > Scale script without too much runtime overhead. (I'll add this as an > Issue if discussion indicates interest). > > cheers -ben > > > > > > - system execute: aString into: anImageBundle > > > > What is anImageBundle here? > > > > - What you think to make scripts working as workspace? All undeclared > > variables will be added to environment automatically. And in case of > > saveAfterRun they will became accessible from any scale scripts. > > > > > > 2016-10-23 20:34 GMT+02:00 Santiago Bragagnolo > > <santiagobragagnolo(a)gmail.com>: > >> > >> Hi everybody. > >> > >> We are officially releasing a first version of scale. > >> > >> Scale is a command line handler that is there for making easier the life > >> of the people that uses scripting in linux. As such, we only tested it > so > >> far in linux. It will be for sure easy to adapt it to mac because its a > >> *nix, but not for windoze. > >> > >> IMPORTANT REMARK: scale is not meant to develop applications, it is > meant > >> to develop scripts in Pharo, to be launched from the command line. This > >> means that scale does not provide a top level syntax to declare classes > or > >> methods: people should do that as any normal Pharo application. Scale > should > >> be used to invoke such applications. > >> > >> When would you use scale? > >> - For example, to replace some bash scripts used for common boring > tasks > >> (and you are using python or ruby there :P) > >> - Another example, would be when you want to replace bash scripts that > >> chain things like: > >> ./pharo eval --save "something" > >> ./pharo eval --save "other something" > >> ... > >> > >> Github: https://github.com/guillep/Scale > >> Oneliner to install: (note it needs sudo) > >> > >> wget -O- > >> https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | > sudo > >> bash > >> > >> > >> In the repository there is some user level documentation based on > examples > >> and a list of available methods on the magical variable system. There > are > >> many examples as well on the repository. > >> > >> Last but not least, I'm using this project in others two projects, where > >> it proof it self quite powerful what keeps me on maintaining Scale. > >> > >> These projects are: > >> > >> Pharo Android VM building https://github.com/sbragagnolo/pharo-vm > >> > >> Here I use it for automating the creation of a > >> * new building image, > >> * the creation of new resource image (for deploying on the > android > >> apk), > >> * linking the android sources into the building directory > >> * generating the code from the console > >> > >> MakrosTool https://github.com/sbragagnolo/MakrosTool > >> > >> MakrosTool is an extension of scale that adds a second magical variable > >> for building up component reification in a ROS based environment. > >> > >> > >> Santiago & Guille > >> > >> > >> > >> > >> > > > >

Oct. 25, 2016