IRC channel logs
2014-02-09.log
back to list of logs
<jcca>Hi, I want compile guile from git (master branch) but does not compile. I get GUILEC ice-9/psyntax-pp.go GC Warning: Failed to grow mark stack to 268435456 frames <mark_weaver>jcca: if you're using 7.4.0, then you need to set GC_MARKERS=1 in the environment with master, for now. or, get the latest git version of libgc. *ggrant plans on porting scheme/guile to "learn x the hard way" as an educational experience. :^) *ggrant might start rewriting his old intro in skribillo though. *ggrant wants to start getting back into Guix, but won't likely be able until he can switch over his whole environment to it. :^/ <jcca>mark_weaver: Thanks, yep I am using 7.4.0. I will try it. <jcca>mark_weaver: Same result :( <mark_weaver>you're sure that GC_MARKERS=1 was set in the environment while doing the compile? <jcca>yes, I am sure, but now I don't get the issue. Now I see "GUILEC ice-9/eval.go" and is stagnant <mark_weaver>well, the first few files take a long time to compile. <mark_weaver>the reason is that the compiler has not yet been compiled, so it's being interpreted. <mark_weaver>as more and more files are compiled, the compiler gets faster. <jcca>Oh, I will wait, thanks a lot for your help. <lloda>wingo: 'bout cf64dca65c4ee4d845a73e7d7c15ab7583aff15b <lloda> scm_array_get_handle (SCM_I_ARRAY_V (array), &h); <lloda> h->base = SCM_I_ARRAY_BASE (array); <lloda> h->ndims = SCM_I_ARRAY_NDIM (array); <lloda> h->dims = SCM_I_ARRAY_DIMS (array); <lloda>hm, also h->array = array I guess <davexunit>impaktor: use this: (set! *random-state* (random-state-from-platform)) <mark_weaver>impaktor, davexunit: well, that's how to set the seed as randomly as possible. <impaktor>just got it to work by having the state as the second arg to random <mark_weaver>impaktor: if you wanted to affect all uses of the random number generator in the whole guile process, then you'd set *random-state*, which is used as the default if you leave off the 'seed' argument to the individual procedures. <mark_weaver>but if you set a "bad" seed, it's probably better to pass it explicitly. <mark_weaver>(also, if you want to control the evolution of that seed) <impaktor>no biggy. Just working on exercise from SICP, ch 3. thanks <amoe>hi there, does guile-lib currently work with guile 2.0 series? <mark_weaver>amoe: apparently so, since GNU Guix has a guile-lib package that's built for guile-2.0. <mark_weaver>amoe: guile-lib supports guile-2 since 0.2.0. best to use 0.2.2, the latest. <jemarch>civodul: adding templates-on-steroids and support for cooked fields to recutils :) *davexunit is adding support for GLSL shaders in guile-2d <davexunit>sort of primitive right now, but I wrote a neat let-like macro for binding variable values to shader programs. :) <Yawar>mark_weaver: i tried to leave a delayed message for you yesterday, but apparently freenode doesn't have that feature :-) anyway i got the test runner working--thanks for the suggestions! am about to send an announcement to the guile-user list: https://github.com/yawaramin/ggspec/releases/tag/v1.0 <mark_weaver>oh, you're targetting guile-1.8 only? that's too bad. <mark_weaver>guile-1.8 has been unsupported for years. lots of known bugs that will probably never be fixed. <Yawar>i know, but this whole thing grew out of my need to test stuff in the second-latest stable release of gnucash, which ships with 1.8. <Yawar>but targeting guile 2 is definitely in my plans <mark_weaver>fwiw, I'd remove the claim that the tests are "completely isolated from each other". unfortunately, there's lots of global state, global options, locale settings, etc. simply unbinding the definitions is not nearly enough to make that claim. <mark_weaver>there's no magic bullet to improve this, I'm afraid. either save/restore all the global state that you can think of, or run each test in it's own guile session (obviously too inefficient). <Yawar>mark, i think i warn of this with the 'unless you're setting global variables' caveat ...? <mark_weaver>well, there are a lot of procedures that mutate global state, or even thread-local state, behind the scenes, where the user is not explicitly setting a global variable. <wingo>very interesting, dunno what to think about it :) <mark_weaver>well, having not read the whole thing yet, I've long known that there's the problem of estimating how much entropy is in the pool. <mark_weaver>if you count bad sources toward that estimation, then you can overestimate the amount of entropy, and that's bad. <Yawar>hmm. yes that's a good point ... i'll change my wording :-) <wingo>sometimes i think we should have our rng be a csprng; not much point in doing otherwise, these days... <mark_weaver>also, we should all upgrade to openssh-6.5p1, I think. <wingo>link? i don't think i saw that vuln <mark_weaver>just that it supports all of DJBs stuff. new private key types, new diffie-helman, new ciphers, based on Curve25519, etc. For those of us who worry that the other common things have been weakened by the NSA. <mark_weaver>I confess I'm not a real cryptographer -- I can't evaluate the relative strengths of these algorithms -- but it seems that Curve25519 is very popular among those who worry about the NSA, including the Gnunet folks. <mark_weaver>a lot of the other algorithms use mystery parameters that came from the NSA. (and that's not a conspiracy theory, just an undisputed fact) <wingo>mark_weaver: do you think guile should ever automatically seed its rng? <mark_weaver>my gut feeling (I've been doing a lot of thinking with my gut lately :) is that it should be the programmer's responsibility. <mark_weaver>it's potentially expensive to do the job right, and it's not always needed. <wingo>how expensive is it, I wonder? <mark_weaver>and on some platforms, we may not have the necessary code/knowledge to do the job right. <wingo>cue another djb rant, about the lack of a syscall for getting randomness <mark_weaver>also, security sometimes demands determinism as well. <dsmith>freecode.com/projects/gc/releases/361403 7.4 <wingo>sure, i'm not arguing that we remove the capability to set a seed; just wondering if we should randomly seed by default <mark_weaver>well, some platforms don't have any good entropy source, in which case we may block waiting for /dev/random. <mark_weaver>well, if we use /dev/urandom, then we might not be getting any entropy at all. <mark_weaver>I don't want to lull programmers into a false sense of security, I guess. I want them to have to think about it. <mark_weaver>well, I dunno. I don't have a clear thought on this, just gut feelings :) <wingo>i guess that doesn't prove anything though, and is somewhat unrelated... <mark_weaver>I can certainly see the argument on the other side. maybe we should make a best effort to initialize *random-seed*, and make it crystal clear in the docs that we don't guarantee how much entropy (if any) is in there. <mark_weaver>but here's the thing: I worry that some people might not read the docs, and just assume that *random-seed* is really randomized. <wingo>it's not clear how much you can help those people, though :/ <mark_weaver>if it always starts at the same value, then it won't take much for them to see that. <mark_weaver>and then they'll look for a way to initialize it, and we provide such a way, but then they'll *have* to read the doc, and there it warns that it's not necessarily sufficient for cryptographic purposes. <wingo>djb does use /dev/urandom for cryptographic purposes though... <mark_weaver>(also, I suspect that on Windows, and possibly on some other system, 'random-state-from-platform' doesn't work very well at all. <wingo>well, something to mull over :) <wingo>otoh we could warn at first use of random, if the seed was not set <mark_weaver>well, fwiw, my mind is open on this. I could probably be convinced either way. <foeniks>what is the preferred way of unit testing in guile scheme scripts? <wingo>i suspect that we should automatically seed, and at least should warn before using the default seed <wingo>but i'm not going to change anything there right now <Yawar>foeniks: the official recommendation is srfi-64 <wingo>and will get back on the email horse before doing anything about it :) <mark_weaver>foeniks: I recommend SRFI-64. we recently added it to guile git, and it'll be in 2.0.10, due out soon. <mark_weaver>foeniks: but the reference implementation of SRFI-64 works with any earlier version of guile as well. <Yawar>... but just fyi there are others to choose from if you want to find one that 'fits' better <mark_weaver>Yawar: fwiw, I think that SRFI-64 would have fit your purposes just fine, but I can certainly sympathize with having a preference for one's own code (especially if you already wrote it :) <Yawar>mark, actually i think ggspec does a couple of things that srfi-64 doesn't right now :-) e.g. the automated subdirectory test runner, and re-running all setups before _each_ test <mark_weaver>loading all files from a directory can be done in a couple of lines of code, with SRFI-64. setups/teardowns can likewise be done with a simple macro, with SRFI-64. <mark_weaver>and on the flip side, I suspect that SRFI-64 can do several things that yours can't do yet. <Yawar>absolutely agreed on the latter :-) <mark_weaver>anyway, there's room for multiple test suites. but SRFI-64 is portable and a lot of work went into it. I don't see a reason to re-invent that wheel without proper investigation. and I think that any such investigation would find that it would easily do what you need. <Yawar>about the former: well, yes you can roll your own directory test runner with srfi-64. but my understanding is the `test-group-with-cleanup` form does all setups _once_ and then runs the tests in the group <Yawar>ultimately, i feel it's about 'fit'. sometimes it's just true that ppl feel more comfortable doing things a certain way than doing them another way <Yawar>foeniks: my understanding is srfi-64 is made to scale up from very simple tests to complex test suites. so you can start out with simple one-liners and later move on to setups, teardowns, etc. <mark_weaver>if you want setup/teardown around each test, then you can use 'test-group-with-cleanup' for each test. it's trivial to write a macro to expand into that, to make it less verbose. <mark_weaver>btw, here's an anecdote: Guile has it's own historic test suite that we've never exported, used just within Guile. SRFI-64 <mark_weaver>SRFI-64's test suite is, of course, written in itself. <Yawar>very true. you make a very good argument that ggspec could simply be implemented using srfi-64 at a lower level. and i may end up doing that.... <Yawar>(btw, so is ggspec's test suite) <mark_weaver>so I had to adapt it somehow. but because SRFI-64 allows users to create custom test runners, I was able to adapt it to report its findings to Guile's own test suite in just a few lines of code. <mark_weaver>I was able to do that because a lot of effort went into making SRFI-64 extremely flexible. <mark_weaver>(it's custom test runners are also used in its own test suite, to accumulate the results of the inner tests, comparing the results with the expected ones) <Yawar>fwiw, i've built similarflexibility into ggspec as well in the form of runtime message callback functions. new callback functions can be written to report results in different formats: e.g. quiet, normal, verbose, xml, json, what have you <Yawar>(not to mention as lisp-y lists) <foeniks>so srfi 64 is not yet in the master branch? <mark_weaver>but it was merged only recently into master, so maybe you need to pull. <mark_weaver>Yawar: I don't doubt that you've done a fine job. I just wonder if it was worth reinventing the wheel from scratch. <Yawar>for me, it was (& is) worth it. for others, they'll have to decide for themselves :-) <mark_weaver>but I confess that I tend to reinvent wheels myself sometimes. <madsy>Unused rest parameters are by default SCM_UNDEFINED, right?