[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