<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Just a few thoughts. Take with a grain of salt.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, 26 Oct 2018 at 01:31, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>    efforts are underway to include the VMMaker source in the opensmalltalk-vm repository. </div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Very nice.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> 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.  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.</div><div><br></div><div>1. move all source under src and all builds under build. So</div><div>    src/smalltalk/                  all the VMMaker-related packages</div>                        AioPlugin</div><div dir="ltr">                        BytecodeSets<div>                        Cog</div>                        VMMaker</div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Could you explain what would be in VMMaker?</div><div>I thought all the plugins were a part of VMMaker rather than siblings. </div><div>i.e. why not src/vmmaker/AioPlugin & src/vmmaker/vm (or src/vmmaker/Core)<br></div><div><br></div><div>Also what would be in Cog?  just the JIT stuff?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>    src/generated/              all the generated code<br><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate">                        plugins/     all generated plugins</span></div><div>                        v3              the V3 VM (now src/vm) </div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate">                        spur32       the 32-bit Spur VM (now spursrc/vm)<br><span style="border-collapse:separate">                        spur64       the 64-bit Spur VM (now spur64src/vm)</span></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div><div>Those renames definitely add clarity and will help newcomers, particularly the v3 one.   </div></div><div>However I think "src" should just be for "raw" sources.</div><div>A top level "generated" folder per your point[2.] would be good, but perhaps also sllmming the name down to "gensrc".</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div>    src/platforms                 the current platforms directory</div><div>    src/third-party/ </div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate">                        processors</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Can "src" be kept just for "our" sources ?</div><div>IIUC, processors/IA32 contains third-party source folder "bochs" </div><div>as well our our code which looks like build script in folders "$(PLATFORM)bochs" </div><div>Ideally that part should be split out under the build folder, and the perhaps the third-party source goes under root folder "othersrc"</div><div>but the existing "processors" folder as a whole is not getting in the way, so for now leave it.</div><div><br></div><div>Though the term "processors" has broad meaning and it may make more sense to newcomers if the folder was "processor-sim" or "cpu-sim".</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div>    build/                             the current build directories</div><div>        macos32x86</div><div>        macos64x64</div><div>    deploy/</div><div>    image/</div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Maybe an idea for the future, "image" could be much more than just holding scripts to create the build.image.</div><div>Initially it could hold image-side code for CI testing of the VM.</div><div>But also it seed the growth of a common image-side codebase for the low level stuff between distributions.</div><div>Pharo's plan is to modularize things to build their shipping image from multiple repositories, </div><div>so it shouldn't matter to them if their bootstrap pulls some parts direct from opensmalltalk.</div><div>Or maybe it would be better to have all that in a different repo <a href="https://github.com/OpenSmalltalk/opensmalltalk-image">https://github.com/OpenSmalltalk/opensmalltalk-image</a></div><div><br></div><div>In any case, "image" as things currently stand feels a bit odd at the top-level.</div><div>It seems it would fit better under "scripts/image", or "scripts/dev.image"</div><div><br></div><div><div>btw, what is spec/locode.xml ?</div><div>Is that something loaded by the image-side by a user? </div><div>That might fit under image/specs/lowcode.xml ?</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div>    tests/</div><div><br></div><div>2. single top-level directories for generated source, and Smalltalk source, everything else unchanged</div><div>smalltalksrc/             all the VMMaker-related packages</div><div>generatedsrc/           all the generated code as above in src/generated, but in generatedsrc instead </div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_8885948791013568884gmail_signature"><div dir="ltr"><div>platforms</div><div>processors</div><div>third-party</div><div>tests</div><div>deploy</div><div><br></div><div>Obviously #1 is more work but produces a much cleaner structure.  Other suggestions? Reactions to the above?<br><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>3. So top level could look like...</div><div>   src/                  our own root sources, native and smalltalk VMMaker </div><div><div dir="ltr"><div>   gensrc/            generated from VMMaker<br></div></div></div><div>   othersrc/          third-party libs kept intree (manually or via subtree or submodule) <br></div><div>   cachesrc/        sources downloaded during build (empty folder on github except readme.md) </div><div>   scripts/</div><div>   build/<br></div><div>   deploy/</div><div><br></div><div>with second level...</div><div>   src/smalltalk/                 all the VMMaker-related packages<br></div><div><div><div>   src/platforms                 the current platforms directory</div><div>   src/third-party/              only the spec files</div></div></div><div><br></div><div>The main readme says "Another distinction is between Stack, Cog and Sista VMs",</div><div>so would it be better to be explicit about which ones are Cog?</div><div>Also would it be better to be explicit about v3 only being 32 bit (if I guess correctly)</div><div>   gensrc/plugins<br></div><div><div><div dir="ltr"><div>   gensrc/v3cog32                   old src<br></div></div></div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>   gensrc/v3stack32                old stacksrc</div></div></div><div><div dir="ltr"><div>   gensrc/spurstack32            old spurstacksrc<br></div></div></div><div><div dir="ltr"><div>   gensrc/spurstack64            old spurstack64src</div></div></div><div>   gensrc/spurcog32               old spursrc<br></div></div></div><div><div>   gensrc/spurcog64               old spur64src</div></div><div><div><div><div><div>   gensrc/spursista32            old spursista64src</div></div></div><div>   gensrc/spursista64            old spursista64src</div></div></div><div>   gensrc/spurlowcode32      old spurlowcodesrc</div><div><div>   gensrc/spurlowcode64      old spurlowcode64src</div></div><div><div><div dir="ltr"><div><br></div></div></div></div><div>   othersrc/gdb<br></div><div><div>   othersrc/bochs         an alternative is to mirror/fork bochs into opensmalltalk-vm/bochs and have a build script pull that to your machine </div><div>                                        e.g. <a href="https://github.com/search?q=bochs+mirror&type=Repositories">https://github.com/search?q=bochs+mirror&type=Repositories</a></div><div>                                       you can have one branch called "mirror" that only *ever* sucks from upstream</div><div>                                       with any custom mods in a branch called "Cog".  </div></div></div></div><div>   scripts/ci</div><div>   scripts/image</div><div>   scripts/git</div><div><br></div>   build/linuxXXX</div><div>   build/winXXX </div><div><br></div><div>   deploy/squeak</div><div>   deploy/pharo</div><div>   deploy/newspeak</div><div><br></div><div>cheers -ben</div><div><br></div></div></div></div></div></div></div></div></div></div></div>