IRC channel logs


back to list of logs

<user___>Hey I'm new to scheme and I was noticing that some values start with '#:' or '%' or '&'. Is there any rhyme or reason to that? Is there a semantic difference to guile? Is there a naming convention I don't get?
<ijp>#: is a keyword, and a distinct type
<ijp>the other two are conventions only
<user___>ijp can you point me to docs? What do they mean in particular?
<ijp>% as a prefix is often used to indicate something "private"
<ijp>e.g. if you have an internal version of a procedure that doesn't perform checks
<ijp>& is used for condition types
<ijp>I'm not sure if & is used anywhere else
<user___>so & is like for booleans?
<user___>or just anything you'd cond against?
<ijp>no, a condition is a compound object that you return in an exception
<user___>oh, I see
<user___>thanks, it looks like I need to reread the manual
***davexuni` is now known as davexunit`
<ijp>I've finally got around to sending those 3 patches for the lua branch
<dsmith-work>ijp: & used to be used in ancient guile for keyword and rest args for lambda* and define*
<ijp>huh, forgot about that
<ijp>I expect I've just thoroughly confused user___
<dsmith-work>The condition stuff is an r6rs thing.
<ijp>I am well aware of that
<dsmith-work>(meant for user__)
<ijp>they've gone though
<dsmith-work>AH yes
***davexunit` is now known as davexunit
<ijp>mark_weaver: I was pointed to this puzzle earlier,
<ijp>figured you might be interested
***ijp` is now known as ijp
<nalaginrut>morning guilers~
<nalaginrut>ijp: so lua works now?
<ijp>no, it passes the tests now
<ijp>big difference
<nalaginrut>yeah, I found it's a little hard to fix, since it's manual parser
<ijp>next thing I will figure out is how to get my lua unlambda interpreter to run right under guile
<nalaginrut>ijp: besides, is 'program' category in guildhall fixed? It was installed to a invalid path that can't be execute
<ijp>I have not got an email back from rotty about the difference, so I might just remove one
<ijp>great, now it is giving me lexer trouble
<ijp>oh, I see the problem, silly mistake
<ijp>I'm assuming it's the parser that is the cause of all my woes with it right now, since the lexer seems to work fine, and I've been fiddling with the codegen
<ijp>hmm, there is a bug in the lexer
<nalaginrut>I think manual lexer is fine, but I prefer LALR
<ijp>ah no, my mistake
*nalaginrut was almost exploded when last time he's trying to write ruby-1.9 BNF for guile
<ijp>ruby's grammar is nuts
<nalaginrut>ruby-1.4 is shorter
<ijp>okay, the problem is just that the parser doesn't return an eof
<ijp>great, that's fixed, but none of my test programs are working :/
<ijp>and still useless at the repl
<ijp>great, I can run _a_ script now
<ijp>the problem with the reader is that it is too eager
<ijp>it tries to read in the whole file as one sequence, rather than one expression at a time
<nalaginrut>ijp: where's your repo?
<ijp>local just now
<ijp>hmm, I think I have the repl working now
<ijp>you still need the 'return', and one ';'
<ijp>but `guild compile' is not working
<ijp>tell, a lie, you don't always need the return
<nalaginrut>well, why ';'
<nalaginrut>hmm...I've heard that yahoo mail in China is stopped today, maybe gmail does another day...
<ijp>nalaginrut: the same reason as you need it in ,L ecmascript
<nalaginrut>alas, I wish gnu-mail could last forever...
<ijp>the language allows you to elide the ;, but the repl isn't clever enough to figure it out yet
<ijp>er, the parser
<ijp>you can get away with it in code, since it can figure it out from the next token
<nalaginrut>ijp: but lua don't need ';', anyway, I'm glad it works even if it need a ';'
<ijp>it's just the repl
<ijp>my next mystery is why `guild compile' hangs
<nalaginrut>hmm...maybe you could create a repo on github, just for languages/lua
<ijp>I'm trying to get it all upstream, so there isn't really a need
<nalaginrut>the languages could be an totally independent module
<nalaginrut>anyway, you decide it
<ijp>it's weird, it only fails from a script, not the repl
<ijp>probably better off waiting till the experts arrive
<mark_weaver>ijp: I'm willing to take a look if you like.
<ijp>ah, morning mark
<mark_weaver>working on lua?
<ijp>yes, but my issue is with `guild compile'
<mark_weaver>does 'compile-file' work?
<ijp>from the repl, yes
<ijp>(with the exact same arguments)
<mark_weaver>what if you import (scripts compile) and run that from the REPL?
<ijp>hmm, no, that worked fine
<mark_weaver>maybe something in your .guile is making things work for the REPL?
<ijp>no, I made sure to use -q
<mark_weaver>how about attaching gdb to the process when it's hung, and ask for a backtrace.
<ijp>hmm, I just tried strace, and it hasn't "hung", it is continually calling read
<mark_weaver>well, it would still be useful to know where it is in the code and what's going on.
<mark_weaver>the gdbinit in the toplevel guile build directory can help.
<mark_weaver>there's a command in there that will give you a scheme backtrace.
<mark_weaver>(but that certainly is interesting)
<mark_weaver>I guess all those reads are returning EOF, right?
<ijp>initially I had assumed it was the parser, but once I got compile-file working I figured it shouldn't be that
<ijp>about a gazillion of -> read(60, "", 4096) = 0
<mark_weaver>yeah, so all EOFs.
<ijp>mark_weaver: sorry, what do I do with this gdbinit? my gdb is very rusty
<mark_weaver>copy it to ~/.gdbinit
<mark_weaver>so run the "guild compile" in one terminal.. then get the process id of that guile.
<nalaginrut>heya mark_weaver
<mark_weaver>in another terminal, run either "gdb guile" or "meta/gdb-uninstalled-guile", depending on whether the guild you're running is based on an installed guile or not.
<mark_weaver>within gdb, type "attach <pid>"
<mark_weaver>then "gbt"
<mark_weaver>and that should print a backtrace in the terminal that's running the guild compile
<mark_weaver>hi nalaginrut!
<mark_weaver>ijp: I'm not sure why it's magically working in the REPL.. maybe something to do with the locale being set? but in any case, I suspect that your parser is not handling EOF properly.
<ijp>well it wasn't, but I tweaked it so it should
<mark_weaver>so the reader that's provided in the spec.scm file is returning an eof-object?
<ijp> was my bt
<mark_weaver>I'd put a 'pk' around the reader, to see what it's returning, and to make sure that it starts returning #eof
<mark_weaver>well, preferably just around the top-level reader (the one in the spec file).
<nalaginrut>hmm...maybe REPL work is deja vu, it's not fine solved
<ijp>I have done so, though I do think I know of one thing it could be
<mark_weaver>ijp: fwiw, 'read-and-compile' in (system base compile) contains the relevant loop.
<mark_weaver>(which calls read-and-parse, which calls your language reader)
<ijp>mark_weaver: top level reader isn't even returning
<ijp>which is very suspicious
<ijp>I'd still like to figure out why this is only happening from the 'guild compile' command
<mark_weaver>have you tried writing your own little guile script that calls compile-file?
<mark_weaver>I suspect it's not so much that it only happens from guild compile, but more than the REPL setup is doing something that fixes it..
<ijp>unless, maybe 'guild compile' is using the installed version of the lua modules?
<mark_weaver>you mean you haven't been using meta/guild ?
<mark_weaver>well, yeah, that would explain it :)
<ijp>no, I have, but it was just a thought
<mark_weaver>ooc, is this master or stable-2.0?
<mark_weaver>also ooc, have you merged from master lately?
<ijp>pretty recently
<mark_weaver>do you have the peek-char-doesn't-consume-eof stuff?
<ijp>nope, my own script worked
<ijp>where by "own script" I mean, I copied guild compile to tmp
<mark_weaver>the only reason I mention it is because it would be better for you to test this with the peek-char-doesn't-consume-eof behavior.
<mark_weaver>when you say you "copied guild compile" what does that mean?
<ijp>cp scripts/compile.scm /tmp
<ijp>then meta/guile /tmp/compile.scm -f main --from=lua /tmp/easy.lua
<ijp>mark_weaver: I think I last merged the commit before that one
<ijp>oh wait no, my mistkae
<ijp>the last I have is the string join patches
<ijp>so I have the correct peek behaviour
<ijp>aha, no, I was looking at the wrong peek patch
<mark_weaver>no, you don't
<ijp>I was thinking of "Avoid unnecessary peeks for EOF in r6rs-ports."
<mark_weaver>I'd merge if I were you.
<ijp>right, I'll try that
<mark_weaver>not that I expect it to make a difference here, but it seems silly to test with the old code.
<mark_weaver>make sure to merge with master, not stable-2.0..
<ijp>right, I'm building now
<ijp>mark_weaver: btw, should we be worried about "hash.c:219:5: warning: left shift count >= width of type [enabled by default]"
<ijp>i.e. would a compiler break that in the future?
*mark_weaver looks
<ijp>this probably isn't an issue on 64 bit computers
<mark_weaver>that line is only executed if unsigned long is a 64-bit type. it shouldn't even be compiled on your machine, but I guess the warning is happening before the dead-code removal pass.
<ijp>fair enough
<mark_weaver>we might want to change that from 'if' to '#if' to avoid the warning on 32-bit machines.
<mark_weaver>thanks for letting me know, I'll put it on my TODO :)
<ijp>also, I was reading an post on regehr's blog from January, and he gave guile as one instance of C not being future proof
<ijp>a post*
<mark_weaver>yeah, I saw that. in fact he linked to the SO post that I answered.
<ijp>it was one you'd fixed, but the chain was interesting
<ijp>it went SO->HN->Regehr->Me
<ijp>I was surprised to learn people post bugs to SO
<mark_weaver>yeah, that's a strange way to report bugs.
<ijp>okay, I've updated, and am still seeing the same behaviour
<mark_weaver>I guess for someone who likes posting on SO, it's easier and more fun than figuring out where the bug report should be sent.
<mark_weaver>The big draw of SO is how they've gamed it. Everyone wants to earn points to show off.
<mark_weaver>I confess I was tempted to do the same, until I came to my senses.
<ijp>I get worried by systems like that, since they favour people who got on board early
<ijp>but I suppose that is true of most thigns
<mark_weaver>yeah, maybe it makes more sense to have points earned long ago fade over time.
<ijp>I'm going to try wrapping the lexer with pk, and see if that gives me any better info
<mark_weaver>but I wonder if we could make more use of the "gaming" idea in our own fora. it's a very effective motivational technique. maybe we could put it to good use.
<ijp>(aside: we need a more useful ,trace)
<ijp>okay, nuclear option: I rigged lex to call exit if it ever gets called, and it never got triggered
<ijp>I'm going to try changing the installed version, and see if that works
<mark_weaver>btw, why is the reader in (language lua spec) rigged to return #unspecified if the port is not a file port?
<ijp>I don't know
<ijp>I noticed that as well, and was leaving it to see if I could come up with a reason
<ijp>so, we have a path problem with meta/guild
<mark_weaver>ah, what's the problem?
<ijp>well, if you have a guile installed, meta/guile will use its .go files
<ijp>meta/guile on the other hand, uses the ones in the build directories
<mark_weaver>good catch
<ijp>which means, you will only see this problem, if you are doing something weird like me :)
<ijp>now how to best fix this?
<mark_weaver>actually, I think this is user error, but if it makes you feel any better, I would have made the same mistake.
<mark_weaver>meta/guild is actually the thing that gets installed.
<mark_weaver>I think you should be doing "meta/uninstalled-env guild compile ..."
<mark_weaver>and indeed, that's exactly what the makefiles do.
<ijp>hmm, yes that works
<mark_weaver>(see the rule at the end of am/guilec
<ijp>great, now to find the place that it says this in the docs, so I can be doubly ashamed
<mark_weaver>nah, it was a natural expectation that if meta/guile runs the uninstalled version, that meta/guild should as well.
<mark_weaver>it's confusing.
<mark_weaver>the relevant doc is the "Using Guile Without Installing It" section of the README.
<mark_weaver>it should probably say something about guild.
<ijp>yeah, I've noticed it now
<mark_weaver>although it might be better to actually make meta/guild do what users would naturally expect.
<mark_weaver>and move the real 'guild' that gets installed somewhere else.
<mark_weaver>I'll want to make some fixes to the eof handling of the lua lexer at some point.
<mark_weaver>or you can.
<ijp>I've got changes to the parser for eof, but I hadn't noticed any problems with the lexer thus far
<mark_weaver>in particular, the 'eof-object?' case at the end of 'lex' should probably consume the peeked eof by returning (read-char) instead of c.
<mark_weaver>and 'eat-comment' should *not* consume the eof.. so it should use 'peek-char' and only 'read-char' if it's not eof.
<ijp>at the risk of sounding like an idiot, how can that be a problem?
<ijp>not the comment thing
<mark_weaver>well, when reading from a terminal, you need to consume the eof or else it will be left for the next read.
<mark_weaver>and that might well quit the outer repl.
<mark_weaver>for an example of the kind of problem this can cause, see;a=commitdiff;h=7520a9b95d2661cf40f6c1bf8be79f38ca632516
<ijp>I expect scheme code is riddled with this issue
<mark_weaver>before that fix, nalaginrut noticed that if he typed Ctrl-D from an inner REPL, it would exit all of the REPLs and quit guile.
<mark_weaver>because the EOF was never consumed.
<mark_weaver>yeah, there's probably some scheme code out there that has grown dependent on our old broken behavior.
<mark_weaver>the alternative is to break code that depends on the standard-mandated behavior.
<nalaginrut>hi guys, is it fixed?
<mark_weaver>anyway, moving forward, the general rule to follow is that if a function that's supposed to 'read' returns an EOF, then the EOF should be consumed. this includes higher-level readers.
<ijp>(non-english speakers not familiar with the tomato/tomato idiom will need to excuse me)
<ijp>non-native english*
<mark_weaver>if a procedure that's supposed to 'read' hits EOF after reading something else, and returns that something else without returning EOF to the caller, then the EOF should *not* be consumed.
<mark_weaver>I think it was a good idea for scheme to start using the work procedure, to avoid the incorrect analogy to mathematical functions.
<mark_weaver>I try to use proper terminology.
<ijp>do we have a note to this effect? in NEWS or the manual?
<mark_weaver>the NEWS mentions it, yes.
<mark_weaver>it mentions the change anyway. it doesn't mention the rule I just gave above.
<mark_weaver>the basic idea, anyway, is that each EOF typed at a terminal should be reported exactly once (no more, no less) to every caller of a read-like procedure.
<mark_weaver>anyway, it's late, and I must sleep. happy hacking!
*mark_weaver --> zzz
<ijp>can't believe it took us an hour and a half to find that issue :/
<nalaginrut>hmm...we can't see the code, so you have to fight yourself
<ijp>well yes, but it wasn't a code problem
<ijp>the problem was one of false assumptions
<cky>ijp: You need to set up your Gnus to respect Mail-Followup-To. :-)
<civodul>Hello Guilers!
<ijp>cky: it is supposed to honour other people's mail-followup-to unless I messed something up
<ijp>which is quite likely
<ijp>hmm, no, it is set incorrectly
<ijp>civodul: wingo: morning.
<ijp>I was a little peeved to learn that meta/guild from a build directory does not work quite correctly, and that I am supposed to have been doing meta/uninstalled-env guild.
<wingo>we could fix that
<ijp>but the good news is, I have a patch for the lua reader so that it can parse files/repl input correctly
<ijp>well, mostly correctly, still needs the ';' like js
<wingo>did you find PEG to be useful at all?
<ijp>I have only played with it a little bit, but I have found one disconcertin issue with it
<ijp>namely if you give define-peg-string-patterns a bad string, you don't get a compile time error, but only unbound variable warnings
<ijp>anyway, I hope to get lua working enough to run in a week or so
<ijp>curried cps: because idiomatic code for suckers
<nalaginrut>how to make an optional arg in 'match'?
<wingo>use tail patterns
<wingo>. (or () (arg))
<wingo>i think
<wingo>not sure if that binds an identifier or no
<jmd>Is there a function to convert "0x1234" into an integer ?
<DerGuteMoritz>jmd: (string->number (string-drop "0x1234" 2) 16)
<nalaginrut>if we have string-substitute, just replace "0x" to "#x"
<Fulax>ArneBab_: are you using guile-2.0.9 from gentoo's lisp overlay? I just saw your +networking bug
<civodul>Fulax: ooh, Gentoo has 2.0.9, cool :-)
<civodul>even Guix doesn't yet have it ;-)
<civodul>we should have a distro hall of fame on Guile's page
<Fulax>civodul: yeah, I bumped it a few days ago, but it is in an overlay, not in the main package repository
<Fulax>civodul: to move it to the main repository, we need to have tools for packages like texmacs, to find guile's binaries of 1.8. Work in progress
<mark_weaver>Gentoo may have 2.0.9, but did you hear that they've been building Guile with --disable-networking by default? (!!!)
<civodul>ahah, shame on 'em!
<ArneBab_>Fulax: yes
<ArneBab_>civodul: that would be cool, yes :)
<ArneBab_>Fulax: I have to go AFK, though: Need to check if a collegues desktop boots with my Gentoo on external disk (Ubuntu fails)
<Fulax>ArneBab_: no hurry, I fixed the package :)
<Fulax>I can close the bug then
<ArneBab_>Fulax: thanks!
<ArneBab_>(my Gentoo boots for him, so I might just clone my disk…)
<ArneBab_>civodul: I would assume that in Future guix could be a bit behind new Guile releases: It depends on a working guile. That’s why for example Gentoo is sometimes a bit slower on GCC-releases: If GCC breaks, Gentoo can’t be fixed…
<ArneBab_>(except if you have binpackages)
<ArneBab_>civodul: does guix have a backup strategy what to do when Guile breaks?
<ArneBab_>civodul: something like slotting Guile (multiple versions side-by-side)
<civodul>ArneBab_: the idea is to keep to Guile packages sometimes
<civodul>the Guile that's used to build everything (which may not be the most recent), and another one
<civodul>so users can still install the latest & greatest
<ArneBab_>so it could be something like slotting
<civodul>staging, i'd say
<stis>sneek: where is logs:
<stis>sneek: where is logs
<mark_weaver>sneek: logs?
<sneek>Someone once said logs is
<stis>thx Mark!
<mark_weaver>np :)
<dsmith-work>civodul: Where is this hall of fame/shame ?
<civodul>it doesn't exist, it was a joke
<dsmith-work>Bah. I didn't see the "should" in there for some reason.
<dsmith-work>Greetings, ijp
***ijp` is now known as ijp
<ijp>so, i got my raspberry pi earlier today
<dsmith-work>Have you booted it up yet?
<sneek>Linux berry 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
<ijp>not yet, I need to clear some space about this place first
<dsmith-work>Not much..
<davexunit>I still haven't much time to play with my pi yet
<turbofail>i feel like i want to buy one but i have no idea what i'd do with it
<dsmith-work>Did you get a case too?
<turbofail>i don't really enjoy soldering, but most of the things that i would want to do with it would probably require it
<dsmith-work>Mine is still bare. Need to put it in something. The i/o pins are directly conncedted to the cpu with no buffering.
<davexunit>turbofail: use a breadboard
<fbs>no dont
<fbs>breadboards are shit :>
<ijp>they are an important prototyping tool, but I hated working with them
<dsmith-work>fbs: Do you mean solderless broeadboards?
<ijp>it didn't help that programming gradually ate away at the part of me that enjoyed fiddling with electronics
<davexunit>I haven't done any electrical work. but I was considering getting a breadboard and trying to learn some stuff.
<turbofail>hm. breadboards. haven't used those in a while
<fbs>ijp: blowing up parts is so much more satisfying
<davexunit>turbofail: let's you tinker without soldering, at least :)
<ijp>my power supply blew up the other day
<fbs>just some copperclad and solder is just as fast
<fbs>and gives you easy grounding and better connections
<davexunit>fbs: yeah? I don't know such things.
<ijp>burnt electronics has such an unsatisfying smell
<dsmith-work>But amazingly distinctive
<ijp>davexunit: it's pretty easy to work with
<ijp>just make sure you remember to cut the tracks in the appropriate places _before_ turning the thing on
<turbofail>nice caps.
<davexunit>I imagine I will blow up some stuff before I learn my lessons.
<turbofail>i have a big electrolytic sitting in my car for some reason
<dsmith-work>And remember to keep the smoke inside.
<fbs>copperclad is great, when your project works you just solder some 'walls' and its cased
<dsmith-work>It's hard to put back. And mostly doesn't work if you let it out.
<fbs>i hope not
<fbs>over 300Joules when fully charged, so the 3 of them is 1kj
<fbs> <- coper case
<turbofail>my dad used to entertain me by blowing up strips of aluminum foil with one of those
<fbs>davexunit: anywya, a breadboard works fine for small projects if you treat it with care, but i dont build anything with more than 10 wires on it
<fbs>using with care -> no long pins, make sure the internal clips dont get pushed out,
<fbs>turbofail: i would like a few of those kfarad 5V things, nice spotwelder
<ijp>and make sure to use properly cut wire, none of this birds nest crap
<turbofail>fbs: ultracaps?
<turbofail>ha. yeah i've wanted to try playing with one of those for a while
<turbofail>i feel like they would be a good fit for a lot of things that currently use batteries
<davexunit>a lot of this electronics talk goes over my head, unfortunately.
<turbofail>like my wireless mouse. it seems silly to use a chemical battery for that
<davexunit>hopefully I'll get around to educating myself a bit. :)
<fbs>batteries are more J/kg
<turbofail>sure, but a lot of these applications don't use a whole lot of energy
<davexunit>I think I've brought this up before, but raspberry pi people seem to like using python and its gpio library. a guile gpio library might be a neat project for someone.
<turbofail>and the ultracap can be recharged almost instantly
<turbofail>(comparatively speaking)
<turbofail>and will in theory last longer as well
<fbs>i think the energy density is 10% that of batteries
<turbofail>yeah i meant last longer as in you'll be able to get more charging cycles out of them
<fbs> i came across that
<fbs>davexunit: i was thinking about getting a rpi and hook it to this multimeter design to get `easy' networking and other stuff
<dsmith-work>davexunit: Sure. Currently takes about 4 hours to build guile on it. It *really* needs a good guile package.
<dsmith-work>I wonder how noisy they are. Electrically.
<dsmith-work>It even took me *hours* just to remove packages (Like X11 stuff) I didn't need so I gad enough space to build Guile.
<dsmith-work>(I'm using a 2G card)
<fbs>isnt 2G the minimum?
<dsmith-work>I think there is only about 150M free on it. I think I got mint to about 800M free before I started building.
<fbs>my guile build dir is 150MB :p
<dsmith-work>That's why. I was nervous about such a small amount of free space.
*fbs finally got guile .9
<dsmith-work>fbs: What took so long?
<fbs>had .6 in debian
<davexunit>dsmith-work: oh wow. I've been meaning to compile guile on mine... that's quite a long time.
<turbofail>hm. that battery article does look pretty interesting. though a) it's still unclear when/whether the researchers will actually be able deliver said technology, and b) they say nothing about charge cycle lifetime
<fbs>only one way to find out :)
<turbofail>they mentioned some sort of lithium air battery from IBM as well, which also sounds interesting for different reasons
<mark_weaver>fbs: debian doesn't have .6, only .5
<dsmith-work>If anyone is interested, I have a built guile in a tarball for the rpi.
<dsmith-work>DESTDIR=foo make install
<dsmith-work>and then tar up the foo
<dsmith-work>IT's the code sneek is running.
<dsmith-work>Well, I did a make install for sneek, and then another make isnstall with DESTDIR
<dsmith-work>I've got no where to put it though. 7M
<dsmith-work>So basically, as root, just unpack this file over yout filesystem. ;^)
<dsmith-work>Yeah, I wouldn't trust me either.
*add^_ is listening to a 9 year old video (not watching it, the flicker is really annoying) with paper to it about writing a Scheme to C compiler.
<mark_weaver>I'll make some proper debs soon.
<mark_weaver>going offline for a bit
<fbs>dsmith-work: i can put it on
<fbs>depends on how public you want to make it
<fbs>dsmith-work: putting a tarbal on gitorious might also work :p
<fbs>civodul: 38?
<fbs>no lies
<civodul>38 what?
<civodul>ah, well 83
<civodul>FDN is a French cooperative ISP
<civodul>it just means i'm the 83rd subscriber
<civodul>s/i'm/i was/ because i'm at another cooperative ISP now
<fbs>is there a #ifdef eqv for using in guile?
<DerGuteMoritz>cond-expand perhaps?
<fbs>im rewriting the network stuff for my irc lib and i want to make gnutls an option
<DerGuteMoritz>ah ok I don't know the proper way to do that
<fbs>basically i got all the ssl stuff in tls.scm, all the networking (socket creation, connect, sendreceive) happens in network.scm
<fbs>so networking uses some of the tls (wrap-tls, setoptions) but nothing else
<mark_weaver>72 users on #guile. yeah!
<fbs>oh mark_weaver you might know
<fbs>fbs | is there a #ifdef eqv for using in guile? im rewriting the network stuff for my irc lib and i want to make gnutls an option. Basically i got all the ssl stuff in tls.scm, all the networking (socket creation, connect, sendreceive) happens in network.scm
<fbs>so networking uses some of the tls (wrap-tls, setoptions) but nothing else
<mark_weaver>You should be able to avoid compiling .go files that don't support gnutls.
<mark_weaver>you should be able to postpone the question until runtime.
<fbs>but how do i handle it at runtime?
<mark_weaver>'cond-expand' is a compile-time thing.
<mark_weaver>let me think a bit about the best way to do this.
<mark_weaver>if I'm not mistaken, (@@ (MODULE NAME) id) will not load that module until it is actually evaluated.
<mark_weaver>let me verify that.
<mark_weaver>actually, that's not true, but there's another way.. hold a bit.
<fbs>oh im not in a hurry
<civodul>fbs: see
<civodul>this is slightly fragile, unfortunately
<civodul>with 2.0.9 you could #:autoload (gnutls)
<mark_weaver>yeah, I was just looking at that. seems that #:autoload still tries to load the module prematurely.
<mark_weaver>but I guess it at least deals gracefully with failure now.
<civodul>yes, exactly
<mark_weaver>and it will try again if it fails the first time?
<mark_weaver>(I'm going to test that now)
<civodul>not sure
<mark_weaver>it tries again.. good.
<mark_weaver>it spews an absurdly large number of repeated errors though. for a super-simple test, it printed 13 lines of errors (6 copies of the same two-line error about the missing module)
<mark_weaver>using 'module-autoload!' only prints the error once.
<mark_weaver>fbs: anyway, your options are: #:autoload in the 'define-module', which only works in 2.0.9 and above, e.g. #:autoload (gnutls) (make-session connection-end/client WHATEVER-ELSE-YOU-WANT)
<mark_weaver>or: (module-autoload! (current-module) '(gnutls) '(make-session connection-end/client))
<mark_weaver>which should work in more versions.
<mark_weaver>I guess 'module-autoload!' is the way to go for now. sorry I don't have a nicer answer.
<mark_weaver>we're clearly going to have to clean this up.
<fbs>so #:autoload only loads the module when the code actually uses one of the procedures in the list?
<fbs>thats quite cool
<mark_weaver>(although in fact it tries to load the module when it's compiled). but if it fails it will deal gracefully, and try again when it actually runs.
<civodul>but when it runs, it gets loaded on demand
<civodul>that is, when you access the specified top-level variables
<mark_weaver>the only slight glitch will happen during compilation of your irc library code (i.e. creation of the .go files)
<civodul>well, you'll get warnings, but it will build
<fbs>should be good enough for now :)
<mark_weaver>at that point, it will try to load the gnutls module, and report some errors if it can't find it.
<mark_weaver>but it'll still work, and in fact the compiled code will be able to use gnutls if it becomes available later.
<fbs>thanks guys :)
<mark_weaver>np :)
*Fulax haz patch for guile-1.8 and makeinfo-5.1