Why not just kill changesets?
Locked
Why not just kill changesets?
 
|
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:
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: Cons:
- 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.
- 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.
- Stuff I've missed. Pros: - 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.
- 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.
- We can completely unload (at least a lot) of the changeset handling machinery* - Smalltalk effectively becomes a peer to kernels which manage code in files, which makes us a lot less of a scary monster to newcomers.
- Stuff I've missed. *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.
I mean, why do anything halfway;) ? 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!
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. 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.
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. P.S. 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.
Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
On 1/2/13, Casey Ransberger <[hidden email]> wrote:
> 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: > > http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption > > 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. > > 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: > > Cons: > > - 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. > > - 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. > - Stuff I've missed. > > Pros: > > - 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. My first reaction. ChangeSets are patches and patches and core goes together fine, right? However I agree that the core should be made smaller. See my suggestion about removing Morphic and having only a two-pane GUI from which to load a Morphic.pck.st file. For convenience I attach the screen shot again. Then at least change sets regarding Morphic would be eliminated. Of couse the first thing people have to do then is to run load scripts to get a useful image to work with. > - 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. At the moment I do not have too much problems with this. But you are right, the question is: how can we make better of github. As discussed just these days, we need some time to get used to the new model of working with github. Suggestion: Investing time for git learning is surely not wasted (at least 5..12 hours ). We can do mini-examples on github with repositories we fork and later delete again. Such a mini-example could be to unload all tests into their corresponding *Test*.pck.st packages hosted on github (in a branch of the main Cuis) This would avoid having test updates in the core change sets. > - We can completely unload (at least a lot) of the changeset handling > machinery* Not instantly, maybe later :-). I do not think it is all that much code but I have not checked. > - Smalltalk effectively becomes a peer to kernels which manage code in > files, which makes us a lot less of a scary monster to newcomers. Sure, and in fact this is not so new at all see https://github.com/bonzini/smalltalk A 1200 classes image is a bit daunting whereas a 500..600 classes image is much less. As it was in the olden days (e.g. Smalltalk V/ for DOS). Thus all these efforts of 'Little Smalltalks' etc. Did somebody check recently how many classes the basic GNU Smalltalk image has? > - Stuff I've missed. > > *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. > > I mean, why do anything halfway;) ? > > 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! > > 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. 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. > > 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. > > P.S. > > 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. Maybe it is and Juan has updated it when doing 4.1 --Hannes _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
ProposalForMinimalMorphicGUIforCuis4.1.png (45K)
Re: Why not just kill changesets?
|
|
P.S. Actually what we should do is an analysis how many classes we
have per class category in the Cuis core and which categories besides the test categories are candidates for offloading into a *.pck.st file (as for example sound). Could somebody paste a code snippet which does this please? SystemOrganizer new categoriesMatching: 'Tests' gives a walkback.... Having more *.pck.st files and less classes in the core would reduce the frequency of change sets for the core as there is less to fix. --Hannes On 1/2/13, H. Hirzel <[hidden email]> wrote: > On 1/2/13, Casey Ransberger <[hidden email]> wrote: >> 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: >> >> http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption >> >> 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. >> >> 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: >> >> Cons: >> >> - 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:) > > How did you do it at that time? > > 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. >> >> - 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. > > OK > >> - Stuff I've missed. >> >> Pros: >> >> - 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. > > My first reaction. ChangeSets are patches and patches and core goes > together fine, right? > > However I agree that the core should be made smaller. See my > suggestion about removing Morphic and having only a two-pane GUI from > which to load a Morphic.pck.st file. > > For convenience I attach the screen shot again. Then at least change > sets regarding Morphic would be eliminated. Of couse the first thing > people have to do then is to run load scripts to get a useful image to > work with. > > > > > >> - 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. > > At the moment I do not have too much problems with this. But you are > right, the question is: how can we make better of github. As > discussed just these days, we need some time to get used to the new > model of working with github. > > Suggestion: Investing time for git learning is surely not wasted (at > least 5..12 hours ). We can do mini-examples on github with > repositories we fork and later delete again. > > Such a mini-example could be to unload all tests into their > corresponding *Test*.pck.st packages hosted on github (in a branch of > the main Cuis) This would avoid having test updates in the core change > sets. > > >> - We can completely unload (at least a lot) of the changeset handling >> machinery* > > Not instantly, maybe later :-). I do not think it is all that much > code but I have not checked. > >> - Smalltalk effectively becomes a peer to kernels which manage code in >> files, which makes us a lot less of a scary monster to newcomers. > > Sure, and in fact this is not so new at all > see https://github.com/bonzini/smalltalk > > A 1200 classes image is a bit daunting whereas a 500..600 classes > image is much less. As it was in the olden days (e.g. Smalltalk V/ for > DOS). Thus all these efforts of 'Little Smalltalks' etc. > > Did somebody check recently how many classes the basic GNU Smalltalk image > has? > >> - Stuff I've missed. >> >> *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. >> >> I mean, why do anything halfway;) ? >> >> 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! >> >> 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. 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. >> >> 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. >> >> P.S. >> >> 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. > > Please see my other thread, I'd like to have it working..... :-) > Maybe it is and Juan has updated it when doing 4.1 > > > --Hannes > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
H. Hirzel wrote:
> P.S. Actually what we should do is an analysis how many classes we > have per class category in the Cuis core and which categories besides > the test categories are candidates for offloading into a *.pck.st file > (as for example sound). > > Could somebody paste a code snippet which does this please? > > SystemOrganizer new categoriesMatching: 'Tests' > > gives a walkback.... > > Something like SystemOrganization categoriesMatching: '*Test*' ? > Having more *.pck.st files and less classes in the core would reduce > the frequency of change sets for the core as there is less to fix. > > --Hannes > Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
In reply to this post by Casey Ransberger-2
Ok. This will be long :)
Casey Ransberger wrote: > 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: > > http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption Thanks for the link. Sometimes I have trouble following the stuff you quote. > 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. > > 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: Ok. It is a good question. I'll interleave some comments on your Cons/Pros, and then add mine. > Cons: > > - 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. > > - 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. 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). > - Stuff I've missed. 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: === Cons (a) miniKernel + loadable packages. Pavel's way: - 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. - Not having the dev tools in the image makes modifying it harder. - 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. - The mini-kernel will also need modifications from time to time. How do we do that? With ChangeSets? - Maintenance will take more work. We'd need procedures to update or re-create the kernel, build the distributions, QA them, etc. - 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. === Cons (b) Packages always loaded. Squeak's way: - We'd need a package loader with atomic loading. Squeak doesn't yet have it, after a decade of using Monticello. - 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. - It would be difficult and dangerous to update the Kernel and PackageLoader packages. - 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. - Updating an image becomes muuuuuuch sloooooweeer. - When updating an image it is much harder to understand what happened, to adapt our code. > Pros: > > - 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. > > - 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. 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. > - We can completely unload (at least a lot) of the changeset handling > machinery* > > - Smalltalk effectively becomes a peer to kernels which manage code in > files, which makes us a lot less of a scary monster to newcomers. > > - Stuff I've missed. > > *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. We can see Squeak's experience with eliminating ChangeSets, and Pharo's experiments with Pharo-Core. Let's learn from them. > I mean, why do anything halfway;) ? > > 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! > > 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. Sure. > 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. I agree. This is the best time to evaluate all possible options. > 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. :) I hope tolerance and respect for everybody's freedom wins. Cheers, Juan Vuletich > P.S. > > 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. > > -- > Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
In reply to this post by Casey Ransberger-2
My take on the core is that it should be like the VM, a set of coherent services which everyone can count on. A baseline and interface.
My experience with Tektronix's Smalltalk is to observe that many people made changes to the core with the result that any attempt to merge results together broke things. So to extend the stump metaphor, people made limbs that required a stronger heart, lungs, and so forth but when others wanted to use a new limb other limbs did not match up with changed arteries. Wow, that was an incredibly bad attempt at an explanation. 8^( What I should say is that having a single coherent baseline is incredibly important for rapid progress. I don't mind that the baseline itself changes and evolves, but the evolution must had a common, single thread. I also like building the core from source, rather than just evolving images, but I want to assume and start from the core and not have to assemble it each time. As you can see, I have not yet had my coffee today. Apologies for the poor communication attempt. -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: Why not just kill changesets?
|
|
In reply to this post by Juan Vuletich-4
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.
Comments inline. On Wed, Jan 2, 2013 at 7:07 AM, Juan Vuletich <[hidden email]> wrote: Ok. This will be long :) Yep:)
I should work on that. I use too much slang at times.
This makes sense.
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.
=== Cons (a) miniKernel + loadable packages. Pavel's way: :) 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.
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. whitepages.com, 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.
- Not having the dev tools in the image makes modifying it harder. 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.
- 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. Again, this isn't my intent. I very much want folks to see the whole system when they come to it.
- The mini-kernel will also need modifications from time to time. How do we do that? With ChangeSets? 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.
- Maintenance will take more work. We'd need procedures to update or re-create the kernel, build the distributions, QA them, etc. 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.
- 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.
There's one that I didn't think of. === Cons (b) Packages always loaded. Squeak's way: 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.
- 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. 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.
- It would be difficult and dangerous to update the Kernel and PackageLoader packages. Until we found a way to do it safely. Big pile of work. Totally. - 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. Git changes are deltas. - Updating an image becomes muuuuuuch sloooooweeer. Agreed. - When updating an image it is much harder to understand what happened, to adapt our code. 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.
Totally!
I was joking about the torches and pitchforks! Cheers, Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
In reply to this post by KenDickey
Hi Ken,
(inline) Ken Dickey wrote: > My take on the core is that it should be like the VM, a set of coherent services which everyone can count on. A baseline and interface. > > My experience with Tektronix's Smalltalk is to observe that many people made changes to the core with the result that any attempt to merge results together broke things. > > So to extend the stump metaphor, people made limbs that required a stronger heart, lungs, and so forth but when others wanted to use a new limb other limbs did not match up with changed arteries. > Yes. The same happens today. The best we can do is to integrate as early as possible. That's why the trunk was so good for Squeak. In Cuis, we also want to integrate contributions early, and discuss enough about changes that could affect compatibility with other ongoing efforts. It might happen that some people want to do changes that are irreconcilable with what others are doing. That's the main reason for forks. Like Tweak, Cuis and Pharo. > Wow, that was an incredibly bad attempt at an explanation. 8^( > > What I should say is that having a single coherent baseline is incredibly important for rapid progress. I don't mind that the baseline itself changes and evolves, but the evolution must had a common, single thread. > Agreed. > I also like building the core from source, rather than just evolving images, but I want to assume and start from the core and not have to assemble it each time. > Me too. > As you can see, I have not yet had my coffee today. > > Apologies for the poor communication attempt. > > -KenD > > :) I think you made your point. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Warnings on image save (was Re: Why not just kill changesets?)
|
|
In reply to this post by Casey Ransberger-2
Hi Casey,
(inline and abridged on subject) Casey Ransberger wrote: > 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. Hey, don't worry. Maybe I overreacted a bit, or I made it look like that. > ... > > > - 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. > > > 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. > > > 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. > This is what I'm coding right now: On quit without save: - Warn about unsaved packages (if you don't save them, you might need to go to the .changes file to recover your work) - Warn about unsaved changes to core (if you don't save them, you might need to go to the .changes file to recover your work) On quit and save: - Don't warn about unsaved packages. You can save them anytime. - Do warn about unsaved changes to core (the change set will be removed, so you'll need to gather them if you want to publish them or update other images). Does this make sense? Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Warnings on image save (was Re: Why not just kill changesets?)
|
|
For me this makes sense
--Hannes On 1/3/13, Juan Vuletich <[hidden email]> wrote: > Hi Casey, > > (inline and abridged on subject) > > Casey Ransberger wrote: >> 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. > > Hey, don't worry. Maybe I overreacted a bit, or I made it look like that. > >> ... >> >> >> - 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. >> >> >> 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. >> >> >> 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. >> > > This is what I'm coding right now: > > On quit without save: > - Warn about unsaved packages (if you don't save them, you might need to > go to the .changes file to recover your work) > - Warn about unsaved changes to core (if you don't save them, you might > need to go to the .changes file to recover your work) > > On quit and save: > - Don't warn about unsaved packages. You can save them anytime. > - Do warn about unsaved changes to core (the change set will be removed, > so you'll need to gather them if you want to publish them or update > other images). > > Does this make sense? > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Yes, I agree too.
2013/1/3 H. Hirzel <[hidden email]> For me this makes sense _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
In reply to this post by Juan Vuletich-4
Dear all
After having read this discussion I think I like it best the way it is with 4.1 at the moment. --Hannes On 1/3/13, Juan Vuletich <[hidden email]> wrote: > Hi Ken, > > (inline) > > Ken Dickey wrote: >> My take on the core is that it should be like the VM, a set of coherent >> services which everyone can count on. A baseline and interface. >> >> My experience with Tektronix's Smalltalk is to observe that many people >> made changes to the core with the result that any attempt to merge results >> together broke things. >> >> So to extend the stump metaphor, people made limbs that required a >> stronger heart, lungs, and so forth but when others wanted to use a new >> limb other limbs did not match up with changed arteries. >> > > Yes. The same happens today. The best we can do is to integrate as early > as possible. That's why the trunk was so good for Squeak. In Cuis, we > also want to integrate contributions early, and discuss enough about > changes that could affect compatibility with other ongoing efforts. > > It might happen that some people want to do changes that are > irreconcilable with what others are doing. That's the main reason for > forks. Like Tweak, Cuis and Pharo. > >> Wow, that was an incredibly bad attempt at an explanation. 8^( >> >> What I should say is that having a single coherent baseline is incredibly >> important for rapid progress. I don't mind that the baseline itself >> changes and evolves, but the evolution must had a common, single thread. >> > > Agreed. > >> I also like building the core from source, rather than just evolving >> images, but I want to assume and start from the core and not have to >> assemble it each time. >> > > Me too. > >> As you can see, I have not yet had my coffee today. >> >> Apologies for the poor communication attempt. >> >> -KenD >> >> > > :) I think you made your point. > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Warnings on image save (was Re: Why not just kill changesets?)
|
|
In reply to this post by garduino
This is in the last GitHub commit. Please check and comment on it.
Cheers, Juan Vuletich Germán Arduino wrote: > Yes, I agree too. > > 2013/1/3 H. Hirzel <[hidden email] > <mailto:[hidden email]>> > > For me this makes sense > > --Hannes > > On 1/3/13, Juan Vuletich <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi Casey, > > > > (inline and abridged on subject) > > > > Casey Ransberger wrote: > >> 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. > > > > Hey, don't worry. Maybe I overreacted a bit, or I made it look > like that. > > > >> ... > >> > >> > >> - 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. > >> > >> > >> 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. > >> > >> > >> 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. > >> > > > > This is what I'm coding right now: > > > > On quit without save: > > - Warn about unsaved packages (if you don't save them, you might > need to > > go to the .changes file to recover your work) > > - Warn about unsaved changes to core (if you don't save them, > you might > > need to go to the .changes file to recover your work) > > > > On quit and save: > > - Don't warn about unsaved packages. You can save them anytime. > > - Do warn about unsaved changes to core (the change set will be > removed, > > so you'll need to gather them if you want to publish them or update > > other images). > > > > Does this make sense? > > > > Cheers, > > Juan Vuletich > > > > _______________________________________________ > > Cuis mailing list > > [hidden email] <mailto:[hidden email]> > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
In reply to this post by Casey Ransberger-2
Hi Casey,
I think we essentially agree. To summarize it a bit: - Rebuilding the system from source would have some nice properties. - This should be done without losing the nice properties of Smalltalk-80 we already enjoy. - It is a rather big project. There are some open problems to solve, and a lot of code to be written or adapted. So, it is mainly about finding enough time / manpower to do it. Cheers, Juan Vuletich Casey Ransberger wrote: > Juan, you've made some interesting points here. I see some of your > reasoning more clearly now. > > Comments inline. > > On Wed, Jan 2, 2013 at 7:07 AM, Juan Vuletich <[hidden email] > <mailto:[hidden email]>> wrote: > > Ok. This will be long :) > > > Yep:) > > Casey Ransberger wrote: > > 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: > > http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption > > > Thanks for the link. Sometimes I have trouble following the stuff > you quote. > > > I should work on that. I use too much slang at times. > > 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. > > 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: > > > Ok. It is a good question. I'll interleave some comments on your > Cons/Pros, and then add mine. > > > Cons: > > - 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. > > - 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. > > > 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). > > > This makes sense. > > - Stuff I've missed. > > > 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: > > > 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. > > > === Cons (a) miniKernel + loadable packages. Pavel's way: > > - 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. > > > :) 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. > > 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. > whitepages.com <http://whitepages.com>, 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. > > > - Not having the dev tools in the image makes modifying it harder. > > > 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. > > > - 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. > > > Again, this isn't my intent. I very much want folks to see the whole > system when they come to it. > > > - The mini-kernel will also need modifications from time to time. > How do we do that? With ChangeSets? > > > 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. > > > - Maintenance will take more work. We'd need procedures to update > or re-create the kernel, build the distributions, QA them, etc. > > > 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. > > > - 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. > > > There's one that I didn't think of. > > === Cons (b) Packages always loaded. Squeak's way: > > - We'd need a package loader with atomic loading. Squeak doesn't > yet have it, after a decade of using Monticello. > > > 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. > > > - 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. > > > 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. > > > - It would be difficult and dangerous to update the Kernel and > PackageLoader packages. > > > Until we found a way to do it safely. Big pile of work. Totally. > > > - 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. > > > Git changes are deltas. > > > - Updating an image becomes muuuuuuch sloooooweeer. > > > Agreed. > > > - When updating an image it is much harder to understand what > happened, to adapt our code. > > > Pros: > > - 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. > > - 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. > > > > - We can completely unload (at least a lot) of the changeset > handling machinery* > > - Smalltalk effectively becomes a peer to kernels which manage > code in files, which makes us a lot less of a scary monster to > newcomers. > > - Stuff I've missed. > > *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. > > > We can see Squeak's experience with eliminating ChangeSets, and > Pharo's experiments with Pharo-Core. Let's learn from them. > > > Totally! > > I mean, why do anything halfway;) ? > > 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! > > 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. > > > Sure. > > > 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. > > > I agree. This is the best time to evaluate all possible options. > > > 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. > > > :) I hope tolerance and respect for everybody's freedom wins. > > > I was joking about the torches and pitchforks! > > Cheers, > Juan Vuletich > > > P.S. > > 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. > > -- > Casey Ransberger > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > -- > Casey Ransberger > ------------------------------------------------------------------------ > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Warnings on image save (was Re: Why not just kill changesets?)
|
|
In reply to this post by Juan Vuletich-4
Yes, this makes sense to me now.
On Thu, Jan 3, 2013 at 6:11 AM, Juan Vuletich <[hidden email]> wrote: Hi Casey, Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Why not just kill changesets?
|
|
In reply to this post by Juan Vuletich-4
Below.
On Thu, Jan 3, 2013 at 8:23 AM, Juan Vuletich <[hidden email]> wrote: -- Hi Casey, <big snip /> Bingo. I brought it up in part to see how far the Git idea might go, and what we might gain and/or lose by pushing the approach farther toward mainstream practices. More a thought experiment than any urgent observation.
Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |