The Trunk: ToolBuilder-Morphic-ul.59.mcz

Levente Uzonyi uploaded a new version of ToolBuilder-Morphic to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Morphic-ul.59.mcz

==================== Summary ====================

Name: ToolBuilder-Morphic-ul.59
Author: ul
Time: 2 May 2010, 12:46:58.475 pm
UUID: 8f5cbf2c-ce56-694f-a88d-5775750e6c57
Ancestors: ToolBuilder-Morphic-fbs.58

- fix: #edit:label:accept: didn't set the label

=============== Diff against ToolBuilder-Morphic-fbs.58 ===============

Item was changed:
  ----- Method: MorphicUIManager>>edit:label:accept: (in category 'ui requests') -----
  edit: aText label: labelString accept: anAction
  "Open an editor on the given string/text"
+
  | window |
  window := Workspace open.
+ labelString ifNotNil: [ window setLabel: labelString ].
+ window model
+ acceptContents:  aText;
+ acceptAction: anAction.
- window model acceptContents:  aText.
- window model acceptAction: anAction.
  ^window.!

On 2010/05/02 11:03, [hidden email] wrote:
I'd noticed the lack of label-setting when I touched this method. I
didn't do anything about the issue because I was fixing something else :)

But things look a bit strange. Look at the versions for
MorphicUIManager>>edit:label:accept:. You'll see the version above, "ul
5/2/2010 ...", and then "ar 4/21/2010 ...". There's no mention of the
changes introduced by ToolBuilder-Morphic-fbs.58, the ancestor of this
version.

You can, however, see my changes and Levente's if you diff between the
versions (as one would expect).

I had expected to see ul's version of the method, then mine, and then ar's.

Is this a bug?

frank

On 02.05.2010, at 13:58, Frank Shearar wrote:
Updating using Monticello skips intermediate versions. It just loads the latest, so the intermediate ones are not in the changes file.

- Bert -

On 2010/05/02 15:21, Bert Freudenberg wrote:
Ah. Makes sense. It does make the VersionsBrowser less useful (IMO at
least), since it shows only those versions in the changes file.

In other words, if I load a Monticello package, and look at the versions
of some method brand new to the image, I'll only see that most recent
version, not the full history of that method (which would require
downloading every mcz/mcd for that package).

But, if I understand correctly, if I loaded up each version separately
and saved the image in between, I would see all the versions because
each save would store that version in the changes file?

frank

On 02.05.2010, at 16:18, Frank Shearar wrote:
>
> On 2010/05/02 15:21, Bert Freudenberg wrote:
>>
>> Updating using Monticello skips intermediate versions. It just loads the latest, so the intermediate ones are not in the changes file.
>
> Ah. Makes sense. It does make the VersionsBrowser less useful (IMO at least), since it shows only those versions in the changes file.

Yup.

> In other words, if I load a Monticello package, and look at the versions of some method brand new to the image, I'll only see that most recent version, not the full history of that method (which would require downloading every mcz/mcd for that package).
>
> But, if I understand correctly, if I loaded up each version separately and saved the image in between, I would see all the versions because each save would store that version in the changes file?

No need to save the image in between. Just load all in succession.

Btw, I'd think The Right Way to do this is put the versions into a database [*] on some server, preferably back to the beginning of time. Then hook the versions browser into that, merging local and remote changes. I think some student (maybe of Ralph?) started on this but I can't remember if it lead anywhere.

- Bert -

[*] How does git or hg or something like that sound as a database format? ;)

On 2010/05/02 17:37, Bert Freudenberg wrote:
That would be awesome, because then I wouldn't have to do it :)

And I was pondering just that, actually: how to make Monticello
git-like, or something like that. The thought's not well-formed. I don't
mean turn Monticello into git or anything like that. I'd just like to be
able to use a Squeak equivalent of, for instance, GitX or TortoiseGit,
and be able to ask the repository questions - "Who touched this method?
How did this class definition evolve?" And since mczs are immutable
(*cough*) one could cache lots of this information.

> - Bert -
>
> [*] How does git or hg or something like that sound as a database format? ;)

There's been recent work in the Squeak-git area: Tony Garnock-Jones'
http://www.squeaksource.com/Git.html, there's
http://gsoc2010.esug.org/projects/git-mercurial and I seem to recall
another project being mentioned on squeak-dev...?

frank

On Sun, 2010-05-02 at 20:40 +0200, Frank Shearar wrote: Hi
It's not a proper solution, more of a crook, but I use my project
Gitocello for tracking Monticello repositories (commits are saved
structured by category into folders, commited with the Monticello
message and author to a local git repository).
I actually started this project to be able to easily share packages
between Squeak and Gnu Smalltalk, but I found that much of the tooling
git provides me with really helps when porting code to and fro (bisect,
blaming, seeing branches and merges, cherry-picking commits, seeing
commits which touch a particular class).

I would love to see Monticello tools evolve to include some of these
features. Personally, what I miss most right now is just being able to
see the minimal diff between two arbitrary versions of a package
(creating and mcd and browsing it seems to show me the complete
package).

Just me formulating dreams.

Regards,
Tim

Hi Tim,

Tim Felgentreff wrote:
> It's not a proper solution, more of a crook, but I use my project
> Gitocello for tracking Monticello repositories (commits are saved
> structured by category into folders, commited with the Monticello
> message and author to a local git repository).

Interesting! Could you elaborate on exactly how you map Squeak's
classes/methods/categories etc. to files?

Tony

Hi
Folder Structure for Kernel starts like this:
    Kernel/
        - Chronology/
            - DateAndTime.st
            - TimeStamp.st
            ...
        - Classes/
        - Methods/
        ...

I use Gitocello for Gitocello itself and it's on Github
(http://github.com/timfel/gitocello)
That's not the latest version, though, I'm in the process of porting it
to an implementation of git in Smalltalk, to avoid callouts to the git
binary.

On Mon, 2010-05-03 at 21:11 +1200, Tony Garnock-Jones wrote:

On 2010/05/03 11:45, Tim Felgentreff wrote:
Would that be Tony's git implementation? :)
(http://www.squeaksource.com/Git.html)

frank

On Mon, 2010-05-03 at 11:51 +0200, Frank Shearar wrote:
> Would that be Tony's git implementation? :)
> (http://www.squeaksource.com/Git.html)
>
> frank

Indeed :)

- tim

Tim Felgentreff wrote:
> On Mon, 2010-05-03 at 11:51 +0200, Frank Shearar wrote:
>> Would that be Tony's git implementation? :)
> Indeed :)

Hooray! I look forward to seeing it!

Had you considered *further* structure than Classname.st? For example

  Classname.st       containing the class definition itself
  Classname/         containing method sources, one per file
    method1.st
    method2.st

or similar?

Tony

On 2010/05/03 12:09, Tony Garnock-Jones wrote:
And Classname/comment :)

frank

Am 2010-05-03 um 13:53 schrieb Frank Shearar:

And meta-data?!
What about Textattibutes of sourcecode? (yes, this is possible in Squeak.)

So Long,
        -Tobias

Tobias Pape wrote:
> Am 2010-05-03 um 13:53 schrieb Frank Shearar:
>> On 2010/05/03 12:09, Tony Garnock-Jones wrote:
>>>   Classname.st       containing the class definition itself
>>>   Classname/         containing method sources, one per file
>>>     method1.st
>>>     method2.st
>> And Classname/comment :)
> And meta-data?!
> What about Textattibutes of sourcecode? (yes, this is possible in Squeak.)

One good starting point would be to examine what Monticello puts in each
commit, and map that onto a filesystem-tree-like structure in as fine-grained a
way as possible. (I don't think MC stores text attributes, BTW; perhaps
something that's unavoidable when quaintly storing source code in files?)

  Package/
    Subpackage/
      Classname.class/
        definition.st
        comment.txt
        methods/
          method:source:code:.st
          method2.st

or

  Package/
    Subpackage/
      Classname.st            The class definition
      Classname.doc           The class comment
      Classname.methods/
        method:source:code:.st
        method2.st

or

  Package/
    Subpackage/
      Classname.st
      Classname.doc
      Classname.method:source:code:.st
      Classname.method2.st

Regards,
  Tony

Guys,

Have you seen Building GitFS blog by Max Leske? It's fairly new. See
http://buildinggitfs.blogspot.com/

Ian.
--
http://mecenia.blogspot.com/

Ian Trudel wrote:
> Have you seen Building GitFS blog by Max Leske? It's fairly new. See
> http://buildinggitfs.blogspot.com/

Yep. We've been corresponding. He's porting the core of the Git package to
Pharo and an alternative API to the file system. I think one of his goals is to
define a mapping from Smalltalk to the file system, but I'm not sure if he has
written up any of his ideas yet.

Tony