[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