tedious programming-in-the-debugger error needs fixing
Locked
123
123
Re: VM Development methodology (was: Development methodology, was: tedious programming-in-the-debugger error needs fixing)
 
|
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 <[hidden email]> 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 <[hidden email]> wrote: Hi all, _,,,^..^,,,_ best, Eliot |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Christoph Thiede
Hi Christoph, I answered your Q's about OpenSmalltalk in another thread. But to your other points, c below... On Tue, Oct 6, 2020 at 3:48 AM Christoph Thiede <[hidden email]> wrote: Hi all, I don't understand/ To branch all you do is add a dash and a name after the current branch. It seems to me that we want to surface that Monticello supports branches by - providing a branch button in the commit dialog which would provide a name template with the string '<branchname>' for one to edit - providing a "merge branch" operation that would offer only to merge the changes from the branch against the most recent common ancestor Git vs. GitHub vs. GitLab: I agree. But this is not about reinventing the wheel. This is about whether we discard a rather beautifully crafted wheel that is one of the main supports and propulsive engines we have for an uncertain future based on git. And I am not encouraged by the Pharo exerience. In Monticello we have something that works *very well*, something that can be extended quickly (look at Vanessa's beautiful selective check-in facility, which mimics git's add/reset staging functionality but in a much lighter-weight and better-integrated way, which Vanessa was able to implement quickly and which I believe involved a single commit for trunk and has worked flawlessly ever since). In git we have a massive dependence on a black box, which, if one looks at the Pharo community has changed entirely their SCM experience, and not for the better. So other than SCM, I agree we should not be reinventing the wheel. But in proposing we move to git you're actually suggesting we get rid of our wheels and go back to rolling logs...
_,,,^..^,,,_ best, Eliot |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Christoph Thiede
> On 2020-10-06, at 3:47 AM, Christoph Thiede <[hidden email]> wrote: > > 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. Nobody could ever look at Mantis and honestly call it 'good'. Our use of it pretty much faded away as it good flooded by bug reports that nobody had time to handle. As system like that takes too much effort to maintain unless you have people (like proper project managers etc) that can spend all their time tracking, pushing, tidying, linking, cleaning out and so on. Git as an entity has some decent aspects for dead-text systems. It can probably be pushed to handle storing code for our needs without breaking too badly. BUT there is no way in hell that its interface is sometihng one would want to intrude into a development system. That's about as good an idea as a commandline version of monticello - if the commands were entered in inverted Braille via dripping hot oil on the back of your hand. If someone can make a system that provides the reasonably decent user experience of MC (which could certainly be improved) and uses git related backend stuff, sure, go for it. But as a daily driver, it just doesn't do it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: XER: Exclusive ERror |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Eliot Miranda-2
Hi,
Now I do not know to which message to reply first :-) and unfortunately most of this is again not about the development process, but at least it is about the experience. I prefer Git over Monticello not only because Git is more wide-spread and has platforms available to support it. I marked some key points in bold in the following paragraphs in case you cannot afford to read all of it. Sorry to those on plaintext mail clients. *You can track more objects with Git* (or any unspecialized VCS) *than with Monticello.* As you confirmed Eliot, you cannot track files in Monticello. You also cannot track a Morph or a Readme in Monticello. Instead we need to squeeze everything into classes and methods. You can track anything with Git that you can transform into a tree of blobs. Including Smalltalk code, it is just a special case. Want a new kind of MCDefinition? Git does not care and will store it for you, whatever it is. Monticello, not so easy. (In the end in both cases you would probably have to write some kind of de/serialization to get something nice, but in Monticello you have to modify the VCS, whereas for generic systems you would extend "above" the VCS.) Using *Git does not imply that you have to use tools outside of the image*. And it does not mean to "be less Smalltalk". Eliot, you asked what I would do if I had unlimited resources. I would improve the Git Browser and accompanying tools so that one could do everything as comfortably as with Monticello, and yet be able to do more than Monticello allows. Well, depending on who you ask, the new tools have already surpassed the Monticello tools in some usability aspects, but certainly not in every way. ;-) But what I meant to say here is that *the long-time Monticello user should be able to feel "at home" even though the repository is a Git repository now*. Regarding the integration of code review, conversation etc. and the tracking of contributions, which got us going here, one can probably build this all in Squeak. There have been projects going in this direction in the past, right Tobias? ;-) With unlimited resources, I would also do that in Squeak because unlimited resources, especially time, means that I could patiently build all the middleware, connectivity, cloud-readiness and OS integration stuff that are more present in the Java, .NET, JavaScript, and Python ecosystems. Or I might try to give those other things more of a Squeak experience, which is one of the things I like about the work Fabio is doing about polyglot programming. Back to reality for now... Of course *it is possible to have domain-specific tools on top of Git* (or any other suitable, unspecialized VCS), to get a "Monticello expericence" (at least the good parts of it). "Git tools" do not need to stop at the level of file trees and branches of them. I have not used IceBerg myself Eliot, but it sounds like it is on the wrong level of abstraction for your taste. We can have "easy" yet rich and powerful tools in the image with just about any VCS, this is *not a conceptual monopoly of Monticello* (or at least it doesn't have to be). So in my opinion we should go with the most practical (to avoid saying "the best") VCS of the respective time. Squot is built with a certain degree of agnosticism toward the kind of repository, as long as it can store arbitrary objects. The Git Browser of course is somewhat specific to Git, as the name tells. For one because of Git-specifics like remotes, but also regarding the vocabulary on the buttons ("commit", "push", "pull"), to look familiar to Git users (of which there are arguably more than there are Smalltalkers). But we could create a different version of the tool that presents things differently, for sure. I think a "real" Git backend for Monticello is also feasible, now that we have a usable Git implemenation in Smalltalk already. That's why I brought it up at all. But it would still be a compromise because *Monticello has more quirks* than just being limited to the respective class hierarchy of MCDefinition. For one, there is this *awful implementation of storage* in Monticello, both on the disk and in memory. What a waste to store the whole snapshot again with each version. And how easy it is to have *a version in the middle of the history missing* from a repository, which makes "diffy versions" dangerous. Git's solution to that (but Mercurial would also be good enough there) is much more space- and time-efficient. You might object that you have to clone the whole Git repository (though there are ways out of that, Microsoft's vfsforgit <https://vfsforgit.org/> being one of them), but for the below-Enterprise-scale project it is just not a problem in Git! Copying the whole history of Squeak Trunk on the other hand will probably take longer than to clone an equivalent Git repository, and it will take up more disk space. Using Git as a backend could solve the efficiency problem in the repository, but *without core changes to Monticello itself, there would still be waste in the image*. This is the reason why we are asked to compress history through less granular commits and contribution reshaping. Quite extraordinary how our tool shapes our process! To refactor this for the better would mean to increase the complexity of Monticello, though. Just as Squot is definitely more complex than Monticello if you count all of Squot's parts (by the way, Squot still uses Monticello for package capturing, loading and image patching, but not the Monticello tools and not the ancestry implementation). Then there is the delineation of a project. In Monticello, you have to save each package of a project separately. And you may have to create a configuration map on top of that. *In Git* (or just about anything else) *you would just have multiple packages in the tree and save them all together*, and each commit constitutes an implicit configuration of the packages. I think this is a *tremendous advantage in usability*. Many projects consist of more than one package. Yet most of the time the -Core, -Test, -Fluff packages evolve simultaneously. This flaw of Monticello as I am willing to call it is at the core of its model, and therefore also its tools! ("Whew, does anyone remember which version of System corresponds to the changes in this Kernel version...?", because the System version didn't have a number yet when the Kernel version was saved, and therefore was not manually !!! referenced in the log message.) We already talked about branches. VMMaker is surprisingly just one package, therefore it is easier to create branches through the naming conventions of packages or versions. *Imagine you would have to care about the branch suffix for three or five, let alone 12 or 50 packages* to create and manage a branch of a project. Well, you could create a branched configuration map, but good luck for not letting stuff that belongs to the branch slip into a package that didn't initially get the new naming. Most of the time it seems easier to branch in Monticello by creating a separate repository to hold the branch. This is also something I would consider for a real Git-in-Monticello: to create a branch, create another repo (with the same Git backing); to "push", copy from a local repsitory to a remote repository (and also copy the ancestors along because everything else would be pointless); to merge, well merge the version from the other repo, be it local or remote. Yet this betrays the concept of a repository if you have multiple instances of the same one on your list of repositories. So it still feels like a workaround, just like relying on version name or package name conventions feels to me. I think this is where Eric Evan's book of Domain-Driven Design calls for "Making an implicit concept explicit". One might also say that branches are not a good idea anyway <https://trunkbaseddevelopment.com/> . That there should only be feature flags or really-short-lived branches that are quickly reviewed and then merged. But to have only short-lived branches without the overhead of actual branch management, *we would need better tools to track contributions and a commitment to process them quickly*! The last part might not be feasible even if we had the tools, because you currently cannot earn a living from maintaining and supervising Squeak Trunk development. And about feature flags: I hear we have too many preferences already? ;-) Now hitting "Post Message" before it's 3 a.m. again... Kind regards, Jakob -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
Am Di., 6. Okt. 2020 um 23:03 Uhr schrieb Jakob Reschke
<[hidden email]>: > I marked some key points in bold in > the following paragraphs in case you cannot afford to read all of it. Sorry > to those on plaintext mail clients. Haha, Nabble converts everything to plain text with some markup anyway. So look out for the *text between asterisks* if you are in the target audience. |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda-2 wrote
> In git we have a massive dependence > on a black box Just to make sure it's noticed, once again in a separate email: We have a usable Git implementation in Smalltalk by now. Not complete, but serviceable. If by black box and dependence you mean that we cannot simply turn the Git interfaces and protocols around, true. But we also don't do that in Monticello, and Monticello is simply not spoken by anyone else. -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda-2 wrote
> On Mon, Oct 5, 2020 at 12:18 PM Jakob Reschke wrote: > >> So either we have that true Git adapter for Monticello (then we would >> also >> not need our own server implementation), or the server has a Monticello >> frontend in front of the Git backend. >> > > If you were architecting this on a tight budget, which would you choose > and why? This one I didn't answer. Starting from what we have today, I would just remove some big dents from the Git Browser and try to create that differently looking GUI variant of it for the "Monticello appeal". Because this does not have the flaws of Monticello I mentioned, but it can have all its benefits, and much of the work has been done already. Alternatively, try to get this MCGitRepository underway, so you can enjoy whatever you like about the Monticello tools and despise about the Git tools (those in the image, not on the command line), and we could still profit from pull requests etc. on platforms like GitHub, or other kinds of Git integrations. One positive thing about this approach is that it should be possible to copy versions between Git repositories and Monticello repositories as we know them today. The big downside for me in this is that I suspect many will then not even look at the alternative tools and their benefits. On a tight budget, I think the Git server in Smalltalk is not really feasible in a way that it provides any benefit over a self-hosted GitLab. -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Phil B
Phil B wrote
> I do very much doubt the durability > of github issues, especially given github's corporate ownership. I think we should focus more on pull requests, not bug reports, and quick wins, even if temporary. If pull requests were no longer free on GitHub (which would mean to cut away the prime feature around which that platform originally revolved), so be it. We could then still push the code somewhere else and return to another tool or process. The benefit of using GitHub would be to get an improvement in contribution tracking *now* (or, rather quickly) without the investment of setting up a custom GitLab and spending the money on additional hosting resources if necessary, or developing a custom Monticello solution. Phil B wrote > There have been numerous times in the past when 'everyone' (esp. major > companies) flocked to things because they had achieved critical mass and > weren't ever going to go away. Visual Basic and Java come to mind. Java is very much alive in the enterprise and still looks like it isn't ever going to go away. Unfortunately, C isn't going away either. ;-) -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
On 06/10/2020 22:43, Jakob Reschke wrote:
> The benefit of using GitHub would be to get an improvement in contribution > tracking *now* (or, rather quickly) without the investment of setting up a > custom GitLab and spending the money on additional hosting resources if > necessary, or developing a custom Monticello solution. There are also many other self hosting choices available like gitea which aren't as heavyweight as GitLab. |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Jakob Reschke
Hi Jakob, Sorry, I was delayed, getting caught up and finally swung back around to this thread.. I suppose many of us drawn towards Git instead of Monticello find Monticello Like what? Please don't say branches. It supported it well-enough for the few times our small community used them. The alternative or improvement needs not
I wanted to grok git by approaching it via its public API. With my new GraphQL expertise, I figured I could spank out a client prototype in an evening. Then I found the schema: and the project was instantly shelved. Why so many types? I think due to the many "social" features that I don't really care about. Monticello does everything I want in only a few pages of code. It's easy to understand and has been relatively easy to extend, so I've stuck with it so far. I'm not against Git, I just haven't been sufficiently interested by it yet. The basics are really "index" or staging area of Git in the Git Browser tools. Git vocabulary is A lot of extra, ignorable features, basically is the definition of over-engineered. Don't get me wrong, it's a great tool for developers with your level of expertise. I'm more of a "user", though, the extra stuff is harder for me. In other ways, Monticello just looks simpler because something is in fact missing. Consider branches: most Git tools have knobs to deal with them in Monticello ancestry does support branching, yet I think Monticello lacks Support for branching was added to Monticello in 2012. See MCVersionNameTest>>#testBranches. Eliot used them during development of cog or spur, but I'm not aware of this feature having been all that critical for Squeak. We tend to like just one master branch with occasional releases. But, it's there and basically achieves the needed functionality. That we were able to even add such functionality highlights one often-overlooked advantage of maintaining control over one's own software destiny. I guess this isn't the case with Github, and yet the demand for more features from the diverse hoards of developers requires it to be all things to all of them. Hence, it's beastly complexity. Chris Muller-3 wrote I thought the social benefits (exposure and growth, I guess) were via exposure to the github user base. If we hosted ourselves, would it be any different than the "deserted island" situation we have now? That's all what I was referring to. I thought the purpose was for the exposure. If you have to host yourself anyway then we're basically down to a tool comparison? Chris Muller-3 wrote > For example, you could submit an It's public read, anyone can access the code and submit improvements to the Inbox. But, I agree, it'd be nice if there were a way for strangers to contribute more obviously. One idea would be for each SqueakSource repository to have it's own internal "Inbox" Repository to support some of these features... Chris Muller-3 wrote Yes, these are just loose ideas conjured in 10 seconds. The point is Monticello is relatively small, simple, and malleable, and this makes it feasible to improve, even if getting it implemented requires writing email. Monticello does suffer from some scalability issues that will eventually need to be addressed. But the redundancy among versions is a feature, not a flaw. To this day, planes have poor internet access, this redundancy is about availability. In the Magma-based, there is only one instance of each MCDefinition shared amongst all Versions, but not everyone set that up on their laptop (I made it as easy as I could). Chris Muller-3 wrote > We have *decades* of Monticello packages for Squeak across not just our I agree. It wasn't meant to be an argument against anything. As we already see in practice, Great! Please don't mistake my lack of interest as "opposition". Chris Muller-3 wrote What I had wanted to do start by sucking in their GraphQL schema into my fantastic new GraphQL Engine, and map their types to the Monticello types. Basically appear to BE a Git server, but mapped behind the scenes to legacy MC repos that could be accessed via the legacy way, for users that wanted to. Alas, the schema is longer than War and Peace. Chris Muller-3 wrote If you're interested in collaborating on my above idea of hosting our own server based on their v4 GraphQL API, but with an MC+ backend, I believe my GraphQL engine is ready. If you know the essential parts of the Git model well enough to know how to hook it up to a MC backend, I could fully support the GraphQL parsing and processing aspect. Email me if you're interested. - Chris |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Jakob Reschke
Hey! Just for fun, I parsed that schema to see if it would help looking at it in a Squeak ObjectExplorer. Mmmm.. a little, but not really... It's the sheer volume, check out the attached screenshot. I looked for something basic sounding, and came across "User". Look, it has 64 fields! :-o And this is just one of 978 types in total. If you can figure out which of these to map to Monticello's 40 (or whatever it is) types, you could use this parser and Engine in combination with WebServer to host a Git server with MC backend.. MC users could ignore git, while Git users could ignore MC. :-D To me, it looks very intimidating, though...  On Mon, Oct 5, 2020 at 1:47 PM Jakob Reschke <[hidden email]> wrote: Hi Eliot, |
Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)
|
|
In reply to this post by Chris Muller-3
Hi Chris,
Thanks for still participating! Am Fr., 9. Okt. 2020 um 01:33 Uhr schrieb Chris Muller <[hidden email]>: >> >> What exactly do you think is so massive about Git? > > > I wanted to grok git by approaching it via its public API. With my new GraphQL expertise, I figured I could spank out a client prototype in an evening. Then I found the schema: > > https://docs.github.com/en/free-pro-team@latest/graphql/overview/public-schema > Oh, the GitHub GraphQL API is definitely not Git! Git has nothing to say about GraphQL, nor does it say anything about issues, apps, gists, reactions, pull requests, ... just to name a few. > > A lot of extra, ignorable features, basically is the definition of over-engineered. Don't get me wrong, it's a great tool for developers with your level of expertise. I'm more of a "user", though, the extra stuff is harder for me. > Git was built with some technical goals in mind and a sane user interface appeared only gradually over its first years. That supports your impression. Alternative user interfaces have been suggested on top of the data model. https://gitless.com/ for example. The Git Browser uses some of its concepts, such as not having a staging area and selecting what's in and out of a commit while creating the new version, just like Monticello. Gitless is just a different command line UI, everything that is going on in the repository is just the same. Like TortoiseGit and the Git Browser are just different graphical user interfaces, the former for files, the latter for objects. Conclusion: the "extraneous" features of the tools serve a purpose in their specific context. Since we have a different context, we will build different tools of course. That does not remove any of the advantages of using Git as a repository, or versions database if you will. A database with advanced tool support out in the world for various needs, such as collaboration supported by platforms like GitHub. That is an option, but it can be a useful one. I would like to make a pun of the "ignorable" features: the Git index or staging area, for example, is a means to achieve the partial commit feature that Eliot mentioned Vanessa has added to Monticello (i. e. the "ignore" feature). But the Git command line user interface lives in a world of bytes, text, and files (instead of specialized objects) and command lines (instead of graphical tools). You could say that this ignore variable of the MCSaveDialog is the negated equivalent of the index. > > Support for branching was added to Monticello in 2012. See MCVersionNameTest>>#testBranches. Eliot used them during development of cog or spur, but I'm not aware of this feature having been all that critical for Squeak. We tend to like just one master branch with occasional releases. But, it's there and basically achieves the needed functionality. > But it is a hidden feature because nothing in the UI indicates its existence, right? This makes it harder to use. Also it is piggy-backed on a different concept (version names), that's why I consider this a workaround about the limitations of the data model. Also your statement does not address the problems of branching in a multi-package project that I wrote about in the earlier long message. > > I thought the social benefits (exposure and growth, I guess) were via exposure to the github user base. If we hosted ourselves, would it be any different than the "deserted island" situation we have now? That's all what I was referring to. I thought the purpose was for the exposure. If you have to host yourself anyway then we're basically down to a tool comparison? > You do not *have to* host yourself. :-) But you could if you don't trust the corporate (yet very open-source-supporting) GitHub. The social benefits of exposure do also exist, but it was not in the focus of this thread. That was an improved development process with regards to the easier tracking of contributions. For example, if you re-work your inbox submission and create another version, it will open another thread on the mailing list, with no traceable connection to the previous conversation. Not so with pull requests on GitHub (or whatever they are called on the alternatives to GitHub), if you update your submission on the same branch (even if you replace the commits that you sent before), the old conversation is still attached to the pull request. By the way, that is something you could trace via that exhaustive GitHub GraphQL API if you wanted to build a Squeak interface to GitHub pull requests. ;-) Sure it seems overwhelming, but who says that you have to consume and support it all? It just offers a lot of options, at your service... I don't think this is a bad thing. >> >> Chris Muller-3 wrote >> >> > For example, you could submit an >> > improvement that allows original contributors of Inbox items to move them >> > to Treated themself. >> >> How? Only Trunk committers have access to the Squeaksource treating backend, >> so neither the code nor the tool is available to normal users for >> improvement. Guest users cannot even delete versions from the inbox >> repository, can they? > > > It's public read, anyone can access the code and submit improvements to the Inbox. But, I agree, it'd be nice if there were a way for strangers to contribute more obviously. One idea would be for each SqueakSource repository to have it's own internal "Inbox" Repository to support some of these features... > That would be a nice first step towards something like pull requests for projects other than Trunk. But you didn't address that submitters cannot move their own contributions to Treated, even if they wanted to. > > The point is Monticello is relatively small, simple, and malleable, and this makes it feasible to improve, even if getting it implemented requires writing email. > Tools on top of the Git data model would also be malleable. Writing email is not the primary issue here (except for the generational favoring of platforms over mailing lists maybe). Integrating the conversation with the code contributions is. As we said, if we were to use GitHub, we should make sure to tie in the conversations there into the mailing lists, just like it has been done for OpenSmalltalk-VM. > Monticello does suffer from some scalability issues that will eventually need to be addressed. When is the eventual time? Git is one possible solution to the scalability problem. One solution where you don't have to reinvent the hosting software. One solution that already has a pure-Smalltalk implementation. > > But the redundancy among versions is a feature, not a flaw. To this day, planes have poor internet access, this redundancy is about availability. In the Magma-based, there is only one instance of each MCDefinition shared amongst all Versions, but not everyone set that up on their laptop (I made it as easy as I could). > Git uses similar value object sharing in its data model. :-) And if you clone a Git repository, you have it right on your laptop. If you download a single Monticello version and go offline, you just have one snapshot and an ancestry where you cannot look at the past snapshots. With a Git repository, you typically have everything at your hands. Of course you shouldn't clone the repository just to install some package (as opposed to develop it). The download-to-install use case is typically satisfied by explicit releases where you put an archive or installer somewhere. Monticello also fills this role currently, next to SqueakMap. In the Git world, there are typically web interfaces that allow you to download just one particular snapshot. Metacello uses the particular HTTP interface of GitHub to download a zip, for example. > > What I had wanted to do start by sucking in their GraphQL schema into my fantastic new GraphQL Engine, and map their types to the Monticello types. Basically appear to BE a Git server, but mapped behind the scenes to legacy MC repos that could be accessed via the legacy way, for users that wanted to. > Hmm this breaks down because that schema is not just about Git, it is also about all of GitHub as indicated above. So your server that implements the whole schema would really be another GitHub server, not another Git server. The basic objects of Git are just blobs, trees, commits, tags, and refs. But this is not the abstraction level of an MCDefinition. There is no point to have an MCTreeDefinition. Instead you would map your MCSomethingDefinition into a tree of blobs and store that in the Git repository. Blobs, trees, and commits would be handled by the MCRepository subclass and something like the MCWriters and MCReaders instead. Does this make sense to you? To be a Git server, you need to be able to manipulate repositories and to provide the fetch and push interface. For repositories, the Smalltalk code is already there. For the interface, only the client side of the protocols is implemented in Smalltalk yet. Kind regards, Jakob |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |