<amz3`>first it seems like ubuntu is broken again wrt libgit2 <amz3`>and with guix's libgit2.so my first attempt to bind fails <winny>how do people unit test guile <winny>i assume guile has good support for most of the sfri's <winny>honestly i have never used them outside of what racket adopted directly <codemac>quick questions for my guile gardeners <codemac>how do you redirect a thunk's stdout AND stderr to a string simultaneously? I've only been using with-output-to-string, etc which don't seem very composable <rekado>seems that it’s failing to load pre-compiled go files ***turbofai` is now known as turbofail`
***turbofail` is now known as turbofail
<civodul>has anyone already ported C code that create port types to 2.1? <civodul>i'm doing that for GnuTLS, but i'd like to avoid duplicating work <civodul>in particular if someone's already written a compatibility shim <jmd>Are there any functions to help formatting text into a certain column width? <wingo>but there is also a format string directive <wingo>~:y or something strange like that <jmd>ok. thanks. I will check both of those out. <amz3`>I managed to bind a libgit2 function <amz3`>I was missing an initialisation step (obvious) <amz3`>now I'm wondering how to wrap all the opaque pointer that the libgit2 API requires <jmd>(format #f "~30@y" "Some very long string") Seems to truncate the string as documented. But dropping the @ doesn't seem to do anything. <amz3`>libgit2 API takes **out kind of pointers everywhere so I am init one using (u64vector 0) and pass that to bytevector->pointer before submiting it to git_repository_open <amz3`>how should I represent the pointer in scheme land? <civodul>amz3: are you writing libgit2 bindings? <civodul>i started something and i davexunit was planning to work on it too <amz3`>I was looking for `define-libgit2type' kind of thing <amz3`>civodul: how do you will use you use libgit2 in guix? <amz3`>civodul: how will you use you use libgit2 in guix? <amz3`>civodul: how will you use libgit2 in guix? <civodul>amz3`: as described in the above bug report :-) <civodul>so are you writing libgit2 bindings? <OrangeShark>amz3`: I was playing around with guile's ffi for libgit2 as well. Had the same issue with thinking how to represent the **out pointer types as well <amz3`>OrangeShark: it solved in the snippet from the bug report from above <Amynka>Hello all. Question what's wrong with lilypond usptream that they are not able to switch to guile-2? Do someone have some info about it ? Thanks <OrangeShark>amz3`: ya, I was looking at it. So use a bytevector, I would have not thought of using that :p <amz3`>OrangeShark: do you want to work together in making the bindings based on civodul work? <amz3`>OrangeShark: where do we host the sources? <OrangeShark>amz3`: I have no preference. I have accounts on github and gitlab but I don't mind creating an account for another git hosting site <civodul>davexunit: do you want to coordinate that? :-) <Amynka>Hello all. Question what's wrong with lilypond usptream that they are not able to switch to guile-2? Do someone have some info about it ? Thanks <paroneayea>amz3`: I applied your pubstrate patches, thanks! <paroneayea>I also moved the repo from github.com to gitlab.com. a bit less bad than before but not the best :) <davexunit>civodul: sounds like whatever they are doing is good. they don't need to be held up by me. :) <davexunit>there's a funny lisp joke to be had with the premise, but that one isn't clever at all <bavier>many people are too quick to pull the "but all the parens!" argument, as if that's a trump card <jmd>Why is lisp like the family of a former Argentine dictator? <davexunit>I mean the real joke is that the lisp programmer spent all their time trying to design a DSL to best describe rescuing the princess <bavier>that would have been more tasteful and in line with the rest of the jokes made there <davexunit>I don't even get the joke in the comic. lisp programmers have rabies? <davexunit>paroneayea: happy to see that your live demos went well <davexunit>civodul: was looking at the gexp implementation and saw 'register-compiler!' which is used in 'define-gexp-compiler'. in the past I've heard that it's best practice that loading a module produces no side-effects, which is sound advice to me, but this seems like a notable exception. <davexunit>I'm having a bit of a hard time determining when such side-effects are appropriate. <davexunit>I do similar things in Sly, which I thought I should try to get rid of, now I'm not so sure. <davexunit>for example, the "signals" in my FRP implementation form a graph where nodes are doubly linked out of necessity, so defining a new signal with 'define-signal' mutates the signals it depends on. I suppose this may also be considered another exception to the best practice. <amz3`>OrangeShark: I created a repository at gitlab and started binding the repository functions <amz3`>the problem is that I pushed something but nothing appears on the website <amz3`>the other problem i have is that i hardcoded the path to the shared library <amz3`>I don't know how to deal with it using autoconf <OrangeShark>amz3`: it looks like other library bindings have the path specified when you configure <amz3`>I've bound some repository procedure I'm in the middle of one right <amz3`>OrangeShark: what do you think about testing? <amz3`>I mean I need to think about testing right now I have no clue how to test the bindings <codemac>ok -- so when I parameterize current-error/output-port on a system* call with dd, it still prints stuff to the terminal, even though through documentation it looks like it should be respecting my current-input/current-output bindings. Anyone run into this before? <civodul>davexunit: i think the 'register-compiler!' kind of thing is akin to 'module-define!' <civodul>the top level is inherently effectul in that sense <civodul>davexunit: but 'define' and 'define-gexp-compiler' hide that under the carpet <civodul>davexunit: GOOPS' define-method is different though, because the load order makes a difference for that one <civodul>(it can create a same-named generic or not) <davexunit>haven't had time to write code really, but I have been thinking about stuff like this for whenever I get around to writing code again. <davexunit>been re-evaluating what works and what sucks in my game engine. kind of in limbo where I know what I'd like to change, but how to change it eludes me. <davexunit>anyway, now I don't feel bad about my FRP implementation. <davexunit>I've identified a few cases where FRP isn't the most convenient way to model time, where something like guile-fibers would be nicer, but thus far can't find a way for everything to live in harmony. <civodul>i'd be interested in examples where FRP doesn't work well, when you have time <codemac>huh. guile-2.2 doesn't print *anything* to the console, but also stores nothing in the output-strings.. <davexunit>civodul: briefly: when you'd like to describe an "actor" doing a sequence of things over time, like: walk towards player, shoot at player if within range, repeat. <davexunit>I've stuffed this into the FRP world by making a sort of monad for describing these sequences, but it feels unsatisfying and has a lot of overhead. <davexunit>where the monad here is an "action", a procedure that takes (world, actor) and returns (new-actor, effects-on-world, next-action) <davexunit>FRP works much better for things like: rotate this sprite by $current-time/32 radians <davexunit>a simple function of time vs. a complex series of steps that describing as a piece-wise function would be a nightmare. <wingo>davexunit have you read the csp book <davexunit>a coroutine describes the latter more naturally, but it has its own problems... <wingo>yes in the sense of how should concurrent processes be represented <civodul>i like the new API so far, it feels sooo much better :-) <OrangeShark>The guile manual mentions wanting a high level FFI, what would a high level FFI look like? Any good examples? <wingo>civodul: aaah, glad to hear it! <davexunit>OrangeShark: a way to define structs with convenient accessors would be really nice <wingo>OrangeShark: luajit's ffi for example <ijp>OrangeShark: larceny let's you c-include a header file and have bindings macro generated <ijp>chez also had some nice stuff <civodul>ijp: i don't believe in auto-generated bindings, feels like Swig as a macro :-) <wingo>civodul: do you think it's advantageous in any way to implement a port type in scheme using the custom binary i/o port api + ffi functions for read/write? <ijp>civodul: maybe, but it's still better than doing it by hand <civodul>ijp: not necessarily in fact, because when using that, you still end up putting an additional layer on top of it to make it feel more idiomatic <civodul>i guess it depends on the library you're writing bindings for <wingo>we need better data abstraction too, not just better function bindings <wingo>civodul: advantageous over a c port type implementation <wingo>i mean it seems like we could implement the gnutls port type in scheme directly <wingo>if those low-level routines are exposed by gnutls, or available to the impl <civodul>ah, good point, that didn't even occur to me since the initial code was in C <wingo>2.1.4 has a custom binary i/o port facility <civodul>but actually these bindings don't use the FFI at all at this point <wingo>having it in c is fine too, good to have users of the new api to make sure things make sense <wingo>right i was just wondering if gnutls exported some low-level gnutls-read / gnutls-write primitives to scheme; if not, no problem. <civodul>i saw a situation where exceptions raised from the 'read' method were silently swallowed <civodul>i forgot to check if that's always the case <wingo>indeed that would be a problem <codemac>Can anyone point me to the source for parameters & open-output-string? strace clearly shows the subprocess not knowing about stderr correctly.