[Vm-dev] reorganizing opensmalltalk-vm

Jakob Reschke forums.jakob at resfarm.de
Fri Oct 26 20:02:50 UTC 2018


Am Fr., 26. Okt. 2018 um 21:13 Uhr schrieb Norbert Hartl <norbert at hartl.name
>:

>
> > Am 26.10.2018 um 20:33 schrieb Todd Blanchard <tblanchard at mac.com>:
> >
> > 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.
> >
> One file per method does not work on windows. So if we do not want to
> loose them one file per class seems to be the way to go, no?
>
>
Actually it works fine on Windows, until people come up with ultra-long
method names, typically taking lots of arguments. ;-)

If I remember correctly, Dale's argument for one method per file was that
you can then ask Git (or whatever file-based VCS) about the history of one
method, which is not possible directly with any coarser format. Yes,
browsing through one method per file without a Smalltalk IDE is daunting.
But the same applies to browsing any code base of a certain size without a
proper IDE.

On the topic of the directory structure, I would prefer option 1 and
keeping the "generated" name in favor of "gensrc". Spelling it out makes it
clearer, IMHO. I also prefer third-party over othersrc because the latter
is too generic. I could also agree on having /third-party as a top-level
folder, so the /src folder only contains stuff that is genuinely
opensmalltalk-vm.

The /tests directory currently does not really contain any tests, right?
Yet, it is also some kind of source code, isn't it? So why not put it under
/src as well?

By the way, once the "real" source code is in the repo, and the generated C
source code is as well, the generated sources will lack behind the
Smalltalk sources most of the time, won't they? That might be confusing for
people who come to the repo, clone or download it and just want to compile
the VM. "Hey I pulled commit abc that fixes xyz, yet I still have the bug
when I build it!?" Are there any plans to tackle this?

Kind regards,
Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181026/60710fcc/attachment.html>


More information about the Vm-dev mailing list