<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___>or just anything you'd cond against? <ijp>no, a condition is a compound object that you return in an exception <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___ <ijp>I am well aware of that ***davexunit` is now known as davexunit
<ijp>figured you might be interested ***ijp` is now known as ijp
<ijp>no, it passes the tests now <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 was almost exploded when last time he's trying to write ruby-1.9 BNF for guile <ijp>ruby's grammar is nuts <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 <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>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 <ijp>the language allows you to elide the ;, but the repl isn't clever enough to figure it out yet <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>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 <ijp>it's weird, it only fails from a script, not the repl <ijp>probably better off waiting till the experts arrive <ijp>yes, but my issue is with `guild compile' <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. <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 <ijp>mark_weaver: sorry, what do I do with this gdbinit? my gdb is very rusty <mark_weaver>so run the "guild compile" in one terminal.. then get the process id of that guile. <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>and that should print a backtrace in the terminal that's running the guild compile <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? <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? <ijp>no, I have, but it was just a thought <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 <ijp>I was thinking of "Avoid unnecessary peeks for EOF in r6rs-ports." <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. <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? <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. <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 <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 <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 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 <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 <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 ..." <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>the relevant doc is the "Using Guile Without Installing It" section of the README. <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. <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. <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>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. <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) <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. <ijp>do we have a note to this effect? in NEWS or the manual? <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. <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. :-) <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. <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>curried cps: because idiomatic code for suckers <wingo>not sure if that binds an identifier or no <jmd>Is there a function to convert "0x1234" into an integer ? <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>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? (!!!) <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 :) <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_>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 <dsmith-work>Bah. I didn't see the "should" in there for some reason. ***ijp` is now known as ijp
<ijp>so, i got my raspberry pi earlier today <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 <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 <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. <fbs>breadboards are shit :> <ijp>they are an important prototyping tool, but I hated working with them <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 <ijp>burnt electronics has such an unsatisfying smell <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 <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 <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>over 300Joules when fully charged, so the 3 of them is 1kj <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>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 <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>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>It even took me *hours* just to remove packages (Like X11 stuff) I didn't need so I gad enough space to build Guile. <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 <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 <dsmith-work>If anyone is interested, I have a built guile in a tarball for the rpi. <dsmith-work>Well, I did a make install for sneek, and then another make isnstall with DESTDIR <dsmith-work>So basically, as root, just unpack this file over yout filesystem. ;^) *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. <fbs>dsmith-work: i can put it on fbs.blinkenshell.org/ <fbs>depends on how public you want to make it <fbs>dsmith-work: putting a tarbal on gitorious might also work :p <fbs>(~user@reverse-83.fdn.fr) <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? <fbs>im rewriting the network stuff for my irc lib and i want to make gnutls an option <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 <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>if I'm not mistaken, (@@ (MODULE NAME) id) will not load that module until it is actually evaluated. <mark_weaver>actually, that's not true, but there's another way.. hold a bit. <fbs>oh im not in a hurry <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. <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>I guess 'module-autoload!' is the way to go for now. sorry I don't have a nicer answer. <fbs>so #:autoload only loads the module when the code actually uses one of the procedures in the list? <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. *Fulax haz patch for guile-1.8 and makeinfo-5.1 