Hi Christoph,

    in this reply I’m only going to address the question about using GitHub
for OpenSmalltalk-VM (for focus, see below).

> On Oct 6, 2020, at 3:48 AM, Christoph Thiede <
christoph.thiede at student.hpi.uni-potsdam.de> wrote:
>
> Hi all,
>
> looks like I'm a bit late back to this debate again, but it's very nice it
> is still going on! There are many arguments I wanted to tell but Jakob
> already explained all of them better than I could do. So just let me come
> back to some points:
>
>
> Mantis:
>
> I just took another look at bugs.squeak.org again, and I'm sorry but I
still
> think that our community deserves a better bug tracking solution than
this.
> It really looks old-fashioned and, from today's point of view, quite
chaotic
> and confusing. And compared to something like GitHub, it does not give me
an
> idea of how to report a bug. Do I have to log in? Which credentials do I
> need to use? Why is there no register button anywhere?
> Also, there must be some reason why the latest issue was submitted nearly
> two years ago. Is Mantis connected to the mailing list at all? Asking all
of
> you who have used Mantis in past and reported newer bugs to the mailing
list
> instead, why did you do that? I would guess because mails provid higher
> visibility and interactivity, is this correct?
>
>
> Phil, you called GitHub & Co. one trend of many that's durability is
> uncertain (correct me if I misunderstood you). I see this point, but
looking
> at the current numbers I strongly believe that GitHub has reached a
critical
> mass of developers and projects that won't move so quickly again. How many
> large global players have decided to use GitHub, including competitors of
> Microsoft itself such as Google, Apple, Facebook, etc.?
>
> At least, according to the trends GitHub is way more popular than
> SourceForge, for example, has ever been, actually, it has even overtaken
git
> itself on Google Trends:
>
https://trends.google.com/trends/explore?date=all&q=github,sourceforge,gitlab,bitbucket,slack
>
> (By the way, if you search any old threads you can also find it on
> web.archive.org in most cases).
>
>> Here you're showing you've already fallen behind: the github trend for
>> discussing things is already fading and those trendier than you have
>> already moved on to the next thing: Slack  is where it's at!  In a year
or
>> two it will be something else... and the treadmill keeps going but not
>> really going anywhere.
>
> Slack is a group messenger used for communication in small to medium
teams,
> but I can hardly imagine someone seriously uses this as a bug tracker for
a
> large-scale software project with a big community, there is just too much
> noise when pressing Enter sends a new message. The same goes for social
> media platforms such as Google Plus that do not even offer basic tracking
> features such as closing or labeling. I don't think you can compare this.
>
>
>> Monticello ancestry does support branching, yet I think Monticello lacks
>> first-class objects for branches, with all the implications for
repository
>> handling.
>
> +1. And I feel the lack of branches for about every second or third
> submission I make to the inbox and am forced to reinvent my one pseudo
> branch wheel.
>
>
> Git vs. GitHub vs. GitLab:
>
> As Jakob already mentioned, they're not the same. I believe that GitHub
> offers the largest range by far, but personally I would still consider it
as
> an improvement to set up a self-hosted GitLab instance (actually, from a
> technical point of view, I think GitLab offers even more convenience
> features for free).
>
> But still, it's right what Eliot said about git and companies:
>
>> One gives up great autonomy when allowing ones core VCS to be in a
foreign
>> system
>
> So why do you use git & GitHub for OpenSmalltalk-VM and not something like
> Monticello?

But I do :-)  The VM is implemented in Smalltalk and a mixture of other
languages but the core VM is *developed* in Smalltalk.  See
source.squeak.org/VMMaker, and in particular the branch VMMaker.oscog which
is the branch of VMMaker that is the trunk of OpenSmalltalk-VM
development.  Other notable branches from this "trunk" are
VMMaker.oscogLLP64, where Nicolas fixed all the work size/pointer size
issues for Windows' horrible LLP64 code model (where sizeof(long) !=
sizeof(void *)), VMMaker.oscogSPC, where I branched to keep the default
compactor working while Clément took the mainline along the path to
multiple compactor implementations, from which we will derive a production
incremental compiler when time allows (see Clément Béra, Eliot Miranda, and
Elisa Gonzalez Boix. “Lazy Pointer Update for Low Heap Compaction Pause
Times.” In Proceedings of the 15th ACM SIGPLAN International Symposium on
Dynamic Languages, 15–27. DLS ’19. ACM, 2019.
https://doi.org/10.1145/3359619.3359741) and VMMaker.gdb where Boris is
aiming to replace the JIT execution simulation machinery with the gdb
framework.  And then of course there's VMMaker itself which is the "old"
Context Interpreter, plus the flexible 32-bit/64-bit pre-Spur system.

The style of development, plus the things we can do that no one else does,
are described in some detail in Daniel Ingalls, Eliot Miranda, Clément
Béra, and Elisa Gonzalez Boix. *“Two Decades of Live Coding and Debugging
of Virtual Machines through Simulation.”**Software: Practice and
Experience* 50,
no. 9 (2020): 1629–50.
https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.2841.  Contact me for a
private copy.  Suffice it to say that because the VM is developed in
Smalltalk both the pace and reliability of development is exceptional, and
I speak in the light of my own trivial experience with the BrouHaHa VM
which was implemented in C, a series of four VMs that grew out of my early
experience at RAL and undergrad student projects, and 12 years at
ParcPlace/DarcPlace-Dodgytalk/ObjectShaft/CincompletelyDysfunctional where
I architected a VM with the same closure model as we have now, and the
transition to 64-bits.

So VMMaker.oscog, in Squeak, is used to develop the VM, and from this C
source is generated that comprises one third of the OpenSmalltalk-VM
repository.  The other two thirds are
- a set of platform-specific support files that provide the OS-specific
implementation of facilities needed by the core VM, plus (importantly) the
implementation of many important plugins, such as the SoundPlugin
- a set of build environments to allow us to build on MacOS, WIndows,
Linux, Solaris (these are the active ones I'm aware of)

All work on the core VM (the core execution engine, including interpreter,
JIT, and core primitives and plugins, and the two memory managers, the old
V3, and the new Spur) is done in Smalltalk, and pushed to OpenSmalltalk-VM.
All work on the platform sources and build environments is done against the
OpenSmalltalk-VM repository.

Were it that Monticello had good file support I would have considered
moving the platform sources into Monticello form Subversion, instead of to
github.  But that would have been a mistake; the integration with modern CI
infrastructure is most important.  ANd in fact had those behind Tonel been
open at the time to make the inclusion of method timestamps possible I
would have (and still want to) moved the back end of the VMMaker Monticello
system into OpenSmalltalk-VM.  It makes sense to have all source
co-located.  What does *not* make sense is replacing the beautifully
integrated and efficient Monticello image experience with the nonsense I
see in Iceberg where one has to ape git, checking out a new branch first
before branching, etc.

So I have no objection to git/github as being a backend for Monticello.
But experience with Pharo and Iceberg, where the promise was made years ago
that a Monticello experience would be preserved, and has not been achieved
years later with considerable engineering effort available.  What they have
in Iceberg is, frankly, a mess where git's model and terminology intrude
into Smalltalk (I talk from experience having used it with Synchrony
Systems late last year/early this).


On Tue, Oct 6, 2020 at 3:48 AM Christoph Thiede <
christoph.thiede at student.hpi.uni-potsdam.de> wrote:

> Hi all,
>
> looks like I'm a bit late back to this debate again, but it's very nice it
> is still going on! There are many arguments I wanted to tell but Jakob
> already explained all of them better than I could do. So just let me come
> back to some points:
>
>
> Mantis:
>
> I just took another look at bugs.squeak.org again, and I'm sorry but I
> still
> think that our community deserves a better bug tracking solution than this.
> It really looks old-fashioned and, from today's point of view, quite
> chaotic
> and confusing. And compared to something like GitHub, it does not give me
> an
> idea of how to report a bug. Do I have to log in? Which credentials do I
> need to use? Why is there no register button anywhere?
> Also, there must be some reason why the latest issue was submitted nearly
> two years ago. Is Mantis connected to the mailing list at all? Asking all
> of
> you who have used Mantis in past and reported newer bugs to the mailing
> list
> instead, why did you do that? I would guess because mails provid higher
> visibility and interactivity, is this correct?
>
>
> Phil, you called GitHub & Co. one trend of many that's durability is
> uncertain (correct me if I misunderstood you). I see this point, but
> looking
> at the current numbers I strongly believe that GitHub has reached a
> critical
> mass of developers and projects that won't move so quickly again. How many
> large global players have decided to use GitHub, including competitors of
> Microsoft itself such as Google, Apple, Facebook, etc.?
>
> At least, according to the trends GitHub is way more popular than
> SourceForge, for example, has ever been, actually, it has even overtaken
> git
> itself on Google Trends:
>
> https://trends.google.com/trends/explore?date=all&q=github,sourceforge,gitlab,bitbucket,slack
>
> (By the way, if you search any old threads you can also find it on
> web.archive.org in most cases).
>
> > Here you're showing you've already fallen behind: the github trend for
> > discussing things is already fading and those trendier than you have
> > already moved on to the next thing: Slack  is where it's at!  In a year
> or
> > two it will be something else... and the treadmill keeps going but not
> > really going anywhere.
>
> Slack is a group messenger used for communication in small to medium teams,
> but I can hardly imagine someone seriously uses this as a bug tracker for a
> large-scale software project with a big community, there is just too much
> noise when pressing Enter sends a new message. The same goes for social
> media platforms such as Google Plus that do not even offer basic tracking
> features such as closing or labeling. I don't think you can compare this.
>
>
> > Monticello ancestry does support branching, yet I think Monticello lacks
> > first-class objects for branches, with all the implications for
> repository
> > handling.
>
> +1. And I feel the lack of branches for about every second or third
> submission I make to the inbox and am forced to reinvent my one pseudo
> branch wheel.
>
>
> Git vs. GitHub vs. GitLab:
>
> As Jakob already mentioned, they're not the same. I believe that GitHub
> offers the largest range by far, but personally I would still consider it
> as
> an improvement to set up a self-hosted GitLab instance (actually, from a
> technical point of view, I think GitLab offers even more convenience
> features for free).
>
> But still, it's right what Eliot said about git and companies:
>
> > One gives up great autonomy when allowing ones core VCS to be in a
> foreign
> > system
>
> So why do you use git & GitHub for OpenSmalltalk-VM and not something like
> Monticello?
>
> Which leads me to my most important point which Uncle Bob from Jakob's
> linked talk above gives this striking name to: elitism.
> In plain theory, I would consider it as an ideal, too, to have a Smalltalk
> system in which you can literally control every bit (ultimately, this might
> be a Smalltalk computer with no separate host system, where all drivers
> etc.
> are written in Smalltalk - completely neglecting every question of
> optimization). But in reality, the Squeak community, or even the entire
> Smalltalk community, is a quite small community, and I would love to change
> this and make Squeak/Smalltalk competitive again for contemporary
> development tasks, which involves the mutual boosting between
> tools/frameworks and developers. And because we are quite small at this
> point, we have two alternative ways we could go:
> Either we can spend our time on reimplementing every good and relevant idea
> from the "real world" in Squeak and making ourself even more comfortable in
> our small niche (which is, as I'm convinced, already very comfortable in
> many terms, compared to most other languages and environments); or we can
> join our forces and focus for now on opening our system towards the real
> world, both in terms of solutions and people. Which one would you choose?
>
> > Yet in my opinion Squeak really needs to get along with the outside world
> > for the mutual benefit; we cannot afford to always reimplement everything
> > in Smalltalk just to be able to comfortably debug the issues we wouldn't
> > have if we had used something mature.
>
> +1000
>
>
> Best,
> Christoph
>
> PS: And as a matter of course, I'm neither in the position nor willing to
> enforce any innovations that would deter some of our important community
> members from the Squeak Project. But I'm not giving up the hope that this
> discussion may reveal some more interesting insights about the desires and
> demands of us as a community. :-)
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201006/ef6a3d88/attachment.html>