IRC channel logs

<DeeEff>Hey guilers, I have a question regarding errors / catch in guile

<DeeEff>catch takes a third parameter which is basically a handler which accepts two arguments, key and "parameters", which describe the error that occured and was caught

<DeeEff>I was hoping someone could point me to the relevant documentation describing the structure of the parameters list that gets passed after an error is caught and the stack is unwound

<DeeEff>I guess I didn't phrase that as much of a question, but basically I want to walk through the parameters passed through and print some of them to (current-error-port) while not necessarily using all of them.

<mark_weaver>DeeEff: the parameters are simply the arguments passed to 'throw'.

<mark_weaver>each key has its own set of parameters

<DeeEff>ok, from what I can tell sometimes you get something like (even? Wrong type argument in position ~A: ~S (1 string) (string))

<DeeEff>is there an easy function to walkt through that list, or should I just make one myself?

<mark_weaver>I don't think we have much in the way of easy procedures for that. you could look at the code for the default exception printers in module/ice-9/boot-9.scm, searching for 'set-exception-printer!'

<zacts>hi guile (scheme) hackers

<mark_weaver>another option is to use R6RS exceptions and conditions, which are a newer and much better design. guile supports them.

<mark_weaver>the newest guile release (2.0.11) will automatically convert legacy guile exceptions into R6RS conditions if caught by an R6RS exception catching form.

<DeeEff>oh, I didn't know about those. I'll check them out.

<mark_weaver>DeeEff: out of curiousity, what are you trying to do?

<DeeEff>I'm writing a small unit testing framework for guile

<DeeEff>similar to quickcheck for haskell

<DeeEff>but I need to be able to catch errors that occur while tests are running

<DeeEff>It's a work in progress to say the least

<DeeEff> https://github.com/ThatGeoGuy/guile-quickcheck if you want to see the code in it's current form (select the develop branch, but keep in mind this is still pre-alpha)

<mark_weaver>DeeEff: Guile 2.0.11 has SRFI-64, and someone else wrote another testing framework for Guile recently as well. seems like there's a lot of redundant work being done in this area.

<davexunit>hello guilers!

<DeeEff>I suppose, but SRFI-64 doesn't do property based testing

<davexunit>so, I hear that guilemacs is alive and well!

<mark_weaver>hi davexunit!

<davexunit>hey mark_weaver!

<mark_weaver>DeeEff: ewhat is property based testing?

<mark_weaver>s/ewhat/what/

<DeeEff>basically, instead of writing static asserts, you write properties about your functions / objects, and test those with randomly generated data

<DeeEff>so for example

<DeeEff>(test-all even? gen-int)

<mark_weaver>oh, I see. I vaguely recall that ijp wrote a quickcheck style tester for guile, didn't he?

<mark_weaver>ijp: did you?

<DeeEff>should fail the test, since gen-int is a thunk which generates any int (within some range)

<paroneayea>davexunit: there was quite a lot of excitement in #emacs over it also :)

<mark_weaver>DeeEff: if you just want to print the exceptions nicely, there's "print-exception"

<DeeEff>is there?

<davexunit>paroneayea: excitement? I thought the folks in #emacs were more hesistant about it. good to hear.

<davexunit>I'm reading the #guile log on gnunet.org now

<mark_weaver>and that has the advantage of being extensible, where we will add new exception printers for it as new exception types are added.

<DeeEff>mark_weaver: this sounds like the best solution for me

<mark_weaver>it's not documented, but it should be.

<davexunit>bipt is so mysterious. you don't hear from bipt for months at a time, and then bipt shows up out of the blue and dumps a batch of awesomeness on us.

<DeeEff>davexunit: is bipt the one doing guilemacs?

<mark_weaver>heh, yeah, not ideal, but I'll forgive him for all the awesomeness he's given us :)

<DeeEff>I'd actually consider guilemacs with evil mode, if it's in a state that it could be used as a daily driver.

<davexunit>DeeEff: not at that stage yet, but things are getting so close

<paroneayea>from #emacs:

<paroneayea><bipt> also, it will make it far easier to add new language features to elisp

<paroneayea><bipt> e.g. i wrote an ffi.el in about fifteen minutes

<paroneayea>:)

<mark_weaver>whie compiling bipt's 'guile' (wip branch), it errored out while compiling 'ice-9/occam-channel.go', so I just touched that file and went on, since I don't care about that module.

<mark_weaver>hmm, failed with the same error in system/foreign-object

<DeeEff>mark_weaver: you mentioned print-exception is not documented, what is the "frame" argument it takes in?

<davexunit>paroneayea: thanks

<mark_weaver>DeeEff: you can pass #f for that argument.

<mark_weaver>it's the stack frame object where the error occurred.

<DeeEff>strange, I keep getting an error saying I passed too many arguments

<DeeEff>(apply print-exception (current-error-port) #f key parameters)

<mark_weaver>remove 'apply' from that.

<mark_weaver>the last argument is the list of arguments passed to the handler.

<DeeEff>doh

<mark_weaver>alas, bipt's 'guile' wip branch doesn't compile for me. I get "No variable named class-of in #<directory (guile-user) ...>"

<davexunit>rats

<mark_weaver>with some of the later modules

<mark_weaver>I guess it might not be hard to fix, but I should probably work on something else and try again later.

<daviid>maybe he 'just' forgot to import goops

<mark_weaver>well, I'm going to touch that .go file also and continue. I don't think I need either of those modules.

<mark_weaver>bipt: fwiw, on your 'wip' branch of guile, I got errors while trying to compile (ice-9 occam-channel), (system foreign-object), and (oop goops active-slot).

<mark_weaver>same error in all cases: "No variable named class-of in <some module>"

<mark_weaver>so far they have been modules I don't need, so I've been touching the .go files and continuing.

<mark_weaver>I suspect that if I had started from a built master and then applied your patches, none of those files would have been rebuilt anyway.

<mark_weaver>seems to happen with many of the modules that use class-of.

<mark_weaver>(it's also happening with most of the modules in (oop goops ...)

<mark_weaver>I think maybe a reasonable workaround for now is to compile current guile master first, and then switch to bipt's wip branch and then 'make' again.

<mark_weaver>though what I ended up doing was copying the .go file from a built master branch for any file that failed to compile. they all seemed unlikely to have been changed on his branch anyway.

<mark_weaver>I also encountered several errors about a missing variable 'cache-miss'

<mark_weaver>well, the built guile mostly works anyway, probably enough to run guile emacs just fine. I am proceeding...

<paroneayea>mark_weaver: did ya get emacs to work with it? or still compiling? :)

<ijp>mark_weaver: I did, and I do occasionally use it

<ijp>but it's nothing special

<dsmith-w`>Wow. Great news form bipt!

***dsmith-w` is now known as dsmith-work

<paroneayea>hi *

<paroneayea>dsmith-work: yeah :)

<ft>What news?

<paroneayea>ft: guilemacs works, with some caveats

<ft>paroneayea: oh? You got an URL to where this was reported? :)