***fangism-ctrl-Z is now known as fangism
<didi`>Which module exports `compile-file' and `compiled-file-name'? <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>$1 = #<procedure compile-file (file #:key output-file from to env opts canonicalization)> <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 <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>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. <ijp>I have certainly seen it, though I have no idea where <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>So I have to upgrade automake...fine. But I'm running Debian stable. <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>I can never remember the hydra url <ijp>vinek: as a rule, you should use the stable branch, rather than master <vinek>Yeah...maybe I should try the last stable release. <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 <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 *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>I never thought I would see this kind of performance. <davexunit>at least, not without using guile master and compost. <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>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? <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 <ijp>the bugfix may have came after 2.0.9, let me check <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 <cbsw>ijp: download new client.scm and replace the old one? <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 <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>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>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>cbsw: maybe a time zone thing <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>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. *wingo doing closure optimization, whee <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 <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>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>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. <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. <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.. <dje42>Righto. But for newbies, it helps to have such things reinforced. <dje42>And this seems like a good place to do so. <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