<richi235>davexunit: gitlab is quite cool and in some aspects already surpasses github, we use it at work <davexunit>the downsides are that there's a CLA and it's not AGPL <richi235>jep, thats true, and it's ruby, i don't like this language that much <davexunit>one of my preferred non-lisp languages to work with <rlb>hmm, it hadn't really dawned on me yet, but if they're going to change the upstream emacs git repository, I suppose that's going to break the debian emacs archive... *rlb has been using the emacs savannah git repo for emacs and guile. <cluck>rlb: from what i've read on e-devel esr is preserving and migrating all repo history too <cluck>so merging history (at least as a separate branch or fork) shouldn't be too impossibly hard <rlb>cluck: yes, but all the sha1s will change <rlb>I may just leave it alone and start over -- we'll see. <mark_weaver>rlb: can you rebase the debian patches on top of the new git repo? <rlb>righ t-- that's not the main issue (and should be trivial) -- it's that (via git-dpm), the debian history has a lot of merges that I assume would be painful to recreate <rlb>though perhaps some fancy git-rebase would preserve most of the internal ones -- dunno <cluck>rlb: you might want to reach out to esr on e-devel first, he's been very meticulous with the migration and helping everyone involved fix issues that popped up <rlb>but I'm not sure I'll care enough to do anything about it -- might just start over with the next upstream release. <rlb>cluck: sure, but I'm not sure this is anything I'm willing to spend much time on, honestly. <rlb>and it might even be safer to just switch and let anyone who wants to see the older history just look at the older branches. <rlb>debian's backstopped anyway since everything's captured at each release (effectively a checkpoint) by the orig.tar.gz, and the debian.tar.gz (that includes debian/patches/*). <mark_weaver>rlb: I see, you're doing merges instead of rebases, which I suppose makes sense. <rlb>I just hadn't thought about it. In any case, I suppose I should (selfishly) hope that they switch at a major i.e. X.Y upstream release. <rlb>mark_weaver: well, it's really a mixture -- it's "whatever git-dpm does", which is effectively to maintain debian/patches as a (continuously rebased) branch that's merged whenever necessary into the master branch. <rlb>mark_weaver: so all changes outside debian/ are on that branch. <rlb>and the patches branch is ephemeral/anonymous <rlb>it's only created when I'm working on the patches, then I can use all the git tools to manage the patches (way more convenient than using quilt/dpatch/by-hand/etc.), and then call "git-dpm update-patches" to switch me back to master after merging the temp branch and regenerating debian/patches <rlb>which of course implies that I can trivially cherry-pick an upstream patch, which automagically turns into a debian/patches/ file (and is applied to the main tree). <rlb>(at the same time -- via "git-dpm cherry-pick ..." <rlb>it's definitely complicated (initial learning curve), but I've found it pretty helpful in the steady-state. <rlb>esp wrt packages like emacs and guile that should have even more infusions from upstream than I've normally managed. <rlb>(I've gotten even better at git-dpm lately, and so it's easier to get things done -- hence the relatively fast inclusion (for me) of your cherry-pick suggestions, etc.) <rlb>otoh, it's a barrier to anyone wanting to help wrt the repo directly... <rlb>mark_weaver: though usually the harder part is the bit you did -- helping me figure out how to fix the problem (incorporating it's usually not too hard) <rlb>the other harder part is incorporating new upstream releases for dfsg-split packages (very happy that's not guile anymore) <davexunit>home after a very busy day hacking a CAS server together <davexunit>in which I wrote a really hacky ruby implementation of drupal's sha512 password hashing algorithm for CAS authentication. <davexunit>I should get away from computers for the night, but now I'm hacking on my Minetest patch that I want to get upstream for Guix compatibility <paroneayea>I had a fairly unproductive day, aside from a w3c meeting <paroneayea>currently switching rapidly between projects making small commits :) <davexunit>I made some minor commits to guix-web last night <davexunit>need to get back to that... and guile-toxcore, and sly, etc. etc. <paroneayea>I still need to get a guix setup. I keep getting nervous about setting up guix users safely and etc <paroneayea>I worry I'm going to do something wrong and it'll be a PITA to clean up, and it's probably unreasonable. <davexunit>once you get that part done it's real easy to maintain <davexunit>yeah, you can easily delete the users+groups that you make *paroneayea listening to Chips Dips and Facerips <paroneayea>yeah I guess it's pretty unlikely guix is going to accidentally mess up the rest of my system <paroneayea>do you like chiptunes? I feel like we've discussed this <davexunit>I think they're okay. I don't listen to them much, though. <davexunit>I like them in the context of video games, but they don't really do it for me outside of that. <paroneayea>I used to listen to a lot of ocremix while hacking <paroneayea>I haven't updated my ocremix collection in like 8 years :) <davexunit>I typically just listen to some combination of punk, stoner rock, black metal, and shoegaze <paroneayea>I can't listen to most music with lyrics while working <paroneayea>if I know the music really well it's background enough <davexunit>that's where I like the atmospheric black metal/shoegaze stuff. long stretches of instrumentals. ***siel_ is now known as siel
<davexunit>writing an extensible, reactive, declarative scene graph API is hard. I've iterated on it for awhile and still haven't come up with something worth keeping. <paroneayea>adhoc: davexunit is working on something called sly <paroneayea>it'll provide a scene graph... but the tricky thing is that it's a functional, reactive system <paroneayea>which is cool otherwise, but figuring out how to make that performance-efficient is hard <adhoc>i've been hacking on some volume description stuff <adhoc>based the idea from some work done by an GPU coder <adhoc>i should port it from C => guile <adhoc>i have my scemes to learn before i can contribute usefully to the project <adhoc>i'll have a crack at installing it with all the dependencies =) <adhoc>in the quite bits of meeting this arvo ***petercom1and is now known as petercommand
<adhoc>not to learn to read the compile dumps/stacktraces <adhoc>ice-9/boot-9.scm:106:20: In procedure #<procedure aec100 at ice-9/boot-9.scm:97:6 (thrown-k . args)>: <adhoc>ice-9/boot-9.scm:106:20: no code for module (srfi srfi-43) <nalaginrut>well, when I'm compiling my complex tree implementation, Guile is 300% cpu occupied and halt, under master ***sethalve_ is now known as sethalves
<civodul>mark_weaver: i have a port of SRFI-115 for use in Guix (if everything goes well) <civodul>mark_weaver: the port works, but SRFI-115 doesn't actually do what i want (i wanted to operate on bits from a port, rather than from a string) <civodul>(yeah, i could have noticed before ;-)) <civodul>but anyway, i'll try to add it to Guile <mark_weaver>civodul: when I looked closely at SRFI-115, I noticed that it's missing some useful features of irregex, so I wasn't sure whether we should just import irregex instead and make some kind of thin wrapper for SRFI-115 implemented in terms of irregex. *rlb wonders why a refresh in magit doesn't actually notice rewritten commits as far as next/prev commit go (still shows the old chain). <mark_weaver>notably, irregex allows you to perform regexp operations on something that is not a contiguous string, but rather a series of chunks of strings. <mark_weaver>rlb: hmm, if you rewrite the commits, won't the commit you're looking at have a different hash, and thus actually be a different commit? so I'd expect next/prev to not magically jump to the new chain. <rlb>mark_weaver: but if I visit the new "base" commit, back still visits the "old" next commit. <rlb>it's like the refresh isn't "deep" <rlb>(or it's going on buffer names or something) *rlb is poking at magit in more depth atm -- see how he likes it... *rlb doesn't like the stale commits, but maybe he's doing it wrong... <mark_weaver>rlb: I typically type 'g' in the *magit-log* buffer and then revisit one of those commits after rewriting the history, and it seems to work properly in that case. <mark_weaver>but I haven't used the next/prev keys (though I probably should) <rlb>it works fine if you revisit the rewritten commit, but until you do, the link from the previous commit goes to the wrong one. <mark_weaver>well, there's no way to change an older commit without changing all the commits after it, because of the way git works. <rlb>right -- that's not what I mean <mark_weaver>the hash of a commit is derived from the entire history it's built upon. <rlb>if I have A -> B -> C -> D and I rebase in a way which changes B, then hit "g", and then (re)visit A, the "back" button doesn't go to the new B, it goes to the old B. <mark_weaver>so, if you're looking at the "old" commit, it is right and proper that "prev" should go to the previous one along that older timeline. <rlb>and by (re)visit A, I mean hit enter on the A that's in the 'l l' buffer after the refresh. <mark_weaver>oh. hmm. so when you (re)visit A, is the hash shown at the top updated? <rlb>don't know -- didn't check <rlb>(I'll look next time) <rlb>in any case, I was trying to figure out if magit could replace one of my normal procedures with gitk, i.e. paging through a set of commits I'm preparing to push -- for now I'll probably just set magit aside again -- need to get this finished. <rlb>(paging through repeatedly, as I rebase to clean up) <mark_weaver>davexunit: you seem to know magit better than I do, so I have a question for you: does magit provide a nice way to revise an earlier commit? I often have a series of commits, and then discover a problem in an earlier commit. <mark_weaver>right now, I use "git format-patch" to save all of the commits after the one I want to change, do the fix, "git add" and "commit --amend" (outside of magit), and then use "git am" to reapply the later commits. but it's just so terrible. there must be a better way. <rlb>mark_weaver: presume you mean other than "R" <rlb>(what davexunit said) <davexunit>which means, I open the short log with 'l l' *rlb uses "git rebase --interactive" heavily (and just tried "R") <davexunit>move the cursor to the git that I want to rebase from, and press 'E' <davexunit>which opens up a new buffer for the interactive buffer <davexunit>there's help text in the buffer, so you should be good to go from there. <davexunit>I use it a lot to squash/fixup commits that I make after a code review to get back to the original number of patches that I had submitted. <davexunit>M-n/M-p will shift commits down/up so you can re-order them if need be <davexunit>git's interactive rebase is a killer feature. magit's interface makes the whole process even better. <rlb>davexunit: yes, rebase --interactive is *brilliant* <mark_weaver>I'd heard of it, but somehow assumed it was for a different purpose than this. <rlb>mark_weaver: and note that the edit window you end up in during the rebase isn't magit specific -- it's an emacs git rebase mode (i.e. you'll end up there even if you do a "git rebase --interactive" from the command line) <davexunit>yeah, I guess the name doesn't really tell you what it's good for. <rlb>mark_weaver: it's tha all singing, all-danciing, by-hand, git history surgery tool. <rlb>(of course larger scale or more complex operations probably require filter-branch, etc.) *rlb predicts mark_weaver will be glad he messed with it <rlb>mark_weaver: and at least from the command line, you give it the start point, i.e. the commit before the ones you want to hack on, i.e. "git rebase --interactive master" will edit all commits since current master HEAD. *mark_weaver is reading about the command line tool now, and will then look at the magit interface. <mark_weaver>git stash is another tool I've never learned. I just use "git diff" and later apply the patch. time to brush up on my git skills! <rlb>mark_weaver: probably best way would be to just "git checkout -b tmp/foo master" and then try it. <rlb>(and make sure it actually drops you into the fancy emacs mode -- if not, that'd be worth fixing) <rlb>though you can do all the same things with normal emacs editing commands in that buffer <rlb>mark_weaver: stash is also handy, but has its limitations -- definitely worth learning (*now*) though. <rlb>mark_weaver: fwiw, I've found that there are any number of cases where you're better off with a throwaway tag/branch because (afaict) it's easier to apply git's full machinery (merges, rebases, etc.) to a branch. <rlb>mark_weaver: and basic stash use is quite straightforward (it's just a stack of saved commits) <ft>I usually just use stash if I only need to stash away my current changes, that can't be committed yet, because I have to do something unrelated, that's done quickly <rlb>save pushes (and clears your working tree), and apply tries to apply (the top commit by default) to the working tree, and drop, drops the top commit. <rlb>(and pop == apply/drop (iff the apply works)) <rlb>ft: yeah, though sometimes I just do this instead "git checkout -b tmp/new-tmp-branch && git commit -am blarg && git checkout prev-branch" *rlb should write a command for that ;> <daviid>wingo: I'm thinking to merge guile-gnome devel to master, tag and release, do you have any objection? <rlb>mark_weaver: oh you may like "git stash show -p" -- similar to "git show OBJ" for a stash. <mark_weaver>sometimes I've applied multiple commits to master, and later realize that they should be on a branch, so I "git branch foo" and then "git reset --hard origin/master". <mark_weaver>anyway, thanks for all the tips! I think I have enough to go on now, and will read up on these commands. <daviid>yes, tx for all these tips! I hope to soon re-read and try all these later! <daviid>I'm such a basic git magit user, pathetic :) *rlb uses "git branch -f X Y" and "git merge --ff-only" or "git merge --no-ff" (depending) fairly often too (for managing the tmp branches, etc.) <mark_weaver>I learned the absolute minimum I needed to know to get things done (barely). <rlb>Sometimes I want to preserve the "detour" (or "goes together") information represented by the set of patches on the branch (even if it could be fast-forwarded), and sometimes I don't. <daviid>debian people are terribly good at all these house keeping tasks :) *rlb has learned git somewhat more deeply (though much of that is internals, not interface), due to bup... <rlb>daviid: survival mechanism <mark_weaver>I have one tip to contribute: if you haven't looked at 'git-new-workdir' from the git source contrib directory, check it out! <rlb>mark_weaver: hmm, have to take a look... <mark_weaver>basically it allows multiple working directories that use the same underlying git store. I use it extensively. <mark_weaver>for example, I have separate working directories for guile-master, guile-stable-2.0, guile-r7rs-wip, etc. <rlb>Oh, and quite a bit more on-topic I suppose... *rlb celebrates *finally* getting guile-1.6 out of Debian (and there was much rejoicing) *rlb thanks the ftp-masters <rlb>end of an era (and let's not break the ABI again ;>) <daviid>mark_weaver: I have that too: guile-gnome [for guile-gnome devel, guile-clutter [for guile-gnome clutter-devel] ... <mark_weaver>rlb: I hate to say it, but we plan to break the ABI with every major release (e.g. 2.0 -> 2.2), at least unless we make some radical change to how the C interface in the future. <rlb>mark_weaver: no, that's fine -- just don't break it *within* an X.Y series. <mark_weaver>(I've occasionally entertained the idea of providing a thin layer analogous to gnulib that gets integrated into each program, and then radically simplifying the interface of the actual libguile shared lib) <rlb>(backstory: I originally compiled 1.8 without thread support -- I can't recall for sure offhand if that was b/c threads had issues in 1.8 at first (could have been arch issues?), or was an accident, but anyway, enabling threads changed the library ABI, so we were stuck with a non-threaded 1.8 in Debian. Since some people presumably needed a threaded guile, I decided to keep 1.6 until 2.0). <rlb>moral of the story -- don't let (relevant) configure arguments change the ABI in backward incompatible ways <mark_weaver>oh, interesting. so 1.8 is non-threaded even in sid? <rlb>(or just start out with the options in Debian you plan to keep forever) <rlb>mark_weaver: I believe so. <rlb>couldn't change it without breaking old rdepends <rlb>(or having a massive library transition) <rlb>which is why I was very happy when guile-2.0 came out (that and the end of the need for the dfsg split) <mark_weaver>if the ABI changes when switching from non-threaded to threaded in 1.8, I suspect the same is true in 2.0. <rlb>mark_weaver: not sure -- can't recall if we fixed it <rlb>mark_weaver: but in any case, I believe I use --with-threads=yes everywhere in 2.0, so I can ignore the problem. <ijp>mark_weaver: good news, I finally have a computer that can build guile master :) <zacts>they also mention scheme in there <zacts>don't know if it would be useful, but it's interesting nonetheless <civodul>mark_weaver: re irregex, that's interesting; i though SRFI-115 was mostly identical <mark_weaver>civodul: my impression is that SRFI-115 is very close to a subset of irregex