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

Re: [Pharo-dev] Multithreading

by Camillo Bruni

On 2013-11-21, at 15:56, 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. 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) > > One more thing: how do I synchronise? For example I want two async processes, but when they both finish I want to execute something. Eg. return merged data generated by processes. Semaphores are your friends: semaphore := Semaphore new. [ ... First Job ... semaphore signal. ] fork. [ ... Second Job ... semaphore signal. ] fork. "consume to signals, aka. pause this thread until both jobs have finished" semaphore wait; wait.

Nov. 21, 2013

PharoLauncher

by Sean P. DeNigris

Just starting to play with it... looks cool. One thing is that I'd like to be able to choose the default image location. It feels wrong to install them under ~/Library/Preferences on the Mac... ----- Cheers, Sean -- View this message in context: http://forum.world.st/PharoLauncher-tp4723991.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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. 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) One more thing: how do I synchronise? For example I want two async processes, but when they both finish I want to execute something. Eg. return merged data generated by processes. > > 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 Igor Stasenko

On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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). > > which is still doesn't eliminates problem completely, because nothing prevents me from having: compilerClass ^ self otherMethod and now in order to work, MC have to know somehow that #otherMethod should also be loaded first. But i think some prioritization guarantees would be really useful. At least i think we can easily prioritize class-side compilation over instance side. Like that, when you compiling any of instance-side method, you know that class side is already there (and can be used as such in different kinds of hooks). > > 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 > > > > > > > -- Best regards, Igor Stasenko.

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by kilon alios

yeah me too Esteban, I checked the link to the pdf but is written in a language its very difficult to understand. Also Sean points tell me nothing about this feature, they look too generic. Oh well maybe its for the people that want to deeply hack the language and system which is not my area of expertise or interest. In any case any positive contribution to Pharo whether interests me or not is ALWAYS welcomed, so thank you :) On Thu, Nov 21, 2013 at 4:21 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > I don't fully see what are the immediate benefits. > > But as usually happen when you replace something old, limited and "not > so well designed" by something better designed from the ground up I > guess it will open Pharo to features not yet thought of. > > Does the new debugger have something "better" than the previous one? > > > Regards! > Esteban A. Maringolo > > > 2013/11/21 Tudor Girba <tudor(a)tudorgirba.com>: > > Triple impressive! This is another sample of an apparently tiny change > that > > actually has deep impact on the future of our beloved environment. > > > > Ladies and gentlemen, I know you are busy, but please take the time to > > acknowledge it :) > > > > Doru > > > > > > > > > > On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> > wrote: > >> > >> 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 > >> > >> > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > >

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Esteban A. Maringolo

I don't fully see what are the immediate benefits. But as usually happen when you replace something old, limited and "not so well designed" by something better designed from the ground up I guess it will open Pharo to features not yet thought of. Does the new debugger have something "better" than the previous one? Regards! Esteban A. Maringolo 2013/11/21 Tudor Girba <tudor(a)tudorgirba.com>: > Triple impressive! This is another sample of an apparently tiny change that > actually has deep impact on the future of our beloved environment. > > Ladies and gentlemen, I know you are busy, but please take the time to > acknowledge it :) > > Doru > > > > > On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> 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 >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Sean P. DeNigris

kilon alios wrote > any links why newcomers like me should be impressed ? Whats the > advantages? Great question! As Camille mentioned, the email is more about cleaning. As a new user, this will likely effect you in two ways. The new clean replacement code: 1) will empower members of our community to write killer IDE enhancements and libraries that you can use 2) will allow you to express yourself in code more effectively. I remember when I first found Smalltalk. I was smitten by the promise of turtles-all-the-way-down, all parts of the system available for exploration and modification. This was quickly followed by the reality of (sometimes) impossible (for me anyway) to understand code (cough... Morphic, FileDirectory). On several shoot-the-moon IDE ideas, I became frustrated and quit. Now we have FileSystem, which is a joy to work with, and rarely gets in my way. Multiply this by the number of items above, and all the others over the releases of Pharo, and... you get the picture... HTH ----- Cheers, Sean -- View this message in context: http://forum.world.st/Old-ClassBuilder-remove-tp4723906p4723980.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Camille Teruel

On 21 nov. 2013, at 14:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This is not *just cleaning*! I wasn't talking about the creation of the slot model nor its integration in the image, but about killing the old class builder, a really enjoyable moment BTW :) > You might perceive it as such being so involved in it. You guys replaced something ugly with something based on a sound explicit model. > When you do this at such a core level, the possibilities explode two layers on top. You might just do not see it, yet :). > > Just two examples: > - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally). > - In Fame we implement bidirectional relationships. By bidirectional relationships I mean you have classes like A ->* B, and when you have a B object and set the A parent, it automatically adds the B instance to the collection in A. The current implementation in Fame is difficult to grasp and the code of specifying the slots is spread over the whole Moose models. Once slots are supported as first class, we can build the strategy of bidirectionality directly in the slot support. This will be more elegant. > > Doru > > > On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: > >> any links why newcomers like me should be impressed ? Whats the advantages ? > > That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. > The later is based on slots and is much more understandable and thus much easier to maintain. > It's been integrated some time ago thanks to Martin. > > Slots are the work of Toon and Camillo and enables a lot of useful features: > http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… > They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). > Slots are an abstraction added on top of low-level class "fields". > It means that one will be able to create a customized slot class that define the logic to read and write a slot: > > Object subclass: #MyClass > slots: { x => MyFancySlot } > category: 'Playground' > > Then when a method read or writes x, the logic you defined in MyFancySlot is executed. > All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)! > >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment. >> >> Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :) >> >> Doru >> >> >> >> >> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> 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 >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Sean P. DeNigris

Tudor Girba-2 wrote > Triple impressive! This is another sample of an apparently tiny change > that > actually has deep impact on the future of our beloved environment. Yes!!!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Old-ClassBuilder-remove-tp4723906p4723979.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 21, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Tudor Girba

And then, imagine what this will do for tools. Given that the class instance will know what kind of slots are around, the tools can help you manage them. You will be able to build your class and then simply say that you want a slot to be bidirrectional and point it to the opposite slot. Really, I am so excited :) Doru On Thu, Nov 21, 2013 at 2:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This is not *just cleaning*! You might perceive it as such being so > involved in it. You guys replaced something ugly with something based on a > sound explicit model. > > When you do this at such a core level, the possibilities explode two > layers on top. You might just do not see it, yet :). > > Just two examples: > - Morphic uses a dictionary to allow extensions to add attributes to the > base class. This is closed-world-based-assumption thinking because I have > to know in advance what parts will be extended by someone else. This should > be easily changeable with slots given that slots are manipulate-able at > runtime (ideally). > - In Fame we implement bidirectional relationships. By bidirectional > relationships I mean you have classes like A ->* B, and when you have a B > object and set the A parent, it automatically adds the B instance to the > collection in A. The current implementation in Fame is difficult to grasp > and the code of specifying the slots is spread over the whole Moose > models. Once slots are supported as first class, we can build the strategy > of bidirectionality directly in the slot support. This will be more elegant. > > Doru > > > On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > >> >> On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> any links why newcomers like me should be impressed ? Whats the >> advantages ? >> >> >> That's just cleaning. The old class builder was an incredibly complex >> piece of code that is now replaced with the Slot class builder. >> The later is based on slots and is much more understandable and thus much >> easier to maintain. >> It's been integrated some time ago thanks to Martin. >> >> Slots are the work of Toon and Camillo and enables a lot of useful >> features: >> >> http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… >> They are based on the reification of class layouts (variable,weak,fixed >> and co) and instance variables (slots). >> Slots are an abstraction added on top of low-level class "fields". >> It means that one will be able to create a customized slot class that >> define the logic to read and write a slot: >> >> Object subclass: #MyClass >> slots: { x => MyFancySlot } >> category: 'Playground' >> >> Then when a method read or writes x, the logic you defined in MyFancySlot >> is executed. >> All that still need to be absorbed by Opal so it's not available right >> now but it will (Pharo 4)! >> >> >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >> >>> Triple impressive! This is another sample of an apparently tiny change >>> that actually has deep impact on the future of our beloved environment. >>> >>> Ladies and gentlemen, I know you are busy, but please take the time to >>> acknowledge it :) >>> >>> Doru >>> >>> >>> >>> >>> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com>wrote: >>> >>>> 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 >>>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 21, 2013