Juan, you've made some interesting points here. I see some of your reasoning more clearly now. I think the problem with the warnings had to do with my not understanding some design constraints clearly, and this clarifies; also, sorry if I offended, that was definitely not my intent. Sometimes I come off as ranty when I don't mean to: mea culpa.<br>
<br>Comments inline.<br><br><div class="gmail_quote">On Wed, Jan 2, 2013 at 7:07 AM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok. This will be long :)</blockquote><div><br></div><div> Yep:)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Casey Ransberger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now that I've wrapped my head around the new Git Cuis dev model, I would recommend grabbing a healthy supply of torches and pitchforks, because I think I'm reaching for a Third Option here. So we're all on the same page about what that means:<br>

<br>
<a href="http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption" target="_blank">http://tvtropes.org/pmwiki/<u></u>pmwiki.php/Main/<u></u>TakeAThirdOption</a><br>
</blockquote>
<br></div>
Thanks for the link. Sometimes I have trouble following the stuff you quote.</blockquote><div><br></div><div>I should work on that. I use too much slang at times.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I thought about sending this straight to Juan, but why not, whole list. I expect that Juan's arguments will be interesting in this case.<br>
<br>
Alright! What do we really need changesets for then? Why not make developing the core the same as developing anything else? So if we killed changesets:<br>
</blockquote>
<br></div>
Ok. It is a good question. I'll interleave some comments on your Cons/Pros, and then add mine.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cons:<br>
<br>
- We'd have to engineer our way around the "breaking the update stream" problem. This is work, but I'm sure it's doable. I did it once:) and ContentPack happened because I needed to do a spot of time travel to fix the update stream after I broke it. If I can travel through time, I'm pretty sure we can handle a bootstrapping problem. Especially given that we have the computational equivalent of a TARDIS at our disposal.<br>

<br>
- Cuis now depends completely on Git. Note: Git is *extremely popular,* not likely to go the way of the dodo any time soon, and maintained like the Linux kernel matters to Linus. Also, switching to another SCM should be relatively trivial when necessary, if not painless. And: Git presently runs most places where Cuis runs.<br>

</blockquote>
<br></div>
Ehhh. No. Cuis doesn't depend on Git at all. We use Git as a shared, universally accessible repository. We also use it to version files, and to ease teamwork. But Cuis is not tied to Git. All Cuis needs is a local file system to store files (obviously, a local clone of a Git repository works).</blockquote>
<div><br></div><div>This makes sense.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Stuff I've missed.<br>
</blockquote>
<br></div>
I add some cons. But before that, I see two ways here. One is to have a really small kernel, and load stuff to build images (the Pavel way). The other one is to have a bigger image, with packages always loaded, and load new versions of packages on top of old ones to update the images (the Squeak way). So:<br>
</blockquote><div><br></div><div>Ahh, I hadn't thought about that in this context. It seems to have been a prominent question in recent times. Monolithic vs. minimal. I favor the latter, though I'll admit that I don't have a clear idea about how to arrive there. Fortunately, Cuis is already very small, so it's less of a pressing concern than it is in e.g., Squeak.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=== Cons (a) miniKernel + loadable packages. Pavel's way:<br>
<br>
- The artefact is no longer a Smalltalk-80 system. This is very important to me. Smalltalk-80 is a huge landmark in the history of computing. One of the main reasons I do Cuis is to preserve and spread this legacy. This is the best tribute I can do to Smalltalk-80 and its developers.<br>
</blockquote><div><br></div><div>:) And a fine tribute it is! I don't think I follow this completely though. It's still the same system which came from PARC. To my mind, if you unload the system browser, and then load it back in, it's still the same system -- kind of like when the image was run through the tracer to get a 64-bit image: it's a different representation of the object memory, but still the same system in spirit.</div>
<div><br></div><div>So I also think maybe I ought to talk about *why* I'd like to be able to unload things like the UI: mainly for headless web servers, or REST services in the backend of some big iron system. When you're e.g. <a href="http://whitepages.com">whitepages.com</a>, the sheer amount of traffic means you end up with a fleet of servers, and there start to be arguments about how to squeeze the best performance out of them. This has a nasty way of ending in Java. Morphic does stuff: and stuff takes time and electricity. In applications that don't need it, there are arguments for and against having it there. For: I can grab the image from the borked server and have the debugger open and waiting for me. Against: expensive compute resources that I probably don't need to be spending on.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Not having the dev tools in the image makes modifying it harder.<br></blockquote><div><br></div><div>Ah! Okay *now* I think I see where you're coming from. Right! I mean I wouldn't recommend programming in bytecode or anything:) and I'm not saying that we should develop in what's basically an OS kernel. Definitely our development images should have the same set of great tools we've got in there right now. But I *would* honestly prefer to build the image up from its component parts when we ship.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- We're not showing newcomers the beauty of the Smalltalk system, but just a bunch of files they need to 'make' in order to have something useful.<br></blockquote><div><br></div><div>Again, this isn't my intent. I very much want folks to see the whole system when they come to it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The mini-kernel will also need modifications from time to time. How do we do that? With ChangeSets?<br></blockquote><div><br></div><div>I knew you were going to go there:) and I'm pretty sure there's a way to bootstrap around that using purely git; this is the hypothetical "dependence" on git that I was talking about originally. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Maintenance will take more work. We'd need procedures to update or re-create the kernel, build the distributions, QA them, etc.<br></blockquote><div><br></div><div>Yeah. And maybe that actually doesn't make sense. To me, this sounds like the "right" way to do it, but some of that may just be dogma that I've been indoctrinated with. I definitely *don't* want to create painful, unnecessary human process. This is an excellent point, Juan.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- As the only way to update an image is to rebuild it from scratch, people wouldn't be able to update their own images. To allow for this, we also introduce the Cons of (b), below.<br></blockquote><div><br></div><div>
There's one that I didn't think of. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=== Cons (b) Packages always loaded. Squeak's way:<br>
<br>
- We'd need a package loader with atomic loading. Squeak doesn't yet have it, after a decade of using Monticello.<br></blockquote><div><br></div><div>Wait -- for some reason I don't think this is true any more. I thought they added atomic loading in Squeak's MC implementation a bit ago. I could be wrong, though. Anyhow, good point. There's a pile of work there.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- We'd need version, dependency, and version dependency control. Otherwise, it is not just optional package loading that becomes fragile, but the base system itself.<br></blockquote><div><br></div><div>We get the versioning part from Git right? And I think the dependency control part might be undecidable with dynamic typing. I think that part is a problem with all dynamic languages. There's no way to know for sure what depends on what, but I definitely see your point. And destabilizing the base unnecessarily is a bad plan. Point taken.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- It would be difficult and dangerous to update the Kernel and PackageLoader packages.<br></blockquote><div><br></div><div>Until we found a way to do it safely. Big pile of work. Totally.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

- In Squeak, we end having package postcripts, and strict load ordering of package version. Loading intermediate versions is required. There is, after all an update stream, but instead of a small set of changes, each update includes all the code. It becomes an huge monster that nobody can audit.<br>
</blockquote><div><br></div><div>Git changes are deltas. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Updating an image becomes muuuuuuch sloooooweeer.<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- When updating an image it is much harder to understand what happened, to adapt our code.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pros:<br>
<br>
- No more confusing dichotomy between what's core and what isn't; everything becomes a package, and lives in whatever repository is appropriate. Symmetry. Exactly one way to manage code. Kernel can be reduced to a bloody stump which has the singular ability to load in other packages (attach limbs.) Epic win for modularity.<br>

<br>
- No more annoying dialogs about unsaved changes in core when there aren't actually any. Everything is a package, so there isn't a distinction. We don't need a special method to determine what's part of core and what isn't WRT the warnings about unsaved changed. Elegance, symmetry, less blivet to worry about.<br>

</blockquote>
<br></div>
This is unfair. I answered (I believe twice) about your concerns with those warnings, but didn't get a response from you! Please, let's discuss those warnings in a separate thread. If we have some use case(s) and some discussion, I believe we'll clarify any doubts and come up with something that works well for everybody.</blockquote>
<div><br></div><div>I thought I replied to that, but it's in my drafts. Oops. Also, I'm sorry about the way I phrased that. The short version of what I said was "I get it now, and yes, the change you suggested does make sense." If I'd sent that, I think this statement might have made a bit more sense. I brought it up here because what I was suggesting seemed to obviate that work.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- We can completely unload (at least a lot) of the changeset handling machinery*<br>
<br>
- Smalltalk effectively becomes a peer to kernels which manage code in files, which makes us a lot less of a scary monster to newcomers.<br>
<br>
- Stuff I've missed.<br>
<br>
*Actually, I could be wrong about this part. Probably the Git stuff is using a lot of it. But I'll bet a single US dollar against the first of you who says killing changesets won't eliminate some net (as opposed to "gross") code, even if I might lose a dollar for dreaming too hard.<br>

</blockquote>
<br></div>
We can see Squeak's experience with eliminating ChangeSets, and Pharo's experiments with Pharo-Core. Let's learn from them.</blockquote><div><br></div><div>Totally! </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I mean, why do anything halfway;) ?<br>
<br>
Okay, so I'm totally locking the doors. It's always raining in Seattle, so rebooting the Frankenstein monster shouldn't be hard, I just have to wait for some lightning. If you try creeping up on me, I'll be able to see your torches, so that's not gonna work. Email is the best plan!<br>

<br>
I can't wait to see what people think about this. Really, it's about whether or not managing code is or is not Smalltalk's problem in the modern world: and that's a hell of a question to talk about, or I think so. I think it's genuinely an important, and open question, specifically in this small community.<br>

</blockquote>
<br></div>
Sure.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At this point, we're almost more of a quorum than a community, and so: if we want to do this, we might be able to tackle it, if we as a group found it sensible, before senseless convention takes over and becomes effectively permanent, rigid.<br>

</blockquote>
<br></div>
I agree. This is the best time to evaluate all possible options.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay now's the time to use your torches and pitchforks. I'll be hiding under the couch. In an unspecified apartment in Seattle. Go.<br>
</blockquote>
<br></div>
:) I hope tolerance and respect for everybody's freedom wins.<br></blockquote><div><br></div><div> I was joking about the torches and pitchforks!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Cheers,<br>
Juan Vuletich<div class="im HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
P.S.<br>
<br>
I presently have low confidence that ContentPack still works right presently:( and I'm okay with that, but either I've got to fix it or we should unload it and move on.<br>
<br>
-- <br>
Casey Ransberger<br>
</blockquote>
<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org" target="_blank">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/<u></u>listinfo/cuis_jvuletich.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger