[Vm-dev] reorganizing opensmalltalk-vm

[Tobias Pape]

Hi All,

> On 25.10.2018, at 19:30, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi All,
> 
>     efforts are underway to include the VMMaker source in the opensmalltalk-vm repository.  I'm hoping to see all the Smalltalk source included in the Tonel format (one file per class, and one file per extended class), with support for Pharo and Squeak quite soon.

I know its not a constructive comment, but I'm not very fond of the Tonel format. 
Yes, it solves the need (or pecularities) of too-many-tiny-files. But so does good-old file-out or Cuis pkg.st formt (eg, https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages/) .
I really do not like the introduction of a new, incompatible Syntax, that also introduces a mismatch between what is written in the browser and what is written to disk[1]. I also do not think that using STON as a metadata format within Tonel is a good match.
  Moreover, Tonel is comparatively young and I'd be cautious to just yet use it in such a rather large, complex project as VMMaker, where bugs in the formats implementation would only surface slowly.


That being said, if there's consensus to go with Tonel, well, so be it.

Regarding the rest: sounds good, with a slight preference to variant #1.


Best regards
	-Tobias

[1]:
Think I have a method with a very long selector, eg MCClassDefinition:


initializeWithName: nameString
superclassName: superclassString
traitComposition: traitCompositionString
classTraitComposition: classTraitCompositionString
category: categoryString 
instVarNames: ivarArray
classVarNames: cvarArray
poolDictionaryNames: poolArray
classInstVarNames: civarArray
type: typeSymbol
comment: commentString
commentStamp: stampStringOrNil
	name := nameString asSymbol.
	superclassName := superclassString ifNil: ['nil'] ifNotNil: [superclassString asSymbol].
	traitComposition := traitCompositionString.
	classTraitComposition := classTraitCompositionString.
	category := categoryString.
	type := typeSymbol.
	comment := commentString withSqueakLineEndings.
	commentStamp := stampStringOrNil ifNil: [self defaultCommentStamp].
	variables := OrderedCollection  new.
	self addVariables: ivarArray ofType: MCInstanceVariableDefinition.
	self addVariables: cvarArray sorted ofType: MCClassVariableDefinition.
	self addVariables: poolArray sorted ofType: MCPoolImportDefinition.
	self addVariables: civarArray ofType: MCClassInstanceVariableDefinition


Seeing the Tonel format, this formatting of the selector, even if it is uncommon, would not be preserved, right?

>  This is therefore an opportunity to also reorganize the structure of the repository to have a more comprehensible and less cluttered top-level directory.  I'm interested in people's ideas.  here are two suggestions.
> 
> 1. move all source under src and all builds under build. So
>     src/smalltalk/                  all the VMMaker-related packages
>                         AioPlugin
>                         BytecodeSets
>                         Cog
>                         VMMaker
>     src/generated/              all the generated code
>                         plugins/     all generated plugins
>                         v3              the V3 VM (now src/vm)
>                         spur32       the 32-bit Spur VM (now spursrc/vm)
>                         spur64       the 64-bit Spur VM (now spur64src/vm)
>     src/platforms                 the current platforms directory
>     src/third-party/
>                         processors
>     build/                             the current build directories
>         macos32x86
>         macos64x64
>     deploy/
>     image/
>     tests/
> 
> 2. single top-level directories for generated source, and Smalltalk source, everything else unchanged
> smalltalksrc/             all the VMMaker-related packages
> generatedsrc/           all the generated code as above in src/generated, but in generatedsrc instead
> platforms
> processors
> third-party
> tests
> deploy
> 
> Obviously #1 is more work but produces a much cleaner structure.  Other suggestions? Reactions to the above?
> _,,,^..^,,,_
> best, Eliot