project directory structure (git for smalltalk)

Agreed that battle-tested says a lot ...

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 12:25:18 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| On 27 February 2012 20:13, stephane ducasse
| <[hidden email]> wrote:
| >
| > 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.
|
| 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
|
| >> 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
| >
|

> 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:)

oh yes!
I hate it too :)

Stef

On 27 February 2012 20:40, Dale Henrichs <[hidden email]> 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).
>
> 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.

Well, I would be one of those people, and do indeed (as per Stephane's
comment) use ruby from emacs. And, in particular, one of my long term
plans is to support shelling into running Smalltalk images just as one
would with SLIME in Common Lisp or Clojure (or Javascript, nowadays).
Coral may scratch my itch; I'm not sure yet.

Using method-per-file might make mapping easier, but it makes reading
the files (much) worse. Which would you prefer, looking at github?
Scroll up and down to see the other methods in the class, or multiple
clicks, backbuttons and scrolls every time you want to see another
method? The same applies for anything that uses files: you replicate
the Browser's biggest disadvantage, namely, seeing exactly one method
at a time.

At any rate, I say all this knowing full well that I'm not
contributing running code!

frank

Stef,

If you've noticed, I've been shipping out a bunch of urls that point into my github repositories...With github, I can create links to any file in my repository and for me this is a level of detail that we do not currently have in the Smalltalk community.

With method-level file granularity, I can point to a single method in my project with a single url[1]. I think that this is incredibly powerful for working with folks in a distributed environment ...

I think that project structure and file formats are important because not only do they impact how one writes code, but they impact how one communicates to other developers and how one navigates the project on github or disk.

So this isn't just about writing code with emacs, but about how we're going to view our projects in settings beyond the image ...

I encourage all of you to follow the links to some examples[1][2][3] and to explore a little bit.

start by following [1]:

  - click on the History button ... this is per method commit history for life of method
  - click on the Blame button ... this is line by line analysis of the method
  - click on the edit button ... fork and make the edit in your copy of the project ...
  - look at the breadcrumbs for the file
   
    If you ask me the breadcrumb for that method isn't very informative (it's in an older version
    of the project structure)...the proposed project structure is much more informative[2], which
    it makes it easier to navigate to this spot (to me this is much the same information I would
    like to see in the code browser).

    Try to get the same level of detail from blame view for gst-smalltalks github repository,
    where methods are kept in monolithic class.st files[3]...

So I think that the discussion about format is important and not about "using Ruby or Python, if you don't like it", but about maximizing our gain when we do go to git/github.

Dale

[1] https://github.com/dalehenrich/filetree/blob/fc4b0b2b388d6960644bdbd10d0808ab498878af/MonticelloFileTree-Core.tree/MCFileTreeReader/addClassAndMethodDefinitionsFromDirectoryEntries:.st
[2] https://github.com/dalehenrich/sample/blob/master/core/Sample-Core.pkg/definitions/classes/SampleCore.class/instance-side/authorName.st
[3] https://github.com/bonzini/smalltalk/blame/bf263f3eb272c24f7c28f65ba9a0e63c2241f146/kernel/SysExcept.st
----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 12:46:00 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
|
| 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
|

why do you tell me that?
I know it and this is why I said to esteban that method granularity is better.

On Feb 27, 2012, at 10:15 PM, Dale Henrichs wrote:

Frank,

You are absolutely right that there is a tension between the "method vs class" view.

The fact that all of the file-based languages put a bunch of methods in a single file, says volumes about the proper way to go - if one were to do file-based development.

Image-based development drives us toward a method per file and that's why I lean in that direction today and frankly it's why we've ended up inventing our own systems for versioning code and projects.

I can already see that in the future the right answer is to support both formats ... if one wants to do primarily file-based development using emacs and the shell, then one will want methods clumped together in files ... if one is primarily image-based development then the disk format is less important and as I've pointed out in my email about github has advantages for image-based developers... Neither approach is better than the other ... the information content is identical. Only the organization of the information is different.

The image-based Smalltalks need to maintain the package snapshots and the code can handle any format we throw at it (given enough resources) so I imagine that in the future the project maintainers will choose a set of formats that support their style of development...I am already supporting 3 different repository formats at the moment as I've changed the format several times in the last month and need to be able to survive across the format change boundaries, a couple of more formats won't break the bank:)

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 1:13:37 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| On 27 February 2012 20:40, Dale Henrichs <[hidden email]> 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).
| >
| > 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.
|
| Well, I would be one of those people, and do indeed (as per
| Stephane's
| comment) use ruby from emacs. And, in particular, one of my long term
| plans is to support shelling into running Smalltalk images just as
| one
| would with SLIME in Common Lisp or Clojure (or Javascript, nowadays).
| Coral may scratch my itch; I'm not sure yet.
|
| Using method-per-file might make mapping easier, but it makes reading
| the files (much) worse. Which would you prefer, looking at github?
| Scroll up and down to see the other methods in the class, or multiple
| clicks, backbuttons and scrolls every time you want to see another
| method? The same applies for anything that uses files: you replicate
| the Browser's biggest disadvantage, namely, seeing exactly one method
| at a time.
|
| At any rate, I say all this knowing full well that I'm not
| contributing running code!
|
| frank
|
| > 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
| > | > |
| > | > |
| > |
| > |
|

The message started out as a reaction to your "let them eat ruby, if they want class per file" and evolved into a more general post, but I neglected to remove the "Stef," bit at the front... sorry ... I did see that you are in favor of the method per file approach.

 
----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 1:24:51 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| why do you tell me that?
| I know it and this is why I said to esteban that method granularity
| is better.
|
| On Feb 27, 2012, at 10:15 PM, Dale Henrichs wrote:
|
| > Stef,
| >
| > If you've noticed, I've been shipping out a bunch of urls that
| > point into my github repositories...With github, I can create
| > links to any file in my repository and for me this is a level of
| > detail that we do not currently have in the Smalltalk community.
| >
| > With method-level file granularity, I can point to a single method
| > in my project with a single url[1]. I think that this is
| > incredibly powerful for working with folks in a distributed
| > environment ...
| >
| > I think that project structure and file formats are important
| > because not only do they impact how one writes code, but they
| > impact how one communicates to other developers and how one
| > navigates the project on github or disk.
| >
| > So this isn't just about writing code with emacs, but about how
| > we're going to view our projects in settings beyond the image ...
| >
| > I encourage all of you to follow the links to some
| > examples[1][2][3] and to explore a little bit.
| >
| > start by following [1]:
| >
| >  - click on the History button ... this is per method commit
| >  history for life of method
| >  - click on the Blame button ... this is line by line analysis of
| >  the method
| >  - click on the edit button ... fork and make the edit in your copy
| >  of the project ...
| >  - look at the breadcrumbs for the file
| >
| >    If you ask me the breadcrumb for that method isn't very
| >    informative (it's in an older version
| >    of the project structure)...the proposed project structure is
| >    much more informative[2], which
| >    it makes it easier to navigate to this spot (to me this is much
| >    the same information I would
| >    like to see in the code browser).
| >
| >    Try to get the same level of detail from blame view for
| >    gst-smalltalks github repository,
| >    where methods are kept in monolithic class.st files[3]...
| >
| > So I think that the discussion about format is important and not
| > about "using Ruby or Python, if you don't like it", but about
| > maximizing our gain when we do go to git/github.
| >
| > Dale
| >
| > [1]
| > https://github.com/dalehenrich/filetree/blob/fc4b0b2b388d6960644bdbd10d0808ab498878af/MonticelloFileTree-Core.tree/MCFileTreeReader/addClassAndMethodDefinitionsFromDirectoryEntries:.st
| > [2]
| > https://github.com/dalehenrich/sample/blob/master/core/Sample-Core.pkg/definitions/classes/SampleCore.class/instance-side/authorName.st
| > [3]
| > https://github.com/bonzini/smalltalk/blame/bf263f3eb272c24f7c28f65ba9a0e63c2241f146/kernel/SysExcept.st
| > ----- Original Message -----
| > | From: "stephane ducasse" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Monday, February 27, 2012 12:46:00 PM
| > | Subject: Re: [Metacello] project directory structure (git for
| > | smalltalk)
| > |
| > |
| > | 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
| > |
|
|

no problem
I'm pragmatic.
I do not like git but I'm ready to learn and use it if I see a real benefit (and I see one).
I just want tools to manage our system.
I will push our team to band its head on the coral syntax.

Stef

+1.

And +1 to the argument of Otto of having the history for each method.

Cheers,
Doru


On 27 Feb 2012, at 21:10, stephane ducasse wrote:

--
www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."

Oh, well... I still disagree (and not because I want to use emacs to program, which I will not do, of course :) I still think that class granularity increases system readability... and that is better in the long way.

but well... there is so much people arguing against my point of view that I'm willing to give it a try with method granularity, just to probe myself that I'm wrong :)

best,
Esteban

El 27/02/2012, a las 7:25p.m., Tudor Girba escribió:

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 8:39:52 AM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| 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?

The compatibility stuff is only needed if we want to maintain compatibility with mcz repositories. I think we covered the issues here[1].

If we STORE NO ANCESTOR METADATA on disk, then a user MUST remember to ADOPT the correct mcz ancestor if they try to store the Monticello package in an mcz repository. If they don't remember then the package is broken and noone will be able to do a Monticello three way merge.

If we STORE ANCESTRY by default, then the naive user will be allowed to be naive. The knowledgable user should be able to disable the storage of ancestry data and will be expected to remember to use ADOPT to repair the ancestry in the cases when it is needed.

I tend to fall on the side of making the naive user successful when there is a choice. I prefer to tell the knowledgable user how to override the default, then explain to the naive user how to do the "right thing."

[1] https://github.com/dalehenrich/filetree/issues/2
|
| 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.

The reason that I am even suggesting the "extra structure" like "core" and "tests" is that I am anticipating that projects with large numbers of packages (imagine a proejct with 100 packages) will need to introduce the extra structure just to organize the packages ...

I am not suggesting that developers must use structure, but I do think that we need to have an answer for developers who want to introduce structure.

I am including top-level directories like "doc" to remind folks that there will be other file-based artifacts stored in these projects ... css files, static html pages, c libraries, c code, moakefiles ... the possiblities are quite endless...

There aren't many projects of substance on github that don't partition their projects into multiple directores and I think it is prudent to anticipate that eventuality.

I will agree that we don't have to allow structure tomorrow, but I want to have an answer for how we will accomodate additional structure before going too far ...

I don't think you can promise me that we will never need "additional structure" and I would rather write the code that handles that stuff up front than wait until it becomes a requirement ...
 
|
| 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.

I've covered duplication of meta data,etc. in my response to Philippe ... short answer ... the only additional meta data we "need" is package ancestry ... and I will tell you that adding back ancestry is a pain too.

|
| 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).

Otto. If the machine is parsing the directory structure then this additional structure isn't necessary. However, if a person is going to look at the structure, then this kind of information is needed ...

You are telling me that when a developer is sitting in a directory called 'accessing' the only way to tell whether this is an extension method or an included method is to `cd ../../` and look for a file called 'definition.st'?

I am suggesting that using a class/extensions directory structure means that I can do a `pwd` or look at the breadcrumbs in the web browser on github and know whether I am looking at an extension method or not ...

You claim that you want to do all of your work with in-image tools....why do you care what the disk package structure looks like?

I claim that the disk structure is for those developers who will be looking at the directory structure on disk or on github...

There are additional problems with mimicking browser structure on disk ... to preserve the category/package convention we will have to name directories on disk "*sample-package" or allow for spaces in the directory names "initialize release" these types of names get to be a real pain in the ass to navigate from the shell ... Let's not do something like this on pupose ... It's bad enough that the Mac OSX file system makes it a pain to have two methods that differ only in case ... not common, but when it happens git things you've deleted one of the files ... not pretty ...

If we mimick the browser category structure, we lose all (obvious) package structure from the directory structure and the developer has to work hard to figure out the package structure ...

I claim that package structure is more important than category structure for the "package structure on disk" ... Look at the fact that pharo is introducing package-based browser ... package structure is important to developers in-image as well...

If you care to spend some time navigating around in a structure that is similar to what you are proposing, I invite you to checkout f878660db9195055fa81e93458289ba868e01aac from the sample project[2].

Here's the url to a method in the sample project that proves my point that you can't tell by looking at the url whether the method is an extension method or not:

    https://github.com/dalehenrich/sample/blob/f878660db9195055fa81e93458289ba868e01aac/Sample.source/Core.pkg/Core.tree/SampleCore/authorName.st

I spent time in the last week navigating around this and a variety of different directory structures and tagged 5 different branches if you'd like to look at them[3].

My current proposal seems to be the simplest structure that clearly conveys the package structure...which I think is the most important. If a developer is going to manipulate the directory structure using vi and the shell, then they had better be very aware of the package structure that they are creating otherwise they will end up with "corrupt" package structure... I have been building all of these examples by hand, so I can vouch for this from experience...

[2] https://github.com/dalehenrich/sample
[3] https://github.com/dalehenrich/sample/tags

|
| 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
|

Esteban,

It is obvious to me that no one will be entirely happy with whatever structure is chosen:(

Ideally we'd not have any requirements at all on directory structure, but if we are to support image-based development then we must define Monticello package structure on disk ...

If you look at the structure that I've proposed, the files map 1 to 1 with Monticello definitions and the subdirectories provide context to a human looking at file paths or github urls ... thats it ...

If someone has a proposal with the same characteristics then I'm all ears.

Other structure proposals obscure the package structure, yet the package structure is the most important information to get right ...

In the long run, I can very easily imagine that individual projects wil have completely different directory structures (as is the current case with the file-based languages), but coming out of the gate we're going to have to pick one so that we can get on with actually using git/github from Smalltalk....

Dale
 
----- Original Message -----
| From: "Esteban Lorenzano" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 4:03:29 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| Oh, well... I still disagree (and not because I want to use emacs to
| program, which I will not do, of course :) I still think that class
| granularity increases system readability... and that is better in
| the long way.
|
| but well... there is so much people arguing against my point of view
| that I'm willing to give it a try with method granularity, just to
| probe myself that I'm wrong :)
|
| best,
| Esteban
|
| El 27/02/2012, a las 7:25p.m., Tudor Girba escribió:
|
| > +1.
| >
| > And +1 to the argument of Otto of having the history for each
| > method.
| >
| > Cheers,
| > Doru
| >
| >
| > On 27 Feb 2012, at 21:10, stephane ducasse wrote:
| >
| >> 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
| >>> |
| >>> |
| >>
| >
| > --
| > www.tudorgirba.com
| >
| > "The coherence of a trip is given by the clearness of the goal."
| >
| >
| >
| >
|
|

> | The first major question (that Philippe touched on) is if we really
> | want to keep the compatibility between git and Monticello going. I

> If we STORE NO ANCESTOR METADATA on disk, then a user MUST remember to ADOPT the correct mcz ancestor if they try to store the Monticello package in an mcz repository. If they don't remember then the package is broken and noone will be able to do a Monticello three way merge.
>
> If we STORE ANCESTRY by default, then the naive user will be allowed to be naive. The knowledgable user should be able to disable the storage of ancestry data and will be expected to remember to use ADOPT to repair the ancestry in the cases when it is needed.

Ok, you're assuming that we need to keep compatibility then. I was
thinking that this could be in the way. Do we really want to work in
MC, then a bit on the file system with git, and then a bit in MC
again?

> The reason that I am even suggesting the "extra structure" like "core" and "tests" is that I am anticipating that projects with large numbers of packages (imagine a proejct with 100 packages) will need to introduce the extra structure just to organize the packages ...

The extra structure that you propose could be handled by creating
projects with project dependencies, can it not?

> I am not suggesting that developers must use structure, but I do think that we need to have an answer for developers who want to introduce structure.

Are you suggesting that one can introduce the structure you want and
it will still work?

> I am including top-level directories like "doc" to remind folks that there will be other file-based artifacts stored in these projects ... css files, static html pages, c libraries, c code, moakefiles ... the possiblities are quite endless...
>
> There aren't many projects of substance on github that don't partition their projects into multiple directores and I think it is prudent to anticipate that eventuality.

We must be missing each other. I have a number of different files in
my git repo, some smalltalk, others not. I organise my git project in
any way I like. I can have multiple subdirectories containing
Smalltalk packages. I can have 1. If the 1 directory becomes big, I
can split it according to my domain (eg. Accounting, Banking or
whatever).

> You are telling me that when a developer is sitting in a directory called 'accessing' the only way to tell whether this is an extension method or an included method is to `cd ../../` and look for a file called 'definition.st'?

You would not have "accessing" if it is an extension - so you can know?

> You claim that you want to do all of your work with in-image tools....why do you care what the disk package structure looks like?

So that I can easily find the file corresponding to the method I have
in the image, for one reason. I do not claim to do all work in the
image; most of it though. And I care about the structure, just because
I care :-)

> I claim that the disk structure is for those developers who will be looking at the directory structure on disk or on github...

I'm not contradicting that, just trying to enhance.

> There are additional problems with mimicking browser structure on disk ... to preserve the category/package convention we will have to name directories on disk "*sample-package" or allow for spaces in the directory names "initialize release" these types of names get to be a real pain in the ass to navigate from the shell ... Let's not do something like this on pupose ... It's bad enough that the Mac OSX file system makes it a pain to have two methods that differ only in case ... not common, but when it happens git things you've deleted one of the files ... not pretty ...

I understand that this is an issue. So how do we handle methods like *
then? *.st? I think the file system must be able to handle it. I
cannot work on my mac at the moment because my partition is non case
sensitive. I have to get a case sensitive partition to work with my
repo at all.

> If we mimick the browser category structure, we lose all (obvious) package structure from the directory structure and the developer has to work hard to figure out the package structure ...

> I claim that package structure is more important than category structure for the "package structure on disk" ... Look at the fact that pharo is introducing package-based browser ... package structure is important to developers in-image as well...

I was thinking of the category and package structure as the same
thing. I don't put code in the same package under different
categories.

> If you care to spend some time navigating around in a structure that is similar to what you are proposing, I invite you to checkout f878660db9195055fa81e93458289ba868e01aac from the sample project[2].

I had a look at the sample project and alternative. I might just be
missing the point. So, I don't really have a preference.

> Using method-per-file might make mapping easier, but it makes reading
> the files (much) worse. Which would you prefer, looking at github?
> Scroll up and down to see the other methods in the class, or multiple
> clicks, backbuttons and scrolls every time you want to see another
> method? The same applies for anything that uses files: you replicate
> the Browser's biggest disadvantage, namely, seeing exactly one method
> at a time.

Why do you like the file per class based approach? If you work in such
a file, do you not find yourself scrolling a lot?

When I'm in the browser, I miss textual search, comparing methods and
driving from the keyboard. When I'm in a file with a load of methods,
I miss the ability to ask for senders, or follow senders one after the
other. I also miss automatic formatting, method categorising, running
tests, refactoring and other things.

For me, having the ability to select multiple methods in a browser to
compare the code between them would fill a large gap. Then, to be able
to do contextual text searches from the keyboard would be cool. I
probably have to learn more keyboard short-cuts in the image, but how
do I navigate using the keyboard?

Otto

On Feb 27, 5:10 am, Dale Henrichs <[hidden email]> wrote:
Nope, I'm sold on this.

> -----------------
>   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.

I'm not sold on this one. Since you have a file for each method you
know when you have the remove the method, when git removes the file.

Cheers
Philippe

Philippe,

How does the image "know that git removed the file"...are you suggesting that we bypass disk-based structures altogether and tightly couple the image to the git database for each project?

One of the assumptions that I've made[1] is that:

  the basic structures and tools will be agnostic as to the
  underlying version control system that is used, whether
  it be svn, git, mercurial or something else.

I make this assumption for the simple reason that I think it is a mistake to tie ourselves to yet another proprietary SCM ... by going with a purely disk-based package snapshot structure we don't dictate which SCM one must use to share code....

With that said, the disk-based package snapshot format doesn't prevent one from creating a system that is tightly coupled to git ...

Dale

[1] https://gist.github.com/1893955
----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Metacello" <[hidden email]>
| Sent: Tuesday, February 28, 2012 12:02:55 AM
| Subject: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
| On Feb 27, 5:10 am, Dale Henrichs <[hidden email]> wrote:
| > 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?
|
| Nope, I'm sold on this.
|
| > -----------------
| >   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.
|
| I'm not sold on this one. Since you have a file for each method you
| know when you have the remove the method, when git removes the file.
|
| Cheers
| Philippe
|

Otto,

I've embedded comments below...

I appreciate your feedback ... as I've said before I wish that we could all get into room with a giant white board and talk this stuff out face to face ... it's very difficult to come to a consensus via email when the differences are subtle ....

I hope that I'm not discouraging feedback ... that is not my intent ... I AM listening and I AM adjusting my proposals based on the feedback so I consider it very valuable ...

Dale

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 27, 2012 10:25:02 PM
| Subject: Re: [Metacello] project directory structure (git for smalltalk)
|
| > | The first major question (that Philippe touched on) is if we
| > | really
| > | want to keep the compatibility between git and Monticello going.
| > | I
|
| > If we STORE NO ANCESTOR METADATA on disk, then a user MUST remember
| > to ADOPT the correct mcz ancestor if they try to store the
| > Monticello package in an mcz repository. If they don't remember
| > then the package is broken and noone will be able to do a
| > Monticello three way merge.
| >
| > If we STORE ANCESTRY by default, then the naive user will be
| > allowed to be naive. The knowledgable user should be able to
| > disable the storage of ancestry data and will be expected to
| > remember to use ADOPT to repair the ancestry in the cases when it
| > is needed.
|
| Ok, you're assuming that we need to keep compatibility then. I was
| thinking that this could be in the way. Do we really want to work in
| MC, then a bit on the file system with git, and then a bit in MC
| again?

Want is not the question. Today I am doing development in git and exporting my work to mcz files. Tomorrow I will be doing development in git and exporting my work to mcz files ... Eventually, I will be doing all of my work in git and there will be no need for mcz files anymore ...

You have been using filetree for a while now and yet you still find it necessary to export mcz files for others to use[1].

Until we reach the point where mcz files are no longer needed, I think that we will need to consider compatibility. In the early stages of the transition, I think that the default should be to preserve mcz ancestry and in the later stages of the transition I think that the default should be to not preserve mcz ancestry ... Throughout the process, I think that a particular set of developers on a project should be free to choose...

[1] https://github.com/finworks/smallsource

|
| > The reason that I am even suggesting the "extra structure" like
| > "core" and "tests" is that I am anticipating that projects with
| > large numbers of packages (imagine a project with 100 packages)
| > will need to introduce the extra structure just to organize the
| > packages ...
|
| The extra structure that you propose could be handled by creating
| projects with project dependencies, can it not?

That's exactly the function of each of those directories ... they are each a separate filetree repository, tied together by metacello dependencies [2]. The difference is that they are not in separate git repositories ... In other words I think that one can have multiple filetree repositories in a single git repository.

For large projects with lots of packages and the desire to separate those packages into separate repositories, I assume that they will still be using a single git repository to manage those repositories so that they can all be managed together in the same version ...

The operative word is choice. I don't think that there should be a restriction of only one filetree repository per git repository .... once should be able to manage multiple filetree repositories in one git project.

The sticky wicket is that these three repositories are not independent ... they are versioned together and checked out together so they are not exactly like the standard external project and metacello must be able to manage packages in separate repositories that are versioned together ...

I've solved the problem (I believe) so I don't think it should be an issue ... if you want to keep your packages in the top-level of the git repository you can do so ... if you want to put your packages in a subdirectory you can do so ... if you want to put your packages in multiple subdirectories you can do so ...

[2] https://github.com/dalehenrich/alternate/blob/master/tests/README.md 
|
| > I am not suggesting that developers must use structure, but I do
| > think that we need to have an answer for developers who want to
| > introduce structure.
|
| Are you suggesting that one can introduce the structure you want and
| it will still work?

There is package structure and there is project structure. A filetree repository is a directory with .pkg subdirectories. and the .pkg directories have a fixed structure....

At the project structure level we are talking about allowing multiple filetree repositories in a single git repository along with all of the other non-source code files...  the project structure has an implication for the metacello specifications as discussed in the previous section...
 
|
| > I am including top-level directories like "doc" to remind folks
| > that there will be other file-based artifacts stored in these
| > projects ... css files, static html pages, c libraries, c code,
| > moakefiles ... the possiblities are quite endless...
| >
| > There aren't many projects of substance on github that don't
| > partition their projects into multiple directores and I think it
| > is prudent to anticipate that eventuality.
|
| We must be missing each other. I have a number of different files in
| my git repo, some smalltalk, others not. I organise my git project in
| any way I like. I can have multiple subdirectories containing
| Smalltalk packages. I can have 1. If the 1 directory becomes big, I
| can split it according to my domain (eg. Accounting, Banking or
| whatever).

Okay we agree that in a real project there will be complex structure at the project level with multiple filetree repositories ... That's the only point I'm trying to make with my alternate project[3].

You questioned why I had the packages separated into 'core', 'platform', and 'tests', which are simply examples of breaking a single repository up into multiple repositories. Now you tell me that you have mutliple package repositories in your git repository ....

I think we must be on the exactly the same page...

As I have said before the question is "how does one specify the metacello dependencies for packages that are in different repositories that are checked out together in the same version?"

I have a proposed solution in the alternate project[4][5][6] and I'm am interested in entertaining discussion on the proposed metacello specifications ...

[3] https://github.com/dalehenrich/alternate
[4] https://github.com/dalehenrich/alternate/blob/master/core/README.md
[5] https://github.com/dalehenrich/alternate/blob/master/platform/README.md
[6] https://github.com/dalehenrich/alternate/tree/master/tests
|
| > You are telling me that when a developer is sitting in a directory
| > called 'accessing' the only way to tell whether this is an
| > extension method or an included method is to `cd ../../` and look
| > for a file called 'definition.st'?
|
| You would not have "accessing" if it is an extension - so you can
| know?

In regards to fine-tuning the details of the package structure ... it is obvious that we have as many differing opinions as there are developers and none of the proposals for package structure are wrong or right .... they each have their advantages and disadvantages .... As far as I can tell none of the structures is obviously better, so we can probably get away with randomly choosing a structure and we won't be obviously wrong ...

I'm going to let the structure simmer a little bit ... we have consensus on big chunks and we are down to relatively minor details ... I think ...
 
|
| > You claim that you want to do all of your work with in-image
| > tools....why do you care what the disk package structure looks
| > like?
|
| So that I can easily find the file corresponding to the method I have
| in the image, for one reason. I do not claim to do all work in the
| image; most of it though. And I care about the structure, just
| because
| I care :-)
|
| > I claim that the disk structure is for those developers who will be
| > looking at the directory structure on disk or on github...
|
| I'm not contradicting that, just trying to enhance.
|
| > There are additional problems with mimicking browser structure on
| > disk ... to preserve the category/package convention we will have
| > to name directories on disk "*sample-package" or allow for spaces
| > in the directory names "initialize release" these types of names
| > get to be a real pain in the ass to navigate from the shell ...
| > Let's not do something like this on pupose ... It's bad enough
| > that the Mac OSX file system makes it a pain to have two methods
| > that differ only in case ... not common, but when it happens git
| > things you've deleted one of the files ... not pretty ...
|
| I understand that this is an issue. So how do we handle methods like
| *
| then? *.st? I think the file system must be able to handle it. I
| cannot work on my mac at the moment because my partition is non case
| sensitive. I have to get a case sensitive partition to work with my
| repo at all.
|
| > If we mimick the browser category structure, we lose all (obvious)
| > package structure from the directory structure and the developer
| > has to work hard to figure out the package structure ...
|
| > I claim that package structure is more important than category
| > structure for the "package structure on disk" ... Look at the fact
| > that pharo is introducing package-based browser ... package
| > structure is important to developers in-image as well...
|
| I was thinking of the category and package structure as the same
| thing. I don't put code in the same package under different
| categories.
|
| > If you care to spend some time navigating around in a structure
| > that is similar to what you are proposing, I invite you to
| > checkout f878660db9195055fa81e93458289ba868e01aac from the sample
| > project[2].
|
| I had a look at the sample project and alternative. I might just be
| missing the point. So, I don't really have a preference.
|

On Feb 28, 1:06 pm, Dale Henrichs <[hidden email]> wrote:
> Philippe,
>
> How does the image "know that git removed the file"...are you suggesting that we bypass disk-based structures altogether and tightly couple the image to the git database for each project?

Sort of. You know (or should) which revision you have in the image and
which you're going to load from disk. git knows which files were
changed, deleted, added since then so you can find out which classes/
methods you need to delete/add/load.

The "only" git specific part is figuring out the revisions and what
changed. It would be a "simple matter of coding" to support other
SCMs.

Cheers
Philippe

Philippe,

I don't deny that one could take this approach ... with enough coding a lot of things can be done ...

The path I am taking is one in which git does not have to be installed to download and load code ...

I think it is important that a developer be able to use git for development, publish on github and make your project available to the broad community, without requiring that everyone install git first ...

When we turn this puppy on, I don't think that every developer will be flocking to git/github to do development. git by itself takes some getting used to ... it is worth learning, but there is a barrier there that may put off a bunch of people ... another group of people will think that their current mcz-based development is working just fine and won't want to bother with git ...

So we won't have the kind of developer saturation that makes it worth requiring an install of git and pharo before you can do anything ...

My intent is to make it possible for those who want to use git to be able to use git and make it possible for them to publish code that others can use without a) requiring the developers to maintain a parallel mcz repository or b) requiring consumers of the code to install git ...

Oh and I'd like to have this system available in less than a month from now ...

Dale

----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Metacello" <[hidden email]>
| Sent: Tuesday, February 28, 2012 9:33:05 AM
| Subject: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
| On Feb 28, 1:06 pm, Dale Henrichs <[hidden email]> wrote:
| > Philippe,
| >
| > How does the image "know that git removed the file"...are you
| > suggesting that we bypass disk-based structures altogether and
| > tightly couple the image to the git database for each project?
|
| Sort of. You know (or should) which revision you have in the image
| and
| which you're going to load from disk. git knows which files were
| changed, deleted, added since then so you can find out which classes/
| methods you need to delete/add/load.
|
| The "only" git specific part is figuring out the revisions and what
| changed. It would be a "simple matter of coding" to support other
| SCMs.
|
| Cheers
| Philippe
|

On Feb 28, 10:06 pm, Dale Henrichs <[hidden email]> wrote:
Fair enough

Cheers
Philippe