[Vm-dev] reorganizing opensmalltalk-vm

Todd Blanchard tblanchard at mac.com
Fri Oct 26 18:33:44 UTC 2018

I suspect it had something to do with making things git merge friendly.

I think the granularity is overly fine at one method per file as it makes browsing a git repo from a web browser annoyingly clicky.  But there it is.

> On Oct 26, 2018, at 11:02 AM, Steffen Märcker <merkste at web.de> wrote:
> May I ask - just out of curiosity - which arguments ultimately lead to the decision to use a new, non-Smalltalk syntax to store code in files? I had a discussion with a colleague today who just wonder why this is, too.
> Best, Steffen
> Am .10.2018, 09:01 Uhr, schrieb Tobias Pape <Das.Linux at gmx.de>:
>> 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

More information about the Vm-dev mailing list