IRC channel logs
2014-12-06.log
back to list of logs
<nkar>how can I get "foo,bar" from ("foo" "bar")? can't find a "join" procedure <nkar>thought it works for strings, not lists <cky>Heh, nkar needed to learn to use `apply`. <cky>Or `string-concatenate` from SRFI 13. <cky>Oh well, their impatience is their loss. <mark_weaver>cky: nkar has recently been a regular on #guix. if you ask sneek to deliver a reply to him, he'll probably receive it there. <mark_weaver>(sneek is on both channels, and delivers messages to whichever channel the recipient speaks on first) <mark_weaver>cky: however, 'string-join' seems like the right tool for the job he wanted. <cky>mark_weaver: I think nkar has a list of strings, wanted to join them using `string-join`, but doesn't know how to use `apply`. <cky>mark_weaver: SRFI 13's `string-concatenate` is a list-taking version, IIRC. <cky>Lemme test with rudybot :-) <mark_weaver>string-join uses string-concatenate internally, but handles putting in the delimiters. <cky>Oh, I see. My bad, I mistook it for string-append. <mark_weaver>also, 'string-join' takes the list of strings as a single argument, so 'apply' it not needed when using it. <zacts>mark_weaver: so I do have a naive programming question. <zacts>may I ask here? It's somewhat scheme / SICPish <zacts>well, I understand the functional programming when you don't have assignment <zacts>and the procedures you write encapsulate the how to compute something <zacts>I don't really see how this metaphor of designing procedures carries over when you add assignment <zacts>how do I design non-functional procedures? A la C or something? <mark_weaver>but SICP might be a good resource for learning about this. <zacts>mark_weaver: I'm used to designing procedures whose sole purpose is to return a value <zacts>mark_weaver: yes, I'm waiting for my Calculus classes to do SICP <zacts>but now my procedures have side effects. they actually DO something now. <zacts>I have no idea how to combine these two ideas together. <zacts>In C functions can DO something with side effects, or they can RETURN a value <zacts>My problem is how to design procedures <zacts>perhaps I'll come up with a better version of what I'm trying to ask, and ask at a later time <mark_weaver>well, one common case of mixing the two styles is to use mutable state internally to a procedure that has a completely functional external interface. <mark_weaver>so the mutable state is only in local variables, and is all discarded when the procedure returns its final result(s). <zacts>is this similar to the idea of a monad? <zacts>I know what you are saying, I think I misunderstand monads. <zacts>but you don't have to explain monads to me now <zacts>ok, well I'll have more questions after I take Calc and read SICP. For now, it's going to be distro hacking. <zacts>mark_weaver: I did just finish a Logic class, with sentential logic and everything, similar to minikanren. It was fun. <zacts>I wonder if Guile has a module for minikanren <zacts>huh, perhaps that could be a project for me. To implement, or improve and adapt an existing, minikanren for guile2. <zacts>sorry mark_weaver I'm kind of dazed tonight. really, too much studying for finals lately. <zacts>finals can do that to people. it's not uncommon for people to have an evil hideous laugh of hysteria during these times. <mark_weaver>minikanren is very nice. I recommend "The Reasoned Schemer", which is all about minikanren. <mark_weaver>and at the end of the book, it shows the implementation in just a couple of pages of very simple and elegant portable scheme code. <zacts>yes, still haven't gone through that book. although I own it. I finished my first reading of the Little Schemer though. <taylanub>zacts: if this helps: one can say all functions with side effects take and return an implicit "state of the universe" value which they update. that state object is propagated through all functions ever called, so to say. <taylanub>not sure if that's what you mean with "how to combine these two ideas together" <zacts>Ok, I'm going to _try_ using emacs bindings again. It's a little odd for me. <zacts>but emacs bindings are optimized for lispy languages <jmd>Anything moved in the direction of Arm porting recently? <jmd>civodul: I think I've got past that hurdle of guile crashing on Arm. <jmd>how long does it typically take to build guile? <civodul>20mn on a recent Intel machine, maybe *davexunit wrote minesweeper in guile :) <davexunit>(don't mind the man behind the curtain managing all the mutable state) <civodul>at the same time, if it were purely purely functional, clicking on it would have no effect <amirouche>is there any kind of "autoconf/automake project template" for guile bindings? <daviid>amirouche: guile-sqlite maybe a good start as well. there is a template in guile-gnome [never used it, i work on guile-gnome existing bindings], but it prepares for a g-wrap, maybe still worth a loo, don't know... <daviid>amirouche: or even sly, because davexunit is an active participant to this channel and may give hints while you start [and he just wrote while typing :)] <amirouche>ok thx I'll see... I am under zile-on-guile spell right now <davexunit>amirouche: feel free to check out sly's configure.ac and Makefile.am <amirouche>Yes, I had a look, but if I'm not mistaken sly doesn't ship C code. <amirouche>anyway, I figured that working on documentation and clean up will be more interesting ;) <daviid>amirouche: for what it's worth, guile-gnome does ship C code [as well as scheme code of course] <davexunit>amirouche: oh, when you said bindings I thought you meant FFI bindings. <daviid>that's what i understood as well :) si there another def? <davexunit>though I think there's little reason to do that these days <amirouche>also it's simpler doing in C in the case of wiredtiger, because it's Object Oriented, hence I need to define every structure in Guile (at least that's what I understood) <amirouche>I think ffi is better when all structs are privante handles <daviid>amirouche: then you _should_ use g-wrap, the previous 'ffi' technique, used by guile-gnomje and guile-cutter [a branch of the guile-gnome tree] <amirouche>btw I'm thrilled to work with sly... I think I'll drop all the web stuff and do some sly hacking instead <amirouche>I looked at g-wrap, didn't get much "inspiration". I will push the code later, you'll see the code is clean (imo) <daviid>amirouche: it would be worth reading the guile-gnome [master] HACKING tips and tricks <davexunit>I dunno, wrapping things from guile gives you a lot of flexibility. <daviid>g-wrap, you should clone devel branch, I completely reviewed the documentation <daviid>davexunit: current FFI lacks goops <mark_weaver>daviid: what does it mean for the FFI to "lack goops" ? <davexunit>I don't see why it needs GOOPS. you just wrap the low-level functions and write a GOOPS layer over it. <daviid>mark_weaver: see the g-wrap doc... <daviid>davexunit: sure, that's what g-wrap does though <mark_weaver>I really think it's non-sensical to say that the FFI lacks GOOPS. I can't even make sense of what you're trying to say. <daviid>anyway, no war here, i'm sauying that someone wrapping a C obect oriented lib like gobjects should use g-wrap, imo <daviid>mark_weaver: it lacks an automatic goops integration, like g-wrap does provide, my sentence was too short, sorry <amirouche>My understanding in the case of wiredtiger is that the OO implementation is something related to wiredtiger internal design (probably because of custom datasources). as an end-user, that OO api, is not useful. <daviid>amirouche: i don't understand anything you wrote, sorry <daviid>no big deal though, i was just trying to help <mark_weaver>daviid: I looked at the g-wrap docs, and I suspect you're mistaken about g-wrap including built-in integration between GOOPS and GObject. <mark_weaver>it is true that g-wrap uses GOOPS, but I don't think it has any support for GObject internally. <mark_weaver>I think the GOOPS/GObject integration is in guile-gnome. <amirouche>daviid: nervermind. GOOPS is not useful of wiredtiger bindings <mark_weaver>based on what amirouche is saying, it's not clear that using g-wrap is the better option. In general, it would be nice to move to using the Dynamic FFI more. <mark_weaver>it avoids a lot of difficulties, especially around C ABI changes between guile versions. <daviid>mark_weaver: how about re-writing g-wrap on top of the modern FFI [i dreamed about that a lot while hacking on guile-gnome guile-clutter] <mark_weaver>I agree that it would be nice to reimplement guile-gnome and guile-clutter on top of the Dynamic FFI. <mark_weaver>I'm not sure where g-wrap would fit into this new picture, if anywhere. <mark_weaver>it seems to me that using the gobject introspection stuff would be best, although I admit that my knowledge of gnome is rather limited. <daviid>yes, we agreed on that a while ago already, but right now, this is expressed in the HACKING document i was refering to, where it probably is probably the route for new bindings, gir based 'only', i'm not convinced yet about existing bindings, and therefore opted to update what we have [guile-gnome guile-cutter] <mark_weaver>daviid: sure, updating the existing bindings makes sense until someone steps up to do a GIR-based ones. <mark_weaver>especially since there's no guarantee that anyone will step up to do them :-/ <daviid>right, it started but has been abandonned, don't know why [guile-gir] <mark_weaver>but if we had them, it would mean that guile-gnome-based programs could be immediately usable on any system with 'guile', whereas today we have to ask people to compile a bunch of C libraries first. <daviid>i know, i wish we had a top notch guile-gir binding too <daviid>i considered working on that, but i need [really want] clutter, right now, and so started this work on what we have <mark_weaver>we have a serious problem with deployment of C-based guile bindings. <mark_weaver>the big problem is that they'll have to be compiled separately for each major version of guile. <mark_weaver>debian has (had?) guile-gnome for guile-1.8, but not for 2.0. <mark_weaver>it'll be at least a few years (jessie+1) before debian has guile-gnome for 2.0. ditto for most other guile libraries based on C. <mark_weaver>whereas for bindings that avoid C and use only the dynamic FFI, we can deploy them immediately using guildhall. <daviid>yep, is that how python does? they have so many lib bindings...? <daviid>mark_weaver: i have an intuition that g-wrap has 'something' we should keep alive, but i had no time [yet] to explore and properly express that idea, if ever correct... by the way i will release guile-gnome and guile-clutter, but have been dragged by 'pay th bill' work highly and unexpectidly recently, so sorry for the delay <daviid>amirouche: just my opinion, but i definitely would not do that: see how sly binds freeimage and guile-sqlite3 binds sqlite3, that's what i would do, my 2c <amirouche>in python both kind of libraries (dynamic and not dynamic) can be shipped with the equivalent of guildhall <mark_weaver>davexunit: oooh, functional minesweeper in guile, nice!! :) *mark_weaver is slower than usual at checking his backlog, since his new crappy ISP keeps dropping his IRC connections despite a keepalive, grr. <davexunit>the last major task is to put together a manual <davexunit>one of the biggest productivity boosters for me is being able to test out wrappers at the REPL as I write them *davexunit really likes guile's texinfo modules <davexunit>I can programmatically iterate over all of my modules and bootstrap my manual with the generated texinfo. 