April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

by Eliot Miranda

Hi Ben, On Apr 18, 2015, at 10:57 AM, Ben Coman <btc(a)openInWorld.com> wrote: > > On 18/04/2015 3:36 pm, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > > > Soâ¦ âmultithreadâ is a complicated issue. Pharo as most Smalltalks is designed thinking is as monolithic so if you are trying to make the image to work in different processesâ¦ it will not be easy at all :) > The goal here is very different. The goal is not to build a multithreaded Smalltalk such that multiple processes execute concurrently on multiple cores or processors. The goal is instead to allow the system to interact freely with multiple threads through the FFI. The scheme allows any number of threads to run the VM but only one if them is running the system at any one time. The scheme allows the VM to change thread on any FFI call, process switch or callback. It makes it extremely cheap to release the VM on a callout so that every FFI call, even one to something trivial such as strlen, to be a release point. On callout the thread performing the FFI call reads the value of the owningThreadID variable, zeros the variable and makes the callout. When that thread returns from the FFI call it tries to conditionally set owningThreadID to its id if it is zero, but if it is non-zero, and therefore owned by some other thread, enters a wait state where the scheduler will give it back the VM at the next suitable opportunity. The heartbeat checks for owningThreadID being zero, and if so, either an existing thread that is waiting, or a new thread if none are waiting, is scheduled and tries to own the VM by again attempting to conditionally set owningThreadID to its ID. Processes can be bound to threads so that the system respects priorities and allows certain activities to happen on specific threads. Callbacks from as-yet-unknown processes can be accepted. The scheme, David Simmons' from his Smalltalk VMs, is relatively simple and extremely efficient. But it's still non-trivial to develop and needs effort to realize. My prototype hasn't been worked on for four years. It is rusty. But it'll work and work well. > The holy grail of multithreaded seems to be functional programing, where essentially the benefit comes from threads not modifying global state. The problem with our monolithic system is that you are often (if not always) modifying global state. Worker threads can be written that avoid explicitly modifying global state, but your worker call a method that calls a method that calls a method that unnoticed by you modifies global state. This has been the source of a number of bugs I've hunted down in Pharo (e.g. Transcript; Monticello repository filter). You have to dig deep to notice these and I have wondered if somehow there could be some system help to make such cases fail-early such that any assignment to any instance variable generates an exception. You could turn this on for worker threads to ensure they can't inadvertently affect the monolithic assumptions of the main system. > > Of course the worker threads need to deal with transient global state, but you are in control writing new code with this in mind -- but it protects reuse of existing monolithic code. > > What would it take to get such a feature? > > Cheers -ben

April 18, 2015

Re: [Pharo-dev] PharoLauncher and Pharo 5.0

by Nicolai Hess

2015-04-18 22:08 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-04-18 6:45 GMT+02:00 Damien Cassou <damien.cassou(a)inria.fr>: > >> >> Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> writes: >> >> > In settings, there used to be option to switch off categories of image >> > sources/templates, like hide Pharo 2 category, but this option seems to >> be >> > missing now. >> >> >> yes, I removed it because it was too costly to maintain. >> >> >> > And one more thing ... GUI has some weird colors (well, I think it is >> > actually missing colors). Screenshot: >> > https://monosnap.com/file/Fs6rfZTlstzqkKzyReRnPUVa28FVZe.png >> > However, this one is not today's change, because this morning I tried >> > updating launcher (to find out whether it supports Pharo 5 :) ) and >> colors >> > were already like this. >> >> >> I confirm and I don't know why. >> > > This changed in pharo 40.004. Setting the rowcolor in the TreeMorph > created by the MorphTreeModel > was removed (by estaban (?)), I think this was because it is bad to have > these values hard coded in > the model (doesn't look nice with the dark theme :) ) > > The now problem is, spec tree model does not expose (or use) the api for > setting this attributes. > I uploaded a workaround fix to set this property when the widget is built > (bypassing spec). > (PharoLauncher-Spec-NicolaiHess.41) > > nicolai > > Well, this was only one half of the problem. Somehow the other backgrounds (desktop/panel) are white instead of gray... > > > > >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> >> >

April 18, 2015

Re: [Pharo-dev] PharoLauncher and Pharo 5.0

by Nicolai Hess

2015-04-18 6:45 GMT+02:00 Damien Cassou <damien.cassou(a)inria.fr>: > > Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> writes: > > > In settings, there used to be option to switch off categories of image > > sources/templates, like hide Pharo 2 category, but this option seems to > be > > missing now. > > > yes, I removed it because it was too costly to maintain. > > > > And one more thing ... GUI has some weird colors (well, I think it is > > actually missing colors). Screenshot: > > https://monosnap.com/file/Fs6rfZTlstzqkKzyReRnPUVa28FVZe.png > > However, this one is not today's change, because this morning I tried > > updating launcher (to find out whether it supports Pharo 5 :) ) and > colors > > were already like this. > > > I confirm and I don't know why. > This changed in pharo 40.004. Setting the rowcolor in the TreeMorph created by the MorphTreeModel was removed (by estaban (?)), I think this was because it is bad to have these values hard coded in the model (doesn't look nice with the dark theme :) ) The now problem is, spec tree model does not expose (or use) the api for setting this attributes. I uploaded a workaround fix to set this property when the widget is built (bypassing spec). (PharoLauncher-Spec-NicolaiHess.41) nicolai > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

April 18, 2015

Bloc ci has been updated

by stepharo

April 18, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo 4.0 is released!

by stepharo

> The answere i expected ;-) > > I have the feeling here in germany Pharo is absolutely invisble. So some > work need to be done: I decided to create a booklet on interactive > programming with Pharo and Roassal ... Language: German, 40-50 Pages. > Target audience: newbies with some programming experience > > i hope to show you some results in summer ... superb! We can translate it to other languages when you have it. > > Volkert > > Am 18.04.2015 um 19:00 schrieb stepharo: >> feel free to copy it and create a better one. >> The source is on github >> >> Stef >> >> Le 18/4/15 07:25, volkert a Ã©crit : >>> Coooool! Yes, spread the Word. Is there a cool promotion flyer / >>> booklet for Pharo? >>> >>> I found this here: http://files.pharo.org/media/flyer-cheat-sheet.pdf. >>> >>> Not really attractive ... Is there something better? >>> >>> BW, >>> Volkert >>> >>> >>> Am 16.04.2015 um 11:29 schrieb Esteban Lorenzano: >>>> Please spread widely. >>>> Sorry for multiple posts. >>>> >> >

April 18, 2015

Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras

by Tudor Girba

Ok. Let's move them then. Could you do it? Cheers, Doru On Sat, Apr 18, 2015 at 7:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > I guess I interpreted Extras as projects that are not right now in code. > We should move then Rubric and Bloc to Pharo. > > Cheers, > Andrei > > On Sat, Apr 18, 2015 at 6:57 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> >> Le 18/4/15 13:01, Tudor Girba a Ã©crit : >> >> That is unclear to me, too. >> >> I thought that the Pharo repo is only for the code from the Pharo >> image, but I now see that we have other projects, like TxText, there as >> well. So, what is the preferred way? >> >> >> I always thought that Extras was projects that would not be in the core. >> Now bloc should at the end be in the core. >> >> Cheers, >> Doru >> >> >> On Sat, Apr 18, 2015 at 8:13 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> Just a meta remark why extras and not Pharo? >>> >>> Le 17/4/15 12:58, Alain Plantec via Pharo-dev a Ã©crit : >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

April 18, 2015

Re: [Pharo-dev] [Vm-dev] NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

by Ben Coman

On 18/04/2015 3:36 pm, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > Soâ¦ âmultithreadâ is a complicated issue. Pharo as most Smalltalks is designed thinking is as monolithic so if you are trying to make the image to work in different processesâ¦ it will not be easy at all :) The holy grail of multithreaded seems to be functional programing, where essentially the benefit comes from threads not modifying global state. The problem with our monolithic system is that you are often (if not always) modifying global state. Worker threads can be written that avoid explicitly modifying global state, but your worker call a method that calls a method that calls a method that unnoticed by you modifies global state. This has been the source of a number of bugs I've hunted down in Pharo (e.g. Transcript; Monticello repository filter). You have to dig deep to notice these and I have wondered if somehow there could be some system help to make such cases fail-early such that any assignment to any instance variable generates an exception. You could turn this on for worker threads to ensure they can't inadvertently affect the monolithic assumptions of the main system. Of course the worker threads need to deal with transient global state, but you are in control writing new code with this in mind -- but it protects reuse of existing monolithic code. What would it take to get such a feature? Cheers -ben

April 18, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo 4.0 is released!

by volkert

The answere i expected ;-) I have the feeling here in germany Pharo is absolutely invisble. So some work need to be done: I decided to create a booklet on interactive programming with Pharo and Roassal ... Language: German, 40-50 Pages. Target audience: newbies with some programming experience i hope to show you some results in summer ... Volkert Am 18.04.2015 um 19:00 schrieb stepharo: > feel free to copy it and create a better one. > The source is on github > > Stef > > Le 18/4/15 07:25, volkert a Ã©crit : >> Coooool! Yes, spread the Word. Is there a cool promotion flyer / >> booklet for Pharo? >> >> I found this here: http://files.pharo.org/media/flyer-cheat-sheet.pdf. >> >> Not really attractive ... Is there something better? >> >> BW, >> Volkert >> >> >> Am 16.04.2015 um 11:29 schrieb Esteban Lorenzano: >>> Please spread widely. >>> Sorry for multiple posts. >>> >

April 18, 2015

Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras

by Andrei Chis

I guess I interpreted Extras as projects that are not right now in code. We should move then Rubric and Bloc to Pharo. Cheers, Andrei On Sat, Apr 18, 2015 at 6:57 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 18/4/15 13:01, Tudor Girba a Ã©crit : > > That is unclear to me, too. > > I thought that the Pharo repo is only for the code from the Pharo image, > but I now see that we have other projects, like TxText, there as well. So, > what is the preferred way? > > > I always thought that Extras was projects that would not be in the core. > Now bloc should at the end be in the core. > > Cheers, > Doru > > > On Sat, Apr 18, 2015 at 8:13 AM, stepharo <stepharo(a)free.fr> wrote: > >> Just a meta remark why extras and not Pharo? >> >> Le 17/4/15 12:58, Alain Plantec via Pharo-dev a Ã©crit : >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

April 18, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo 4.0 is released!

by stepharo

feel free to copy it and create a better one. The source is on github Stef Le 18/4/15 07:25, volkert a Ã©crit : > Coooool! Yes, spread the Word. Is there a cool promotion flyer / > booklet for Pharo? > > I found this here: http://files.pharo.org/media/flyer-cheat-sheet.pdf. > > Not really attractive ... Is there something better? > > BW, > Volkert > > > Am 16.04.2015 um 11:29 schrieb Esteban Lorenzano: >> Please spread widely. >> Sorry for multiple posts. >>

April 18, 2015