August 2014 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Fogbugz login to issue

by Chris Cunningham

Interesting. I tried going the other way (on the same issue) and looking at the read only view from Penelope. Once there, I have no idea where to go. Maybe find the package Rectangle is part of and try digging down there? Hmm, nope. Either wrong guess, or now that 2489 is closed, it isn't on Penelope. (Or I missed it while paging through the pages there). In any case, even poorer workflow. Guess it is time to dig out my login to Fogbugz again. On Sat, Aug 2, 2014 at 9:14 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tim Mackinnon wrote > > I think it has to do with whether you are logged into fogbugz > > For sure if you're already logged in you'll go right to the issue, but now > when you're not logged in: > 1. https://pharo.fogbugz.com/default.asp?2489 brings you to the login page > 2. When you click either login link, you go to the login page but the query > has been stripped > > What I'm saying is that the 2489 should be preserved in the login link, so > that you automatically go to the issue you were interested in instead of to > the dashboard. Then you have to remember the issue number from a few steps > ago = very poor workflow > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Fogbugz-login-to-issue-tp4771555p4771557.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 4, 2014

First commit with Git-Filetree

by kilon alios

So I have started using gitfiletree and the first commit seems to commit only .filetree file and not my package folder. I had to add the package folder with a "git add" and of course make a commit of it .Is this normal ? the process I have followed is this 1) Create a github repo intialized with a readme and license file 2) git clone the repo to my hd 3) in a clean pharo image install gitfiletree as described in Git and Pharo chapter in Pharo for the Enterprise 4) in monticello add repository +gitfiletree and then choose the git folder 5) select a package and click save 6) add the commit info My other commits dont need any extra step just a simple "git push".

Aug. 4, 2014

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

by Guillermo Polito

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

Re: [Pharo-dev] [pharo-project/pharo-core] ea9df7: 40138

by Sean P. DeNigris

GitHub wrote > 13729 3 menu item to generate inst var accessors > https://pharo.fogbugz.com/f/cases/13729 I left a comment in the issue, but maybe no one is checking there since it's closed... >From the original comment: There is currently 3 menu items to generate iv accessors: Analyse > Create inst var accessors Refactoring > Class Refactoring > Generate accessors Refactoring > Inst Var Refactoring > Accessors Each one has it's own underlying logic. I keep the second that has a shortcut associated and remove the two others. Please put back #3. It is a different use case. #2 is a batch operation adding accessors for all inst vars. #3 adds accessors for one inst var. When many inst vars are involved, it is tedious to deselect all the other accessors... The main problem was not that there was multiple options, but that they were poorly organized (see http://forum.world.st/Nautilus-accessor-over-generation-td4679480.html) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-ea9df7-40138-tp4770903p47717… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 4, 2014