[Vm-dev] reorganizing opensmalltalk-vm
Steffen Märcker
merkste at web.de
Fri Oct 26 19:34:52 UTC 2018
Sure. Please note that this was an honest question and not an offence. I
just want to understand which specific problems it addresses. If I have a
look at the files in the src directory of, e.g., the Pharo2VW repository,
I see:
> Class {
> #name : #Pharo2VW,
> [...]
> }
>{ #category : #'instance creation' }
> Pharo2VW class >> exporter [
> ^ self new
> ]
An opposite approach could be to write out directly executable code that
generates the classes, methods etc.
Best, Steffen
Am .10.2018, 21:12 Uhr, schrieb Norbert Hartl <norbert at hartl.name>:
>
>
>> 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?
>
> Norbert
>> 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