- Pharo-dev - lists.pharo.org

extract data from .mcz

by Alexandre Bergel

Hi! Anyone has some code snippet to extract data from .mcz file ? Getting all the classes, doing some queries... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Thierry Goubier

Hi Florin, you're in for some interesting questions :) First, I did not have a methodology for finding the issue (or explaining the algorithm) when I started, and I didn't have one afterwards; you need to look into the WhyLine stuff for that (they do a lot better, but I don't have the time to reimplement their tool). But I noticed that understanding an algorithm is easy (relatively) when: - You can easily move repeatedly to any point in an execution stream of that algorithm (i.e. ubiquitous debugging: step forward, backward, jump at any point back and forth, any number of times). - At each point, you are given the precise point in the source code (debugger-like) - At each point, you get significant values: assignments, arguments, return values Representation is easy: an execution is a tree. A sequence in this execution is items at the same level in the tree. Calls are subtrees, as well as iterations. Gui is simple: a tree on the left, code pane on the right. See an example underway: I'm trying to find a bug in LayoutFrame, so I traced LayoutFrame>>transform: (without breaking Morphic). [image: Images intÃ©grÃ©es 1] This is for exploration at the moment, and not comparing values. And on a single method, and highlighting is broken in Pharo 4 :( In the value tracking idea, what we thought then in the place I worked in at that time, is that we could study comparing / diffing trace trees to see where the two versions of the algorithm diverges. We didn't follow up and it wasn't published. I have new visualisations on Roassal now, but they are for static analysis of multitask C code. Does that give you ideas? Thierry 2014-10-06 15:08 GMT+02:00 Florin Mateoc <fmateoc(a)gmail.com>: > Hi Thierry, > > On 10/4/2014 5:32 PM, Thierry Goubier wrote: > > > >> I do have specific tools I can use in such circumstances > >> that you > >> don't have. > >> > >> > >> What kind of tools? I would be interested in learning about them > >> and the > >> analysis use cases they support. > >> > >> > >> I have a trace tool for those situations (and also for parser work). > >> > >> > >> What trace tool? Is an example available? > > > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > > > >> My original use case was: > >> - Finding the bug in an error correction decoding algorithm which > >> worked without error, but with non-satisfying results: lower than > >> expected SNR. > >> - Has then been used very successfully to explain the algorithm. > >> - Was then used as the basis for a hardware design methodology by > >> dynamic code traces of multithreaded programs > >> > > I am very interested in the "explaining the algorithm" aspect of your > tool. Could you please talk a little about that? > > I think I had a similar use case - improving an algorithm working over a > lot of data (so stepping through it with a > debugger was unrealistic) - and my approach was to run two versions in > parallel (the latest (best) available iteration > in the implementation, known to work, versus the bleeding edge), with > synchronization points for every iteration within > the algorithm execution, so that I would catch (through a halt) any > divergence as soon as it started, and from them on > using the debugger. > This worked quite well, but it did not help with explaining the working of > the algorithm and I kept wishing I had a > visualization that would help me get to an intuitive (and holistic, not > just of the subparts) understanding of how the > algorithm worked (in the style of Bret Victor's visualizations), but I did > not know how to get to it. So, if you did > manage to get to such a visualization (one that does not come from an > already (pre-existing for the creator of the > visualization) understanding of the algorithm), that would be fantastic > > Florin > >

Oct. 6, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Florin Mateoc

Hi Thierry, On 10/4/2014 5:32 PM, Thierry Goubier wrote: > >> I do have specific tools I can use in such circumstances >> that you >> don't have. >> >> >> What kind of tools? I would be interested in learning about them >> and the >> analysis use cases they support. >> >> >> I have a trace tool for those situations (and also for parser work). >> >> >> What trace tool? Is an example available? > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > >> My original use case was: >> - Finding the bug in an error correction decoding algorithm which >> worked without error, but with non-satisfying results: lower than >> expected SNR. >> - Has then been used very successfully to explain the algorithm. >> - Was then used as the basis for a hardware design methodology by >> dynamic code traces of multithreaded programs >> I am very interested in the "explaining the algorithm" aspect of your tool. Could you please talk a little about that? I think I had a similar use case - improving an algorithm working over a lot of data (so stepping through it with a debugger was unrealistic) - and my approach was to run two versions in parallel (the latest (best) available iteration in the implementation, known to work, versus the bleeding edge), with synchronization points for every iteration within the algorithm execution, so that I would catch (through a halt) any divergence as soon as it started, and from them on using the debugger. This worked quite well, but it did not help with explaining the working of the algorithm and I kept wishing I had a visualization that would help me get to an intuitive (and holistic, not just of the subparts) understanding of how the algorithm worked (in the style of Bret Victor's visualizations), but I did not know how to get to it. So, if you did manage to get to such a visualization (one that does not come from an already (pre-existing for the creator of the visualization) understanding of the algorithm), that would be fantastic Florin >> Other use cases I use it for: >> - Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text >> editor errors) where halt makes the image unusable. >> - Debugging code in Parsers when the code of a reduction is not >> working properly (somewhere deep in the AST). >> >> >> Is this more than a logger? > > Part of it is a logger, to record events. > > A second part of it is a code rewriting tool. You give it a method, it adds the code to trace the execution and > recompiles the method. > > A third part is a viewer which links each recorded event with the expression which generated it in the method. > > (The second part could be changed to use the Opal facilities instead of code rewriting. There is probably work to be > done on the logger as well: remote logging via RS232, Jtag probes, etc...). > > Thierry > >

Oct. 6, 2014

Re: [Pharo-dev] gt issues

by Christophe Demarey

Hello, Le 4 oct. 2014 Ã 11:51, Tudor Girba a Ã©crit : > Pharo needs a centralised way to manage tabs and windows, its a system heavily .... wait that is wrong.... solely based on GUIs. So this is not a GT issue, its more a Pharo issue. > The problem with GT because is such a detailed tool it exposes this Pharo weakness a lot more than other tools. > > The GTInspector problem will be solved by adding the possibility for each last tab to close. Please, add these feature for all tabs (maybe not for the first one but it does not matter). I often need to hide/close intermediates tabs that are just there because they were needed for the navigation. At the end, I just want to keep inspectors on objects I want to look at. Regards, Christophe.

Oct. 6, 2014

DNUs in the styler

by Thierry Goubier

I'm encountering DNUs in the Styler in Pharo 4.0. Is someone else encountering those as well? A way to reproduce: RBParser parseFaultyMethod: 'test ^ ()' Whereas: RBParser parseFaultyMethod: 'test ^ ^ self' correctly returns an AST with RBParseErrorNode(s) inside. Thierry

Oct. 6, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 6, 2014

[pharo-project/pharo-core] 3752f5: 40286

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3752f50dc11765fa2b86c21fc9e495ccabfc47c2 https://github.com/pharo-project/pharo-core/commit/3752f50dc11765fa2b86c21f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-06 (Mon, 06 Oct 2014) Changed paths: A ConfigurationOfGTInspector.package/ConfigurationOfGTInspector.class/instance/versions/version105_.st A ConfigurationOfGTInspector.package/ConfigurationOfGTInspector.class/instance/versions/version106_.st A ConfigurationOfGTPlayground.package/ConfigurationOfGTPlayground.class/instance/versions/version105_.st A ConfigurationOfGTPlayground.package/ConfigurationOfGTPlayground.class/instance/versions/version106_.st A ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/baselines/baseline292_.st M ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/symbolic versions/development_.st A ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/versions/version274_.st A ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/versions/version275_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version122_.st M GT-Inspector.package/GTObjectVariablesBrowser.class/instance/private building/evaluatorIn_.st M GT-Inspector.package/GTSimpleMethodsBrowser.class/instance/building/evaluationAction.st A GT-InspectorExtensions-Core.package/extension/Character/instance/gtInspectorCharacterIn_.st A GT-InspectorExtensions-Core.package/extension/Float/instance/gtInspectorFloatIn_.st M GT-InspectorExtensions-Core.package/extension/Float/instance/gtInspectorVariableValuePairs.st A GT-InspectorExtensions-Core.package/extension/Integer/instance/gtInspectorIntegerIn_.st R GT-InspectorExtensions-Core.package/extension/Integer/instance/gtInspectorVariableValuePairs.st A GT-InspectorExtensions-Core.package/extension/NewValueHolder/instance/announcer.st M GT-Playground.package/GTPlayground.class/instance/building/codeIn_.st A Glamour-Rubric-Presentations.package/GLMPharoPlaygroundPresentation.class/instance/actions/installGoAction.st M Glamour-Rubric-Presentations.package/GLMRubricSmalltalkCodePresentation.class/instance/rendering/defaultSelectionActions.st M Rubric.package/RubShoutStylerDecorator.class/instance/editing/stylerStyled_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script286.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40286.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40286 14154 GTools version 1.0.5 https://pharo.fogbugz.com/f/cases/14154 http://files.pharo.org/image/40/40286.zip

Oct. 6, 2014

GT-Inspector for SmallDictionary

by Sven Van Caekenberghe

Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.64 Author: SvenVanCaekenberghe Time: 6 October 2014, 1:52:40.640585 pm UUID: 060f943c-eae0-426b-8cb2-8ac2e559ba44 Ancestors: GT-InspectorExtensions-Core-AndreiChis.63 Copy Dictionary>>#gtInspectorItemsIn: to SmallDictionary Remove Dictionary>>#gtInspectorVariableValuePairs as it is not needed (showing the named instance variables is OK) Sven

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector silly titles

by Sven Van Caekenberghe

On 06 Oct 2014, at 13:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > It is not crazy. You will see that these will follow just like creating new presentations will follow. I didn't mean the idea was crazy, I understand and agree with the reasoning, it is just that expecting all existing code to change is totally unrealistic. > But, we can certainly make it easier. I like the idea of removing the class prefix if it exists. It can be done in the default implementation from Object>>#gtDisplayOn: OK, propose something and we'll see. > Doru > > On Mon, Oct 6, 2014 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > So what, everybody has to either rewrite all old printStrings or add new gtDisplayStrings ? That is crazy, especially for cross platform packages. > > It would be quite easy to rewrite GTInspector>>#printObjectAsAnItem: to not add the prefix if it is already present. > > On 06 Oct 2014, at 13:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Yes, the label does introduce redundancy in some cases, but that is because the use of printString has to be rethought :) > > > > printString was used for a long time as a primary inspection tool. Because of that it tries to do too much (like adding the class name), and it is certainly not suitable for a label. > > > > gtDisplayString is meant for labeling the content of the object. It is used also for things like a list. As soon as you will do something with your objects, you will want to have something smaller. There is no need to have the class part of that string. Relying on that convention is brittle, as it is easy for people to not have the class name in there. But, for an inspector, having the class at all times is a prerequisite, so that will be displayed always separately (to ensure that the right information is offered). > > > > gtDisplayString relies on printString by default, so people can provide the labels at their convenience. > > > > Cheers, > > Doru > > > > > > On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I think the titles of GT-Inspector windows/panes are a bit silly: > > > > <Screen Shot 2014-10-06 at 13.13.41.png> > > > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a Dictionary(...))' where the class name is repeated. > > > > I think it is very important to honour the standard/general Smalltalk approach and assume the #printString already contains the class name. If not, you are basically punishing everybody who went through the trouble of writing custom #printString implementation (like me, I do this for most classes). > > > > I saw the whole #display thing, but you can't force everybody to rewrite #printString to #gtDisplayString or whatever. > > > > Sven > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector silly titles

by Tudor Girba

It is not crazy. You will see that these will follow just like creating new presentations will follow. But, we can certainly make it easier. I like the idea of removing the class prefix if it exists. It can be done in the default implementation from Object>>#gtDisplayOn: Doru On Mon, Oct 6, 2014 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > So what, everybody has to either rewrite all old printStrings or add new > gtDisplayStrings ? That is crazy, especially for cross platform packages. > > It would be quite easy to rewrite GTInspector>>#printObjectAsAnItem: to > not add the prefix if it is already present. > > On 06 Oct 2014, at 13:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Yes, the label does introduce redundancy in some cases, but that is > because the use of printString has to be rethought :) > > > > printString was used for a long time as a primary inspection tool. > Because of that it tries to do too much (like adding the class name), and > it is certainly not suitable for a label. > > > > gtDisplayString is meant for labeling the content of the object. It is > used also for things like a list. As soon as you will do something with > your objects, you will want to have something smaller. There is no need to > have the class part of that string. Relying on that convention is brittle, > as it is easy for people to not have the class name in there. But, for an > inspector, having the class at all times is a prerequisite, so that will be > displayed always separately (to ensure that the right information is > offered). > > > > gtDisplayString relies on printString by default, so people can provide > the labels at their convenience. > > > > Cheers, > > Doru > > > > > > On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I think the titles of GT-Inspector windows/panes are a bit silly: > > > > <Screen Shot 2014-10-06 at 13.13.41.png> > > > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a > Dictionary(...))' where the class name is repeated. > > > > I think it is very important to honour the standard/general Smalltalk > approach and assume the #printString already contains the class name. If > not, you are basically punishing everybody who went through the trouble of > writing custom #printString implementation (like me, I do this for most > classes). > > > > I saw the whole #display thing, but you can't force everybody to rewrite > #printString to #gtDisplayString or whatever. > > > > Sven > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014