FileTree and Cypress status

Over the weekend I finished up on work moving FileTree[1] to use the new Cypress package structure[2].

I've updated the FileTree installation instructions[3] including some notes on contributing to the project. If you are using an earlier version of FileTree, you'll want to upgrade to this by basically installing the new version on top of the old.

There are a handful of changes between the old and new package formats that are worth mentioning:

  - more compact directory structure (fewer intermediate directories)
  - .package extension instead of .pkg for the package directory
  - 4 dialect-specific branches[8]:

    master
    pharo1.3
    squeak4.3
    gemstone2.4

  - class creation attributes in a properties.json file[4]
  - method protocol name "embedded" in method source[5]
  - UTF8 support
  - class comment extracted into a README.md file[6], so that
    markdown syntax can be used for more meaningful and visible
    class comments using UTF8

The upshot is that we've got a common package structure for VW[7], GemStone, Pharo and Squeak, with VAST coming soon.

Dale

[1] https://github.com/dalehenrich/filetree
[2] https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
[3] https://github.com/dalehenrich/filetree/blob/master/README.md
[4] https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/properties.json
[5] https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/instance/customProjectAttributes.st
[6] https://github.com/CampSmalltalk/Cypress-Mocks/blob/master/gemstone/packages/Cypress-Mocks.package/CypressMockBasic.class/README.md
[7] https://github.com/CampSmalltalk/STIG
[8] https://github.com/dalehenrich/filetree/network

Hi dale

{
        "category" : "ConfigurationOfFileTree",
        "classinstvars" : [
                 ],
        "classvars" : [
                "LastVersionLoad" ],
        "commentStamp" : "",
        "instvars" : [
                "project" ],
        "name" : "ConfigurationOfFileTree",
        "pools" : [
                 ],
        "super" : "Object",
        "type" : "normal" }

I found that really strange that we use yet another syntax for encoding information. I still do not get (but I'm probably too stupid to understand)
why

#(
        #(category ConfigurationOfFileTree)
        #(classinstvars ….
        )

does not make it?

Probably the sirens of the hype.


Stef

On Apr 9, 2012, at 10:40 PM, Dale Henrichs wrote:

May be I can write a Smalltalk literal parser in less methods than the json one and in one class since it looks like this is the killer argument for this crappy syntax usage.
If this is what should be done to avoid to get a bad syntax for the file we will store and that ****people for sure will edit  with a text editor***.

Give me the spec and I will write one with tests. It looks like a task I can handle.

Stef



On Apr 9, 2012, at 10:40 PM, Dale Henrichs wrote:

or better (?):

{
        #super->#Object.
        #name: #ConfigurationOfFileTree.
        #category->#ConfigurationOfFileTree.
        #classinstvars->#().
        #classvars->#().
        #commentStamp->''.
        #instvars->#(project).
        #pools->#().
        #type->#normal }

and we avoid even the parser :)

On Apr 9, 2012, at 10:58 PM, stephane ducasse wrote:

Stef we are consistently using JSON (remember the earlier conversations: the JSON parser is more portable than a Smalltalk parser) ... with that said, it is a fact that whichever format is chosen there will be disagreement over the details ... we all believe in the content (which is most important) and I expect that over time, the formats will migrate to something different...

Dale

----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, April 9, 2012 1:53:12 PM
| Subject: Re: [Metacello] FileTree and Cypress status
|
| Hi dale
|
| {
| "category" : "ConfigurationOfFileTree",
| "classinstvars" : [
| ],
| "classvars" : [
| "LastVersionLoad" ],
| "commentStamp" : "",
| "instvars" : [
| "project" ],
| "name" : "ConfigurationOfFileTree",
| "pools" : [
| ],
| "super" : "Object",
| "type" : "normal" }
|
| I found that really strange that we use yet another syntax for
| encoding information. I still do not get (but I'm probably too
| stupid to understand)
| why
|
| #(
| #(category ConfigurationOfFileTree)
| #(classinstvars ….
| )
|
| does not make it?
|
| Probably the sirens of the hype.
|
|
| Stef
|
| On Apr 9, 2012, at 10:40 PM, Dale Henrichs wrote:
|
| > Over the weekend I finished up on work moving FileTree[1] to use
| > the new Cypress package structure[2].
| >
| > I've updated the FileTree installation instructions[3] including
| > some notes on contributing to the project. If you are using an
| > earlier version of FileTree, you'll want to upgrade to this by
| > basically installing the new version on top of the old.
| >
| > There are a handful of changes between the old and new package
| > formats that are worth mentioning:
| >
| >  - more compact directory structure (fewer intermediate
| >  directories)
| >  - .package extension instead of .pkg for the package directory
| >  - 4 dialect-specific branches[8]:
| >
| >    master
| >    pharo1.3
| >    squeak4.3
| >    gemstone2.4
| >
| >  - class creation attributes in a properties.json file[4]
| >  - method protocol name "embedded" in method source[5]
| >  - UTF8 support
| >  - class comment extracted into a README.md file[6], so that
| >    markdown syntax can be used for more meaningful and visible
| >    class comments using UTF8
| >
| > The upshot is that we've got a common package structure for VW[7],
| > GemStone, Pharo and Squeak, with VAST coming soon.
| >
| > Dale
| >
| > [1] https://github.com/dalehenrich/filetree
| > [2]
| > https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
| > [3] https://github.com/dalehenrich/filetree/blob/master/README.md
| > [4]
| > https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/properties.json
| > [5]
| > https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/instance/customProjectAttributes.st
| > [6]
| > https://github.com/CampSmalltalk/Cypress-Mocks/blob/master/gemstone/packages/Cypress-Mocks.package/CypressMockBasic.class/README.md
| > [7] https://github.com/CampSmalltalk/STIG
| > [8] https://github.com/dalehenrich/filetree/network
|
|

We're entering "bike shedding" territory ... there are bigger fish to fry than worrying over one unreadable format over another...

Dale

----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, April 9, 2012 1:58:28 PM
| Subject: Re: [Metacello] FileTree and Cypress status
|
| May be I can write a Smalltalk literal parser in less methods than
| the json one and in one class since it looks like this is the killer
| argument for this crappy syntax usage.
| If this is what should be done to avoid to get a bad syntax for the
| file we will store and that ****people for sure will edit  with a
| text editor***.
|
| Give me the spec and I will write one with tests. It looks like a
| task I can handle.
|
| Stef
|
|
|
| On Apr 9, 2012, at 10:40 PM, Dale Henrichs wrote:
|
| > Over the weekend I finished up on work moving FileTree[1] to use
| > the new Cypress package structure[2].
| >
| > I've updated the FileTree installation instructions[3] including
| > some notes on contributing to the project. If you are using an
| > earlier version of FileTree, you'll want to upgrade to this by
| > basically installing the new version on top of the old.
| >
| > There are a handful of changes between the old and new package
| > formats that are worth mentioning:
| >
| >  - more compact directory structure (fewer intermediate
| >  directories)
| >  - .package extension instead of .pkg for the package directory
| >  - 4 dialect-specific branches[8]:
| >
| >    master
| >    pharo1.3
| >    squeak4.3
| >    gemstone2.4
| >
| >  - class creation attributes in a properties.json file[4]
| >  - method protocol name "embedded" in method source[5]
| >  - UTF8 support
| >  - class comment extracted into a README.md file[6], so that
| >    markdown syntax can be used for more meaningful and visible
| >    class comments using UTF8
| >
| > The upshot is that we've got a common package structure for VW[7],
| > GemStone, Pharo and Squeak, with VAST coming soon.
| >
| > Dale
| >
| > [1] https://github.com/dalehenrich/filetree
| > [2]
| > https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
| > [3] https://github.com/dalehenrich/filetree/blob/master/README.md
| > [4]
| > https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/properties.json
| > [5]
| > https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/instance/customProjectAttributes.st
| > [6]
| > https://github.com/CampSmalltalk/Cypress-Mocks/blob/master/gemstone/packages/Cypress-Mocks.package/CypressMockBasic.class/README.md
| > [7] https://github.com/CampSmalltalk/STIG
| > [8] https://github.com/dalehenrich/filetree/network
|
|

Esteban,

I want to avoid having to execute code to interpret the contents of the package ... it's a major security hole ... another reason for eliminating the chunk format for methods and class definitions... No external code is executed with the current Cypress format until the code is actually loaded and the initializers are run...

Listen folks, we are very close to the point where we can once again share source code across multiple dialects ... something that hasn't been done in DECADES ... are we really going to nitpick over the format of the files?

As I have said many many times ... THE FORMAT WILL CONTINUE TO EVOLVE OVER TIME ... JSON IS EXPEDIENT AND A PARSER EXISTS ... The current implementation reads three different package formats[1][2][3], there is certainly room for more.

I seem to recall a little phrase that we Smalltalkers are supposed to be familiar with:

  Make it work, make it right, make it fast

We have hit the first baby step in "Make it work" ... give us a chance to "make it work" before we argue about what will "make it right" ...

Dale


[1] https://github.com/dalehenrich/filetree/tree/master/tests/testRepositories/ver01
[2] https://github.com/dalehenrich/filetree/tree/master/tests/testRepositories/ver03
[3] https://github.com/dalehenrich/filetree/tree/master/tests/testRepositories/ver04


----- Original Message -----
| From: "Esteban Lorenzano" <[hidden email]>
| To: [hidden email]
| Sent: Monday, April 9, 2012 2:03:27 PM
| Subject: Re: [Metacello] FileTree and Cypress status
|
| or better (?):
|
| {
| #super->#Object.
| #name: #ConfigurationOfFileTree.
| #category->#ConfigurationOfFileTree.
| #classinstvars->#().
| #classvars->#().
| #commentStamp->''.
| #instvars->#(project).
| #pools->#().
| #type->#normal }
|
| and we avoid even the parser :)
|
| On Apr 9, 2012, at 10:58 PM, stephane ducasse wrote:
|
| > May be I can write a Smalltalk literal parser in less methods than
| > the json one and in one class since it looks like this is the
| > killer argument for this crappy syntax usage.
| > If this is what should be done to avoid to get a bad syntax for the
| > file we will store and that ****people for sure will edit  with a
| > text editor***.
| >
| > Give me the spec and I will write one with tests. It looks like a
| > task I can handle.
| >
| > Stef
| >
| >
| >
| > On Apr 9, 2012, at 10:40 PM, Dale Henrichs wrote:
| >
| >> Over the weekend I finished up on work moving FileTree[1] to use
| >> the new Cypress package structure[2].
| >>
| >> I've updated the FileTree installation instructions[3] including
| >> some notes on contributing to the project. If you are using an
| >> earlier version of FileTree, you'll want to upgrade to this by
| >> basically installing the new version on top of the old.
| >>
| >> There are a handful of changes between the old and new package
| >> formats that are worth mentioning:
| >>
| >> - more compact directory structure (fewer intermediate
| >> directories)
| >> - .package extension instead of .pkg for the package directory
| >> - 4 dialect-specific branches[8]:
| >>
| >>   master
| >>   pharo1.3
| >>   squeak4.3
| >>   gemstone2.4
| >>
| >> - class creation attributes in a properties.json file[4]
| >> - method protocol name "embedded" in method source[5]
| >> - UTF8 support
| >> - class comment extracted into a README.md file[6], so that
| >>   markdown syntax can be used for more meaningful and visible
| >>   class comments using UTF8
| >>
| >> The upshot is that we've got a common package structure for VW[7],
| >> GemStone, Pharo and Squeak, with VAST coming soon.
| >>
| >> Dale
| >>
| >> [1] https://github.com/dalehenrich/filetree
| >> [2]
| >> https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
| >> [3] https://github.com/dalehenrich/filetree/blob/master/README.md
| >> [4]
| >> https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/properties.json
| >> [5]
| >> https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/instance/customProjectAttributes.st
| >> [6]
| >> https://github.com/CampSmalltalk/Cypress-Mocks/blob/master/gemstone/packages/Cypress-Mocks.package/CypressMockBasic.class/README.md
| >> [7] https://github.com/CampSmalltalk/STIG
| >> [8] https://github.com/dalehenrich/filetree/network
| >
|
|

+1

I think that JSON is a good enough choice at the current time in order
to advance and see the real purpose of this that is, store smalltalk
code in git and share between dialects.

Pay no attention to the implementation details like JSON.

Great work Dale!

El lun, 09-04-2012 a las 15:13 -0700, Dale Henrichs escribió:
--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

make it work +1

On Apr 10, 2012, at 12:01 AM, Dale Henrichs wrote:

> We're entering "bike shedding" territory ... there are bigger fish to fry than worrying over one unreadable format over another…

no
and this is why I will write a dialect independent literal Array parser.

On Apr 10, 2012, at 12:13 AM, Dale Henrichs wrote:

> Esteban,

Hi esteban,
I started to write one SimpleLIteralArrayParser so that we can get rid of that stupid syntax.

> I want to avoid having to execute code to interpret the contents of the package ... it's a major security hole ... another reason for eliminating the chunk format for methods and class definitions... No external code is executed with the current Cypress format until the code is actually loaded and the initializers are run...
>
> Listen folks, we are very close to the point where we can once again share source code across multiple dialects ... something that hasn't been done in DECADES ... are we really going to nitpick over the format of the files?
>
> As I have said many many times ... THE FORMAT WILL CONTINUE TO EVOLVE OVER TIME ... JSON IS EXPEDIENT AND A PARSER EXISTS ... The current implementation reads three different package formats[1][2][3], there is certainly room for more.

What I learned is that stuff stay there for years.

> I seem to recall a little phrase that we Smalltalkers are supposed to be familiar with:
>
>  Make it work, make it right, make it fast
>
> We have hit the first baby step in "Make it work" ... give us a chance to "make it work" before we argue about what will "make it right" …

so I will give you my parser when it is running like that I will have contributed to a real bikeshed discussion but for something.

Stef

On 2012-04-09, at 11:58 PM, stephane ducasse wrote:

>
> On Apr 10, 2012, at 12:01 AM, Dale Henrichs wrote:
>
>> We're entering "bike shedding" territory ... there are bigger fish to fry than worrying over one unreadable format over another…
>
> no
> and this is why I will write a dialect independent literal Array parser.

Stephane,

What exactly is your objection to JSON? What makes s-expressions so much more desirable?

Cheers,

Colin

Stef,

Agreed ... if we are going to do something rather than just discuss then we are not in bike shedding territory ...

If we're going to discuss parsable Smalltalk formats, then I don't think that we really want to do straight literal array syntax:

  - literal arrays are not rich enough for the problem space, with JSON we
    get objects with named fields in the mix and that is an important
    feature

  - literal arrays are not readable ... if they were we'd be using
    literal arrays in Metacello specs today, because that's were I
    started

Here's an example properties.json:

{
  "classinstvars" : [ "specials" ],
  "instvars" : [  "classPaths",
                  "definedClasses" ],
  "name" : "CypressLayout",
  "namespace" : "STIG",
  "super" : "DirectoryLayout",
  "superNamespace" : "STIG" }

Here's that example translated to literal arrays:

#(
  #('classinstvars' #( 'specials'))
  #('instvars' #( 'classPaths'
                  'definedClasses'))
  #('name' 'CypressLayout' )
  #('namespace' 'STIG' )
  #('super' 'DirectoryLayout')
  #('superNamespace' 'STIG')
)

Both of these are pretty ugly and unreadable, because of all the extra language-specific syntax.

The actual smalltalk expressions for class creation would actually be preferable, but we have a divergance of class creation protocol between dialects. VW example:

  GemStone.Gbs.ServerClasses defineClass: #AbstractSession
    superclass: #{GemStone.Gbs.ServerClasses.GbsServerClass}
    indexedType: #none
    private: false
    instanceVariableNames: ''
    classInstanceVariableNames: ''
    imports: '
            SpecialGemStoneObjects.*
            '
    category: 'GbsRuntime-GbsServerClassSupport'

GemStone example:

  Object subclass: 'UnicodeData'
    instVarNames: #( id name category
                    combineClass bidiClass decompType decompMap
                    decDigit digit number bidiMirrored
                    unicode1Name isoComment upperCase lowerCase
                    titleCase dispatchId collateId collatePrevious
                    collateNext)
    classVars: #( CollateEnd File MAX_ENTRY SortedTable Table)
    classInstVars: #()
    poolDictionaries: { }
    inDictionary: Globals

These two examples are at least recognizable Smalltalk code and are readable by smalltalk programmers ... Of course it looks like we will need a full-blown smalltalk parser to pull this off ... the other problem with this approach is that we have to invent mappings for the various arguments so that code from VW could be bootstrapped into GemStone ...

If we're going to write a parser for human readable and machine parsable format, perhaps we should look at YAML[1]. YAML has parsers written in 11 languages (listed on their page) and it was designed to be human readable and machine parsable[2]. Here's the YAML for the original properties.json:

classinstvars:
    -specials
instvars:
    - classPaths
    - definedClasses
name: CypressLayout
namespace: STIG
super: DirectoryLayout
superNamespace: STIG

If we're going to expend effort writing a parser, perhaps a YAML parser is a better place to put your effort. YAML has support for a rich set of constructs[3] as well ... all in a readable/parable structure...

Frankly the next generation of the structure should use YAML ... I would be using YAML right now if we had a parser...

Dale
         
[1] http://yaml.org/
[2] http://www.yaml.org/spec/1.2/spec.html#id2708649
[3] http://www.yaml.org/spec/1.2/spec.html#Preview
----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, April 9, 2012 11:58:59 PM
| Subject: Re: [Metacello] FileTree and Cypress status
|
|
| On Apr 10, 2012, at 12:01 AM, Dale Henrichs wrote:
|
| > We're entering "bike shedding" territory ... there are bigger fish
| > to fry than worrying over one unreadable format over another…
|
| no
| and this is why I will write a dialect independent literal Array
| parser.
|
|
|
|
|

Regarding being stuck with a format for years ... I would agree if the implementation was not designed to be malleable, but with the current implementation I am actively supporting multiple, completely incompatible formats.

Monticello was based on serialization of Squeak objects and therefore was brittle... we are just lucky that the Monticello data structures didn't contain some classes that changed shape on a regular basis ... I had to go through hoops to read and write Monticello files because the structure of OrderedCollection in GemStone doesn't match the implementation in Squeak ...

Moving file structure around while not completely simple is not a hard problem ... we don't have to support writing multiple formats anyway ... all we have to do is support the reading of old formats and that is a requirement no matter what because we are dealing with versions of disk structure that is frozen in time by git or svn ...

I don't think it makes any sense to move sideways from JSON to literal Smalltalk arrays ... I think it makes sense to move forward to YAML ... look at the YAML documentation[1], before writing a literal array parser ... it is language neutral and has a very rich set of structures ...

I don't think a YAML parser would be necessarily easy to write, but just think:

  if we had YAML parser written in Smalltalk and managed in a github project, we'd be able
  to contact the folks over at yaml.org and supply them with an URL to the Smalltalk
  implementation that could be used by multiple Smalltalk dialects...

To me, that would be cool!

Dale

[1] http://www.yaml.org/spec/1.2/spec.html#Preview
----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, April 10, 2012 12:00:54 AM
| Subject: Re: [Metacello] FileTree and Cypress status
|
|
| On Apr 10, 2012, at 12:13 AM, Dale Henrichs wrote:
|
| > Esteban,
|
| Hi esteban,
| I started to write one SimpleLIteralArrayParser so that we can get
| rid of that stupid syntax.
|
| > I want to avoid having to execute code to interpret the contents of
| > the package ... it's a major security hole ... another reason for
| > eliminating the chunk format for methods and class definitions...
| > No external code is executed with the current Cypress format until
| > the code is actually loaded and the initializers are run...
| >
| > Listen folks, we are very close to the point where we can once
| > again share source code across multiple dialects ... something
| > that hasn't been done in DECADES ... are we really going to
| > nitpick over the format of the files?
| >
| > As I have said many many times ... THE FORMAT WILL CONTINUE TO
| > EVOLVE OVER TIME ... JSON IS EXPEDIENT AND A PARSER EXISTS ... The
| > current implementation reads three different package
| > formats[1][2][3], there is certainly room for more.
|
| What I learned is that stuff stay there for years.
|
| > I seem to recall a little phrase that we Smalltalkers are supposed
| > to be familiar with:
| >
| >  Make it work, make it right, make it fast
| >
| > We have hit the first baby step in "Make it work" ... give us a
| > chance to "make it work" before we argue about what will "make it
| > right" …
|
| so I will give you my parser when it is running like that I will have
| contributed to a real bikeshed discussion but for something.
|
| Stef
|
| >
| > Dale
| >
| >
| > [1]
| > https://github.com/dalehenrich/filetree/tree/master/tests/testRepositories/ver01
| > [2]
| > https://github.com/dalehenrich/filetree/tree/master/tests/testRepositories/ver03
| > [3]
| > https://github.com/dalehenrich/filetree/tree/master/tests/testRepositories/ver04
| >
| >
| > ----- Original Message -----
| > | From: "Esteban Lorenzano" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Monday, April 9, 2012 2:03:27 PM
| > | Subject: Re: [Metacello] FileTree and Cypress status
| > |
| > | or better (?):
| > |
| > | {
| > | #super->#Object.
| > | #name: #ConfigurationOfFileTree.
| > | #category->#ConfigurationOfFileTree.
| > | #classinstvars->#().
| > | #classvars->#().
| > | #commentStamp->''.
| > | #instvars->#(project).
| > | #pools->#().
| > | #type->#normal }
| > |
| > | and we avoid even the parser :)
| > |
| > | On Apr 9, 2012, at 10:58 PM, stephane ducasse wrote:
| > |
| > | > May be I can write a Smalltalk literal parser in less methods
| > | > than
| > | > the json one and in one class since it looks like this is the
| > | > killer argument for this crappy syntax usage.
| > | > If this is what should be done to avoid to get a bad syntax for
| > | > the
| > | > file we will store and that ****people for sure will edit  with
| > | > a
| > | > text editor***.
| > | >
| > | > Give me the spec and I will write one with tests. It looks like
| > | > a
| > | > task I can handle.
| > | >
| > | > Stef
| > | >
| > | >
| > | >
| > | > On Apr 9, 2012, at 10:40 PM, Dale Henrichs wrote:
| > | >
| > | >> Over the weekend I finished up on work moving FileTree[1] to
| > | >> use
| > | >> the new Cypress package structure[2].
| > | >>
| > | >> I've updated the FileTree installation instructions[3]
| > | >> including
| > | >> some notes on contributing to the project. If you are using an
| > | >> earlier version of FileTree, you'll want to upgrade to this by
| > | >> basically installing the new version on top of the old.
| > | >>
| > | >> There are a handful of changes between the old and new package
| > | >> formats that are worth mentioning:
| > | >>
| > | >> - more compact directory structure (fewer intermediate
| > | >> directories)
| > | >> - .package extension instead of .pkg for the package directory
| > | >> - 4 dialect-specific branches[8]:
| > | >>
| > | >>   master
| > | >>   pharo1.3
| > | >>   squeak4.3
| > | >>   gemstone2.4
| > | >>
| > | >> - class creation attributes in a properties.json file[4]
| > | >> - method protocol name "embedded" in method source[5]
| > | >> - UTF8 support
| > | >> - class comment extracted into a README.md file[6], so that
| > | >>   markdown syntax can be used for more meaningful and visible
| > | >>   class comments using UTF8
| > | >>
| > | >> The upshot is that we've got a common package structure for
| > | >> VW[7],
| > | >> GemStone, Pharo and Squeak, with VAST coming soon.
| > | >>
| > | >> Dale
| > | >>
| > | >> [1] https://github.com/dalehenrich/filetree
| > | >> [2]
| > | >> https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
| > | >> [3]
| > | >> https://github.com/dalehenrich/filetree/blob/master/README.md
| > | >> [4]
| > | >> https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/properties.json
| > | >> [5]
| > | >> https://github.com/dalehenrich/filetree/blob/master/repository/ConfigurationOfFileTree.package/ConfigurationOfFileTree.class/instance/customProjectAttributes.st
| > | >> [6]
| > | >> https://github.com/CampSmalltalk/Cypress-Mocks/blob/master/gemstone/packages/Cypress-Mocks.package/CypressMockBasic.class/README.md
| > | >> [7] https://github.com/CampSmalltalk/STIG
| > | >> [8] https://github.com/dalehenrich/filetree/network
| > | >
| > |
| > |
|
|

> #(
>   ('classinstvars' ( 'specials'))
>   ('instvars' #( 'classPaths'  'definedClasses'))
>   ('name' 'CypressLayout' )
>   ('namespace' 'STIG' )
>   ('super' 'DirectoryLayout')
>   ('superNamespace' 'STIG')
> )

Why this is not good.
It is robust, simple to validate and nobody has to guess where to put [ : ", ' …..

>>> We're entering "bike shedding" territory ... there are bigger fish to fry than worrying over one unreadable format over another…
>>
>> no
>> and this is why I will write a dialect independent literal Array parser.
>
> Stephane,
>
> What exactly is your objection to JSON? What makes s-expressions so much more desirable?

I do not have to know that " is equal to ' and that [ is equal to ( and that I need a ,
You know this kind of shit.  
Now if the basic syntax of smalltalk would not let us express it in two minutes then we could start to think
but this is not the case.
I do not even understand why we are discussing that. Then if we load this into an image we should use the ****SAME**** query tools to query
them and not end up into oh yes this is a specific DSL so let us build different tools. We have far better to do.
So I will continue to write a simple literal array parser.

Just give me the spec you want. It should not be difficult to implement that with full test coverage.

I can look in window spec in visual works for that reason and for free.

>
> Cheers,
>
> Colin

On Apr 10, 2012, at 7:41 PM, Dale Henrichs wrote:

> Regarding being stuck with a format for years ... I would agree if the implementation was not designed to be malleable, but with the current implementation I am actively supporting multiple, completely incompatible formats.
>
> Monticello was based on serialization of Squeak objects and therefore was brittle... we are just lucky that the Monticello data structures didn't contain some classes that changed shape on a regular basis ... I had to go through hoops to read and write Monticello files because the structure of OrderedCollection in GemStone doesn't match the implementation in Squeak ...
>
> Moving file structure around while not completely simple is not a hard problem ... we don't have to support writing multiple formats anyway ... all we have to do is support the reading of old formats and that is a requirement no matter what because we are dealing with versions of disk structure that is frozen in time by git or svn ...
>
> I don't think it makes any sense to move sideways from JSON to literal Smalltalk arrays ... I think it makes sense to move forward to YAML ... look at the YAML documentation[1], before writing a literal array parser ... it is language neutral and has a very rich set of structures ...


to me Yaml for what you need make little sense.


>
> I don't think a YAML parser would be necessarily easy to write, but just think:
>
>  if we had YAML parser written in Smalltalk and managed in a github project, we'd be able
>  to contact the folks over at yaml.org and supply them with an URL to the Smalltalk
>  implementation that could be used by multiple Smalltalk dialects…


This is a difficult story. We can ask a student to write a parser and like that Smalltalk will be added to the list of the cool languages
implementing YAML but this applies to a lot of projects.

On Tue, Apr 10, 2012 at 12:51 PM, stephane ducasse
<[hidden email]> wrote:
So let me see if I understand:

- JSON is unfamiliar or confusing
- S-expressions are less confusing and are perfectly capable of
representing the data
- You're worried that if this data ends up in a method literal, the
standard Smalltalk tools won't be able to peer inside it
- You think that writing and maintaining a cross-dialect s-expression
parser will be easier than using platform-specific JSON parsers

Is that right?

Colin

On Apr 10, 2012, at 10:09 PM, Colin Putney wrote:

Yes
Uniformity is for me a plus.

>
> Colin

On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
<[hidden email]> wrote:

Ok, since you wrote "I do not even understand why we are discussing
that." I'll make the argument in favour of JSON:

- JSON is a simple, well-defined syntax (see http://json.org/)

- There are many, many parser implementations already out there,
including basically all Smalltalk dialects.

- We're specifically talking about syntax for storing data in a file,
not inside the image. Smalltalk tools like "senders" aren't going to
be able to work with this data anyway, and in fact, we don't want to
pollute the image with symbols that aren't actually Smalltalk code.

- JSON is really, really common out in the wider world. Part of the
appeal of putting Smalltalk code on Github is so that it's visible on
the web, instead of locked away in our images and non-standard
versioning systems. If we're trying to put our code out there for
people to see, we should use a syntax that they can already
understand. S-expressions will only be familiar to Lispers.

The point I'm making here is that Dale and the other folks at STIC
didn't just pick JSON to avoid writing a parser. You may be correct
that writing an s-expression parser is easy and perhaps easier than
using dialect-native JSON parsers. But even if that's true, there's a
good argument for using JSON anyway. Now, if you want to argue that
s-expressions are a better fit for the problem, ok, let's hear that
argument.

Colin