IRC channel logs


back to list of logs

***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
<davexunit>there's no <<foo>> variable in my module :(
<paroneayea>davexunit: like this:
<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
<davexunit>yes, I did that.
<davexunit>paroneayea: no
<davexunit>the example doesn't work
<davexunit>using guile 2.1.4
<paroneayea>davexunit: oh
<paroneayea>ACTION forgot an --ad-hoc at shell
<paroneayea>ok yup davexunit , I'm also hitting that bug.
<paroneayea>davexunit: file a bug!
<paroneayea>davexunit: so that's two goops + srfi-9 bugs in guile 2.2 I guess
<paroneayea>guess some more testing needs to be done there
<nalaginrut>Artanis with the new server-core is likely to be released end of this year \\o/
<atheia>w00t, sounds cool :-)
<dsmith-work>Tuesday Greetings, Guilers
<OrangeShark>Tuesday greetings
<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>in the first example, baz must be a list.
<davexunit>and that list is transformed into additional arguments to goo
<davexunit>er, foo
<davexunit>1 + N args
<davexunit>whereas the second example is passing just 2 args to foo
<dsmith-work>davexunit: Yes! YOu are right!
<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.
<davexunit>no worries :)
<dsmith-work>davexunit: It's good to think about something sane every now and then.
<OrangeShark>hi amz3` o/
<wingo>ACTION ponders wisdom of adding handle-interrupts vm instructions
<wingo>good evening civodul
<civodul>heya wingo!
<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. :)
<daviid>ft: it has all C types
<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 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 ...
<daviid>ft: have to run bbl, good luck!
<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