[Vm-dev] reorganizing opensmalltalk-vm

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

> Am 26.10.2018 um 20:33 schrieb Todd Blanchard <tblanchard at mac.com>:
> 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.
One file per method does not work on windows. So if we do not want to loose them one file per class seems to be the way to go, no?

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