IRC channel logs


back to list of logs

<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>I'm quite comfortable with ruby
<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?
<mark_weaver>well, I suppose it's not that simple
<mark_weaver>nevermind me :)
<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>for example
<rlb>(for guile)
<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)
<dsmith-work>Hey hey
<paroneayea>hi hi!
<mark_weaver>ho ho
<paroneayea>what's up mark_weaver
<paroneayea>sup davexunit
<davexunit>hey paroneayea
<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>heh :)
<paroneayea>I had a fairly unproductive day, aside from a w3c meeting
<paroneayea>then drank some caffeine
<paroneayea>and now I'm hyper
<paroneayea>so trying to do something productive
<paroneayea>currently switching rapidly between projects making small commits :)
<davexunit>that's what I've been doing
<davexunit>can't stick with anything right now
<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 should just do it probably
<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
<paroneayea>I'm sure it's probably pretty easy in reality
<davexunit>yeah, you can easily delete the users+groups that you make
*paroneayea listening to Chips Dips and Facerips
<davexunit>and deleted /gnu/store and /usr/var/guix
<paroneayea>it's my go-to "hyper hacking" album
<paroneayea>yeah I guess it's pretty unlikely guix is going to accidentally mess up the rest of my system
<davexunit>I don't really have any hacking music
<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>some of my favorites
<paroneayea>I used to listen to a lot of ocremix while hacking
<paroneayea>but I've gotten tired of that
<paroneayea>or rather
<paroneayea>I haven't updated my ocremix collection in like 8 years :)
<davexunit>I like ocremix's sonic collection
<davexunit>I typically just listen to some combination of punk, stoner rock, black metal, and shoegaze
<paroneayea>heh :)
<paroneayea>I can't listen to most music with lyrics while working
<paroneayea>with some exceptions
<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.
<davexunit>back to the drawing board.
<nalaginrut>morning guilers~
<adhoc>scene graph API?
<paroneayea>adhoc: davexunit is working on something called sly
<paroneayea>a game engine
<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>mostly using oct-trees
<adhoc>no near complete
<adhoc>but fun none the less =)
<adhoc>based the idea from some work done by an GPU coder
<adhoc>i should port it from C => guile
<paroneayea>adhoc: maybe you should help out with sly! :)
<paroneayea>or at least
<paroneayea> /join #sly :)
<adhoc>i have
<paroneayea>well then ;)
<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)
<civodul>Hello Guilers!
<nalaginrut>well, when I'm compiling my complex tree implementation, Guile is 300% cpu occupied and halt, under master
<nalaginrut>I'll try stable-2.0
<nalaginrut>, it's killed by system monitor
***sethalve_ is now known as sethalves
<dsmith-work>Moning Greetings, Guilers
<civodul>mark_weaver: i have a port of SRFI-115 for use in Guix (if everything goes well)
<civodul>just so you know ;-)
<stis>evening guilers!
<dsmith-work>stis: Heya stis
<mark_weaver>civodul: oooh, nice!
<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
<civodul>and submit it to the list
<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)
<mark_weaver>hmm, dunno!
*rlb is poking at magit in more depth atm -- see how he likes it...
<davexunit>magit has greatly improved my git workflow
*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>by "previous" do you mean "earlier" ?
<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>of course
<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.
<davexunit>mark_weaver: I do an interactive rebase
<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>interactive rebase*
<davexunit>there's help text in the buffer, so you should be good to go from there.
<mark_weaver>interesting, thanks!
<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.
<mark_weaver>sounds like just what I need.
<davexunit>M-n/M-p will shift commits down/up so you can re-order them if need be
<mark_weaver>oooh, nice!
<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
<mark_weaver>no doubt! my current method has been *painful*
<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>(it's just sugar)
<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.
*mark_weaver reads
<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 :)
<mark_weaver>haha, same here!
*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).
<daviid>mark_weaver: me too :)
<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>happened today
*rlb thanks the ftp-masters
<mark_weaver>woohoo!! \\o/
<daviid>rlb: fantastic! finally
<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)
<mark_weaver>rlb: agreed. have we done that in the past?
<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 :)
<mark_weaver>ijp: yay!
<mark_weaver>rlb: I hope so. that's the default, anyway.
<zacts>just FYI
<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
<paroneayea>civodul: ooh
<paroneayea>I was looking at srfi-115
<paroneayea>it looks neat