<chrislck>is it from the same vein "a guild of schemers/racketeers/guilers"? <chrislck>nice but otherwise a bit obscure when called from other tools lol <civodul>roptat: merged diff support in guile-git! <civodul>like i wrote there, might be worth providing 'diff-fold' <roptat>civodul, I have one or two additional functions in other parts that I'd like to contribute, but I can't connect to gitlab <roptat>tree-entry-type and config-foreach <civodul>roptat: yeah gitlab.com doesn't work in IceCat, go figure <civodul>do you think you could contribute them "soon"? <civodul>i'd like to have a Guile-Git release out before the Guix release <roptat>yeah, I'll push the patches to my branch when they're ready (maybe in one or two hours) <roptat>then I can't create a MR because I can't connect, but I suppose you can still merge "manually"? <civodul>Epiphany works with gitlab.com, but it's even better to avoid it altogether <roptat>civodul, I have my patches except one that adds config-entry. I think it should go to git/config.scm, but it's already used for configuration of guile-git itself <roptat>what should I do? move config.scm to configuration.scm maybe? ***jao is now known as Guest39334
<pkill9>is lisp like programming the programmer instead of programming the machine? <roptat>oh well, eolie doesn't work for me "ValueError: Namespace Handy not available" <civodul>roptat: nice! re renaming (git config), i'm not entirely sure, but maybe that's ok <civodul>i don't think anyone has good reasons to use the current (git config), it's pretty useless <civodul>so it should be backwards-compatible in practice <civodul>we'll have to document it in NEWS, though <civodul>roptat: other than that, could you add tests for the new (git config)? <civodul>also, as for diff-foreach, it may make sense to provide tag-fold instead of/in addition to tag-foreach <roptat>sure, though I'm not sure what you mean by "implement diff-foreach in terms of diff-fold" <roptat>libgit provides only diff-foreach, not fold <roptat>so I'd implement diff-foreach in terms of diff-fold that I'd implement in terms of diff-foreach? I'm confused <roptat>ouch, got a segfault when trying to implement config-fold <civodul>roptat: git_diff_foreach takes a void pointer argument if i'm not mistaken, so that's enough to implement diff-fold <civodul>then diff-foreach becomes a special case of diff-fold that returns *unspecified* <roptat>although, how do I create a pointer from an arbitrary guile object? ***Guest39334 is now known as jao
<roptat>wait, the callback needs to return 0, so I need to update the pointer in some way <roptat>or maybe I can make a double pointer <roptat>so, I have a double pointer to an arbitrary object, and I need to make the second pointer point to a new arbitrary object, how can I do that? <roptat>p1 -> p2 -> o1, I can't change the addresses pointed to by p1, so I want to change p2 with another pointer: p1 -> p2 -> o2 <roptat>I guess I can dereference p1, but then how do I updatte p2 to point somewhere else? <civodul>roptat: actually branch-fold & co. are not based on the C "foreach" function, but rather on iterators <civodul>otherwise yes, you can have an extra pointer indirection like you wrote <leoprikler>I think you'd typically have p2 as a bytevector and write arbitrary pointers into it :) <roptat>so, I can transform a pointer to a bytevector? <roptat>sounds scary, do I simply copy the address to the bytevector? <leoprikler>yep, there's pointer->bytevector and bytevector->pointer <leoprikler>for writing you need pointer-address and a number-writing func <roptat>well, that's not what I want it seems, bytevector->pointer returns a new pointer to the bytevector, not a pointer that points to the address contained in the bytevector <roptat>mh, actually I'll get different sizes of pointers, so how do I write an address (a number) to it? <civodul>sorry for the bumps on the road, i didn't expect it to get tricky <roptat>ok, I think I have all the elements I need now, thanks :) ***Thunderbi is now known as nckx
***sneek_ is now known as sneek
<roptat>now I wonder if the garbage collector will play nicely <roptat>I mean, in the callback, I create a new pointer to the new value of the payload, and put its address inside a bytevector... won't the GC be able to collect the payload? That could cause a segmentation fault, right?