IRC channel logs


back to list of logs

***micro__ is now known as Guest76703
<int3__>can I store lists in association lists?
<int3__>I'm having this issue where (assq-ref 'a '((a))) returns #f
<int3__>ideally I'd like it to return '()
<int3__>more puzzlingly, (assq 'a '((a b))) returns '(a b), but (assq-ref 'a '((a b))) returns #f
<int3__>... the reversal of arguments in the -ref version tripped me up
<cky>int3__: I'm glad you figured it out.
<cky>int3__: Indeed the argument order is different.
<nalaginrut>mark_weaver: hmm...still failed, the tarball throw other compiling error
<mark_weaver>nalaginrut: what error?
<nalaginrut>ports.c:2263: error: 'finalize_iconv_descriptors' undeclared (first use in this function)
<mark_weaver>nalaginrut: that's a bug that I've since fixed.. (well, an incompatibility with very new libgc)
<mark_weaver>very easy to fix though.
<mark_weaver>just apply this fix by hand:
<nalaginrut>I still want to use the latest from git
<nalaginrut>since I could fine something wrong for latest Guile when I'm trying to improve artanis
<mark_weaver>this is the latest from git:
<mark_weaver>that version will not give you the compile error.
<mark_weaver>in practice, hydra updates the tarballs very often. it's rarely more than a few hours behind the latest from git.
<mark_weaver>they're always right here:
<mark_weaver>if you want to compile directly from git, that's fine too, but you'll need to make sure all the relevant *.m4 are installed so you can run ./
<nalaginrut>mark_weaver: well, I think there should be a way to solve *.m4
<mark_weaver>sure, it can definitely be done.
<mark_weaver>I wrote here in IRC what needs to be done to get past the first problem you had, with `PKG_CHECK_MODULES(LIBFFI, libffi)'
<nalaginrut>I did set the ACLOCAL_PATH, but it seems useless
<mark_weaver>the same error happened?
<mark_weaver>so you should be able to type "ls -l $ACLOCAL_PATH/pkg.m4" and see the file
<mark_weaver>and of course you need to 'export' it.
<mark_weaver>and then run ./ again, with that variable set.
<nalaginrut>I did that in ~/.bashrc and source it
<nalaginrut>echo $ACLOCAL_PATH is fine
<mark_weaver>what does "ls -l $ACLOCAL_PATH/pkg.m4" print?
<nalaginrut>I copied all the share/aclocal/* to guile/m4, seems is cool now
<nalaginrut>maybe something misuse there
<nalaginrut>hmm...still some wrong remained, but better, though haven't solved yet
<nalaginrut>[nalaginrut@li476-169 guile]$ ls -l $ACLOCAL_PATH/pkg.m4
<nalaginrut>-rw-r--r-- 1 root root 7.2K Sep 7 2012 /usr/share/aclocal/pkg.m4
<mark_weaver>and what about "export | grep ACLOCAL_PATH" ?
<mark_weaver>and what does "aclocal --print-ac-dir" print?
<nalaginrut>[nalaginrut@li476-169 ~]$ export | grep ACLOCAL_PATH
<nalaginrut>declare -x ACLOCAL_PATH="/usr/share/aclocal"
<nalaginrut>[nalaginrut@li476-169 ~]$ aclocal --print-ac-dir
<nalaginrut>non-POSIX recursive variable expansion
<nalaginrut>what it is?
<nalaginrut>I think m4 solved
<nalaginrut>I think the problem is that I installed automake to /usr/local
<mark_weaver>yeah, but it should be solvable.
<nalaginrut>what's the non-POSIX warning?
<mark_weaver>I have no idea
<nalaginrut>I think it may not cause error when compiling, but I never saw it
<mark_weaver>I have another idea: export ACLOCAL="aclocal -I /usr/share/aclocal"
<mark_weaver>export ACLOCAL="aclocal -I /usr/share/aclocal"
<mark_weaver>then try rerunning ./
<mark_weaver>I'm worried about those m4 files you copied into guile/m4 though.
<mark_weaver>that's really not a proper fix.
<nalaginrut>yes, but my aim is to run artanis
<mark_weaver>I would do "git reset --hard" and "git clean -dxf" to restore your git checkout to a pristine condition. (though beware that will delete anything in there that's not part of the git repo)
<nalaginrut>when I'm hacking artanis, I think I could find some bug/enhance/request for Guile
<mark_weaver>if you just want to get it working, then use a tarball from hydra.
<nalaginrut>mark_weaver: but I want to use the latest Guile, there're some benefits
<mark_weaver>the tarball *is* the latest guile from the stable-2.0 branch.
<mark_weaver>there is not a single commit in stable-2.0 that's not in that tarball.
<mark_weaver>well, do as you wish...
<nalaginrut>No rule to make target `../../build-aux/snippet/c++defs.h', needed by `c++defs.h'. Stop.
<nalaginrut> many strange problem...
*nalaginrut copied buid-aux from tarball
<mark_weaver>nalaginrut: what version of automake do you have? "automake --version" ?
<nalaginrut>the latest
<nalaginrut>warning: implicit declaration of function 'GC_pthread_detach'
<mark_weaver>what version of libgc do you have?
<nalaginrut>I'll try 7.3
<mark_weaver>no, try 7.2d
<mark_weaver>there are issues with 7.3
<mark_weaver>use this:
<nalaginrut>error: static declaration of 'GC_set_finalizer_notifier' follows non-static declaration
<nalaginrut>under gc-7.2d
<mark_weaver>nalaginrut: did you re-run configure after installing gc-7.2d?
<nalaginrut>mark_weaver: should I? I'll try it
<mark_weaver>nalaginrut: Yes. I suspect that's what caused the problem.
<nalaginrut>well, it's so hard to build Guile this time...
<nalaginrut>never meet such a hard time for that
<nalaginrut>maybe because I'm using centOS-6.0
<mark_weaver>yeah, that would explain it.
<civodul>Hello Guilers!
<mark_weaver>hi civodul!
<civodul>mark_weaver: so, how's everything? ;-)
*civodul goes through his backlog
<mark_weaver>civodul: okay. I just finished writing a patch for BOM handling. I think it's "the right thing (TM)". It compiles anyway. Now to test :)
<civodul>heheh :-)
<civodul>do we keep today as the target release date?
<mark_weaver>well, it passes all the tests that I'd written the last time around. that's a good sign.
<mark_weaver>civodul: I think we should wait another day or two.
<mark_weaver>but we're definitely close now.
<mark_weaver>partly it depends on how the review process goes.
<mark_weaver>civodul: what's your schedule like over the next couple of days, for purposes of the release?
<civodul>well, dunno
<civodul>it should be doable
<civodul>well, rather during the week-end, then
<mark_weaver>sure, if you want to wait until then, that's fine. better, even :)
<nalaginrut>civodul: heya
<civodul>mark_weaver: yeah, it's probably better to make sure we get the BOM things right
<civodul>well, i say "we" but you do all the work :-)
<mark_weaver>haha. I'm definitely in a productivity burst right now :)
<mark_weaver>I wish I could keep this up all the time.
<civodul>heh :-)
<civodul>it's really great that you're paying attention to all this
<mark_weaver>civodul: oh, btw, I notice that the clang build on hydra is failing, due to an old version of libffi. How hard would it be to upgrade libffi to 3.0.13?
<civodul>mark_weaver: easy!
<civodul>i didn't know the new version was released
<civodul>i'll update it
<mark_weaver>thanks :)
<mark_weaver>that should fix the clang build.
<mark_weaver>wingo: it appears that f60a7648d5926555c7760364a6fbb7dc0cf60720 broke the cygwin build on hydra.
<mark_weaver>see for details
<mark_weaver>it seems to be causing crashes. sometimes segfaults, sometimes aborts.
<civodul>done; should turn green later today
<mark_weaver>nalaginrut: you got guile built from git?
<mark_weaver>(on centos)?
<nalaginrut>yeah, I compiled Guile from git on centOS-6.0
<nalaginrut>oh what a great achievement~
<nalaginrut>almost did a half LFS before...
<nalaginrut>In ice-9/boot-9.scm:
<nalaginrut> 157: 1 [catch #t #<catch-closure 90b65f0> ...]
<nalaginrut>In unknown file:
<nalaginrut> ?: 0 [apply-smob/1 #<catch-closure 90b65f0>]
<nalaginrut>ERROR: In procedure apply-smob/1:
<nalaginrut>ERROR: Throw to key `decoding-error' with args `("scm_from_stringn" "input locale conversion error" 22 #vu8(103 117 105 108 101))'.
<nalaginrut>well, I just run 'guile'
<nalaginrut>and #vu8(103 117 105 108 101) is "guile"
<mark_weaver>I remember seeing something like this before.
<mark_weaver>as I recall, it was something about libunicode not being built with iconv support, or some such.
<mark_weaver>libunistring, I mean.
<nalaginrut>that's why I stick to use Guile on git, things could be fixed quickly if it's fixed
<nalaginrut>should I use a newer libunistring?
<mark_weaver>I don't think it's a bug in guile. I think you probably have a bad libunistring.
<mark_weaver>did you build libunistring yourself?
<mark_weaver>I suspect it's not so much an issue of it being too old, but that one of its dependencies was missing when it was built.. but it built anyway, but with reduced functionality.
<nalaginrut>I'll try latest libiconv
<mark_weaver>it might also be that you're missing some important locale on your system.
<mark_weaver>but building libiconv and then rebuilding libunistring might also work.
<mark_weaver>I don't have time right now to look further into this.
<nalaginrut>my libunistring is 0.9.3 , the latest
<mark_weaver>yeah, but if it couldn't find a suitable libiconv when it was ./configure'd, it would have built a hobbled version of libunistring that can't do what guile needs.
<mark_weaver>or, it could be that you're missing some locales. I'm not sure which.
<nalaginrut>if locales does, how can I resolve it
<mark_weaver>well, come to think of it, I don't think it's the locales.
<mark_weaver>did you keep a log of the output of building libunistring? you'd see that it was missing iconv in the configure output.
<nalaginrut>I'm building libunistring
<mark_weaver>okay. pay close attention to the output of configure.
<mark_weaver>look for things having to do with iconv.
<nalaginrut>hmm...but seems it's ok, and compiling is ok
<nalaginrut>/home/nalaginrut/libunistring-0.9.3/conftest.c:125: undefined reference to `libiconv_open'
<nalaginrut>/home/nalaginrut/libunistring-0.9.3/conftest.c:126: undefined reference to `libiconv'
<nalaginrut>/home/nalaginrut/libunistring-0.9.3/conftest.c:127: undefined reference to `libiconv_close'
<nalaginrut>well, I just installed iconv
<mark_weaver>yeah. install libiconv and then rebuild libunistring.
<nalaginrut>I think the problem may because my Guile's prefix=/usr, but others are /usr/local
<nalaginrut>I used to install packages to /usr/local, but this time I installed Guile to /usr
<mark_weaver>did you run 'ldconfig' as root after installing the libraries?
<mark_weaver>is /usr/local/lib in /etc/ (or /etc/* )?
<nalaginrut>I run ldconfig each time after make install
<nalaginrut>well, I specified --with-libiconv-prefix=/usr, and it detected /usr/lib/, but undefined reference to `libiconv_open'
<nalaginrut>checking for iconv... yes
<nalaginrut>checking for working iconv... yes
<nalaginrut>checking how to link with libiconv... /usr/lib/
<mark_weaver>I'm sorry, I don't have time to help more now.
<nalaginrut>that's fine, have nice dream I recommend ;-)
<nalaginrut>well, 'LC_ALL=en_US.UTF-8 guile' works
<nalaginrut>but the default is en_US.utf8
*nalaginrut shrug
<mark_weaver>nalaginrut: ah, interesting!
<nalaginrut>oh, you still awake?
<mark_weaver>stupidly, yes :)
<nalaginrut>I have to go home now, maybe few minutes...
<nalaginrut>how can I change utf8 to UTF-8 in global?
<mark_weaver>I don't know how to do it on centos, sorry.
<mark_weaver>nalaginrut: oh, maybe look in /etc/sysconfig/i18n ?
<nalaginrut>mark_weaver: well, it's LANG="en_US.UTF-8" there
<nalaginrut>maybe I should change to utf8?
<mark_weaver>nalaginrut: no.
<mark_weaver>so that's the system-wide setting, and that works with guile. you must be setting it to "en_US.utf8" somewhere else.. maybe in your dot files?
<nalaginrut>export LC_ALL=en_US.UTF-8 in /etc/profile
<nalaginrut>hoo, perfect now (maybe not, maybe compile latest mysql...)
<mark_weaver>nalaginrut: if I were you, I'd just install Debian wheezy :)
<mark_weaver>but I guess you've already done all the hard work :)
<nalaginrut>well, it's not my work, a guy chose centOS
<mark_weaver>wingo, civodul: I just posted my proposed BOM patch.
<nalaginrut>anyway, artanis+nginx works on this VPS now
<mark_weaver>glad to hear it! :)
<civodul>mark_weaver: great, i'll comment ASAP
<nalaginrut>curl --head
<nalaginrut>Nginx is nice~
*nalaginrut gotta go~~
<nalaginrut>with three days short vacation~
<mark_weaver>I still have more tests to write, and some updates for the manual would be good too.
<mark_weaver>nalaginrut: okay, have fun! :)
<nalaginrut>see you
<mark_weaver>civodul: I just posted a revised version of the patch, that adds tests and fixes a few other minor things.
<mark_weaver>and now, I must sleep :)
*mark_weaver --> zzz
<lloda>civodul: there are already array-map! tests in ramap.test. They pass.
<lloda>I'm redoing the patches to add the handle releases.
<tupi>the nice thing about having [like forced to] to use other stupidely designed languages is that when you switch/come back to scheme, live all of a sudden seems bearable
<civodul>lloda: aah, this is you! :-)
<wingo>sorry i'm not helping out now; busy & a bit behind...
<civodul>wingo: no problem, you've had your share, too ;-)
<wingo>i left some todos in the release notes; documenting --language and the new file name interfaces are probably foremost among them
***sneek_ is now known as sneek
<ijp>good afternoon
<mark_weaver>hello guilers!
<stis>heya mark_weaver!
<mark_weaver>hi stis!
<civodul>hey mark_weaver
<civodul>had enough sleep? ;-)
<mark_weaver>hi civodul! not as much as I'd like, but enough, yes :)
<mark_weaver>any thoughts on the BOM patch?
<civodul>i replied, no?
<mark_weaver>ah yes, indeed you did.
<civodul>in short, it looks good to me, modulo details
<mark_weaver>excellent! thanks. reading now.
<civodul>mark_weaver: build_clang is green now: :-)
<mark_weaver>yay :) thanks for taking care of that.
<mark_weaver>any idea why these are happening? FAIL: filesys.test: sendfile: pipe
<mark_weaver>the primary build just failed because of it. I've seen it happen before recently too, maybe even semi-randomly (?)
<mark_weaver>civodul: thanks for the review. also, good catch about the case-sensitivity issue. indeed, iconv supports the lower case names, and so many of the tests I wrote fail if the lower case names are used.
<mark_weaver>ugh, strcasecmp is a bit of a heavy tool though. it takes into account the current locale.
<mark_weaver>well, I wrote the code so that 'strcmp' is rarely called, so I guess it's okay.
<mark_weaver>civodul: I can't find @ununnumberedsec in the texinfo manual.
<mark_weaver>is it some guile-specific macro?
<mark_weaver>oh nevermind. wetware spell checker failure :)
<mark_weaver>civodul: I was thinking of maybe adding a "BOM Handling" node to the "Input and Output" section, but if you have a better idea of where to put this, I'm open to suggestions.
<duper>Can I compile guile scripts yet?
<ijp>depends what you want to compile it into
<ijp>executables no, bytecode yes
<duper>bytecode for what platform?
<ijp>guile's vm
<duper>is that lightning?
<duper>is there a procedure I can call to do it from the REPL?
<ijp>duper: what version of guile are you using?
<duper>whatever version I have to. ;)
<duper>latest stable i suppose *shrug*
<ijp>guile automatically compiles files it runs (like e.g. python)
<ijp>but you can do it from the shell with 'guild compile'
<duper>okay, that's new.. I think the last version I used was 1.6.3.
<ijp>right, this is a 2.0 feature
<duper>So I can just guile compile a.scm and then guile a.out or something?
<amgarchIn9>Hi! Is there a workaround for valgrid+libgc that does not involve libgc update?
<ijp>duper: not quite, you can't get executables yet.
<ijp>I'm sure you can run only the bytecompiled code, but I can't remember the incantations
<amgarchIn9>duper: you just run *.scm files as before. Compilation to bytecode is an implementation detail to speed up the interpreter.
<ijp>right, this is what is recommended
<ijp>civodul: wingo: I'm not planning on touching it till after the 2.0.8 release, but once that happens I intend to rebase the lua branch and fix any breakage. Would it make more sense to base it off master or stable-2.0?
<ijp>I mean, the two will be roughly equivalent at that point, but for going forward does it matter?
<davexunit>the guile vm can speak lua? very neat.
<ijp>there is a lua->tree-il compiler that has been languishing
<ijp>I want to bring it up to date, and then we'll see
<davexunit>do you think that it can help bring more people to the guile camp?
<ijp>I have no idea
<davexunit>what advantage does using lua in guile have over the usual way?
<ijp>I'm not sure that there are many people going "I'd love to use guile, if only it supported lua"
<davexunit>yeah, that's likely true. a lot of people like lua as an "extension" language, though.
<davexunit>extension in quotes because they just embed it usually.
<davexunit>is it more of a "hey look what the guile vm can do!" kind of thing?
<ijp>to me it is, I'm not sure what the original motivation was
<ijp>the lua branch slightly predates my involvement
<duper>Why would you want to put guile and Lua together?
<duper>just seems to me you would either use one or the other
<taylanub>Some people prefer one over the other, and it's nice if they can still benefit from the rest of Guile.
<taylanub>Although I will probably never understand any person preferring Perl, Python, Ruby, Lua, or JavaScript over Scheme, although I haven't used all those languages yet.
<davexunit>I use python, ruby, and javascript regularly. I'm not as good at scheme yet so I don't know which I like the best.
<mark_weaver>it would be useful for guile to support other popular languages, so that application authors can choose libguile without sacrificing users who would prefer to write in their favorite language.
<ijp>duper: well, one thing you might want to do is write your application in scheme, but use lua for extension since it's more "normal"
<mark_weaver>that's core to the original concept of guile.
<ijp>but guile has always supported multiple languages
<duper>I've written Perl, Python, Ruby, and Scheme.. I prefer Ruby for most things, but guile is nice for writing configuration files..
<ijp>originally it was guile/ctax/lua
<ijp>er, not lua, tcl
<duper>I will say that learning Scheme by reading SICP made me a better programmer in other languages.
<ijp>duper: :)
<ijp>it was technomancy's april fools software
<duper>ijp: TCL has major security problems.
<ijp>duper: and we haven't supported it for well over a decade :)
<ijp>but I hear back in the early 90s tcl was all the rage
<duper>ijp: interesting, but XML is too cumbersome for configuration syntax IMNSHO
<ijp>duper: indeed, that was kind of the point
<duper>ya, a lot of ppl thought Tcl was the language of the future back then. :)
<duper>about the only thing I'd ever use it for now is eggdrop bot scripting
<ijp>I think the only software I use that I know has tcl in it is gitk, and redis's cli client
<duper>Apache recently nixed mod_tcl.
<duper>I was under the impression that the whole point of Lua was to interface other programming languages with C code.
<duper>Is that incorrect?
<ijp>lua is a programming language
<duper>err.. well, to create an API for invoking C functions from software not written in C, e.g. as sort of an FFI
<tupi>duper: see for their goals
<duper>I have "Programming in Lua" on my bookshelf but haven't read it, yet.
<tupi>do not :) stick to scheme and guile ...
<ijp>game developers seem to like it
<duper>The only program I ever wrote in Lua was an amateur radio call sign generator.
<duper>Usually when I'm programming Scheme I use Racket since it can compile to binary with mzc. I only use guile for extensions and configs.
<duper>the flashy GUI IDE isn't bad either.
<duper>ijp: text games like MUD's/MOO's/MUSHes or actual games with GUI's?
<ijp>"actual" games
*duper just remembers the text-based game exercises from his programming paradigms course.
<duper>and the sample MUD code that's included with DrScheme
<mark_weaver>civodul, wingo: I just posted an improved BOM patch, with more tests, full docs, and incorporating civodul's excellent feedback.
<davexunit>lua is pretty beloved by game developers.
<davexunit>they often scoff at using a lisp for game scripting
<duper>oh, Scheme Invader, neat-o..
<ijp>davexunit: what's the current state of gshmup?
<duper>Lua's used by a lot of open source security tools, too (WireShark, NMap, Snort, etc.)
<davexunit>ijp: merging the good stuff back into the original gnumaku repo and fixing up the rest of gnumaku.
<davexunit>I've taken a break from it, but I did some work over the past week.
<ijp>okay, cool
<davexunit>writing an allegro wrapper using Guile's FFI was a great decision.
<davexunit>that eliminated a ton of bad C code that I wrote before.
<davexunit>I'm writing a small C extension that handles particles and collision detection only. I think I can write everything else in Guile.
<davexunit>the basic particle system and coroutines are back up and running :):
<wingo>ijp: master, because master has PEG
<wingo>mark_weaver: will take a look in the mornign
<mark_weaver>wingo: thanks. I'm still tweaking it, so make sure to find my most recent post in the thread.
<mark_weaver>(I'll probably most another revision before then)
<civodul>mark_weaver: i'm seeing a utf-8 vs. UTF-8 test failure:
<civodul>wonder why it shows up just now
<mark_weaver>civodul: interesting. the only thing I pushed was a patch to change some strcmp's to strcasecmp's.
*mark_weaver looks
<civodul>and Hydra points at an unrelated commit
<mark_weaver>civodul: well, before this fix, "utf-8" was handled by iconv and not by our internal code.
<civodul>hmm, i think here it's (web reponse) that does (set-port-encoding! p "utf-8")
<civodul>i can't reproduce it locally :-/
<mark_weaver>the only difference between the expected and actual values is the case of the "utf-8".
<civodul>yes, i know
<civodul>response-body-port just calls set-port-encoding! with the charset string it has had
<civodul>so, lower-case "utf-8" here
<civodul>+ if (strcasecmp (encoding, "UTF-8") == 0)
<civodul> {
<civodul> pt->encoding = "UTF-8";
<civodul>that's the thing
<mark_weaver>I'll fix it.
<civodul>yeah, i can reproduce it now (i just had to type "make", ahem...)
<civodul>ok, i let you fix it :-)
<mark_weaver>I remember scratching my head when I saw that, but I guess the idea was to reduce the number of copies of "UTF-8" floating around.
<civodul>yeah, dunno
<cky>Isn't it also to normalise the casing?
<civodul>cky: yes, except that it was strcmp just above :-)
<civodul>hey lloda
<cky>Oh. Hah.
<civodul>lloda: just one patch left :-)
<lloda>hello civodul
*cky continues working on the in-core SRFI 45.
<lloda>in array-for-each patch, you say 1-dimension where you mean 1-argument
<civodul>ah, right
<civodul>well, 1-argument means a 1-dimension walk
<lloda>not really, that depends on the strides
<civodul>hmm, yeah
<civodul>tricky :-)
<lloda>annnd anyway scm_ramapc() calls rafe or ramap or racp for rank-1 sections even for arrays of higher rank
<lloda>anyway, it's good to cover the 1-argument case.
<civodul>lloda`: looking more closely, it seems OK to deprecate scm_array_fill_int
<civodul>could you move that bit to a separate patch?
<civodul>and make sure both the declaration and definition are in #if SCM_ENABLE_DEPRECATED == 1 ?
<lloda`>ok, no problem. Coming...
<lloda`>erc doing weird things
<mark_weaver>cky: while you're at it, it would be great if SRFI-41 would use the new core promises, but that will require some way to make new promise types.
<mark_weaver>cky: it doesn't have to be totally general, or exposed to the user.
<mark_weaver>cky: I suspect that once 2.0.8 goes out the door, we won't be able to make SRFI-41 use the core promises until 2.2.
<taylanub>In "6.15.1 Regexp Functions" of the Guile manual, near the bottom, where it says "Without the `post' symbol, just one regexp match is made. For example ...", the example uses `post' anyhow. Is that a mistake, or do I misinterpret something ?
<mark_weaver>civodul: I just pushed a fix for the "utf-8" build issue.
<mark_weaver>it's sooooo nice having hydra there. continuous integration rocks! :)
<cky>mark_weaver: Okay, I'll make a new smob type called stream-promise and provide a way for srfi-41 to use it.
<cky>mark_weaver: How do you export a C function into a specific module?
<mark_weaver>cky: preferably, it should be done in such a way that most of the code is shared internally.
<cky>e.g., if I want to export into (srfi srfi-41 promise) or the like?
<mark_weaver>use 'scm_c_define_module'
<mark_weaver>see section 6.20.3 of the manual for an example.
<cky>Okay, will look. Thanks!