- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Way to see diffs between different builds?

by Patrik Sundberg

On Wed, Jul 25, 2012 at 1:25 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-07-25, at 14:10, Patrik Sundberg wrote: > > > Hi, > > > > Is there a way to see the diffs (in terms of changes to image) between > one > > 2.0 build number and another? I don't see any obvious link on the CI > server > > to it, and the github export seems to be done in a way that makes the > diffs > > enourmous. > > you can use the git repos and filter out non-st methods: > git diff $VERSION_A $VERSION_B -- $(git diff --name-only $VERSION_A > $VERSION_B | grep .st) > > Ok, I'll try that. I haven't looked at it more closely, but how come the diffs get so HUGE? is there any easy wins to get more "proper" diffs? > If not, is there a way to do it in image? I can only see changes for > > individual MC packages, not a more system level diff to see exactly what > > changed from one build to another. > > We should have a global Pharo MC Package which has all other packages as > dependencies, that would simplify quite a few things here... > > Otherwise you're stuck with downloading the image for a specific version > which might be corrupted, and thus leaves you without any chance of > inspecting the changes... > > Right, a fully packetized system with meta-packages would seem ideal.

July 25, 2012

Re: [Pharo-project] Way to see diffs between different builds?

by Camillo Bruni

On 2012-07-25, at 14:10, Patrik Sundberg wrote: > Hi, > > Is there a way to see the diffs (in terms of changes to image) between one > 2.0 build number and another? I don't see any obvious link on the CI server > to it, and the github export seems to be done in a way that makes the diffs > enourmous. you can use the git repos and filter out non-st methods: git diff $VERSION_A $VERSION_B -- $(git diff --name-only $VERSION_A $VERSION_B | grep .st) Git even has a utility to find the version that introduced a certain bug :) http://incitecode.com/2009/10/13/finding-bugs-with-git-bisect/ > If not, is there a way to do it in image? I can only see changes for > individual MC packages, not a more system level diff to see exactly what > changed from one build to another. We should have a global Pharo MC Package which has all other packages as dependencies, that would simplify quite a few things here... Otherwise you're stuck with downloading the image for a specific version which might be corrupted, and thus leaves you without any chance of inspecting the changes... > I was starting to dig into the metacello bootstrapping problem in 2.0 and > became clear to me it'd help me a lot if I could more easily follow the > diffs. > > Thanks, > Patrik

July 25, 2012

Re: [Pharo-project] ContextPart >> copyTo: -> copyUpTo: ?

by Frank Shearar

On 25 July 2012 13:19, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Jul 25, 2012 at 1:30 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 25 July 2012 11:42, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > Guys. Did I miss something or ContextPart>>copyTo: should be renamed to >> > #copyUpTo: ? >> >> You feel that #copyTo: implies an inclusive bound? >> >> There's only one >> #copyTo: implementor (ContextPart) and only one #copyUpTo: >> (SequenceableCollection) and both are "up to and including" copies. In >> other words there isn't a clear precedence one way or the other for >> having #copyTo: meaning either "and including" or "not including". >> Your argument is, I guess, that there should be? (The method comments >> are perfectly clear on what both method do, at least.) >> > > With #copyTo: I feel that I am copying from one place (source) to a target, > when what it actually does (if I understood correctly) is to copy the source > (receiver) up to the parameter (stop there). So #copyTo: is totally > misleading. By that argument the correct name would be #copyFromSelfTo: or #copyFromHereTo:, neither of which look appetising. (The names would semi-parallel SequenceableCollection's #copyFrom:to:, only a ContextPart is already an element in a collection.) frank >> frank >> >> > Thanks, >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 25, 2012

Re: [Pharo-project] ContextPart >> copyTo: -> copyUpTo: ?

by Mariano Martinez Peck

On Wed, Jul 25, 2012 at 1:30 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 25 July 2012 11:42, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Guys. Did I miss something or ContextPart>>copyTo: should be renamed to > > #copyUpTo: ? > > You feel that #copyTo: implies an inclusive bound? There's only one > #copyTo: implementor (ContextPart) and only one #copyUpTo: > (SequenceableCollection) and both are "up to and including" copies. In > other words there isn't a clear precedence one way or the other for > having #copyTo: meaning either "and including" or "not including". > Your argument is, I guess, that there should be? (The method comments > are perfectly clear on what both method do, at least.) > > With #copyTo: I feel that I am copying from one place (source) to a target, when what it actually does (if I understood correctly) is to copy the source (receiver) up to the parameter (stop there). So #copyTo: is totally misleading. > frank > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

July 25, 2012

[Pharo-project] Way to see diffs between different builds?

by Patrik Sundberg

Hi, Is there a way to see the diffs (in terms of changes to image) between one 2.0 build number and another? I don't see any obvious link on the CI server to it, and the github export seems to be done in a way that makes the diffs enourmous. If not, is there a way to do it in image? I can only see changes for individual MC packages, not a more system level diff to see exactly what changed from one build to another. I was starting to dig into the metacello bootstrapping problem in 2.0 and became clear to me it'd help me a lot if I could more easily follow the diffs. Thanks, Patrik

July 25, 2012

Re: [Pharo-project] ContextPart >> copyTo: -> copyUpTo: ?

by Frank Shearar

On 25 July 2012 11:42, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Guys. Did I miss something or ContextPart>>copyTo: should be renamed to > #copyUpTo: ? You feel that #copyTo: implies an inclusive bound? There's only one #copyTo: implementor (ContextPart) and only one #copyUpTo: (SequenceableCollection) and both are "up to and including" copies. In other words there isn't a clear precedence one way or the other for having #copyTo: meaning either "and including" or "not including". Your argument is, I guess, that there should be? (The method comments are perfectly clear on what both method do, at least.) frank > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com >

July 25, 2012

[Pharo-project] ContextPart >> copyTo: -> copyUpTo: ?

by Mariano Martinez Peck

Guys. Did I miss something or ContextPart>>copyTo: should be renamed to #copyUpTo: ? Thanks, -- Mariano http://marianopeck.wordpress.com

July 25, 2012

[Pharo-project] markdown to latext and html

by StÃ©phane Ducasse

Hi To support the publication in pdf and html directly, plus let people not to bother about latex, I would really to experiment the following for the next chapters of books. I do not know well markdown but I would like to know if the following makes sense. I would like to see if we can use markdown (plus some extensions for in text annotation, figure definition) as pivot language and to be able to generate latex and html from it. >From a simple analysis of current chapter here are the needs: structure title (with ref) section (with ref) subsection paragraph itemize/enumerate code snippet (with ref) figure with caption and ref inside a text area link code index comment for editor citation reference I probably miss some of them but this is the core and we can reduce the number from the latex stand point. What do you think? Does markdown support the item above. Is the petitMarkdown parser working? Because I would like to write a visitor that generates the latex we use for the book. I would like to use Zinc documentation as a test. Stef

July 25, 2012

Re: [Pharo-project] [ANN] Alternative view of a system browser

by Goubier Thierry

Le 22/07/2012 18:22, Camillo Bruni a Ã©crit : > We will have almost exactly that browser, very soon in Pharo :) > I built an internal FileSystem which eventually will be used for > versioning. Using the standard FileBrowser from Pharo on the internal > FS delivers a very similar experience (albeit less code focused) as > your example :) Yes, I believed it could very well. After all, this is the very same kind of organisation (tree-based). It could offer code sharing opportunities. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 25, 2012

Re: [Pharo-project] [ANN] Alternative view of a system browser

by Goubier Thierry

Le 21/07/2012 08:55, Fernando Olivero a Ã©crit : > Hi, nice work. Looking forward to play with it. > Is it similar to the Newspeak browser? Where methods expand in place. > > Fernando No, not with the methods expanding in place. But yes, when looking at the tree. At the moment, it tries to answer two needs : A high level view of the overall system, down to as much detail you'd like (i.e. methods), but while still staying compact (overall view). And with a hierarchical organisation you can customize. A simple UI, so that you can play with multiple browsers at the same time (hence see multiple methods at the same time, that is two or three). I tried to look into a more advanced design, where I would be able to use the whole Pharo background image as the class tree, but I lack the correct data representation to make use of that (and it involves a bit more implementation effort). It would have looked this way : * A single graph / tree for the entire image, layed on the world morph, wher you can open / close subsets. * A few (3-5) simple morphs windows / editors with the look of a workspace, showing just the code of a method / a class, triggered by double-clicking on one item of the graph/tree. But the normal, treeMorph layout, is more vertical than horizontal, and would have not made good use of the screen real estate; also because when you look at the code organisation, it's not very deep : I've found only : * group of packages * package * Class category * Class * Class side of class * Method protocol * Method Which is only 7 deep at worst. I think this approach could be tried with a different representation, maybe using Mondrian? But at the same time, the tree morph is very powerful because it's very easy when doing keyboard navigation. Thierry > > On Wed, Jul 18, 2012 at 7:36 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I do not have a connection to look at it. >> But I LOVE the idea. I love the idea that we can prototype fast new tools and rethink how processesâ¦. >> Spec is one way to enable that. For example I love the GlamourInspector and it would be great to rewrite it with Spec. >> Thanks a lot. >> Stef >> >> On Jul 17, 2012, at 3:12 PM, Goubier Thierry wrote: >> >>> I believe that the traditional SystemBrowser of Smalltalk of old has been made unusable by the amount of code (and structure) you find in today's Smalltalk images. >>> >>> So this is to show you an alternative, a different way to browse through packages / classes and methods and code. This is Spec-based. >>> >>> https://picasaweb.google.com/lh/photo/ic_fRnBXXdyqbiJ5NRP9YtMTjNZETYmyPJy0l… >>> >>> What is missing / targeted ? >>> * Drag and drop reorganisation of the tree as preferred / or as package / category reuse. >>> * A good search facility in the tree. It is already keyboard navigation friendly (since the tree view is). >>> * Most / All menu methods of a complete System Browser. I'm planning on reusing the OmniBrowser command structure as much as possible (to make it faster). >>> * Funny ideas on how to use the tree structure : group / selection display, queries, metrics ... >>> ** There is probably a lot more to be done here, but it would probably require Mondrian or other graph visualisation tools. >>> >>> Expect the code sometime by the end of the week, in a Pharo 2.0 / Pharo 1.4 version. >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >> >> > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 25, 2012