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

Re: [Pharo-dev] strange error in latest 3.0 -

by Tudor Girba

I looked more into it, and here is a smaller example: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; package: 'Moose-Algos-Graph'; load This one does open the debugger, so the other emergency evaluator issue comes from somewhere else. The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in ClassModifiedClassDefinition>>isPropagation "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" self oldClassDefinition layout ifNil: [ ^ false ]. ^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables (the method was added 3 days ago by Ben) Doru On Sun, Jan 26, 2014 at 3:50 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > If I execute the following code in 30720: > Gofer new > smalltalkhubUser: 'Moose' project: 'MooseAlgos'; > configuration; > loadDevelopment. > > I get an emergency evaluator with a strange Original error: > MessageNotUnderstood Trait>>layout. > > Can anyone have a look at the first one? It seems to be related to some > deep code changes because the same code works find in 30714. > > And also there seems to be something related to a nsWriteStream: message > somewhere that breaks the Spec debugger in the same process and this is why > we get an Emergency evaluator instead of the debugger. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 26, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Esteban Lorenzano

yep, I can confirm. Looks like latest update broke something. Esteban On 26 Jan 2014, at 15:50, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > If I execute the following code in 30720: > Gofer new > smalltalkhubUser: 'Moose' project: 'MooseAlgos'; > configuration; > loadDevelopment. > > I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout. > > Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714. > > And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 26, 2014

strange error in latest 3.0 -

by Tudor Girba

Hi, If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment. I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout. Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714. And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Jan. 26, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Tudor Girba

Hi ClÃ©ment, I just tried to reproduce the visualization, but it is not available in the Sista image. I also tried to load LiliVisualization, but it does not seem to be working either. Could you point me to a full image? Anyway, I saw the printString you have, but I could not find any of the custom inspectors your were mentioning. Could you point me to where I can find them? As for the visualizations, indeed I saw them before. But, my problem is that I do not know what problems they are trying to solve (besides the graph looking nice - which can be a goal in itself). Could you elaborate on this? Perhaps we can find alternative solutions. Cheers, Doru On Thu, Jan 16, 2014 at 4:03 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Hi Doru, > > I agree that custom tools are valuables. I don't know anyone working in > VMs that does not have his own tools. Have you ever looked at the StackVM / > CogVM Simulator ? They're cool and similar to what I am doing for my > research project. I believe Eliot showed it in some presentation. And see > how the java Maxine VM guys sold their inspector tool suite. > > For the roassal visualization, take the image there: > https://ci.inria.fr/rmod/view/Mate/job/Sista/ > and execute: (Morph>>#invalidRect:from:) liliCFG convertToSSA > roassalVisualisation > This should work on any method. > The alternative, the text visualization that I used before, is: > (Morph>>#invalidRect:from:) liliCFG convertToSSA printString. > As you can see in complex control flow the roassal visualization is way > better. > > For the 3 other tools I did/am doing the problem is that the other project > is not stable currently. It will be stable again in several months. I have > one half- stable image for demo, but even there only the Memory inspector > works (the stack inspector is not stable). It requires to bootstrap an > image in a byte array, the bootstrapped image being in a different object's > format. So I guess I could show you some tools this summer (or this autumn) > if you are really interested but not now. Basically there's an inspector > for the objects in memory, for the stack, and some kind of cpu instructions > debugger. Note that the problem is not in writing tools itself but in > building a running system where I could apply the tools. > > Another interesting tool suite is the one from spoon: > 3D visu: http://www.youtube.com/watch?v=FQgMlpQpu7w > 2D visu: http://www.youtube.com/watch?v=1Uh8v7IzXJk > The first tool would be cool as an alternative to the pointer explorer to > detect memory leaks. > > Cheers, > > > 2014/1/16 Tudor Girba <tudor(a)tudorgirba.com> > >> Hi Clement, >> >> I am happy you see value in these specific tools and that you built your >> own. I strongly believe there is great potential for Pharo in showing how >> development can change dramatically when these custom tools become cheap, >> and I would want to collect examples that provide incentives for others to >> do the same. So now, I am even more interested in taking a look :) >> > >> Could you point me to: >> - the way to setup the image (ideally with scripts starting from a Pharo >> 3.0 image) >> - the Spec tools and Roassal visualizations you built >> - some instances of how to trigger the inspectors and visualizations >> >> ? >> >> Cheers, >> Doru >> >> >> On Wed, Jan 15, 2014 at 9:45 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: >> >>> Hello, >>> >>> I looked in the literature and there are a few paper about exactly the >>> visualization I want. >>> Examples: >>> a paper about Graph Layout for Code Flow Visualization >>> >>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.3748&rep=rep1&… >>> a bachelor thesis on java control flow graph visualization for compiler >>> optimization >>> http://ssw.jku.at/General/Staff/TW/Wuerthinger06Bachelor.pdf >>> >>> Perhaps at some point if we find a bachelor to hire in our team we could >>> ask him to implement such a visualization too (as they did for java >>> seemingly). >>> >>> But I looked at java's control flow graph I saw they would not increase >>> much my productivity compared to what I have now, back jumps are displayed >>> but not in a so good way. Therefore I'll use what I have now. However it >>> would be nice to have that to teach easily compiler optimizations to people. >>> >>> Doru, >>> >>> I *really* need dedicated tools but I have already built them myself. A >>> year ago, I didn't know about GTInspector and Moldable debugger, so I built >>> dedicated inspectors with the old inspector framework of Pharo, then as it >>> was not good enough I built new inspectors based on Spec, and I ported the >>> generic classes of these inspectors in Pharo 3. Specific subclasses of >>> these inspectors exist for my projects. For example, here's an inspector of >>> an object in memory (an object oriented pointer): >>> >>> [image: Images intÃ©grÃ©es 1] >>> >>> With on the left the current address in memory, then what field it is >>> for the object (which is the class MethodDictionary), then the address >>> written at this memory location, and the result of #printString sent to >>> this new address. >>> >>> The next tool I'm going to built is a read only debugger (I mean without >>> on the fly method edition) to step on x86 disassembled instructions and its >>> abstract representation (similar to R*egister Transfer Language >>> <http://fr.wikipedia.org/wiki/Register_Transfer_Language>)* I used in >>> my compilation chain. I discussed once with Andrei and it seems the >>> moldable debugger fits more in the case where you need to debug smalltalk >>> code or at least byte code dependent code. In my case I compile from AST to >>> x86 skipping the byte code so as far as I know it is quite hard to build a >>> tool with what you have. In addition, I'd like to plug the Spec inspectors >>> I built before, which may not be easy if I choose to build the additional >>> tools in Glamour. So the timing is not very good for tools in my projects. >>> >>> Thanks for offering your help anyway. >>> >>> >>> However the tool you showed on RB AST is really cool, especially that I >>> use all the time intermediate representations that could perfectly fit this >>> kind of inspectors (mostly graphs). But I prefer visualization like the one >>> of roassal. >>> >>> Regards >>> >>> >>> >>> >>> 2014/1/15 Marcus Denker <marcus.denker(a)inria.fr> >>> >>>> >>>> On 14 Jan 2014, at 22:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> > >>>> > As far as I can see, the visualization is derived from source code. >>>> This can be seen as being similar to how an AST is derived from source >>>> code. The GTInspector already provides an implementation of understanding >>>> this mapping. For example, in an image with GTInspector (just download the >>>> Moose one for quick tests) do: >>>> > (Collection>>#collect:) parseTree inspect >>>> > >>>> > and you get a picture like the attached one. >>>> > <Inspector on a RBMethodNode (coll...ion).png> >>>> >>>> This is *very* impressiveâ¦ :-) >>>> >>>> Marcus >>>> >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 26, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by Tudor Girba

Hi, I would be interested in seeing what kind of tools could help us. So, let's start by making explicit the kinds of things we are looking for and I can try to build some tools for it. Doru On Sat, Jan 25, 2014 at 10:30 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > Sean > Iâm trying to understand how we could work together to share forces on > cleaning morphic. > Now it is not easy because some of the changes are crosscutting many > packages. > If somebody has an idea. > > Stef > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 26, 2014

Re: [Pharo-dev] browsing comment versions

by Sven Van Caekenberghe

On 26 Jan 2014, at 13:56, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> >> >> >> Where is a bug? > > when I add comment to classes I often get a text that I cannot edit. > My problem is that I cannot find a way to reproduce it systematically Yes, I have seen it as well ...

Jan. 26, 2014

Re: [Pharo-dev] browsing comment versions

by Pharo4Stef

> > > > Where is a bug? when I add comment to classes I often get a text that I cannot edit. My problem is that I cannot find a way to reproduce it systematically

Jan. 26, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30720 Home: https://github.com/pharo-project/pharo-core

Jan. 26, 2014

[pharo-project/pharo-core] 642ed1: 30720

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 642ed1760c01949504c77891e76ed3dedb63b73b https://github.com/pharo-project/pharo-core/commit/642ed1760c01949504c77891… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-26 (Sun, 26 Jan 2014) Changed paths: M Compression.package/GZipReadStream.class/class/unzipping/unzip_.st M Monticello.package/MCPackageManager.class/class/system changes/classModified_.st M NautilusCommon.package/extension/RecentMessageList/instance/lastClasses_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script373.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30720.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/announcements/methodAdded_.st M Spec-Tools.package/MessageBrowser.class/instance/announcements/methodRemoved_.st M System-Announcements.package/ClassAdded.class/definition.st A System-Announcements.package/ClassAnnouncement.class/README.md A System-Announcements.package/ClassAnnouncement.class/definition.st A System-Announcements.package/ClassAnnouncement.class/instance/testing/isPropagation.st M System-Announcements.package/ClassCommented.class/definition.st M System-Announcements.package/ClassModifiedClassDefinition.class/definition.st A System-Announcements.package/ClassModifiedClassDefinition.class/instance/accessing/isPropagation.st M System-Announcements.package/ClassRecategorized.class/definition.st M System-Announcements.package/ClassRemoved.class/definition.st M System-Announcements.package/ClassRenamed.class/definition.st M System-Announcements.package/ClassReorganized.class/definition.st A Tools.package/ImageCleanerCommandLineHandler.class/README.md A Tools.package/ImageCleanerCommandLineHandler.class/class/accessing/commandName.st A Tools.package/ImageCleanerCommandLineHandler.class/class/accessing/description.st A Tools.package/ImageCleanerCommandLineHandler.class/definition.st A Tools.package/ImageCleanerCommandLineHandler.class/instance/actions/cleanUpImage.st A Tools.package/ImageCleanerCommandLineHandler.class/instance/activation/activate.st Log Message: ----------- 30720 12701 In GZipReadStream #unzip:to: answer the new file name, but not #unzip: https://pharo.fogbugz.com/f/cases/12701 11755 When removing an instance variable, far too many package are dirty after https://pharo.fogbugz.com/f/cases/11755 12713 RecentMessageList>>lastClasses: includes obsolete testclasses https://pharo.fogbugz.com/f/cases/12713 12726 add command line handler for ImageCleaner https://pharo.fogbugz.com/f/cases/12726 http://files.pharo.org/image/30/30720.zip

Jan. 26, 2014

Re: [Pharo-dev] About doing things late (1 month before release)

by Esteban Lorenzano

thatâs Pavel sharing our âsecret talksâ to the whole worldâ¦ :P On 26 Jan 2014, at 09:58, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > + 1000 > >> We should be restrained at the start of Pharo 4 development too because we firstly need to improve modularization of the system. It's common that at the start of the development cycle a huge amount of various modifications is integrated and often with only little regards on modularization. Then to improve the Pharo in this frontline is very hard and ungrateful task. >> At the start of the new release we firstly need to change our system and integration tools to take this into account... >> >> Cheers, >> -- Pavel > >

Jan. 26, 2014