- Pharo-dev - lists.pharo.org

About your contributions: Improve Pharo right now, right there.

by stepharo

Hi guys I'm sure that most of you did not realize it, but Pharo does not magically improve. It improves because some of us are looking at the tracker issues and looking at the code and improving it. Since Pharo is yours I wonder why you do not take the time to improve. In fact, this is the key advantage of true open-source: being able to have an impact. An example, I was fed up to have a stupid widget to move method between protocol and classes between packages. I fixed it. It took my 20 min without knowing anything about Nautilus. And it improved Pharo Right now, Right there. Of course if more people would be improving Pharo we could also focus on enabling technology and frameworks. But apparently we have to choose either we improve Pharo now or we invent cool stuff that takes time. I wonder why I do not go for the fame of writing a cool stuff instead of just improving systematically the system. I wrote some roadmaps for people willing also to help. https://github.com/pharo-project/pharo-workingRoadmaps Stef

Aug. 4, 2014

Re: [Pharo-dev] Problem with creating a reference of OSProcess

by stepharo

you should add temp declaration. Apparently this is needed now. At least I got the same error and just adding temps fixed it. Stef On 4/8/14 21:13, kilon alios wrote: > when I do this > > thiproc := OSProcess thisOSProcess . > > I get this > > Association(Object)>>doesNotUnderstand: #emitStore: > OCLiteralVariable>>emitStore: > OCASTTranslatorForValue(OCASTTranslator)>>visitAssignmentNode: > RBAssignmentNode>>acceptVisitor: > OCASTTranslatorForValue(RBProgramNodeVisitor)>>visitNode: > OCASTTranslatorForValue(OCASTTranslator)>>visitNode: > OCASTTranslatorForEffect(OCASTTranslator)>>visitReturnNode: > RBReturnNode>>acceptVisitor: > OCASTTranslatorForEffect(RBProgramNodeVisitor)>>visitNode: > OCASTTranslatorForEffect(OCASTTranslator)>>visitNode: > [ :each | self visitNode: each ] in > OCASTTranslatorForEffect>>visitSequenceNode: in Block: [ :each | self > visitNode: each ] > Array(SequenceableCollection)>>do: > OCASTTranslatorForEffect>>visitSequenceNode: > RBSequenceNode>>acceptVisitor: > OCASTTranslatorForEffect(RBProgramNodeVisitor)>>visitNode: > OCASTTranslatorForEffect(OCASTTranslator)>>visitNode: > OCASTTranslator>>visitMethodNode: > RBMethodNode>>acceptVisitor: > OCASTTranslator(RBProgramNodeVisitor)>>visitNode: > OCASTTranslator>>visitNode: > RBMethodNode>>generateIR > RBMethodNode>>generate: > [ > [ > ast := self parse. > self doSemanticAnalysis ] > on: OCSourceCodeChanged > do: [ :notification | > self source: notification newSourceCode. > notification retry ]. > cm := ast generate: self compilationContext compiledMethodTrailer ] in > OpalCompiler>>compile in Block: [ ... > BlockClosure>>on:do: > OpalCompiler>>compile > [ self compile ] in OpalCompiler>>translate in Block: [ self compile ] > BlockClosure>>on:do: > OpalCompiler>>translate > OpalCompiler>>evaluate > SmalltalkEditor>>evaluateSelectionAndDo: > > Do I do something wrong ? > > I can inspect the object just fine.

Aug. 4, 2014

Re: [Pharo-dev] Can forking speed up anything?

by stepharo

On 4/8/14 19:46, Alexandre Bergel wrote: > Hi Yuriy, > > My advice is to use OpenCL. OpenCL is a standard to use the graphical card to carry out massive computation. > The good news is that Ronie has worked on a binding between OpenCL and Pharo. I am using it and it works pretty well. > http://smalltalkhub.com/#!/~ronsaldo/OpenCL Alex first a good algorithm with a controlled complexity is important. If you have a naive algorithm you can wait that the Universe die before getting a result. I remember doing stupid algorithm that we speed up with roel from a couple of hours to 20 s. Second OpenCL binds you to system having openCL support and this is important to understand it. Stef > > Cheers, > Alexandre

Aug. 4, 2014

Re: [Pharo-dev] Why Bloc?

by stepharo

On 4/8/14 21:06, Sean DeNigris wrote: > <not trolling, genuinely curious> > When SimpleMorphic was released, the problem was that we didnât know how to integrate it into our existing Morphic. Also, the problem with starting with CUISâs Morphic was IIRC that it didnât properly handle internationalization. Now that weâre heading toward a total replacement anyway, why start from scratch when there are these projects, Morphic 3, and who-knows-what-else already available? > </not trolling, genuinely curious> Sean (alain is on vacation without computer) So I will try to reply. First did you look at SimpleMorphic? We did :) ESUG even paid for it while originally it was to support Morphic 3. Second, we read Cuis code. Third Alain did Miro. So he accumulated experience. Four Bloc is clean local coordinates no global hand ActiveHand, World. one nice layout (based on anchor work of igor) no fullbounds (you cannot draw outside a morph. Period!) fully (yes fully pluggable halo - they are packaged in a different optional package) Now it is a long way to get something working for real. So why bloc, we started to clean morphic with alain and we hit a wall. Morphic is so heavy that trying to move inside is really difficult. Now there is a risk that alain does not deliver so we should - look at what he is doing - we try to document the classes - I'm trying to move some cleans/ideas from bloc to Morphic (introducing Margin, cleaning layoutFrame is a way to improve) - Since bloc runs inside morphic, cleaning morphic reduces the morphic behavior that creeps in Bloc Here are some ideas to help - for example, if you want to make bloc use Athens transformation - write more tests - write stupid examples - I'm cleaning menumorph and rewriting a menuMorph for Morphic with the hope that we can blocify the code so that I can propose some simple MenuMorph to Bloc. I'm busy with project proposal writing and other duties but if you want you can join. - I'm doing the same with theme and basic widgets. - Can we do a simple button in Bloc? - clean the one we have in Morphic Alain would like to use Athens for the rendering of Bloc elements .... so this is another nice project to help. Stef

Aug. 4, 2014

Re: [Pharo-dev] Can forking speed up anything?

by stepharo

> > Thanks, I know about this, The problem is exactly that Iâm wrapping > whole hierarchies in my own objects because I need that. Anyway thank you! explain us what you are doing because sometimes we know tricks :). I think that often people that forking can solve speed but you have to introduce sync points and there it can be gory. Stef

Aug. 4, 2014

Problem with creating a reference of OSProcess

by kilon alios

when I do this thiproc := OSProcess thisOSProcess . I get this Association(Object)>>doesNotUnderstand: #emitStore: OCLiteralVariable>>emitStore: OCASTTranslatorForValue(OCASTTranslator)>>visitAssignmentNode: RBAssignmentNode>>acceptVisitor: OCASTTranslatorForValue(RBProgramNodeVisitor)>>visitNode: OCASTTranslatorForValue(OCASTTranslator)>>visitNode: OCASTTranslatorForEffect(OCASTTranslator)>>visitReturnNode: RBReturnNode>>acceptVisitor: OCASTTranslatorForEffect(RBProgramNodeVisitor)>>visitNode: OCASTTranslatorForEffect(OCASTTranslator)>>visitNode: [ :each | self visitNode: each ] in OCASTTranslatorForEffect>>visitSequenceNode: in Block: [ :each | self visitNode: each ] Array(SequenceableCollection)>>do: OCASTTranslatorForEffect>>visitSequenceNode: RBSequenceNode>>acceptVisitor: OCASTTranslatorForEffect(RBProgramNodeVisitor)>>visitNode: OCASTTranslatorForEffect(OCASTTranslator)>>visitNode: OCASTTranslator>>visitMethodNode: RBMethodNode>>acceptVisitor: OCASTTranslator(RBProgramNodeVisitor)>>visitNode: OCASTTranslator>>visitNode: RBMethodNode>>generateIR RBMethodNode>>generate: [ [ ast := self parse. self doSemanticAnalysis ] on: OCSourceCodeChanged do: [ :notification | self source: notification newSourceCode. notification retry ]. cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... BlockClosure>>on:do: OpalCompiler>>compile [ self compile ] in OpalCompiler>>translate in Block: [ self compile ] BlockClosure>>on:do: OpalCompiler>>translate OpalCompiler>>evaluate SmalltalkEditor>>evaluateSelectionAndDo: Do I do something wrong ? I can inspect the object just fine.

Aug. 4, 2014

Why Bloc?

by Sean DeNigris

<not trolling, genuinely curious> When SimpleMorphic was released, the problem was that we didnât know how to integrate it into our existing Morphic. Also, the problem with starting with CUISâs Morphic was IIRC that it didnât properly handle internationalization. Now that weâre heading toward a total replacement anyway, why start from scratch when there are these projects, Morphic 3, and who-knows-what-else already available? </not trolling, genuinely curious> - S

Aug. 4, 2014

Re: [Pharo-dev] Can forking speed up anything?

by Denis Kudriashov

Hi Do you try TaskIt framework? It has BlockClosure>>forkIt which transparently executes code in separate image. 2014-08-04 12:17 GMT+04:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi guys, > > I have a script that runs very slow and does a lot of non dependent > operation of a collection. I wander if I can speed it up by making it run > in another process, because as far as I understand everything runs on a > single thread, so I guess this wonât save me. > > Uko >

Aug. 4, 2014

Re: [Pharo-dev] Can forking speed up anything?

by Alexandre Bergel

Hi Yuriy, My advice is to use OpenCL. OpenCL is a standard to use the graphical card to carry out massive computation. The good news is that Ronie has worked on a binding between OpenCL and Pharo. I am using it and it works pretty well. http://smalltalkhub.com/#!/~ronsaldo/OpenCL Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Aug 4, 2014, at 4:17 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > I have a script that runs very slow and does a lot of non dependent operation of a collection. I wander if I can speed it up by making it run in another process, because as far as I understand everything runs on a single thread, so I guess this wonât save me. > > Uko

Aug. 4, 2014

Re: [Pharo-dev] Can forking speed up anything?

by kilon alios

yes thats correct. I am using python threads , (they are green threads too like pharo) to make my blocking socket not block the overall execution of code. Dont need fork on the pharo side because I send the message and I expect an immediate reply so the blocking is too short for the user to notice. I was giving OSProcess a try using the fork methods for thisProcess but it looks like it requires an XDisplayControlPlugin , which is weird that it does not just bass the block as argument to the new instance of pharo. of course it can be done already with command: method and passing any code you want to run to the new pharo instance together with a message to close image . it will return an object with the variable runState to #running while your code in the pharo instance runs and then #complete as soon as it finishes to take advantage of multiple cores and true concurency. On Mon, Aug 4, 2014 at 4:46 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Wait, if your computations make use of I/O, wouldn't *forking* allow to > take advantage when a green thread is blocked for example, writing a > socket? :) > > > On Mon, Aug 4, 2014 at 2:53 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Mon, 4 Aug 2014, Frank Shearar wrote: >> >> On 4 August 2014 09:38, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>>> >>>> >>>> >>>> 2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >>>> >>>>> >>>>> Hi guys, >>>>> >>>>> I have a script that runs very slow and does a lot of non dependent >>>>> operation of a collection. I wander if I can speed it up by making it >>>>> run in >>>>> another process, because as far as I understand everything runs on a >>>>> single >>>>> thread, so I guess this wonât save me. >>>>> >>>>> I don't think forking can speed up anything. >>>> >>> >>> But that's only because we're single-threaded, hence single-cored. If >>> we had a VM that handle multiple threads (like if we resuscitated >>> Andreas' and Igor's Hydra work), then forking _would_ speed things up. >>> But that would raise another huge issue, namely the shared state >>> nature of the image. >>> >> >> Hydra works differently. It's basically running multiple images from a >> single VM, and provides channels between images for communication (like in >> Erlang). There's no shared state at all between images, and one image can >> only use one core just like now. >> It's also possible to use multiple cores by spawning new VMs. IIRC >> OSProcess has some support for this. >> >> >> Levente >> >> >> >>> So perhaps forking _would_ help if your computations were big enough >>> to justify the cost of spinning up a clone image, like David Lewis' >>> recent work. >>> >>> frank >>> >>> Usually the best solution is to profile your operation with the >>>> Profiler, >>>> then implement differently costly operations, either by removing >>>> object/block creations in smalltalk if this is possible, else by >>>> implementing costly operations in C and bind them like that: >>>> http://clementbera.wordpress.com/2013/06/19/optimizing- >>>> pharo-to-c-speed-with-nativeboost-ffi/ >>>> >>>> >>>> >>>> >>>> >>>>> Uko >>>>> >>>> >>>> >>>> >>> >

Aug. 4, 2014