November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [OT] World Hello Day - November 21, 2013

by Camillo Bruni

VTermOutputDriver stdout red: 'Hello '; blue: 'World'. :P On 2013-11-21, at 12:47, phil(a)highoctane.be wrote: > FileStream stdout nextPutAll: 'Hello World' > > Works with an eval from the CLI > > On Thursday, November 21, 2013, Torsten Bergmann wrote: > see: http://en.wikipedia.org/wiki/World_Hello_Day > > so: > > Transcript show: 'HelloWorld' > > > > -- > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller > > >

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Martin Dias

wow, impressive! On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > Yesterday Camille did the change to finally remove the old class builder! > (just a removal + a small change to NativeBoost to use the new class > builder to create anonymous classes). > > This means > - 1000 Loc of completely un-understandable code removed. > - we now 100% run on the new class builder from the Slot Project. > > Next on the list (not all for Pharo3): > > - remove PackageInfo > - old Browser + CodeHolder hierarchy > - PseudoClass&Co â> Ring > - old AST+Compiler (this in Pharo4) > > We already did (all in Pharo3): > -> remove URI > -> deprecated Url for ZnUrl > -> removed HTTPSocket facade > -> MIMEType retired for ZnMimeType > -> old Debugger is removed > -> Class categories are replaced by Protocols > > I am quite sure that these cleanups will enable us to build a lot of very > interesting things > in the future. > > Marcus >

Nov. 21, 2013

Re: [Pharo-dev] Multithreading

by kilon alios

Python is in the same situation, what Python coders do is span processes, in this case OS process which is an instance of python interpreter , the advantage of an OSprocess is that it can run on a separate core in case you have a multicore cpu. This way you get true concurrency. However OS process are isolated so you will have to make them communicate via sockets or pipes. Python has such libraries to facilitate easy communication between processes. In case of Pharo you would be opening Pharo headless several times, one instance for each concurrent task you want. This way you will get non blocking code and able to take advantage of all the cores of your cpu. On Thu, Nov 21, 2013 at 1:38 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 21 Nov 2013, at 12:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 20 Nov 2013, at 20:58, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > So what you are looking for is Process and semaphores. > > This is not multithreading in the default Pharo VM + image, currently our > semaphore/process management is not multithreaded, but executes all the > process in the same thread. > > > Ouch. Do you know if this is planned for any milestone? > > > It is a problem that is far from simple to solve. Just defining a > milestone will not help anything. > > Marcus >

Nov. 21, 2013

Re: [Pharo-dev] Multithreading

by Sven Van Caekenberghe

On 21 Nov 2013, at 12:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 20 Nov 2013, at 20:58, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> So what you are looking for is Process and semaphores. >> >> This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. > > Ouch. Do you know if this is planned for any milestone? This is not necessarily bad. Erlang, king of multiprocessing, has a pretty slow VM and runs its own scheduling. Like Erlang, it should be possible to have really a lot of Processes. Not that there are no (important) differences, of course. >> What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction. >> >> (see #forkAt: Process userBackgroundPriority) >> >> Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one. >> >> The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC). >> >> >> >> >> 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful. >> >> uko >> >> On 20 Nov 2013, at 19:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >>> Hello, >>> >>> What do you mean by multithreading ? >>> Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ? >>> >>> >>> 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now. >>> >> >> >

Nov. 21, 2013

Re: [Pharo-dev] [OT] World Hello Day - November 21, 2013

by phil＠highoctane.be

FileStream stdout nextPutAll: 'Hello World' Works with an eval from the CLI On Thursday, November 21, 2013, Torsten Bergmann wrote: > see: http://en.wikipedia.org/wiki/World_Hello_Day > > so: > > Transcript show: 'HelloWorld' > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Nov. 21, 2013

Re: [Pharo-dev] Multithreading

by Marcus Denker

On 21 Nov 2013, at 12:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 20 Nov 2013, at 20:58, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> So what you are looking for is Process and semaphores. >> >> This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. > > Ouch. Do you know if this is planned for any milestone? It is a problem that is far from simple to solve. Just defining a milestone will not help anything. Marcus

Nov. 21, 2013

Re: [Pharo-dev] Multithreading

by Yuriy Tymchuk

On 20 Nov 2013, at 20:58, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > So what you are looking for is Process and semaphores. > > This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. Ouch. Do you know if this is planned for any milestone? > What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction. > > (see #forkAt: Process userBackgroundPriority) > > Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one. > > The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC). > > > > > 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful. > > uko > > On 20 Nov 2013, at 19:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> What do you mean by multithreading ? >> Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ? >> >> >> 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now. >> > >

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by ClÃ©ment Bera

This mechanism does not work with Monticello. On my builds I have for this case something similar to: ./pharo $JOB_NAME.image config $REPO ConfigurationOfMyProject --install=bleedingEdge ./pharo $JOB_NAME.image eval --save 'SmalltalkImage compilerClass: OpalCompiler. Compiler recompileAll.' 2013/11/21 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> > >> Yes, you can do it per class-hierarchyâ¦ you can implement on the class > side a method to parametrize the compiler: > >> > >> compiler > >> ^super compiler options: #(- optionInlineTimesRepeat) > > > > Thanks, Marcus, that works just great. > > Marcus, > > Are we sure this option mechanism works when loading code through > Monticello ? > > I mean, this build fails the PEGParser tests: > > https://ci.inria.fr/pharo-contribution/job/Xtreams/ > > but it includes the #compiler options in Xtreams-Parsing-nice.7 > > Could it not be that this is a chicken-egg problem: the #compiler options > are only there _after_ the class is loaded/compiled, or maybe it is an > instance/class side problem ? > > Sven > > >

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Marcus Denker

On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> >>> Yes, you can do it per class-hierarchyâ¦ you can implement on the class side a method to parametrize the compiler: >>> >>> compiler >>> ^super compiler options: #(- optionInlineTimesRepeat) >> >> Thanks, Marcus, that works just great. > > Marcus, > > Are we sure this option mechanism works when loading code through Monticello ? > Noâ¦ we should make sure that MC loads the method first. I think it does that for #compilerClass already (but not sure). > I mean, this build fails the PEGParser tests: > > https://ci.inria.fr/pharo-contribution/job/Xtreams/ > > but it includes the #compiler options in Xtreams-Parsing-nice.7 > > Could it not be that this is a chicken-egg problem: the #compiler options are only there _after_ the class is loaded/compiled, or maybe it is an instance/class side problem ? > > Sven > >

Nov. 21, 2013

Re: [Pharo-dev] Loading Xtreams in Pharo

by Torsten Bergmann

> https://ci.inria.fr/pharo-contribution/job/Xtreams/ > > still a little rough, but it is a start. If possible I would like to see the project itself moved over from SqS to STHub. Not as a "Pharo" fork but as a replacement for the Squeaksource repo. Sorry but I was too often bitten by SqS problems... Thx T.

Nov. 21, 2013