project directory structure (git for smalltalk)

I've basically spent a big part of the last week working though alternate directory structure schemes to be used in git for a Smalltalk project ...

There are two pieces to the structure. The first part is the structure that we use to represent the Monticello package structure on disk and the second part of the structure is how the packages are organized in the git project.

I've prepared a gist[1] that gives you a picture of what I am proposing for the package structure and then shows two different package structures:

  - classic Monticello package structure[3]
  - alternate package structure[2]

So I'd like to have some feedback on the proposed structure. If you haven't already seen it please take a look at the assumptions[4] that I think should be made for this project.

I'd appreciate it if you would ask questions or propose alternatives for discussion ... there are a bunch of factors that have gone into putting the structure together, but I think my proposal is a readable structure that can be managed from disk and can be mapped into image-based constructs ....

Dale

[1] https://gist.github.com/1892114
[2] https://github.com/dalehenrich/alternate
[3] https://github.com/dalehenrich/sample
[4] https://gist.github.com/1893955

see my comment on 

On Feb 25, 8:51 pm, Dale Henrichs <[hidden email]> wrote:
I don't want to be a party pooper but I see several problems with this
Monticello/git duality. It mostly comes down to keeping the Monticello
and git metadata in sync.

For example since it's still Monticello there has to be all the
Monticello metadata which is laying around in "strange" files like [1]
[2]. This makes it quite unlikely that you can edit the source with a
text editor and not screw up the Monticello metadata. And if you'll
just be using it through the in-image tools why bother with a nice
source layout at all?

When you do a merge, will that be a git or a Monticello merge? If it's
a git merge how will the Monticello metadata be updated and vice
versa?

And a lot of information is duplicated. git already tracks author and
timestamp, so does Monticello. git already has a revision id but
Monticello has a different one.

I wonder whether it wouldn't be simpler to either embrace git or
Monticello. If you embrace git then why not go for a source format
that you can actually edit with a text editor like [3] and use all the
git metadata (author, timestamp)? This way git merge and everything
would just work fine. I realize this is a lot of work. If you embrace
Monticello then why bother with git at all? So that you don't have to
use SqueakSource?

 [1] https://github.com/dalehenrich/sample/tree/master/core/Sample-Core.pkg
 [2] https://github.com/dalehenrich/sample/tree/master/core/Sample-Core.pkg/definitions
 [3] https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/test/smalltalk/st/redline/ArrayTest.st

Cheers
Philippe

Philippe,

You are not a party pooper ... these are exactly the kinds of questions I'm looking for:) They are excellent questions.

I'm going to highlight several of your points and then answer:

  "keeping the Monticello and git metadata in sync. For example
   since it's still Monticello there has to be all the Monticello
   metadata which is laying around in "strange" files ...
   makes it quite unlikely that you can edit the source with a
   text editor and not screw up the Monticello metadata."

  "If you'll just be using it through the in-image tools why
   bother with a nice source layout at all?"

  "And a lot of information is duplicated."

  "If you embrace git then why not go for a source format that
   you can actually edit with a text editor like [3] and use
   all the git metadata (author, timestamp)?"

  "If you embrace Monticello then why bother with git at all?"

I'm going to address your last point first, since everything else follows from that... I think...

-----------------
  Why bother with git at all?

Monticello versions individual packages (source files), it is not an SCM[1]. In many respects Monticello is closer to RCS[2] than Git[3].

Git manages versions of entire directory structures...making it possible to version collections of packages along with the entire range of ancillary files that are typically required for modern software development.

Monticello manages versions of a single package. A single file.... If you find yourself needing to do anything beyond managing a single mcz file, Monticello does not help. Need I say more?

-----------------
  Why bother with Monticello at all?

When it comes to image-base development Monticello's declarative model (i.e, definition snapshot) is a REQUIRED component.

If you can afford to file in code fresh every time you start an image (non-image-based development), then you don't need to monkey with snapshots, because when you REMOVE a method from a file, it will not be present the next time you file in the source.

In image-based the development, the act of REMOVING a method from a file is not sufficient ... you have to arrange to physically remove the method from the image as well. The Monticello snapshot manages the bridge between Smalltalk source and the image quite well.

-----------------
  Synthesis of Monticello and Git

The idea then is to preserve the Monticello snapshot (required for image-based development) while taking advantage of Git (required to bring modern SCM capatabilties to Smalltalk).

BTW, Git does a great job of tracking file identity and file history ... Putting a single method in each .st file, it is possible to track the revision history of a single method as it is moved form package to package and class to class ... pretty cool...

-----------------
  Monticello Meta Data

The 'package' file can be eliminated with no loss of information.

The 'version' file is kept in order to allow one to explicitly preserve package ancestry (package author, timestamp, UUID, ancestry, etc.). The project maintainers should be given the option to preserve package ancestry. If the maintainers decide to preserve the package ancestry, then they can make informed decisions when doing merges. If they choose to not preserve the package ancestry, then it should be safe to remove the 'version' file. Issue 2[5] and Issue 6[6] for the filetree project covers the thinking in a bit more detail.

The method author/date timestamp information is kept (for the moment at least) because the MCMethodDefintion>>= uses the timstamp, until the Monticello logic can be changed (in GemStone, Squeak, and Pharo) it makes sense to continue to use the timestamp [7].

If I'm not mistaken this covers the redundant data and the 'strange' files.

-----------------
  Summary

This project isn't about replacing SqueakSource...this project is about bringing the power of git to Smalltalk development and leverage github for the features that far surpass anything that we have in Smalltalk[8][9][10][11][12][13].

BTW, Git is not the only target. The mapping of Monticello/Metacello to disk is SCM neutral. SVN or mercurial can be used just as easily with the proposed disk format.

I suggest that git/github is a good choice for the Smalltalk community at large, but it isn't a requirement.

Dale

[1] http://en.wikipedia.org/wiki/Software_configuration_management
[2] http://linuxcommand.org/man_pages/rcs1.html
[3] http://en.wikipedia.org/wiki/Git_(software)
[4] https://github.com/dalehenrich/sample/tree/master/core/Sample-Core.pkg
[5] https://github.com/dalehenrich/filetree/issues/2
[6] https://github.com/dalehenrich/filetree/issues/6
[7] https://github.com/finworks/smallsource/issues/12
[8] https://github.com/features/projects
[9] https://github.com/features/hosting
[10] https://github.com/features/community
[11] https://gist.github.com/
[12] http://pages.github.com/
[13] http://developer.github.com/

----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Metacello" <[hidden email]>
| Sent: Sunday, February 26, 2012 12:38:29 PM
| Subject: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
| On Feb 25, 8:51 pm, Dale Henrichs <[hidden email]> wrote:
| > I've basically spent a big part of the last week working though
| > alternate directory structure schemes to be used in git for a
| > Smalltalk project ...
| >
| > There are two pieces to the structure. The first part is the
| > structure that we use to represent the Monticello package
| > structure on disk and the second part of the structure is how the
| > packages are organized in the git project.
| >
| > I've prepared a gist[1] that gives you a picture of what I am
| > proposing for the package structure and then shows two different
| > package structures:
| >
| >   - classic Monticello package structure[3]
| >   - alternate package structure[2]
| >
| > So I'd like to have some feedback on the proposed structure. If you
| > haven't already seen it please take a look at the assumptions[4]
| > that I think should be made for this project.
| >
| > I'd appreciate it if you would ask questions or propose
| > alternatives for discussion ... there are a bunch of factors that
| > have gone into putting the structure together, but I think my
| > proposal is a readable structure that can be managed from disk and
| > can be mapped into image-based constructs ....
|
| I don't want to be a party pooper but I see several problems with
| this
| Monticello/git duality. It mostly comes down to keeping the
| Monticello
| and git metadata in sync.
|
| For example since it's still Monticello there has to be all the
| Monticello metadata which is laying around in "strange" files like
| [1]
| [2]. This makes it quite unlikely that you can edit the source with a
| text editor and not screw up the Monticello metadata. And if you'll
| just be using it through the in-image tools why bother with a nice
| source layout at all?
|
| When you do a merge, will that be a git or a Monticello merge? If
| it's
| a git merge how will the Monticello metadata be updated and vice
| versa?
|
| And a lot of information is duplicated. git already tracks author and
| timestamp, so does Monticello. git already has a revision id but
| Monticello has a different one.
|
| I wonder whether it wouldn't be simpler to either embrace git or
| Monticello. If you embrace git then why not go for a source format
| that you can actually edit with a text editor like [3] and use all
| the
| git metadata (author, timestamp)? This way git merge and everything
| would just work fine. I realize this is a lot of work. If you embrace
| Monticello then why bother with git at all? So that you don't have to
| use SqueakSource?
|
|  [1]
|  https://github.com/dalehenrich/sample/tree/master/core/Sample-Core.pkg
|  [2]
|  https://github.com/dalehenrich/sample/tree/master/core/Sample-Core.pkg/definitions
|  [3]
|  https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/test/smalltalk/st/redline/ArrayTest.st
|
| Cheers
| Philippe
|

Hi Dale,

It's great that you're asking these questions; I've been brewing over
them for a few days now. I'm sure if we put our heads together on the
list we'll come up with something great.

The first major question (that Philippe touched on) is if we really
want to keep the compatibility between git and Monticello going. I
think we don't have to worry too much about that, as long as we keep:
1. categories as the "link": if you load classes from anywhere and can
create a (git or MC) package from a category, and
2. the *<category> mechanism for extensions

Then, if we load an MC package, be able to manage it in an external
repository or load a git package, publish the code to an MC
repository. Do we really need a lot of "compatibility" stuff such as
the metadata?

I propose for a file based system that we avoid giving structure like
"core" or "tests" to it. We've already got the convention of naming
packages X-Core, X-Tests-Core, X-Pharo-Tests-Core and all of that.
Defining too much structure just makes it difficult to extend. I think
we should keep less information in the git structure.

That makes the second question for me: how much meta-data to keep? I
think the answer is to take all the meta data from the git repository
and not to keep any other meta data. Duplicating meta data just makes
things more complicated and less flexible. If you keep stuff in git,
use git's meta data that's in the git repository. Merging version
files and other meta information is just a pain.

The ideal file structure for me is something that mirrors the
smalltalk system browser. And I really think we don't need more than
this. For example:

+-Sample-Core\        # always packages at this level - what else?
  +-SampleCore\       # directories at this level are classes - what else?
  |  +-definition.st
  |  +-class-side\
  |    +-initialization
  |      +-initialize.st
  |  +-instance-side\
  |    +-accessing
  |      +-sample.st
  |      +-sample:.st
  +-AnotherSampleClass
      ....

Extensions simply are methods that don't have a definition in this
package. The definition must then be elsewhere - what else? Methods
should only contain the source (no meta and no chunk format).

There are many file based tools that makes this look almost like a
smalltalk browser! (Even vim).

Then, I would not monkey with the structure. More simplicity and less
flexibility (in the sense that you allow any file structure and get
the meta information to be magically compatible with MC).

I'll make some comments on your assumptions...

HTH
Otto

On Sat, Feb 25, 2012 at 9:51 PM, Dale Henrichs <[hidden email]> wrote:

Hi Dale,

after seeing your examples, I have to tell something:

what I really, really don't like is the method-centric approach.

I don't understand why classes can't be a file "Class.st", unless those confusing and useless separation... to have everything separated that way makes source files completely unreadable for one without the class in their system.
And being capable to "read" the code without loading is a very important issue.
Also, offer a structure not so alien to newcomers or people just browsing sources is very important (I do it everytime, with java, ruby, python, etc., just to see how other did it and see if I can take ideas).
We don't need another object format, chunk format is completely capable to provide this.

So, here my counter-proposal:
(based on "alternate")

core
        Package.pkg
                Class.st (a FILE)
extension
        Package.pkg
                Object.st (a FILE *without* class definition, just the method extensions)
tests
doc
platform (not sure about this)
metadata (if needed, better to keep all metadata in one unique position than distributed on all structure)

What we gain: clarity, readability and conciseness
What we loose: method grained versioning *in git* (and just in git, diff tool can help here while in file, nothing changes when in image)

best,
Esteban

El 27/02/2012, a las 1:39p.m., Otto Behrens escribió:

While we're on the subject of declarative Smalltalk syntax. I am aware
of at least four different syntax flavours (not including chunk) :

GNU &  Étoilé: http://book.seaside.st/book/getting-started/gst/first-component,
http://etoileos.com/dev/docs/languages/smalltalk/
RedLine: https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/test/smalltalk/st/redline/ArrayTest.st
Coral: http://rmod.lille.inria.fr/coral/syntax.html
Resilient Smalltalk: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&type=pdf
(page 5)

Any more?

Do the different syntaxes offer benefits over each other, other than
different syntactic sugar?

Nick

On Feb 27, 5:33 pm, Esteban Lorenzano <[hidden email]> wrote:

Esteban,

Thanks for the feedback!

We could have a Class.st file and an Object.st file, but we can't just fileIn those .st files ...

We have to have the package snapshot in order to correctly remove methods and classes from the image on load. Therefore we would have to turn those two files into snapshots ... so we would have to parse the files, create the snapshot and definitions, then do the load ... It makes the initial implementation a bit harder (and might even make the snapshot creation from disk a bit more efficient), but it is definitely doable.

If we're going to put more than one method in file, I would want to get rid of the chunk format altogether... I wouldn't want to look at chunk format all day long. There's the format used by redline[1][2] and the format used by GST[3]. It looks like Amber uses chunk format[4]...Are there other alternatives...Personally, the redline format looks very clean...

I'd be inclined to preserve the package structure with something like this though:

+-Sample-Core.pkg\
  +-snapshot\
  | +-classes\
  | | +-SampleCore.st
  | +-extensions\
  | | +-Object.st

I think that if we are going to be organizing around package snapshots (and I still maintain that this is simply required for image-based development), then the disk structure needs to preserve the package structure...

Otto, you've been living with "method per file" organiszation for quite a while ... have you considered going with "class per file" as suggested by Esteban?

Dale

[1] https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/main/smalltalk/st/redline/Character.st
[2] https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/main/smalltalk/st/redline/Array.st
[3] https://github.com/bonzini/smalltalk/blob/master/packages/seaside/core/Seaside-GST.st
[4] https://github.com/NicolasPetton/amber/blob/master/st/IDE.st
----- Original Message -----
| From: "Esteban Lorenzano" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 9:33:47 AM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| Hi Dale,
|
| after seeing your examples, I have to tell something:
|
| what I really, really don't like is the method-centric approach.
|
| I don't understand why classes can't be a file "Class.st", unless
| those confusing and useless separation... to have everything
| separated that way makes source files completely unreadable for one
| without the class in their system.
| And being capable to "read" the code without loading is a very
| important issue.
| Also, offer a structure not so alien to newcomers or people just
| browsing sources is very important (I do it everytime, with java,
| ruby, python, etc., just to see how other did it and see if I can
| take ideas).
| We don't need another object format, chunk format is completely
| capable to provide this.
|
| So, here my counter-proposal:
| (based on "alternate")
|
| core
| Package.pkg
| Class.st (a FILE)
| extension
| Package.pkg
| Object.st (a FILE *without* class definition, just the method
| extensions)
| tests
| doc
| platform (not sure about this)
| metadata (if needed, better to keep all metadata in one unique
| position than distributed on all structure)
|
| What we gain: clarity, readability and conciseness
| What we loose: method grained versioning *in git* (and just in git,
| diff tool can help here while in file, nothing changes when in
| image)
|
| best,
| Esteban
|
| El 27/02/2012, a las 1:39p.m., Otto Behrens escribió:
|
| > Hi Dale,
| >
| > It's great that you're asking these questions; I've been brewing
| > over
| > them for a few days now. I'm sure if we put our heads together on
| > the
| > list we'll come up with something great.
| >
| > The first major question (that Philippe touched on) is if we really
| > want to keep the compatibility between git and Monticello going. I
| > think we don't have to worry too much about that, as long as we
| > keep:
| > 1. categories as the "link": if you load classes from anywhere and
| > can
| > create a (git or MC) package from a category, and
| > 2. the *<category> mechanism for extensions
| >
| > Then, if we load an MC package, be able to manage it in an external
| > repository or load a git package, publish the code to an MC
| > repository. Do we really need a lot of "compatibility" stuff such
| > as
| > the metadata?
| >
| > I propose for a file based system that we avoid giving structure
| > like
| > "core" or "tests" to it. We've already got the convention of naming
| > packages X-Core, X-Tests-Core, X-Pharo-Tests-Core and all of that.
| > Defining too much structure just makes it difficult to extend. I
| > think
| > we should keep less information in the git structure.
| >
| > That makes the second question for me: how much meta-data to keep?
| > I
| > think the answer is to take all the meta data from the git
| > repository
| > and not to keep any other meta data. Duplicating meta data just
| > makes
| > things more complicated and less flexible. If you keep stuff in
| > git,
| > use git's meta data that's in the git repository. Merging version
| > files and other meta information is just a pain.
| >
| > The ideal file structure for me is something that mirrors the
| > smalltalk system browser. And I really think we don't need more
| > than
| > this. For example:
| >
| > +-Sample-Core\        # always packages at this level - what else?
| >  +-SampleCore\       # directories at this level are classes - what
| >  else?
| >  |  +-definition.st
| >  |  +-class-side\
| >  |    +-initialization
| >  |      +-initialize.st
| >  |  +-instance-side\
| >  |    +-accessing
| >  |      +-sample.st
| >  |      +-sample:.st
| >  +-AnotherSampleClass
| >      ....
| >
| > Extensions simply are methods that don't have a definition in this
| > package. The definition must then be elsewhere - what else? Methods
| > should only contain the source (no meta and no chunk format).
| >
| > There are many file based tools that makes this look almost like a
| > smalltalk browser! (Even vim).
| >
| > Then, I would not monkey with the structure. More simplicity and
| > less
| > flexibility (in the sense that you allow any file structure and get
| > the meta information to be magically compatible with MC).
| >
| > I'll make some comments on your assumptions...
| >
| > HTH
| > Otto
| >
| > On Sat, Feb 25, 2012 at 9:51 PM, Dale Henrichs
| > <[hidden email]> wrote:
| >> I've basically spent a big part of the last week working though
| >> alternate directory structure schemes to be used in git for a
| >> Smalltalk project ...
| >>
| >> There are two pieces to the structure. The first part is the
| >> structure that we use to represent the Monticello package
| >> structure on disk and the second part of the structure is how the
| >> packages are organized in the git project.
| >>
| >> I've prepared a gist[1] that gives you a picture of what I am
| >> proposing for the package structure and then shows two different
| >> package structures:
| >>
| >>  - classic Monticello package structure[3]
| >>  - alternate package structure[2]
| >>
| >> So I'd like to have some feedback on the proposed structure. If
| >> you haven't already seen it please take a look at the
| >> assumptions[4] that I think should be made for this project.
| >>
| >> I'd appreciate it if you would ask questions or propose
| >> alternatives for discussion ... there are a bunch of factors that
| >> have gone into putting the structure together, but I think my
| >> proposal is a readable structure that can be managed from disk
| >> and can be mapped into image-based constructs ....
| >>
| >> Dale
| >>
| >> [1] https://gist.github.com/1892114
| >> [2] https://github.com/dalehenrich/alternate
| >> [3] https://github.com/dalehenrich/sample
| >> [4] https://gist.github.com/1893955
|
|

Damn it, I didn't know about Resilient Smalltalk.

I agree with Esteban: I would gladly lose the niceness of per-method
versioning if it meant I could have multiple methods in a file.

I've discussed :) gst's syntax with the Coral folks. Mainly, our
disagreements regarding syntax boil down to that I _want_ nesting
syntax (they will allow nesting classes without any extra work,
they're semantically more elegant than "oh you can only nest 1 level
(method in a class)") and they don't. I think that's a fair summary,
Stephane?

Both gst and Coral (and, it looks, Resilient) offer a clear and simple
way to define a class such that method membership is lexically
obvious.

Well, gst doesn't quite have the kind of nesting I want to permit, but
it is closer. Anyway, mainly I'd say "use gst because they've been
using it for a while and it clearly works for them".

Nick, maybe quiz UKSTUG tonight? (Seeing as you've just started, most
likely, this message will arrive in your inbox too late :/)

frank

On 27 February 2012 18:14, Nick Ager <[hidden email]> wrote:

> Otto, you've been living with "method per file" organiszation for quite a while ... have you considered going with "class per file" as suggested by Esteban?

I haven't tried it. I really like the method per file approach because
the git merge is so cool. Its also easy to get a method's history from
git, and very nice to see useful output in git whatchanged. I imagine
the st image mapping so nicely to objects in git, with the tools
nicely integrated.

I think the image is a mega powerful thing and I imagine working in
the image for some time, using refactoring tools, auto formatting,
running tests automatically and lots of beautiful reasons, essentially
why I like Smalltalk.

I use text based tools like grep and vim and git to enhance the whole
image. We've got a bit of code in ruby and I've touched a bit of
python recently, with classes and methods in a file. And I longed for
my ST image. Nothing like it.

It will totally rock with some tools to interface more directly with
git. I wish I had the stamina like some of you who do 36 hour days :-)
Business first at the moment, unfortunately.

could we avoid to change everything at the same time?
I do not like redline syntax (and in particular the + starting at the beginning of the line)  and prefer the one of coral (pepsi).
This syntax does not have a proper scope. Without the class definition you do not know where the method is so good luck.
Then + makes the code brittle because you have to make sure that it is the first character.
And I will seriously veto it for pharo. I studied since year syntaxes for scripting language (remember our discussions at lugano). Now again can we avoid to mix everything?
I do not see why the syntax of the method is now entering discussion.

Esteban having one file per method is important to avoid also the mess when your methods are reshuffled.

Stef

On Feb 27, 2012, at 7:35 PM, Frank Shearar wrote:

Yes but I could live with it as soon as I can save flatten :)
And I **hate** the red line syntax for method.

> Both gst and Coral (and, it looks, Resilient) offer a clear and simple
> way to define a class such that method membership is lexically
> obvious.

Indeed :)

I do not like the |a b d| and class Var in GNU.
Now we should work on coral but I do not have the cycles.
 

I agree otto :)

3 clients this week :)

On Feb 27, 2012, at 8:18 PM, Otto Behrens wrote:

On 27 February 2012 20:13, stephane ducasse <[hidden email]> wrote:
Indeed: I don't mind the |a b d| part too much, as it reads a bit like
"these variables exist within this scope (this class definition). I do
dislike the class var business: implicit variable declaration _sucks_.
But if I could only choose from the current options (in other words
not invent yet another format), I'd hold my nose and choose gst's
syntax despite the implicit class var stuff (mainly because it is
fairly battle tested).

frank

Hi,

I also don't like the redline syntax... it predates the "+" and "-" from ObjectiveC, but I think for us something like GST or coral are better (even if I don't completely like the [] to mark a method, at least is clear :)

but... I strongly support file-per-class, I think this approach is really needed for being able to really manipulate git on files... I also don't think we'll loose the power of merging and versioning from git... which are, again, just in the file side... our images will remain with all the power of current versioning.

best,
Esteban

El 27/02/2012, a las 5:25p.m., Frank Shearar escribió:

Ahhh... I forget to say... I also agree that we don't need to change current chunk format to have  a good git-monticello integration.
We can start as we are, and do that later...

best,
Esteban

El 27/02/2012, a las 5:25p.m., Frank Shearar escribió:

Stef,

Good point, I was thinking the same thing:) We won't be changing everything at the same time, but I do think that we need to understand the scope of what we're doing so we can plan on staging features in (if indeed staging is needed) ...

For example, if we go with one method for file ... chunk format is okay since you are only looking at one chunk at a time ... chunk format becomes noisy when looking at an entire file of chunks (in my opinion). If you are going with a file per class, then the format becomes much more important, if nothing else because it becomes necessary to arrange to parse the format so that the class file can be converted to definitions (chunk format is pretty easy to parse, but bad for reading).

We aren't going to git to ALLOW developers to write Smalltalk with emacs. We're going to git to leverage the capabilities of git, to give us some things that we don't have right now... However, when we go to git, developers WILL write Smalltalk with emacs[1], so we need to be prepared.

The fact is that for now, the primary use-case for git-based repositories will be from within a Smalltalk image, so losing "method grained versioning *in git*" is currently a greater price than gaining "clarity, readability and conciseness" on disk...

Dale

----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 12:10:29 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| could we avoid to change everything at the same time?
| I do not like redline syntax (and in particular the + starting at the
| beginning of the line)  and prefer the one of coral (pepsi).
| This syntax does not have a proper scope. Without the class
| definition you do not know where the method is so good luck.
| Then + makes the code brittle because you have to make sure that it
| is the first character.
| And I will seriously veto it for pharo. I studied since year syntaxes
| for scripting language (remember our discussions at lugano). Now
| again can we avoid to mix everything?
| I do not see why the syntax of the method is now entering discussion.
|
| Esteban having one file per method is important to avoid also the
| mess when your methods are reshuffled.
|
| Stef
|
| > Esteban,
| >
| > Thanks for the feedback!
| >
| > We could have a Class.st file and an Object.st file, but we can't
| > just fileIn those .st files ...
| >
| > We have to have the package snapshot in order to correctly remove
| > methods and classes from the image on load. Therefore we would
| > have to turn those two files into snapshots ... so we would have
| > to parse the files, create the snapshot and definitions, then do
| > the load ... It makes the initial implementation a bit harder (and
| > might even make the snapshot creation from disk a bit more
| > efficient), but it is definitely doable.
| >
| > If we're going to put more than one method in file, I would want to
| > get rid of the chunk format altogether... I wouldn't want to look
| > at chunk format all day long. There's the format used by
| > redline[1][2] and the format used by GST[3]. It looks like Amber
| > uses chunk format[4]...Are there other alternatives...Personally,
| > the redline format looks very clean...
| >
| > I'd be inclined to preserve the package structure with something
| > like this though:
| >
| > +-Sample-Core.pkg\
| >  +-snapshot\
| >  | +-classes\
| >  | | +-SampleCore.st
| >  | +-extensions\
| >  | | +-Object.st
| >
| > I think that if we are going to be organizing around package
| > snapshots (and I still maintain that this is simply required for
| > image-based development), then the disk structure needs to
| > preserve the package structure...
| >
| > Otto, you've been living with "method per file" organiszation for
| > quite a while ... have you considered going with "class per file"
| > as suggested by Esteban?
| >
| > Dale
| >
| > [1]
| > https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/main/smalltalk/st/redline/Character.st
| > [2]
| > https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/main/smalltalk/st/redline/Array.st
| > [3]
| > https://github.com/bonzini/smalltalk/blob/master/packages/seaside/core/Seaside-GST.st
| > [4] https://github.com/NicolasPetton/amber/blob/master/st/IDE.st
| > ----- Original Message -----
| > | From: "Esteban Lorenzano" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Monday, February 27, 2012 9:33:47 AM
| > | Subject: Re: [Metacello] project directory structure (git for
| > | smalltalk)
| > |
| > | Hi Dale,
| > |
| > | after seeing your examples, I have to tell something:
| > |
| > | what I really, really don't like is the method-centric approach.
| > |
| > | I don't understand why classes can't be a file "Class.st", unless
| > | those confusing and useless separation... to have everything
| > | separated that way makes source files completely unreadable for
| > | one
| > | without the class in their system.
| > | And being capable to "read" the code without loading is a very
| > | important issue.
| > | Also, offer a structure not so alien to newcomers or people just
| > | browsing sources is very important (I do it everytime, with java,
| > | ruby, python, etc., just to see how other did it and see if I can
| > | take ideas).
| > | We don't need another object format, chunk format is completely
| > | capable to provide this.
| > |
| > | So, here my counter-proposal:
| > | (based on "alternate")
| > |
| > | core
| > | Package.pkg
| > | Class.st (a FILE)
| > | extension
| > | Package.pkg
| > | Object.st (a FILE *without* class definition, just the method
| > | extensions)
| > | tests
| > | doc
| > | platform (not sure about this)
| > | metadata (if needed, better to keep all metadata in one unique
| > | position than distributed on all structure)
| > |
| > | What we gain: clarity, readability and conciseness
| > | What we loose: method grained versioning *in git* (and just in
| > | git,
| > | diff tool can help here while in file, nothing changes when in
| > | image)
| > |
| > | best,
| > | Esteban
| > |
| > | El 27/02/2012, a las 1:39p.m., Otto Behrens escribió:
| > |
| > | > Hi Dale,
| > | >
| > | > It's great that you're asking these questions; I've been
| > | > brewing
| > | > over
| > | > them for a few days now. I'm sure if we put our heads together
| > | > on
| > | > the
| > | > list we'll come up with something great.
| > | >
| > | > The first major question (that Philippe touched on) is if we
| > | > really
| > | > want to keep the compatibility between git and Monticello
| > | > going. I
| > | > think we don't have to worry too much about that, as long as we
| > | > keep:
| > | > 1. categories as the "link": if you load classes from anywhere
| > | > and
| > | > can
| > | > create a (git or MC) package from a category, and
| > | > 2. the *<category> mechanism for extensions
| > | >
| > | > Then, if we load an MC package, be able to manage it in an
| > | > external
| > | > repository or load a git package, publish the code to an MC
| > | > repository. Do we really need a lot of "compatibility" stuff
| > | > such
| > | > as
| > | > the metadata?
| > | >
| > | > I propose for a file based system that we avoid giving
| > | > structure
| > | > like
| > | > "core" or "tests" to it. We've already got the convention of
| > | > naming
| > | > packages X-Core, X-Tests-Core, X-Pharo-Tests-Core and all of
| > | > that.
| > | > Defining too much structure just makes it difficult to extend.
| > | > I
| > | > think
| > | > we should keep less information in the git structure.
| > | >
| > | > That makes the second question for me: how much meta-data to
| > | > keep?
| > | > I
| > | > think the answer is to take all the meta data from the git
| > | > repository
| > | > and not to keep any other meta data. Duplicating meta data just
| > | > makes
| > | > things more complicated and less flexible. If you keep stuff in
| > | > git,
| > | > use git's meta data that's in the git repository. Merging
| > | > version
| > | > files and other meta information is just a pain.
| > | >
| > | > The ideal file structure for me is something that mirrors the
| > | > smalltalk system browser. And I really think we don't need more
| > | > than
| > | > this. For example:
| > | >
| > | > +-Sample-Core\        # always packages at this level - what
| > | > else?
| > | >  +-SampleCore\       # directories at this level are classes -
| > | >  what
| > | >  else?
| > | >  |  +-definition.st
| > | >  |  +-class-side\
| > | >  |    +-initialization
| > | >  |      +-initialize.st
| > | >  |  +-instance-side\
| > | >  |    +-accessing
| > | >  |      +-sample.st
| > | >  |      +-sample:.st
| > | >  +-AnotherSampleClass
| > | >      ....
| > | >
| > | > Extensions simply are methods that don't have a definition in
| > | > this
| > | > package. The definition must then be elsewhere - what else?
| > | > Methods
| > | > should only contain the source (no meta and no chunk format).
| > | >
| > | > There are many file based tools that makes this look almost
| > | > like a
| > | > smalltalk browser! (Even vim).
| > | >
| > | > Then, I would not monkey with the structure. More simplicity
| > | > and
| > | > less
| > | > flexibility (in the sense that you allow any file structure and
| > | > get
| > | > the meta information to be magically compatible with MC).
| > | >
| > | > I'll make some comments on your assumptions...
| > | >
| > | > HTH
| > | > Otto
| > | >
| > | > On Sat, Feb 25, 2012 at 9:51 PM, Dale Henrichs
| > | > <[hidden email]> wrote:
| > | >> I've basically spent a big part of the last week working
| > | >> though
| > | >> alternate directory structure schemes to be used in git for a
| > | >> Smalltalk project ...
| > | >>
| > | >> There are two pieces to the structure. The first part is the
| > | >> structure that we use to represent the Monticello package
| > | >> structure on disk and the second part of the structure is how
| > | >> the
| > | >> packages are organized in the git project.
| > | >>
| > | >> I've prepared a gist[1] that gives you a picture of what I am
| > | >> proposing for the package structure and then shows two
| > | >> different
| > | >> package structures:
| > | >>
| > | >>  - classic Monticello package structure[3]
| > | >>  - alternate package structure[2]
| > | >>
| > | >> So I'd like to have some feedback on the proposed structure.
| > | >> If
| > | >> you haven't already seen it please take a look at the
| > | >> assumptions[4] that I think should be made for this project.
| > | >>
| > | >> I'd appreciate it if you would ask questions or propose
| > | >> alternatives for discussion ... there are a bunch of factors
| > | >> that
| > | >> have gone into putting the structure together, but I think my
| > | >> proposal is a readable structure that can be managed from disk
| > | >> and can be mapped into image-based constructs ....
| > | >>
| > | >> Dale
| > | >>
| > | >> [1] https://gist.github.com/1892114
| > | >> [2] https://github.com/dalehenrich/alternate
| > | >> [3] https://github.com/dalehenrich/sample
| > | >> [4] https://gist.github.com/1893955
| > |
| > |
|
|

Agreed ...

Camillo Bruni and Max Leske have a real good start on interfacing to git from Smalltalk, so there is progress on that front...

Dale

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 11:18:22 AM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| > Otto, you've been living with "method per file" organiszation for
| > quite a while ... have you considered going with "class per file"
| > as suggested by Esteban?
|
| I haven't tried it. I really like the method per file approach
| because
| the git merge is so cool. Its also easy to get a method's history
| from
| git, and very nice to see useful output in git whatchanged. I imagine
| the st image mapping so nicely to objects in git, with the tools
| nicely integrated.
|
| I think the image is a mega powerful thing and I imagine working in
| the image for some time, using refactoring tools, auto formatting,
| running tests automatically and lots of beautiful reasons,
| essentially
| why I like Smalltalk.
|
| I use text based tools like grep and vim and git to enhance the whole
| image. We've got a bit of code in ruby and I've touched a bit of
| python recently, with classes and methods in a file. And I longed for
| my ST image. Nothing like it.
|
| It will totally rock with some tools to interface more directly with
| git. I wish I had the stamina like some of you who do 36 hour days
| :-)
| Business first at the moment, unfortunately.
|
| >
| > Dale
| >
| > [1]
| > https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/main/smalltalk/st/redline/Character.st
| > [2]
| > https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/main/smalltalk/st/redline/Array.st
| > [3]
| > https://github.com/bonzini/smalltalk/blob/master/packages/seaside/core/Seaside-GST.st
| > [4] https://github.com/NicolasPetton/amber/blob/master/st/IDE.st
| > ----- Original Message -----
| > | From: "Esteban Lorenzano" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Monday, February 27, 2012 9:33:47 AM
| > | Subject: Re: [Metacello] project directory structure (git for
| > | smalltalk)
| > |
| > | Hi Dale,
| > |
| > | after seeing your examples, I have to tell something:
| > |
| > | what I really, really don't like is the method-centric approach.
| > |
| > | I don't understand why classes can't be a file "Class.st", unless
| > | those confusing and useless separation... to have everything
| > | separated that way makes source files completely unreadable for
| > | one
| > | without the class in their system.
| > | And being capable to "read" the code without loading is a very
| > | important issue.
| > | Also, offer a structure not so alien to newcomers or people just
| > | browsing sources is very important (I do it everytime, with java,
| > | ruby, python, etc., just to see how other did it and see if I can
| > | take ideas).
| > | We don't need another object format, chunk format is completely
| > | capable to provide this.
| > |
| > | So, here my counter-proposal:
| > | (based on "alternate")
| > |
| > | core
| > |    Package.pkg
| > |        Class.st (a FILE)
| > | extension
| > |    Package.pkg
| > |        Object.st (a FILE *without* class definition, just the
| > |        method
| > |        extensions)
| > | tests
| > | doc
| > | platform (not sure about this)
| > | metadata (if needed, better to keep all metadata in one unique
| > | position than distributed on all structure)
| > |
| > | What we gain: clarity, readability and conciseness
| > | What we loose: method grained versioning *in git* (and just in
| > | git,
| > | diff tool can help here while in file, nothing changes when in
| > | image)
| > |
| > | best,
| > | Esteban
| > |
| > | El 27/02/2012, a las 1:39p.m., Otto Behrens escribió:
| > |
| > | > Hi Dale,
| > | >
| > | > It's great that you're asking these questions; I've been
| > | > brewing
| > | > over
| > | > them for a few days now. I'm sure if we put our heads together
| > | > on
| > | > the
| > | > list we'll come up with something great.
| > | >
| > | > The first major question (that Philippe touched on) is if we
| > | > really
| > | > want to keep the compatibility between git and Monticello
| > | > going. I
| > | > think we don't have to worry too much about that, as long as we
| > | > keep:
| > | > 1. categories as the "link": if you load classes from anywhere
| > | > and
| > | > can
| > | > create a (git or MC) package from a category, and
| > | > 2. the *<category> mechanism for extensions
| > | >
| > | > Then, if we load an MC package, be able to manage it in an
| > | > external
| > | > repository or load a git package, publish the code to an MC
| > | > repository. Do we really need a lot of "compatibility" stuff
| > | > such
| > | > as
| > | > the metadata?
| > | >
| > | > I propose for a file based system that we avoid giving
| > | > structure
| > | > like
| > | > "core" or "tests" to it. We've already got the convention of
| > | > naming
| > | > packages X-Core, X-Tests-Core, X-Pharo-Tests-Core and all of
| > | > that.
| > | > Defining too much structure just makes it difficult to extend.
| > | > I
| > | > think
| > | > we should keep less information in the git structure.
| > | >
| > | > That makes the second question for me: how much meta-data to
| > | > keep?
| > | > I
| > | > think the answer is to take all the meta data from the git
| > | > repository
| > | > and not to keep any other meta data. Duplicating meta data just
| > | > makes
| > | > things more complicated and less flexible. If you keep stuff in
| > | > git,
| > | > use git's meta data that's in the git repository. Merging
| > | > version
| > | > files and other meta information is just a pain.
| > | >
| > | > The ideal file structure for me is something that mirrors the
| > | > smalltalk system browser. And I really think we don't need more
| > | > than
| > | > this. For example:
| > | >
| > | > +-Sample-Core\        # always packages at this level - what
| > | > else?
| > | >  +-SampleCore\       # directories at this level are classes -
| > | >  what
| > | >  else?
| > | >  |  +-definition.st
| > | >  |  +-class-side\
| > | >  |    +-initialization
| > | >  |      +-initialize.st
| > | >  |  +-instance-side\
| > | >  |    +-accessing
| > | >  |      +-sample.st
| > | >  |      +-sample:.st
| > | >  +-AnotherSampleClass
| > | >      ....
| > | >
| > | > Extensions simply are methods that don't have a definition in
| > | > this
| > | > package. The definition must then be elsewhere - what else?
| > | > Methods
| > | > should only contain the source (no meta and no chunk format).
| > | >
| > | > There are many file based tools that makes this look almost
| > | > like a
| > | > smalltalk browser! (Even vim).
| > | >
| > | > Then, I would not monkey with the structure. More simplicity
| > | > and
| > | > less
| > | > flexibility (in the sense that you allow any file structure and
| > | > get
| > | > the meta information to be magically compatible with MC).
| > | >
| > | > I'll make some comments on your assumptions...
| > | >
| > | > HTH
| > | > Otto
| > | >
| > | > On Sat, Feb 25, 2012 at 9:51 PM, Dale Henrichs
| > | > <[hidden email]> wrote:
| > | >> I've basically spent a big part of the last week working
| > | >> though
| > | >> alternate directory structure schemes to be used in git for a
| > | >> Smalltalk project ...
| > | >>
| > | >> There are two pieces to the structure. The first part is the
| > | >> structure that we use to represent the Monticello package
| > | >> structure on disk and the second part of the structure is how
| > | >> the
| > | >> packages are organized in the git project.
| > | >>
| > | >> I've prepared a gist[1] that gives you a picture of what I am
| > | >> proposing for the package structure and then shows two
| > | >> different
| > | >> package structures:
| > | >>
| > | >>  - classic Monticello package structure[3]
| > | >>  - alternate package structure[2]
| > | >>
| > | >> So I'd like to have some feedback on the proposed structure.
| > | >> If
| > | >> you haven't already seen it please take a look at the
| > | >> assumptions[4] that I think should be made for this project.
| > | >>
| > | >> I'd appreciate it if you would ask questions or propose
| > | >> alternatives for discussion ... there are a bunch of factors
| > | >> that
| > | >> have gone into putting the structure together, but I think my
| > | >> proposal is a readable structure that can be managed from disk
| > | >> and can be mapped into image-based constructs ....
| > | >>
| > | >> Dale
| > | >>
| > | >> [1] https://gist.github.com/1892114
| > | >> [2] https://github.com/dalehenrich/alternate
| > | >> [3] https://github.com/dalehenrich/sample
| > | >> [4] https://gist.github.com/1893955
| > |
| > |
|

After further review, I admit that the reason redline format looked so clean is that it was missing some necessary information:), so I'll back down on that opinion...

For now we'll stick with chunk and method per file ... I'm sure we'll have the opportunity to revisit the file format discussion in the future:)

Dale
----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 12:13:21 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
|
| On Feb 27, 2012, at 7:35 PM, Frank Shearar wrote:
|
| > Damn it, I didn't know about Resilient Smalltalk.
| >
| > I agree with Esteban: I would gladly lose the niceness of
| > per-method
| > versioning if it meant I could have multiple methods in a file.
| >
| > I've discussed :) gst's syntax with the Coral folks. Mainly, our
| > disagreements regarding syntax boil down to that I _want_ nesting
| > syntax (they will allow nesting classes without any extra work,
| > they're semantically more elegant than "oh you can only nest 1
| > level
| > (method in a class)") and they don't. I think that's a fair
| > summary,
| > Stephane?
|
| Yes but I could live with it as soon as I can save flatten :)
| And I **hate** the red line syntax for method.
|
| > Both gst and Coral (and, it looks, Resilient) offer a clear and
| > simple
| > way to define a class such that method membership is lexically
| > obvious.
|
| Indeed :)
|
| I do not like the |a b d| and class Var in GNU.
| Now we should work on coral but I do not have the cycles.
|  
|
| > Well, gst doesn't quite have the kind of nesting I want to permit,
| > but
| > it is closer. Anyway, mainly I'd say "use gst because they've been
| > using it for a while and it clearly works for them".
| >
| > Nick, maybe quiz UKSTUG tonight? (Seeing as you've just started,
| > most
| > likely, this message will arrive in your inbox too late :/)
| >
| > frank
| >
| > On 27 February 2012 18:14, Nick Ager <[hidden email]> wrote:
| >> While we're on the subject of declarative Smalltalk syntax. I am
| >> aware
| >> of at least four different syntax flavours (not including chunk) :
| >>
| >> GNU &  Étoilé:
| >> http://book.seaside.st/book/getting-started/gst/first-component,
| >> http://etoileos.com/dev/docs/languages/smalltalk/
| >> RedLine:
| >> https://github.com/redline-smalltalk/redline-smalltalk/blob/master/src/test/smalltalk/st/redline/ArrayTest.st
| >> Coral: http://rmod.lille.inria.fr/coral/syntax.html
| >> Resilient Smalltalk:
| >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&type=pdf
| >> (page 5)
| >>
| >> Any more?
| >>
| >> Do the different syntaxes offer benefits over each other, other
| >> than
| >> different syntactic sugar?
| >>
| >> Nick
| >>
| >> On Feb 27, 5:33 pm, Esteban Lorenzano <[hidden email]> wrote:
| >>> Hi Dale,
| >>>
| >>> after seeing your examples, I have to tell something:
| >>>
| >>> what I really, really don't like is the method-centric approach.
| >>>
| >>> I don't understand why classes can't be a file "Class.st", unless
| >>> those confusing and useless separation... to have everything
| >>> separated that way makes source files completely unreadable for
| >>> one without the class in their system.
| >>> And being capable to "read" the code without loading is a very
| >>> important issue.
| >>> Also, offer a structure not so alien to newcomers or people just
| >>> browsing sources is very important (I do it everytime, with
| >>> java, ruby, python, etc., just to see how other did it and see
| >>> if I can take ideas).
| >>> We don't need another object format, chunk format is completely
| >>> capable to provide this.
| >>>
| >>> So, here my counter-proposal:
| >>> (based on "alternate")
| >>>
| >>> core
| >>>         Package.pkg
| >>>                 Class.st (a FILE)
| >>> extension
| >>>         Package.pkg
| >>>                 Object.st (a FILE *without* class definition,
| >>>                 just the method extensions)
| >>> tests
| >>> doc
| >>> platform (not sure about this)
| >>> metadata (if needed, better to keep all metadata in one unique
| >>> position than distributed on all structure)
| >>>
| >>> What we gain: clarity, readability and conciseness
| >>> What we loose: method grained versioning *in git* (and just in
| >>> git, diff tool can help here while in file, nothing changes when
| >>> in image)
| >>>
| >>> best,
| >>> Esteban
| >>>
| >>> El 27/02/2012, a las 1:39p.m., Otto Behrens escribió:
| >>>
| >>>
| >>>
| >>>
| >>>
| >>>
| >>>
| >>>> Hi Dale,
| >>>
| >>>> It's great that you're asking these questions; I've been brewing
| >>>> over
| >>>> them for a few days now. I'm sure if we put our heads together
| >>>> on the
| >>>> list we'll come up with something great.
| >>>
| >>>> The first major question (that Philippe touched on) is if we
| >>>> really
| >>>> want to keep the compatibility between git and Monticello going.
| >>>> I
| >>>> think we don't have to worry too much about that, as long as we
| >>>> keep:
| >>>> 1. categories as the "link": if you load classes from anywhere
| >>>> and can
| >>>> create a (git or MC) package from a category, and
| >>>> 2. the *<category> mechanism for extensions
| >>>
| >>>> Then, if we load an MC package, be able to manage it in an
| >>>> external
| >>>> repository or load a git package, publish the code to an MC
| >>>> repository. Do we really need a lot of "compatibility" stuff
| >>>> such as
| >>>> the metadata?
| >>>
| >>>> I propose for a file based system that we avoid giving structure
| >>>> like
| >>>> "core" or "tests" to it. We've already got the convention of
| >>>> naming
| >>>> packages X-Core, X-Tests-Core, X-Pharo-Tests-Core and all of
| >>>> that.
| >>>> Defining too much structure just makes it difficult to extend. I
| >>>> think
| >>>> we should keep less information in the git structure.
| >>>
| >>>> That makes the second question for me: how much meta-data to
| >>>> keep? I
| >>>> think the answer is to take all the meta data from the git
| >>>> repository
| >>>> and not to keep any other meta data. Duplicating meta data just
| >>>> makes
| >>>> things more complicated and less flexible. If you keep stuff in
| >>>> git,
| >>>> use git's meta data that's in the git repository. Merging
| >>>> version
| >>>> files and other meta information is just a pain.
| >>>
| >>>> The ideal file structure for me is something that mirrors the
| >>>> smalltalk system browser. And I really think we don't need more
| >>>> than
| >>>> this. For example:
| >>>
| >>>> +-Sample-Core\        # always packages at this level - what
| >>>> else?
| >>>>  +-SampleCore\       # directories at this level are classes -
| >>>>  what else?
| >>>>  |  +-definition.st
| >>>>  |  +-class-side\
| >>>>  |    +-initialization
| >>>>  |      +-initialize.st
| >>>>  |  +-instance-side\
| >>>>  |    +-accessing
| >>>>  |      +-sample.st
| >>>>  |      +-sample:.st
| >>>>  +-AnotherSampleClass
| >>>>      ....
| >>>
| >>>> Extensions simply are methods that don't have a definition in
| >>>> this
| >>>> package. The definition must then be elsewhere - what else?
| >>>> Methods
| >>>> should only contain the source (no meta and no chunk format).
| >>>
| >>>> There are many file based tools that makes this look almost like
| >>>> a
| >>>> smalltalk browser! (Even vim).
| >>>
| >>>> Then, I would not monkey with the structure. More simplicity and
| >>>> less
| >>>> flexibility (in the sense that you allow any file structure and
| >>>> get
| >>>> the meta information to be magically compatible with MC).
| >>>
| >>>> I'll make some comments on your assumptions...
| >>>
| >>>> HTH
| >>>> Otto
| >>>
| >>>> On Sat, Feb 25, 2012 at 9:51 PM, Dale Henrichs
| >>>> <[hidden email]> wrote:
| >>>>> I've basically spent a big part of the last week working though
| >>>>> alternate directory structure schemes to be used in git for a
| >>>>> Smalltalk project ...
| >>>
| >>>>> There are two pieces to the structure. The first part is the
| >>>>> structure that we use to represent the Monticello package
| >>>>> structure on disk and the second part of the structure is how
| >>>>> the packages are organized in the git project.
| >>>
| >>>>> I've prepared a gist[1] that gives you a picture of what I am
| >>>>> proposing for the package structure and then shows two
| >>>>> different package structures:
| >>>
| >>>>>  - classic Monticello package structure[3]
| >>>>>  - alternate package structure[2]
| >>>
| >>>>> So I'd like to have some feedback on the proposed structure. If
| >>>>> you haven't already seen it please take a look at the
| >>>>> assumptions[4] that I think should be made for this project.
| >>>
| >>>>> I'd appreciate it if you would ask questions or propose
| >>>>> alternatives for discussion ... there are a bunch of factors
| >>>>> that have gone into putting the structure together, but I
| >>>>> think my proposal is a readable structure that can be managed
| >>>>> from disk and can be mapped into image-based constructs ....
| >>>
| >>>>> Dale
| >>>
| >>>>> [1]https://gist.github.com/1892114
| >>>>> [2]https://github.com/dalehenrich/alternate
| >>>>> [3]https://github.com/dalehenrich/sample
| >>>>> [4]https://gist.github.com/1893955
|
|

On Feb 27, 2012, at 9:40 PM, Dale Henrichs wrote:

> Stef,
>
> Good point, I was thinking the same thing:) We won't be changing everything at the same time, but I do think that we need to understand the scope of what we're doing so we can plan on staging features in (if indeed staging is needed) ...
>
> For example, if we go with one method for file ... chunk format is okay since you are only looking at one chunk at a time ... chunk format becomes noisy when looking at an entire file of chunks (in my opinion). If you are going with a file per class, then the format becomes much more important, if nothing else because it becomes necessary to arrange to parse the format so that the class file can be converted to definitions (chunk format is pretty easy to parse, but bad for reading).

Yes but for now let us focus on the back-end and how to help people manage their project

> We aren't going to git to ALLOW developers to write Smalltalk with emacs. We're going to git to leverage the capabilities of git, to give us some things that we don't have right now... However, when we go to git, developers WILL write Smalltalk with emacs[1], so we need to be prepared.

Then they should switch to python or ruby.
At least I would do that (no joke).

> The fact is that for now, the primary use-case for git-based repositories will be from within a Smalltalk image, so losing "method grained versioning *in git*" is currently a greater price than gaining "clarity, readability and conciseness" on disk...
>
> Dale