***karswell` is now known as karswell
<davexunit>is it not possible to make a generic method that uses record types? <davexunit>has guile 2.2 changed the weird thing where defining a record type with goops loaded would also define a class? <davexunit>I just want to have generic methods that work with my record types :( <davexunit>using class-of on an instance of that record type returns a class <paroneayea>davexunit: it should work with <<foo>>, where <foo> was your class, though <paroneayea>davexunit: I filed a bug where I found out that srfi-9 records were hitting an infinite loop while trying to resolve a method in guile 2.2 <paroneayea>davexunit: you'll need to both import goops and srfi-9 <davexunit>paroneayea: hmm, I don't know why that isn't working for me... <paroneayea>davexunit: does my example work if you put it in the repl? <paroneayea>davexunit: also, have you imported (oop goops) in your *current module*? <paroneayea>davexunit: it's not enough to just import it in your library <paroneayea>davexunit: so that's two goops + srfi-9 bugs in guile 2.2 I guess <nalaginrut>Artanis with the new server-core is likely to be released end of this year \\o/ <jmd>How can I pass a #:rest argument to another procedure expecting one? <dsmith-work>jmd: Might be able to use apply. That's how you pass on dotted rest args. <jmd>dsmith-work: I'll try it. Thanks. <jmd>dsmith-work: Seems to work. Thank you. <jmd>(I always wondered what apply was for.) <dsmith-work>jmd: Yeah, why use (apply foo bar baz) when you can (foo bar baz) ? <davexunit>dsmith-work: they mean two different things. <davexunit>and that list is transformed into additional arguments to goo <davexunit>whereas the second example is passing just 2 args to foo <dsmith-work>jmd: Yeah, why use (apply foo (list bar baz)) when you can (foo bar baz) ? <dsmith-work>davexunit: Been living in Kernel land a lot lately. Not much Schemeing going on. <dsmith-work>davexunit: It's good to think about something sane every now and then. <wingo>ACTION ponders wisdom of adding handle-interrupts vm instructions <ft>Hm, to deal with the contents of byte-vectors (I am building a library that implements a binary protocol…), the intended way to look at parts of them is to turn them into lists of integers and work on those? <ft>There are functions to reference, say eight bytes as an 64 bit integer, but I can't get arbitrary parts of a source vector, it would seem. <daviid>ft: I would look at srfi-4 if I were you <ft>daviid: I've seen that one. But the most useful of that library seems to be u8vector->list and list->u8vector. :) <ft>daviid: Yes, but I would kind of like something that lets me reference a sub-vector of arbitrary length. <daviid>ft: you can do that as well, see 7.5.5.3 SRFI-4 - Relation to bytevectors <ft>daviid: I must be missing something them, since I have been staring at the byte-vectors API for quite a while now. Is there something that lets me do (bytevector-substr #vu8( 1 2 3 4 5 6 ) 2 3) => #vu8(3 4 5)? <daviid>#vu8( 1 2 3 4 5 6 ) 2 3) this is not an homogeousa vector (and you'd miss a parenthesis <daviid>so, it is obviously not a bytervector ewither, it's your oen beast <daviid>then you'd have to develop a special interface fore that ... <ft>#vu8( 1 2 3 4 5 6 ) would be the bytevector. 2 and 3 are the other arguments to my hypothetical ‘bytevector-substr’ procedure. :) <daviid>ft: as I said, this is your own beast, you'd have to write the API to these ... <ft>#vu8( ... ) is the read syntax for byte vectors, not really my own beast. I need to extract parts of it (as in starting at an offset and running for a given length), and I don't think the existing API lets me do that. <ft>Which is okay, and in that case, I think turning it into a list first is my best bet. <daviid>ft: I know about the read syntax :), I was calling your own beast this 'bytevector-substr' which is probably easy to write using bytevector procedures. it does not sound good to me to turn it to a list first