IRC channel logs


back to list of logs

<taylan>roelj: the record will most certainly not be accessible as a plain struct in C, I'm afraid
<roelj>taylan: I was afraid for that.. :(
<roelj>So using the module API, I could call the corresponding getter for an object to get the value.
<roelj>And that way I could get all the information that is in the record.
<taylan>yeah, you could create a wrapper API in C so the constructor, type predicate, and field getters and setters are callable as C functions, though they will take/return SCM values most of the time
<roelj>That shouldn't be a problem :)
<roelj>I think I see how I can achieve what I want now
<roelj>Thanks for referring me to the module API..
<taylan>well I guess one could also write wrappers so that you e.g. automatically get a native float, integer, etc. from a field that contains a number
<roelj>That seems to be the way to go :)
<roelj>Well, my records contain lists of items
<roelj>I think that would get fairly complex
<taylan>yeah, probably best to leave that as SCM then
<roelj>I could write some wrapper functions to convert when needed
<taylan>BTW with you can have a Scheme API to use C structs, i.e. the other way around...
<taylan>well, it might be a blocker that I haven't properly integrated it with the FFI yet...
<roelj>That's an interesting take on it
<taylan>but in principle, you can make a Scheme bytevector that's backed by a pointer to a C struct, so kinda like having the underlying memory of the struct as a 'char*', and then via bytestructures you duplicate the struct layout in Scheme and get structured access to the values again
<taylan>ACTION -> zzzZZZ
<roelj>Goodnight, and thanks for your insight!
<kristofer>I'm getting a stack overflow with this code:
<kristofer>I'm guessing my recursive approach could be adjusted to iterate, but I'm having trouble wrapping my head around it
<mark_weaver>kristofer: there's an extra set of parens where it shouldn't be. two open parens before the 'if'.
<mark_weaver>otherwise, it would be iterative, I think
<mark_weaver>the key is for the recursive calls to be in "tail position"
<davexunit>wee, I have a websocket server and client talking to each other, both written in Guile.
<davexunit>not standards compliant yet, but a good start.
<Xe>davexunit: ooh, that sounds cool
<davexunit>it's pretty neat!
<davexunit>I have a simple server that just reverses the text that you send to it
<davexunit>and the client can talk to it successfully
<davexunit>(define ws (make-websocket "ws://localhost:9090"))
<davexunit>(websocket-send ws "hello")
<davexunit>(websocket-receive ws)
<davexunit>=> "olleh"
<mark_weaver>davexunit: sweet!!
<mark_weaver>that's really great news
<davexunit>I think this is one of those 80% done, 80% to go situations since I haven't fully implemented the spec. ;)
<davexunit>this Guile implementation is nicer that the Ruby one I use for stuff at work.
<davexunit>what I have for the client so far, if anyone is interested.
<davexunit>lots of TODOs in there, but a decent rough draft I think.
<davexunit>ACTION zzz
<jmarciano>davexunit: I watch your gits... that is great what you have done already.
<davexunit>"Your task is to write a proper version of leftpad; make sure yours operates in linear time instead of the quadratic time caused by the string concatenation in Azer’s code." lol
<rekado>I just noticed that my documentation patches to SXpath are in the stable-2.0 branch, but not in master.
<rekado>is this on purpose?
<rekado>or is master going to be rebased on top of stable-2.0 for the next release?
<davexunit>rekado: stable-2.0 will likely be merged into master
<rekado>oh, okay
<davexunit>that happens periodically, IIRC.
<rekado>when I prepare patches for Guile should I base them on master?
<davexunit>rekado: depends on what you are targetting
<davexunit>for my JSON work, I targeted stable-2.0
<davexunit>if I was hacking on the compiler, I'd target master.
<rekado>I want to make some changes to web and http
<davexunit>stable-2.0 sounds like the right place
<davexunit>if the author of lurks here, just want to say that I love it!
<jmarciano>so many guile stuff on that website
<jyc>is there a good way to wrap guile's http server implementation so if the connection is reset by the client I don't print an error message?
<davexunit>you would most likely want to patch the server
<jyc>so actually take the server code, modify it, then use it?
<davexunit>jyc: I guess I'm saying that you should investigate the source
<davexunit>to see if its possible to do what you want without modification or not
<paroneayea>wow horray
<paroneayea>I now have commit access to Guile
<paroneayea>pushing the rebased verison of bipt's elisp stuff up!
<amz31>ACTION looking at ethreads
***amz31 is now known as amz3
<davexunit>paroneayea: yay!
<paroneayea>wingo: where should I push the rebased branch to? Should I clobber the existing wip-bpt-elisp branch or make a new one
<paroneayea>like more simply wip-elisp or something
<paroneayea>the wip-bpt-elisp one is 5 years old
<paroneayea>ACTION pushes to wip-elisp for now :)
<jyc>davexunit: that was good advice, found out how
<jyc>but there seems to be a bug in the documentation: it says that the write hook is called with three arguments, when in fact it's called with four
<jyc>is the process for me to submit a patch w/ fixed documentation?
<jyc>*to some mailing list, etc.
<amz3>jyc: yeah
<paroneayea>wingo: new wip-elisp branch on guile's origin with rebased branch :)
<jyc>amz3: cool, thanks
<amz3>looks like ethreads makes obslete all other event loops :D
<paroneayea>amz3: I would really like to take some time to understand it more
<paroneayea>if that's really truly true, I'd be pretty happy to have 8sync deprecated :)
<amz3>well, I don't know yet if it can integrate another event loop
<davexunit>ACTION needs to check out ethreads as well
<holomorph>paroneayea: \\o/
<paroneayea>hi holomorph :)
<cojy>amz3: i responded to your mk mailing list post the other day if you didn't see
<cojy>if it's too confusing or anything i could write more notes
<jyc>is the guile web server taking two ^C's to quit expected?
<davexunit>yeah, but I haven't learned exactly why yet. :)
<jyc>:P alright
<amz3>cojy: I'm looking at you message right now
<amz3>it's impressive
<amz3>cojy: what implementation of minikanren are you using?
<amz3>is there a repository?
<amz3>maybe add it to PANL repo
<cojy>amz3: it's this one
<cojy>the dcg macro is in the panl repo so it should only take a few basic changes to use it in any minikanren