IRC channel logs

2014-04-12.log

back to list of logs

***fangism-ctrl-Z is now known as fangism
<didi`>Which module exports `compile-file' and `compiled-file-name'?
<didi`>(system base compile)?
<dsmith-work>didi`: I think so
<didi`>dsmith-work: Cool.
<dsmith-work>Though I think boot-9 autoloads it
<dsmith-work>compile-file anyway
<didi`>dsmith-work: It doesn't seem to do it here, but that's OK.
<ijp>it may only autoload it when guile is used interactively
<ijp>for whatever reason, we do that for (ice-9 threads) and (ice-9 regex)
<dsmith-work>Enter `,help' for help.
<dsmith-work>scheme@(guile-user)> compile-file
<dsmith-work>$1 = #<procedure compile-file (file #:key output-file from to env opts canonicalization)>
<dsmith-work>
<dsmith-work>ya
<ijp>(define-module (guile-user) #:autoload (system base compile) (compile compile-file) #:filename #f)
<ijp>so it *should* work in scripts, I think, just not modules you define yourself
<didi`>ijp: Ah!
<didi`>ijp: So that's our reason.
<dsmith-work>Hey, I've got an image pinned up on my wall. The title has "The Sacred Text of Gerald J. Sussman Confounds the Python Heretics. 2009 A. S."
<dsmith-work>I can't find it anywhere. Anyone ever seen that?
<dsmith-work>Has angels holding books with lambdas and old bearded guys in robes cringing in anguish.
<dsmith-work>Probably some famous painting that I am ingorant of.
<dsmith-work>It's 6 sided
<ijp>I have certainly seen it, though I have no idea where
<didi>I've never seen it.
<ijp>I've probably got a copy on one of my dead hard drives
***ijp is now known as ijp-ccbyncsa
***ijp-ccbyncsa is now known as ijp
<dsmith-work>ijp: If you ever come accross it again, please direct me to it.
***fangism is now known as fangism-ctrl-Z
<vinek>Does anyone mind if I ask what OS/distro do the guile developers run? I'm trying to install guile from git and I get: configure.ac:41: require Automake 1.12, but have 1.11.6 \\n autoreconf: automake failed with exit status: 1
<vinek>
<vinek>So I have to upgrade automake...fine. But I'm running Debian stable.
<vinek>Wheezy.
<vinek>I guess I can install Debian testing.
<vinek>I just wonder if I should do that to keep up with development. So far I've just been downloading and installing packages that are needed manually. I didn't realize I'd have to do that for core packages like automake.
<ijp>if you are running from git, you would do well to satisfy the dependencies
<ijp>there is automatic testing for a bunch of OSes
<ijp>hmm, no sneek
<ijp>I can never remember the hydra url
<ijp> http://hydra.nixos.org/jobset/gnu/guile-master
<ijp>vinek: as a rule, you should use the stable branch, rather than master
<ijp> http://hydra.nixos.org/jobset/gnu/guile-2-0 is probably a better link actually
<vinek>Yeah...maybe I should try the last stable release.
<wingo>meep meep
<stis>hej guilers!
<ksinkar>How do I connect to a remote guile instance from my emacs?
<ksinkar>I know we can do it in Common Lisp using slime and swank. Is there any way to do it in Guile
<ft>geiser
<wingo>ksinkar: M-x connect-to-guile; see geiser manual
<dje42>When's the last time someone reviewed the smob section of the manual?
<wingo>uf, probably been a long time
<dje42>Now's a good time. :-)
*davexunit has 35000 particles rendering at 60 fps with guile-opengl :)
<davexunit>only linear motion right now, though. no sqrts or anything in the update procedure.
<davexunit>and this is also without composting. :)
<davexunit>I never thought I would see this kind of performance.
<davexunit>at least, not without using guile master and compost.
<wingo>sweet :)
<wingo>i think with compost i managed to get some huge number of particles fwiw, a few hundred thousand
<wingo>but i am currently breaking compost by changing things in master's compiler
<davexunit>wow a few hundred thousand is great.
<davexunit>I used the GL instanced rendering extension along with the proper GLSL shader.
<davexunit>I instance the same textured quad 'n' number of times with different positions.
<davexunit>for my purposes, ~30000 is way more than good enough for now.
<wingo>did you switch to guile-opengl, btw?
<davexunit>wingo: yes I did.
<cbsw>how to use guile web module to post data? (http-post "http://www.example.com" #:body "name=admin&password=secret") this is actually a get request not post
<ijp>cbsw: which version are you using?
<ijp>this should have been fixed already
<cbsw>ijp, 2.0.9
<cbsw>I'm using debian
<ijp>the bugfix may have came after 2.0.9, let me check
<ijp> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15908
<ijp>so yes, it was fixed after 2.0.9
<wingo>yep that bug was my fault, sorry about that
<ijp>cbsw: the report links to a workaround
<ijp>alternatively, you define the new version yourself in (web client) through save-module-excursion &co.
<cbsw>How do i fix it as i'm using debian wheezy testing
<ijp>as I just said
<cbsw>ijp: download new client.scm and replace the old one?
<ijp>that is a third way
<cbsw>ijp: Could you tell me more details as I'm not very familiar with guile
<ijp>the bug report above links to a workaround, which is basically that you need to explicitly pass the content-length header
<ijp>the second way, is to have some sort of fixes.scm that you load in your app that does (define previous-module (set-current-module (resolve-module '(web client)))) <new definition of extend-request from the patch> (set-current-module previous-module)
<ijp>which won't actually work, now that I think about it
<ijp>save-module-excursion would, but then you'd need to fiddle a bit, so that you aren't making an internal define
<ijp>try loading https://gist.github.com/10543607
<ijp>d'oh
<ijp>okay, now try it
<cbsw>ERROR: No variable named extend-request
<cbsw>extend-request is not exported in client.scm
<ijp>hmm, I'm not sure why being exported is relevant there
<cbsw>I think extend-request is a procedure only accessible inside client module without exporting it
<ijp>I know that
<ijp>but that's why I changed the current module
<ijp>I guess I should change it to an eval, or something
<ijp>cbsw: just add the content-length header
<ijp>it's a pain, but it'll be simpler than me making umpteen more mistakes
<ijp>I've got a working gist this time, https://gist.github.com/10543607
<ijp>when civodul comes on, I'm going to ping him and find out how he does this in guix, because there has to be a less ugly way
<cbsw>ijp: This one works, thanks
<cbsw>ijp: By the way, did you edit the gist just now? Here it shows revised 8 hours ago.
<ijp>time travel
<ijp>cbsw: maybe a time zone thing
<cbsw>ijp: Yeah, i think so
<mark_weaver>cbsw, ijp: make sure not to apply that workaround to guile 2.0.10 or later.
<mark_weaver>also, the simpler way to fix it is to (set! extend-request (lambda (r k v . additional) ...))
<mark_weaver>no need for a module excursion.
<mark_weaver>cbsw: the simpler way to fix it is to (set! extend-request (lambda (r k v . additional) ...))
<mark_weaver>cbsw: also, you should avoid doing that on guile 2.0.10 or later.
<mark_weaver>there's no need for a module excursion, just (set! extend-request ...) in your own module.
<mark_weaver>s/your own module/any module that imports it/
*wingo doing closure optimization, whee
<stis>swedan does the wave!
<stis>err seden
<stis>err sweden, argh
<wingo>:)
<cluck>no more vodka for stis today :)
<ijp>mark_weaver: the reason for the excursion was to handle imports
<ijp>which, as it turns out, did not work because I misinterpreted how toplevels were handled
<mark_weaver>ijp: what do you mean by "to handle imports" ?
<ijp>e.g. request-headers
<ijp>that is defined in (web request), and is imported by (web client)
<ijp>so, the hope was that by cleverly changing module, I wouldn't need to worry about that
<mark_weaver>oh, well, it's true that you need to import (web request)
<mark_weaver>in whatever module contains the 'set!'
<mark_weaver>but in Guile, when you import 'extend-request', you import the entire mutable variable. if you mutate it with 'set!', that changes it in the entire session, i.e. in all modules that import 'extend-request' past or future.
<mark_weaver>this is not the case for R6RS or R7RS though.
<ijp>indeed
<mark_weaver>oh, I see. 'extend-request' is not even exported.
<mark_weaver>so I guess it would be (set! (@@ (web client) extend-request) (lambda ...))
<tupi>hello guilers. make generate-defuns [doc/clutter] gives me this error http://paste.lisp.org/display/142016 [note that clutter-actor-meta.xml is not new, it is in clutter since 1.4]. should I report a bug or could it still be a malformed xml expression?
<tupi>when updating guile, do i have to recompile the all chain as well, g-wrap, cairo ... clutter, guile-lib ...?
<mark_weaver>tupi: you shouldn't have to except when switching between major versions (e.g. 2.0.x -> 2.2.x)
<dje42>Besides outdated calls to scm_set_smob_mark, the docs in the smob section of the manual suggest a careful ordering is required when initializing a smob.
<dje42>I understand the reasoning behind it, but is it being overly cautious?
<dje42>E.g., In the example in libguile-smobs.texi, what would happen if image->name was initialized with name directly, instead of first SCM_BOOL_F and later with name ?
<dje42>Hmmm, I see the "Let us look at what might happen" section of this file has been removed (compare 2.0.9 vs git), so the overly cautious prose has been removed from the docs, but not the overly cautious code (I think).
<mark_weaver>yeah, I don't know why the example doesn't initialize image->name to name directy.
<mark_weaver>*directly.
<dje42>If you read the 2.0.9 version of the text it says "why", but I don't think that description is valid (or at least not anymore).
<dje42>So the prose got deleted, but the code is left with this oddity.
<mark_weaver>even in the older days, I don't see why image->name could be initialized to 'name' directly.
<mark_weaver>s/could/couldn't/
<tupi>mark_weaver: ok tx
<dje42>Still, I think if the code is updated, it would be really useful to the reader to explain why it's valid. E.g., even though scm_new_smob may cause a garbage collect, the pointer to image is on the stack and thus the contents of image is protected.
<dje42>Well, s/on the stack/on the stack or in a register/
<mark_weaver>sure, though that's a very fundamental requirement of the garbage collector..
<mark_weaver>but I suppose there's no harm in repeating it.
<dje42>Righto. But for newbies, it helps to have such things reinforced.
<dje42>And this seems like a good place to do so.
<mark_weaver>*nod*
<dje42>Righto.
<mark_weaver>sounds reasonable :)
<stis>hey check out : http://c-lambda.se/guile-log/prolog.html#prolog
<stis>WDYT ?
<wingo>looks nicely done!
<stis>Well it's thanks to you guys, and a hell of a lot of work ;-)
<ijp>Hemann and Friedman have a paper on yet another currying macro for scheme, colour me unimpressed
<ijp>it's better than most, but at the cost of making function application stupidly costly