IRC channel logs
2013-10-23.log
back to list of logs
<dsmith>mark_weaver, An interesting happened on my rpi today <dsmith>mark_weaver, Running the bare "guile" command gets a backtrace and then a segfault. <dsmith>guile --version is happy. As is --help <mark_weaver>fwiw, I regret recommending the rpi. I did't know that it required a big binary blob to even boot :-( <dsmith>Something with the repl apparently <dsmith>Is 1 a reasonable value for the last arg to scm_call_1 ? <dsmith>#3 0xb6ed9724 in scm_call_1 (proc=0x35c880, arg1=0x1) at eval.c:486 <dsmith>probably is SCM_EOL or something <dsmith>#4 0xb6ec469c in display_application (frame=0x30f550, indentation=-1225676836, sport=0x30f500, port=0x3, pstate=0x394c10) at backtrace.c:263 <dsmith>Here is the first thing that looks bogus to me <dsmith>#24 0xb6f5df78 in vm_regular_engine (vm=0x153fe0, program=0x15a858, argv=0xb1e50, nargs=-1231733432) at vm-engine.c:129 <dsmith>There is a lot of nargs that don't look right <dsmith>Hmm. 1418224 (nargs) is 0x15a3f0 <mark_weaver>it might be that nargs is not being shown properly, because of optimization interfering with debugging or something like that. <mark_weaver>#23 0xb6f531d8 in vm_error_wrong_type_apply (proc=0xb6f9a4ec) at vm.c:504 <dsmith>Annotated with another backtrace, withouht --no-debug <mark_weaver>I wonder if something got corrupted on your filesystem. <dsmith>Not out of disk. Not out of ram. <mark_weaver>nargs looks more reasonable in all those. I think the nargs things was a red herring. <mark_weaver>it looks like it begins with trying to apply something that's not a procedure, but then it crashes while trying to print the error message. <mark_weaver>presumably because of some deeper problem that got things in a bad state. <dsmith>Well, /usr/local/share/guile/2.0/system/repl/repl.scm looks ok <mark_weaver>it wouldn't be using that anyway. it would use the .go file <mark_weaver>but the last thing is was trying to load was system/repl/debug <dsmith>I tried ./meta/guile from the build dir <dsmith>guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting ~A): ~S (exact integer #(#f # <dsmith> #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f))) <dsmith>Cannot exit gracefully when init is in progress; aborting. <mark_weaver>presumably this was all working at some point, which is exact build, right? <dsmith>Yes. No problems with the build. <mark_weaver>well then, I see two possibilities: (1) something got corrupted, or (2) some raspbian update changed something that broke your guile build. <mark_weaver>or I suppose (3) you updated and installed some shared library that guile uses, that broke guile. <dsmith>make check tries to build binary-io.lo and fails with <dsmith> /usr/include/arm-linux-gnueabihf/sys/types.h:147:20: fatal error: stddef.h: No such file or directory <dsmith>I don't remember doing any updates though. <mark_weaver>sounds like filesystem corruption to me. remember that flash devices lose blocks from time to time. <dsmith>I suspect the sd card might be corrupt <dsmith>mark_weaver, Thanks. I'm not going to be able to mess with this any more tonight. <dsmith>dpkg-query: warning: files list file for package 'libatasmart4:armhf' missing; assuming package has no files currently installed <dsmith>dpkg-query: unrecoverable fatal error, aborting: <dsmith> unable to open files list file for package `hicolor-icon-theme': Input/output error <dsmith>A reboot or restart will probably be the end. <mark_weaver>can you dump his state somewhere such that it won't be lost? <mark_weaver>it might just be that a relatively small number of files have gone missing. it might be as simple as restoring this files. <mark_weaver>when I used an OLPC XO-1 a lot, that's what I noticed. files would go missing from time to time, so I had to restore them from backup. <mark_weaver>for the files that are part of debian, it might be sufficient to reinstall the associated packages. I forgot the flag, but there's an option to force reinstall of an existing package. <mark_weaver>and then you might be able to restore the missing files in your guile build directory using 'make'. <mark_weaver>which shouldn't take anywhere near as long as rebuilding all of guile from scratch. <shanecelis>ok, SCM_VARIABLE_INIT(c_name, "scheme-name", X) places what values in c_name and scheme-name? I thought it would just be X, but is it instead a variable that holds X? <mark_weaver>shanecelis: well, 'scheme-name' doesn't hold a variable object, but 'c_name' will. <mark_weaver>the idea is that if someone does (set! scheme-name blah) from scheme, you'll see the new value the next time you do scm_variable_ref (c_name) <shanecelis>Hmm... my work around to get GC to happen for some objects in a preferred thread appears to sometimes not work. It looks like there's a race condition. Is there any way to block GC for a section? <shanecelis>Hmm... well, this seems to work: Empty the guardian then run the GC in a critical section. <dsmith>nalaginrut, Yes. sneek has been running there for quite some time. <mark_weaver>Raspberry Pi actually turns out to be a very bad option among the cheap single-board computers. <mark_weaver>it has a bizarre architecture such that the GPU (which requires a big binary blob) is needed to boot the rest of the computer. <nalaginrut>yes I agree too, but its ecosystem was built well, so many guys who want to startup a prototype of a product will choose it, and my team choose it in the very beginning too <synacktic>Is it possible to use ",br" with GOOPS methods? <synacktic>I tried setting breakpoints on methods but they never seem to do anything. It works perfectly with regular procedures though <mark_weaver>well, presumably ,br expects a procedure, not a method. <mark_weaver>however, there *is* a procedure associated with every method. the trick is getting the procedure object. <mark_weaver>it's certainly possible, but I'll have to look into how to get it. <ijp>synacktic: using goops is non-typical <synacktic>I just refer to it by the name of the generic <mark_weaver>well, the generic function is distinct from a method. several methods can be associated with a single generic. <ijp>hmm, generics are applicable structs, so that might be something to do with it <synacktic>I wasn't really sure how else to refer to the method <mark_weaver>most of us here don't do much object-oriented programming, but IMO goops is quite nice for that purpose, in the few cases where I think it's appropriate to use OO programming. <synacktic>That's really interesting. Is that common among schemers? <mark_weaver>most of us here tend to prefer the functional programming style. <mark_weaver>the "OO programming style" as usually understood is typically dominated by lots of mutable state. <mark_weaver>(though there are OO systems that don't involve mutation, such as in Haskell) <synacktic>Can you use generics outside of an object system? <ijp>presumably they work on records <mark_weaver>I don't know how to answer that question because I don't know what you mean by "generics" or "object system". Both of vague terms. <mark_weaver>synacktic: anyway, to try to answer your original question... I think ijp is right that the problem is related to the fact that generics are applicable structs. (procedure <APPLICABLE_STRUCT>) should return the procedure associated with an applicable struct. <mark_weaver>so you might be able to say ,br (procedure <GENERIC>) <mark_weaver>we should probably fix ,br to do that automatically, but for now, I'd be curious if that works. <mark_weaver>however, if it works, that's going to dump the debugger into the GOOPS machinery for looking up the appropriate method, which is probably not ideal. <ijp>you get the top level handler, not the specific <synacktic>I'm going to try to rewrite my code without GOOPS. I'm new to scheme and I'd like to learn how to write it as idiomatically as possible. <mark_weaver>I'd have to dig into GOOPS to find out how to get the procedure associated with a specific method, but 'compute-applicable-methods' is probably the starting point. <ijp>synacktic: please report to ^^ or it will get forgotten <mark_weaver>ijp: when you wrote "it will" what were you referring to? <mark_weaver>ijp: did you mean: ,br (procedure <GENERIC>) will work? <ijp>yes ,br (procecure <generic>) gives you the top procedure (before dispatch) <synacktic>What would be the bug exactly? ",br confusing to use with GOOPS"? <mark_weaver>more generally, it probably doesn't work for any applicable struct. <ijp>just say what you did, what you expected, and what actually happened <mark_weaver>synacktic: you can keep it short and sweet. bug reporting needn't be a big job, but it's very helpful. <ijp>okay, the procedure gets passed down to frame-matcher, where it compares with eq <ijp>since the frame procedure is never going to be the applicable struct, it never succeeds <ijp>it's a little weird that applicative structs return #t for closure? <ijp>.oO(what is the distinction then between closure? and procedure?) <mark_weaver>synacktic: how are you learning scheme? are you working through a book? <ijp>I think frame-matcher is probably the right place to fix this <synacktic>Basically I'm just using a reference and trying to implement some little problems <ijp>other calls up the stack are public, and may pass in their own matcher <synacktic>I was recently reading A New Kind of Science, so I decided to implement the cellular automaton he described in there <ijp>wolfram seems like an arsehole <mark_weaver>synacktic: I don't think you will get much out of trying to simply use Scheme to implement things in the same way you've learned in other languages. <mark_weaver>synacktic: in order to help me make a recommendation, may I ask what your skill set is? what programming languages are you used to working with, and how comfortable are you with math? <ijp>okay, I have a hack that will work for applicable structs, but not dispatch for goops objects <ijp>that one will require more thought <mark_weaver>ijp: excellent! thanks for your work on bugs lately. <synacktic>I'm a college student, taking Calc 1 and "Discrete Structures I" right now. (Discrete is more interesting, imo.) I'm most comfortable with C, followed by Python. I dabble in a lot of languages. As far as functional languages go, I've written a little bit of Haskell, but not much else. (A cellular automaton, in fact.) <synacktic>I can also write Java and C++ if my grade depends on it. <synacktic>Oh, and as far as how comfortable I am with math, I can only speak from my experiences with those classes I mentioned but I'm very comfortable with them. I've actually considered majoring in math before. Formal logic is pretty cool, imo. <synacktic>The cellular automaton in Haskell was implemented as a lazy infinite 2D list, which imo was really cool, but I'm not sure how I would do that in scheme. (Also it caused my computer to start swapping after a while.) <ijp>streams are in (srfi srfi-41) <synacktic>For some reason I don't have (srfi srfi-41) on my machine <ijp>it may have only been added after 2.0.5 which is probably what you have <ijp>there is (ice-9 streams) but I would not recommend it <synacktic>Do you guys keep the stable releases as tags in the git repo? <mark_weaver>yes, but I'd just use the 'stable-2.0' branch. or you can just install 2.0.9 <ijp>looks like it was a 2.0.8/9 addition <mark_weaver>synacktic: you're using Debian or a derivative, right? if so, do "apt-get build-dep guile-2.0" which should install everything you need to build the upstream guile-2.0.9 tarball from source. <mark_weaver>to build from git, you'll also need automake 1.13 or newer, which is in saucy but not in anything older. although the automake package doesn't pull in any other new dependencies, so you should be able to install it from saucy on an older system without upgrading anything else. <mark_weaver>or you can use the guile-2.0.9 tarball, in which case you don't need automake at all. <synacktic>I just figured it would be easier to upgrade later if I used the git repo <mark_weaver>fwiw, I have extensive experience with Debian, and although most of the time it's a bit dangerous to try to upgrade individual packages from a newer release, in the case of automake it's perfectly safe and self-contained. <mark_weaver>if you use the git repo, make sure to checkout the 'stable-2.0' branch. <wingo>ijp: link to your peval bug? <ijp>wingo: things are okay, paracetemol just kicked in so I don't have a headache now :) <wingo>ijp: that change looks good, nice catch <wingo>i was incidentally doing something similar in the thunk? folder just now <wingo>fix the indentation of the "if" though :) <ijp>hmm, how'd I forget that <ijp>wingo: btw, do you know what the purpose of closure? is? <ijp>no, this is related to a different bug <wingo>my email is in shambles right now unfortunately <ijp>well, it's not directly related <ijp>I saw a use of closure? in some code, and while that one turned out to be a paramter, I couldn't figure out how closure? was supposed to differ from procedure? <wingo>i don't think it's a globally bound thing <ijp>it is available in (guile-user) <ijp>it was a red herring anyway, but I got curious <ijp>I have a fix for that bug too <ijp>I must have turned off deprecation warnings and forgotten abou tit <ijp>wingo: how do you make sure a peval test isn't too fragile? <wingo>ijp: you can't, really -- try to make it small, that's all <nalaginrut>I found gpc stands for guile-python on savannah, it's started before 2003, and seems die. I think the work much easier in Guile2, hmm...maybe too optimistic <wingo>implementing a language is a lot of work, yo. <wingo>yep, because the parser is a lot of work, and you have to implement a runtime, and the standard libraries <nalaginrut>so 'hard' means 'a lot of work', or 'some points is too complicated' ? <nalaginrut>maybe it's related good news to find a way to go, or there's no way for some guys. Some complicated things may need genius mind... <ijp>hmm, when I try writing tests, it wants to use a toplevel apply, rather than a primitive apply, which means it isn't coming up <ijp>I've tried a few different variants, but none of them have used (primitive apply) <wingo>why not simplify by removing the (if (pair? _) (set! l foo)), change to (set! l foo) <wingo>ijp: pass resolve-primitives <wingo>e.g. (pass-if-peval resolve-primitives code pat) <wingo>again, in master this is different... <ijp>well, if it wasn't a conditional, I'd have expected it (though I didn't try) to inline it <wingo>currently peval does nothing if a variable is ever set! <ijp>it also makes the test case look kinda confusing <wingo>and that is likely to continue being the case <wingo>dunno, as you like -- I would go for the smaller test, but whatevers :) <ijp>resolve-primitives looks like it was what I was after <tupi>hello guilers. mark_weaver, reading the log... note that debian now has guile 2.-.9+1-1 ..., for info