[Vm-dev] reorganizing opensmalltalk-vm

Norbert Hartl norbert at hartl.name
Fri Oct 26 19:12:05 UTC 2018

> Am 26.10.2018 um 20:02 schrieb Steffen Märcker <merkste at web.de>:
> 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.
Can you elaborate on why you think tonel is not  smalltalk syntax and the others are?

> 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