IRC channel logs


back to list of logs

<davexunit>gnusosa: yeah I'll give it a shot. maybe I'll start tonight if I have time by getting doxygen to generate the xml spec.
<davexunit>gotta run now.
<gnusosa>daviid: Oh that's great I'm looking at it
<mark_weaver>gnusosa: g-wrap has a significant disadvantage. it generates C code that must be compiled into an .so instead of using the dynamic FFI. if we can avoid generating any C code, then the entire library can be platform independent and much more easily distributed.
<mark_weaver>any .so files generated would be specific to a particular major version of guile, so a version compiled for guile-2.0 won't work with guile-2.2 or guile-2.4
<mark_weaver>that causes major practical problems.
<mark_weaver>if you can make a binding in pure scheme using the dynamic FFI, that would be vastly preferable.
***karswell` is now known as karswell
<gnusosa>mark_weaver: what about dynamic foreign functions?
<gnusosa>mark_weaver: this is confusing
<gnusosa>mark_weaver: I hope you're referring to this because if that's the case I'm liking what I'm reading
<mark_weaver>gnusosa: yes, that's it
<mark_weaver>guile-opengl is a good example of an automatically generated binding for the dynamic FFI.
<gnusosa>mark_weaver: it seems pretty forward
<gnusosa>yeah I was reading that from their source code
*davexunit generated xml docs for libgit2 with doxygen
<davexunit>the output isn't quite right, actually.
<davexunit>it thinks all the functions are named GIT_EXTERN
<davexunit>gnusosa: okay, got a doxygen config that seems to do the right thing.
<davexunit>I'm not sure I really want to write a new reader for this nasty input, though.
<davexunit>might be best to make it a one-off job.
<davexunit>and future api changes to libgit2 would be easy to handle manually as they happen
<davexunit>sxpath is sweeet
<nalaginrut>morning guilers~
***michel_mno_afk is now known as michel_mno
<davexunit>hmm, sxml-match is both cool and frustrating
<davexunit>it can select attributes without regard to the order in which they are listed in the list, but not the same for nodes
<davexunit>I have an sxml node that has 'type and 'name child elements, but the order in which they appear doesn't matter.
<davexunit>and I would like to select for their values
<mark_weaver>davexunit: sounds like you should sort those nodes before matching.
<davexunit>mark_weaver: I guess so. or use sxpath or something, but I haven't figured that out enough to make it elegant to do this.
<mark_weaver>the thing is, in most cases the order of xml nodes does matter, right?
<davexunit>I guess it depends.
<davexunit>people write xml files that are essentially code
<davexunit>so I guess in those cases the order is important
<mark_weaver>for html/xhtml it certainly matters
<ijp>order generally does matter for documents
<davexunit>yeah for the order of rendering
<mark_weaver>not just for rendering, but for the semantic meaning of the document
<davexunit>I guess I could sort first, it will still be a pain though because there's other elements that I don't care about within.
<davexunit>I just want a convenient way to express "I want the values of children x and y"
<davexunit>and of course bind their values to an identifier. probably just have to use sxpath.
<mark_weaver>yeah, maybe we need another tool for that, or to enhance sxml-match somehow, dunno!
<mark_weaver>I vaguely recall paroneayea asking for the same thing not long ago, maybe you two should chat about it :)
<davexunit>if I can figure out the right sxpath combinator that does it, I could add some sugar.
<mark_weaver>yeah, sxpath should be able to do it
<davexunit>down another rabbit hole I go.
<mark_weaver>though I remember having trouble learning about sxpath when I wanted to use it once.
<mark_weaver>we need better docs for these things
<davexunit>the documentation is almost non-existant
<mark_weaver>I think I found some obscure web page, not by the author, that gave me some clues.
<paroneayea>davexunit: mark_weaver: yes I ran into this problem
<paroneayea>but I figured out how to do it
<paroneayea>davexunit: want the source link?
<paroneayea>(sadly it's on github because I'm building some experimental stuff for the w3c group, and the rest of the group is on github, but here:)
<davexunit>paroneayea: sure!
<davexunit>no worries about github
<paroneayea>you can clone that and run the commented out example at the bottom against the dustycloud_less_feed.xml file if you like
<paroneayea>davexunit: what it does is it takes all child elements from an atom:entry at the bottom of the function and passes them into process-entry
<davexunit>paroneayea: thanks, I'll take a look when I can.
<paroneayea>the process-entry thus loops through all of those as a list and builds up a result with fold (in this case, to build a hash-table because it's for building json, but)
<paroneayea>davexunit: also of use
<paroneayea>inspiration for this came from reading one of the examples in the manual
<paroneayea>davexunit: look at the catamorphisms and named-catamorphisms examples. It's the named-catamorphisms one that helped me figure out how to process things out of order
<paroneayea>even though I'm not using catamorphisms at all
<paroneayea>good luck, davexunit !
<davexunit>paroneayea: glad to see that someone already encountered and solved this problem.
<davexunit>yay growing community
<dsmith-work>Happy Friday, Guilers!!
<bestaf>happy day
<bestaf>this channel looks livelier than before
<paroneayea>wingo: or anyone who knows:
<paroneayea>would that be a reasonably efficient way to do substitutions on a vlist?
<paroneayea>or is vlist-map just as (in)efficient? :)
<davexunit>anything that doesn't have to create an entirely new list would be more efficient than mapping over the whole thing
<wingo>depends on whether you expect the substitution to be shallow or deep
<davexunit>fast setting operations are why we need wingo's "fector" :)
<paroneayea>wingo: not totally sure what you mean, unless you mean like copying recursively... it only needs to affect the elemnts in the list
<wingo>davexunit: yes, but with vlist-map you end up with a perfectly-sized vlist, as far as its geometric expansion goes
<wingo>davexunit: with append on a shared tail it start expanding from 1 at the join point
<wingo>fwiw what i would do is
<wingo>maybe vlist-drop is cheaper than a bunch of vlist-cdrs...
<wingo>dunno, that's probably pretty good as far as vlists go :)
<paroneayea>wingo: there's no vlist-cdr function afaik
<paroneayea>ok! :)
<wingo>it's spelled vlist-tail
<paroneayea>wingo: thanks for your input :
<paroneayea>wingo: ah
<wingo>if this is an operation you expect to be doing often, then use fectors or something like that :)
<paroneayea>wingo: it's for a Conway's Game of Life implementation in sly
<paroneayea>wingo: I want to ship it with Sly proper in the examples/, so that limits us to using Guile builtins, unless davexunit ever uses an external library for Sly :)
<paroneayea>an external library for functional datastructures :)
<paroneayea>external libraries are already used ;)
<wingo>or you just copy in the library to sly :)
<paroneayea>I wonder if vlist-substitute is useful enough to submit as a patch to Guile proper?
<ijp>File fortyone.js is large (12.3M) :/
<ijp>ah, it looks less bad when I compare it to the .go than to the .scm
***michel_mno is now known as michel_mno_afk
<gnusosa>davexunit: I found where guile-opengl does the parsing
<gnusosa>I was reading it for a while, it seems very specific to there examples.
<daviid>davexunit: gnusosa
<daviid>oh soory
<gnusosa>daviid: yes?
<daviid>no, had an idea but was hesitating, will wait a bit more :) sorry for the noise
<gnusosa>no worries
<gnusosa>So yeah I'm trying to modify parse.scm into grabbing libgit doc
<davexunit>gnusosa: I have all the docs generated as xml via doxygen
<davexunit>I should upload them to a git repo for you to see
<gnusosa>davexunit: let me know when you upload it
<davexunit>gnusosa: sure
<davexunit>I'm at work so I need some time
<davexunit>next time I'm waiting for a process to finish running or something
<gnusosa>davexunit: don't worry same here