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

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

by stepharo

Thanks you could also provide code :) Stef On 4/8/14 23:04, Sean P. DeNigris wrote: > stepharo wrote >> add an entry and assign to camille. > Done https://pharo.fogbugz.com/default.asp?13770 > > > > ----- > 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

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

by Sean P. DeNigris

stepharo wrote > add an entry and assign to camille. Done https://pharo.fogbugz.com/default.asp?13770 ----- 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

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by kilon alios

I can tell you why. Because its rarely is simple for people not familiar with Pharo like me. I once tried to help Damien with PharoLauncher. I added the progress bars you get when you download a new image it was simple as pie. Then Damien recommended for me to try to add support to PharoLauncher for CLI . I understand how Pharo does CLI stuff but was not able to understand anything about how PharoLauncher downloads and handles images. I literally spent hours trying to understand the internal architecture and gave up after 2 hours or so cause I had no clue how things worked. Also finding a bug to fix in Pharo is time consuming, you have to go through one bug after another till you find that you can figure out whats wrong and how to fix. Its not easy and its very annoying at times. Generally what kills me is lack of motivation, I don't like reading other's people code, I don't even like reading my code. I prefer documentation , If I am to fix a bug I want at least someone to show me how it works because figuring it by myself takes a lot of time and I am simply not willing to invest that time just because people find documentation something that should write one day when their software reaches version 1 meaning years later. So you want to motivate people to contribute to bug fixes ? Do not allow any code to enter pharo main distribution without full class comments. I really mean "full class comment" not 2 , or 3 lines. PBE has been left hanging years after the release of 1.4 , why ? you expect people to contribute to bug fixes even when the most basic of documentation is abandoned ? Sorry if I sound harsh but you wanted a honest answer . For me undocumented code is far more annoying than a bug or a missing feature. On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo(a)free.fr> wrote: > 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 kilon alios

yes temp fixes this. Strange bug . I also see it works with class variables, so it not as a big problem as I feared, thanks Stef :) On Mon, Aug 4, 2014 at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: > 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] Problem with creating a reference of OSProcess

by Guillermo Polito

Ha, the Workspace stores variables in a Dictionary, which contains Associations instead of the new global variable objects! Maybe we need to introduce a new kind of collection containing the new Global variables or something like that? (okok, a global variable is not exactly what you have in a workspace, so I don't like the name) On Mon, Aug 4, 2014 at 9:33 PM, stepharo <stepharo(a)free.fr> wrote: > 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] [pharo-project/pharo-core] ea9df7: 40138

by stepharo

sean add an entry and assign to camille. We got confused with igor and it took us a while to find. I think that the implementation in Analyse was not necessary. (so probably having 2 and 3 is ok) even if I never saw the difference. Stef On 4/8/14 15:08, Sean P. DeNigris wrote: > 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

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