[Vm-dev] reorganizing opensmalltalk-vm

[Steffen Märcker]

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