IRC channel logs

2013-04-08.log

back to list of logs

<cky>wigs: I'll respond to your messages on IRC, since I'm lazy. ;-)
<wigs>cky: sure
<wigs>I just had a better look at the core promises as well
<wigs>how they print
<cky>wigs: After discussion with mark_weaver, we decided the display of #<procedure ...> in the lazy promises was actually more useful than just the object addresses, since it displays location information.
<cky>(line number and file name and the like)
<wigs>ah, true
<wigs>but this leaves somethign to be desired, with the core promises as well
<cky>As for srfi-45:promise, that's possible but very verbose.
<wigs>it makes it very clear the object type
<wigs>otherwise you have two similar but not the same formats, where one means core and the other srfi-45. which is which?
<wigs>clearer to use a single format with different tag at the front
<mark_weaver>wigs: I'm open to suggestions. it's not too late :)
<mark_weaver>wigs: what tags would you use?
<wigs>#<promise and #<srfi-45:promise
<mark_weaver>honestly, I'd like to see the core promises go away
<mark_weaver>yeah, I thought about that, but it's very long.
<wigs>long but clear, and you can use the same format for the remainder
<wigs>core promises, it is not clear whether '#<procedure' is the value or the promise thunk
<mark_weaver>*nod*
<wigs>1 sec.
<mark_weaver>wigs: I'm sympathetic to your suggestion
<mark_weaver>one thing though: if a new SRFI is made that's just like SRFI-45 except with 'eager' as a macro to support multiple values nicely, then those two SRFI promises could actually be the same underlying type.
<mark_weaver>then what?
<mark_weaver>ideally, I'd have preferred to make all promises in the system to be the same type.
<wigs>sure, especially as srfi-45 is semantically a superset
<mark_weaver>the only problem is that the core promise API makes a promise (no pun intended) that I think was a serious mistake: they contain mutexes and do locking automatically.
<mark_weaver>which slows them down quite a bit.
<mark_weaver>so actually, SRFI-45 is not semantically a superset.
<wigs>then deprecate?
<wigs>imo the same should be done with streams
<mark_weaver>yeah, I think I'd prefer that.
<mark_weaver>so maybe the core promises and streams should print as #<legacy-promise ...> and #<legacy-stream ...>
<mark_weaver>and the modern promises and streams should print as #<promise ...> and #<stream ...>
<wigs>hm
<wigs>once deprecated, sure
<mark_weaver>and hopefully we can use just one underlying promise type for all non-legacy promises for the foreseeable future.
<cky>mark_weaver++
<mark_weaver>wigs: why do we have to wait until they're deprecated?
<wigs>avoid confusion over e.g. namespace
<wigs>promise? answers for legacy-promise
<wigs>srfi-45:promise? answers for promise
<mark_weaver>well, there's a good chance that we'll add (ice-9 promises) soonish that contains something like SRFI-45 but not quite.
<mark_weaver>the underlying promise type will be the same as SRFI-45 promises though.
<mark_weaver>but it'll export a different 'eager'
<cky>Will (ice-9 promises) be in C (albeit without mutexes), or still in Scheme?
<mark_weaver>so then we have two predicates that correspond to the same type. so we can't follow this rule of using the predicate for the tag.
<wigs>i see
<mark_weaver>cky: I think Scheme, unless it can be shown that there's a very significant performance advantage to using C.
<wigs>i think i missed the mail talking about this different eager
<cky>Because I can think of a way to make two promise types in C without lots of duplicate code.
<cky>wigs: The new eager just allows multiple values.
<wigs>ah
<mark_weaver>wigs: in SRFI-45, eager is a procedure, so it can't accept a single expression that yields multiple values.
<mark_weaver>we can't fix that without making eager a macro.
<mark_weaver>but that potentially breaks compatibility with code written for SRFI-45.
<wigs>yeah I see
<mark_weaver>(in practice, I suspect that most code would work fine)
<wigs>which of these modules do you think will replace r5rs in the default namespace?
<wigs>(do you think)
<cky>mark_weaver: Tricky part is precompiled .go files. It would still try to look for an eager procedure.
<mark_weaver>wigs: right, that too.
<mark_weaver>sorry, that was for cky
<cky>;-)
<wigs>isnt that quite an odd choice for srfi, that delay is syntax and eager not?
<mark_weaver>wigs: well, I think the SRFI-45-like one with eager as a macro would be the best candidate, but I don't think we can replace the core promises for the foreseeable future, nor do I see a compelling reason to do so.
<wigs>mark_weaver: makes sense
<mark_weaver>it could break existing Guile code that depends on the core promises locking mutexes by default, and for what? to save a single use-modules' line?
<wigs>did either of you read the srfi discussion archive, and see any comments about eager-procedureness?
<mark_weaver>yes, and I recently posted my proposal to keep eager a procedure that takes any number of arguments (to make it work like 'values' except creating a promise).. and Eli Barzilay convinced me that it was a bad idea.
<mark_weaver>that's why I reverted my SRFI-45 changes to support multiple values.
<mark_weaver> http://srfi.schemers.org/srfi-45/post-mail-archive/maillist.html
<wigs>thanks
<mark_weaver>as Eli wisely advised, it's more important to promise the best API we can than to preserve strict SRFI-45 compatibility.
<mark_weaver>s/promise/provide/
<wigs>hence, maybe new srfi. got ya
<mark_weaver>of course we need to keep SRFI-45 itself compatible. but it's better to make a new SRFI (and in the meantime, (ice-9 promises))
<mark_weaver>and in practice, most code could be switched over to use the new SRFI without any changes.
<mark_weaver>so popping the stack back to our original discussion, this idea of having multiple modules with different APIs but the same underlying promise type conflicts with the idea of printing the SRFI number in the type tag.
<wigs>yes it does
<wigs>I presume that ice-9:promise? and srfi-45:promise? will answer to the same objects?
<wigs>then they should get the short tag
<mark_weaver>yes
<mark_weaver>another idea: it might be possible, with some trickery, to arrange to make the core promises use the same underlying representation as the modern ones in 2.2.
<cky>In practice there will just be two stream types, SRFI 45/(ice-9 promises)/whatever new SRFI we write; and SRFI 41's stream promises.
<cky>(If we ignore the core/legacy promises.)
<mark_weaver>I can foresee the need for other modules to make their own distinct promise types, so I don't think we can assume that there will be only two.
<wigs>cky: and there is no room to have srfi-41 use the 45 types, correct?
<mark_weaver>so I think we'll want some kind of type tag that's part of the modern promise data structure.
<mark_weaver>but when someone asks for a new disjoint promise type, they'll give it their own new tag name.
<mark_weaver>so for example, SRFI-41 streams are actually modern promises with a 'stream' tag.
<wigs>ah
<wigs>would you use this to prevent e.g. (force $stream)
<wigs>and other low-level fiddling
<mark_weaver>wigs: yes
<mark_weaver>wigs: really, each new type of promise needs a new set of procedures to operate on it.
<wigs>good
<mark_weaver>the simplest way to do it is to put the whole SRFI-45 implementation (which is quite small) within a macro, so that it can be instantiated as many times as you like.
<mark_weaver>unfortunately, there's a psyntax bug in 2.0 that prevents this from working.
<mark_weaver>I'm extremely exhausted right now. I wouldn't be surprised if my brain is not quite working properly right now :)
<wigs>back to simpler topics..
<wigs>two questions remain
<wigs>you two discussed it yesterday, and are fairly convinced of the utility for printing the promise thunk?
<wigs>(i.e. for source details)
<wigs>and.. the utility of printing the value, when it has been computed?
<wigs>#<promise addr thunk> and #<promise addr => value>
<cky>mark_weaver: You should go to sleep when you're able to. Now that you don't necessarily have to finish NEWS tonight.
<wigs>or s/=>/#:value/
<wigs>(more standard for object printers)
<dsmith>In other news.., Now building psyntax-pp.go
<cky>:-D
<dsmith>So I guess it's been building for about 4 hours or so?
<dsmith>The good thing is, that it's not been hitting the swap.
<wigs>dsmith: where is this?
<dsmith>wigs, My cobal qube 2 where sneek lives
<cky>wigs: This is the machine that sneek runs on.
<dsmith>cobalt
<cky>Jinx!
<wigs>is this a typical compile time?
<dsmith>For that box, yeah
<wigs>parallel build?
<dsmith>Takes all weekend to build.
<wigs>fun
<dsmith>IT's a 300MHz mips. 64M of ram I think.
<cky>Hahaha, almost like the 300MHz Celeron system I built back in 1999.
<dsmith>It's from about that time
<dsmith>sneek should be especially sluggish..
<dsmith>Hmmm.
<dsmith>No sneek
<dsmith>Ahh..
<dsmith>Doen't like the new libgmp that came with the upgrade I guess
<dsmith>Bah
<dsmith> GUILEC ice-9/psyntax-pp.go
<dsmith>/bin/sh: line 5: 8518 Illegal instruction GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guild compile --target="mipsel-unknown-linux-gnu" -Wunbound-variable -Warity-mismatch -Wformat -L "/home/dsmith/src/guile/module" -L "/home/dsmith/src/guile/module" -L "/home/dsmith/src/guile/guile-readline" -o "ice-9/psyntax-pp.go" "./ice-9/psyntax.scm"
<dsmith>make[2]: *** [ice-9/psyntax-pp.go] Error 132
<mark_weaver>dsmith: hmm
<mark_weaver>dsmith: does the debian wheezy package of guile 2.0 work?
<dsmith>I'll check..
<dsmith>No. But ldd shows it trying to use the libguile from /usr/local/lib
<dsmith>I'll need to remove that
<mark_weaver>I wonder if you have anything else in /usr/local/lib that's out of date and causing problems.
<dsmith>I just mv'ed lib to lib-old and share/guile to share/guile-old in /usr/local
<dsmith>I was getting an error about gmp. Now it's this
<dsmith>ERROR: In procedure catch-closure:
<dsmith>ERROR: Throw to key `decoding-error' with args `("scm_from_stringn" "input locale conversion error" 22 #vu8(45 45 118 101 114 115 105 111 110))'.
<mark_weaver>ah, I've seen that come up a few times.
<dsmith>from guile --version
<mark_weaver>what are your LANG and/or LC_ALL variables set to?
<dsmith>Locale?
<dsmith>LANG=en_US
<dsmith>No LC_ALL
<mark_weaver>just for kicks, what happens if you set LANG=en_US.utf8 ?
<dsmith>Make it very happy
<dsmith>makes
<dsmith>$ LANG=en_US.utf8 guile --version
<dsmith>guile (GNU Guile) 2.0.5-deb+1-3
<mark_weaver>you'll have to ask Ludovic about that. I thought that issue was fixed ages ago. I just don't remember what's going on there.
<mark_weaver>but almost all of us are using utf8 locales nowadays.
<mark_weaver>gotta go afk for a while. good luck!
<dsmith>THanks
<mark_weaver>dsmith: I'm back. any luck now running guile from git?
<dsmith>Well, that was quick!
<dsmith>I did a fresh pull, and am currently running make _version.
<dsmith>I'll try the build again with the .utf8 LANG
<dsmith>mark_weaver, I sent off the end of the build messages to guile-devel
<mark_weaver>I don't think that will make a difference for this.
<mark_weaver>building+installing Boehm gc-7.2d in /usr/local and then reconfiguring and rebuilding would probably be worth a try.
<dsmith>Yes
<mark_weaver>but a more direct approach would be to try to reproduce the illegal instruction in gdb and see where it's happening.
<mark_weaver>(but Boehm GC-7.2d is recommended in any case)
<dsmith>Hmm. the packaged libgc is
<dsmith>Version: 1:7.1-9.1
<mark_weaver>yes, it's very old.
<mark_weaver>many years old in fact.
<wigs>ubuntu has 7.2 which works on wheezy
<mark_weaver>it's highly recommended to install and run gc-7.2d
<mark_weaver>it's not a big build.
<dsmith>Yes it is.
<wigs>true
<mark_weaver>personally, I would avoid using any ubuntu packages on stock debian.
<dsmith>(recommended)
<mark_weaver>certainly something as core as gc
<wigs>I did have some problems with 7.1 package installed and local build of 7.2
<dsmith>How about 7.2alpha4
<wigs>even with 7.2 installed in /usr/local
<mark_weaver>also, does ubuntu even build for mipsel?
<dsmith>heh
<dsmith>I'll build the libgc
<mark_weaver>dsmith: I recommend this: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz
<mark_weaver>it's what I use on my wheezy box, anyway.
<wigs>mark_weaver: thats a point
*wigs pc-biased
<mark_weaver>it was a very quick and easy build for me. of course nothing will be as quick for you, but my point is, it's not big by any means.
<dsmith>The reason I asked about the alpha4 is I already have that installed in /usr/local
<dsmith>I'll build the newer one.
<mark_weaver>yeah, I think you should rebuild it.
<mark_weaver>btw, you may have moved /usr/local/lib and /usr/local/share out of the way, but what about /usr/local/include?
<mark_weaver>I worry about all this old crufty stuff mucking things up.
<dsmith>Sure
<dsmith>Well, I just moved those to try the packaged guile. I've since uninstalled that
<mark_weaver>also /usr/local/lib/pkgconfig
<mark_weaver>well, I guess that's in /usr/local/lib, so.
<dsmith>Ive never had a problem building guile with one already installed from source. This was actually working somewhat, as it got through the doc snarfing, and also it had aready compiled eval
<mark_weaver>*nod*
<mark_weaver>is it consistently reproducable? did you try rerunning make?
<mark_weaver>maybe it was some sporadic heisenbug, or maybe something more repeatable.
<mark_weaver>probably too late for that, but if it happens again, it's worth trying to repeat it.
<mark_weaver>and then the next step would be to either dump core and then look at the core in gdb, or run in gdb and get it to crash.
<wigs>given your previous locale settings.. related to utf8 characters in e.g. docstrings?
<dsmith>Looks like I have unistring installed from source.
<mark_weaver>wigs: well, scheme source code is always read in UTF-8 (unless there's an emacs-style coding decl).
<mark_weaver>dsmith: ah, that might be a problem.
<mark_weaver>dsmith: the libunistring from wheezy is good. I think you should clear out the one from /usr/local
<dsmith>I'll get rid of the old source builds and use packages, except for libgc
<mark_weaver>sounds good.
<dsmith>make was 222m into the build when it failed.
<mark_weaver>make sure to get rid of the include files, the pkgconfig files (/usr/local/lib/pkgconfig), the aclocal files (/usr/local/share/aclocal)
<mark_weaver>you shouldn't have to rebuild everything.
<mark_weaver>you can skip the ./autogen.sh step.
<mark_weaver>and you can leave any .go files that were successfully compiled.. I guess maybe that's just eval.go, but that's a big time commitment...
<mark_weaver>you'll need to rerun ./configure though.
<dsmith>Hmm.. Looks like I have some auto*tools installed in /usr/local too.
<mark_weaver>(after clearing out the old /usr/local stuff and installing the new gc-7.2d)
<dsmith>/usr/local is all cleaned out. Still building libgc
<dsmith>I'll fire off another guile build once libgc is installed, but I'm not waiting around for it
<mark_weaver>yeah, it's clearly a long process. brings back memories of building guile on my yeeloong, though the yeelong was still quite a bit faster than your box.
<dsmith>So make was about 3 hours and 42 minutes into it.
<dsmith>Ok!
<dsmith>new libgc installed
<dsmith>Starting the guile ./configure and make
<mark_weaver>cool
<mark_weaver>if you run into any further problems, it would be worth running "make check" in the libgc build dir.
<dsmith>Oh, I did a pull too, so it's now v2.0.7-323-geed0d26
<mark_weaver>(and maybe if you're leaving it going overnight, it might be worth leaving a "make check" running)
<dsmith>Yeah, I skipped the make check for libgc. I usually run that before I install.
<mark_weaver>eminently understandable, given the slowness of your box.
<dsmith>It's a pain to build on this thing, but it's really nice to know that guile *does* work there.
<mark_weaver>indeed
<mark_weaver>and it'll be great to have 2.0.8 tested on your box before release
<mark_weaver>I should really get my yeeloong repaired.
<dsmith>Though civoduls build farm is great
<dsmith>Oooo
<dsmith>checking whether ldexp() can be used without linking with libm... Segmentation fault
<dsmith>Ok, this box is acting goofy
<mark_weaver>there are issues with Linux on MIPS relating to floating-point stuff.
<mark_weaver>I ran into similar problems on my Yeeloong, and wrote a patch for Linux to emulate some of the missing stuff.
<dsmith>Hmm. It was ok before the etch->wheezy upgrade
<mark_weaver> http://www.mail-archive.com/loongson-dev@googlegroups.com/msg00382.html
<mark_weaver>I'm actually not sure off hand if that's relevant to your box at all.
<mark_weaver>some of it, at least, was loongson-specific. but I'm not sure that all of it was.
<mark_weaver>well, I can't remember, really. I did that work about 1.5 years ago.
<dsmith>I was running a make check for libgc while I was running ./configure in guile. The make check failed with a segfault! Re running it and it ran cleanly.
<mark_weaver>actually, some to think of it, that's probably not relevant for sneek's box.
<dsmith>That *shouldn't* have had any interaction.
<mark_weaver>s/some/come/
<mark_weaver>hmm
<mark_weaver>well, it might be a sporadic problem
<dsmith>Yes, I'm concerned that I might be having some HW flakyness
<mark_weaver>but it's definitely true that there are lots of issues on mipsel. there are issues in the toolchain, and lots of modern software has to be patched up to work around problems on mipsel.
<dsmith>Yes.
<dsmith>Emacs had X11 issues too.
<mark_weaver>it might be worth running "make check" a few more times.
<dsmith>Good idea
<dsmith>Currently re-running ./configure in guile.
<dsmith>heh
<dsmith>checking whether ldexp() can be used without linking with libm... yes
<dsmith>checking for libunistring... yes
<dsmith>Worked this time
<mark_weaver>wow. yeah. I confess that I'm coming around to your suspicion of hardware flakiness.
<mark_weaver>I had issues with mipsel, but not this kind of random stuff.
<mark_weaver>the problems were generally reproducible.
<mark_weaver>it could be that the illegal instruction you got before was just more random flakiness.
*dsmith considers plugging the fan back in
<dsmith>Though it *has* been running fine fanless for many years
<dsmith>Ahem. Sure seems like there are a *lot* more math func checks.....
<mark_weaver>I think that's probably my fault :)
<dsmith>heh
<dsmith>Well, ./configure finished.
<dsmith>On to make
<dsmith>And bed for me. We'll see how it goes in the morning.
<mark_weaver>okay, sleep well!
<cordawyn>I've been trying to install guildhall and I could swear everything worked fine yesterday ;-)
<cordawyn>but today it just won't find the guildhall scripts
<cordawyn>I have $GUILE_LOAD_PATH set properly (I think) - it points to a dir with "guildhall" and "scripts" subdirs
<cordawyn>but strangely enough, guile just ignores $GUILE_LOAD_PATH
<cordawyn>guile
<cordawyn>%load-path
<cordawyn>$1 = ("/usr/share/guile/2.0" "/usr/share/guile/site/2.0" "/usr/share/guile/site" "/usr/share/guile")
<cordawyn>guile -L $GUILE_LOAD_PATH
<cordawyn>%load-path
<cordawyn>$1 = ("/home/cordawyn/.local/share/guile/site/2.0" "/usr/share/guile/2.0" "/usr/share/guile/site/2.0" "/usr/share/guile/site" "/usr/share/guile")
<cordawyn>what could be wrong?
<wigs>cordawyn: $ export GUILE_LOAD_PATH
<wigs>?
*nalaginrut is stealing something from tekuti...
<cordawyn>argh, I'll be damned :)
<cordawyn>thanks, wigs
<wigs>nalaginrut: git-db ??
<nalaginrut>wigs: well, base64 & atom
<wigs>oh
<nalaginrut>wigs: but yes, I'm writing a blog-engine based on git, just like jekyll and hyde
<nalaginrut>actually, it's just a kind of static page generator
<nalaginrut>folks may use it to build blog on github
<wigs>i see
<wigs>blogs blogs everywhere
<wingo>:)
<civodul>Hello Guilers!
<wingo>moin
<nalaginrut>blog is important for hackers, but I still don't find a nice blog-engine for me, so I have to write it...
<nalaginrut>morning~
<wigs>hi
<wigs>nalaginrut: you are serious? there are *loads*
<cordawyn>nalaginrut: what's wrong with jekyll?
<nalaginrut>cordawyn: it's cool, but the only problem is 'non-Scheme' ;-P
<cordawyn>or hekyll, for FP-minded :)
<DerGuteMoritz>if you are looking for something schemey there's http://api.call-cc.org/doc/hyde
<nalaginrut>DerGuteMoritz: oh~nice
<DerGuteMoritz>written for Chicken though
<nalaginrut>cool
<DerGuteMoritz>ah and the docs still claim there is no native markdown parser which is not true anymore
*DerGuteMoritz needs to make an update
<wingo>you have a markdown parser in scheme?
<DerGuteMoritz>yes
<wingo>nice :)
<DerGuteMoritz> https://bitbucket.org/DerGuteMoritz/lowdown
<wingo>does it use htmlprag or somethign for the html?
<DerGuteMoritz>I just couldn't stand it anymore at some time :-)
<civodul>there's also one in Hop, IIRC
<DerGuteMoritz>it emits SXML
<wingo>excellent
<nalaginrut>SXML is enought~
<nalaginrut>SXML is enough~
<DerGuteMoritz>it's a mostly straight port of pandoc's markdown parser
<nalaginrut>hmm...why it's named hyde? I thought it's python one
<DerGuteMoritz>nalaginrut: yeah I discovered the python one after I had already released it ;_D
<nalaginrut>;-P
<DerGuteMoritz>should have known better, the "joke" is too obvious
<nalaginrut>DerGuteMoritz: for that reason, I can't find it with google
<cordawyn>make it "hyde.scm"? ;-)
<DerGuteMoritz>nalaginrut: try finding scheme with google
<nalaginrut>I did that all the morning
<DerGuteMoritz>no problem though, I'm working on a successor to hyde anyway right now
<nalaginrut>can it work with Guile?
<DerGuteMoritz>unlikely out of the box
<DerGuteMoritz>some compatibility layer would have to be written
<wingo>anything can work with guile with a small matter of programming!
<DerGuteMoritz>right hehe
<DerGuteMoritz> http://pestilenz.org/~ckeen/blog/posts/hyde-blog-generator.html
<nalaginrut>yeah
<DerGuteMoritz>ah already found it? :-)
<DerGuteMoritz>here's his code https://github.com/ckeen/hyde-blog
<nalaginrut>DerGuteMoritz: thanks~
<DerGuteMoritz>feel free to pillage the code or ideas if you still want to write your own :-
<nalaginrut>DerGuteMoritz: if possible, I just want to run it with Guile, with some modify
<nalaginrut>is hyde on github?
<DerGuteMoritz>nalaginrut: no, it's in chicken's (old) central egg svn repo right now
<DerGuteMoritz>I may move it to bitbucket when I touch it next, though
<nalaginrut>DerGuteMoritz: is it in chicken-core?
<DerGuteMoritz>no, it can be installed with chicken-install
*nalaginrut is cloning chicken
<DerGuteMoritz>no need to
<DerGuteMoritz> https://code.call-cc.org/svn/chicken-eggs/release/4/hyde
<DerGuteMoritz> https://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/hyde/
<nalaginrut>DerGuteMoritz: would you mind if I put it on github after I made it compatible with Guile?
<DerGuteMoritz>nalaginrut: not at all
<nalaginrut>;-)
<DerGuteMoritz>beware though, the code contains some WTFs, it has grown over time
<nalaginrut>hmm
<DerGuteMoritz>not too bad WTFs, but still
<DerGuteMoritz>if you find scratching your head over something, feel free to bug me
<nalaginrut>OK
<nalaginrut>anyway, chicken site is slow in my network, include git
<DerGuteMoritz>are you cloning the core repo?
<DerGuteMoritz>it's largish
<nalaginrut>DerGuteMoritz: but I can't open the svn page
<DerGuteMoritz>what happens?
<nalaginrut>I don't know, it's slow, then throw unavailable
<nalaginrut>why not put it on github
<DerGuteMoritz>strange, it works for me
<DerGuteMoritz>yeah I will put it on a different hoster with the next update
<DerGuteMoritz>well I can do it right now already, just a minute
<DerGuteMoritz>when I started hyde the egg system was unable to handle distributed repos so that's why it's in the svn repo
<nalaginrut>DerGuteMoritz: nowadays github is better, though I think 'hyde' name may cause some issue ;-D
<DerGuteMoritz>I prefer bitbucket's web interface
<DerGuteMoritz>if I were to choose my tools by popularity I wouldn't be programming Scheme after all :-P
<nalaginrut>as you wish, I just want to read the code ;-P
<DerGuteMoritz>nalaginrut: there you go https://bitbucket.org/DerGuteMoritz/hyde
<nalaginrut>DerGuteMoritz: nice~thanks
<DerGuteMoritz>does anyone know where the code for Hop is hosted?
<DerGuteMoritz>on the website I only find a tarball
<nalaginrut>what's hop?
<DerGuteMoritz>ah found it
<DerGuteMoritz>nalaginrut: some Schemely web thing from France http://hop.inria.fr/ :-)
<DerGuteMoritz>civodul: hm are you sure the Markdown parser was in Hop?
*DerGuteMoritz can't find it
<nalaginrut>since there's static-page-compiler now, I'll try to write a real blog-engine with plugin-able theme
<DerGuteMoritz>cool, ping me when you have something to look at if you don't mind
<nalaginrut>DerGuteMoritz: sure
<nalaginrut>DerGuteMoritz: besides, this blog-engine will base one my web-framework Artanis: https://github.com/NalaGinrut/artanis
<nalaginrut>s/one/on
<nalaginrut>which is easy to work with Nginx
<DerGuteMoritz>how does it relate to nginx?
<DerGuteMoritz>does it run as a module?
<nalaginrut>DerGuteMoritz: no, you may configure it as reverse proxy
<nalaginrut>And I made it, it works for me
<nalaginrut>in short, it just redirect the request to local port, since Artanis could run on localhost:3000 or other ports you like
<DerGuteMoritz>I see. is anything special necessary to work behind a reverse proxy? I thought that's completely transparent
<nalaginrut>DerGuteMoritz: I think nothing complicated, just configure it and write rule, as simple as *.scm redirect to locahost:3000, and run artanis on 3000, and it works
<nalaginrut>I'll write a tutorial for that
<nalaginrut>artanis based on guile's inner server which could be 10K concurrency, if work with Nginx, I believe it's enough
<DerGuteMoritz>why not leave the nginx out?
<nalaginrut>it can
<nalaginrut>just run Artanis on your favorite port, and it's done ;-)
<nalaginrut>drop nginx means run it on 80
<DerGuteMoritz>right
<nalaginrut>but my VPS is shared with other guys, so I have to work with Nginx
<DerGuteMoritz>what I mean is: if you aim for performance, then having a proxy in between probably doesn't improve the situation :-)
<nalaginrut>well, all the static things will be handled by nginx, only dynamic part will be artanis', so I think it may proved
<nalaginrut>if artanis handled all things, it's useless with nginx
<DerGuteMoritz>yeah that may help
<nalaginrut>even if it's not enough, Nginx could be configured to balance the loads, there could be multi artanis process or distributed, I love nginx
<DerGuteMoritz>I would still make your application server capable to server static files as a fallback
<DerGuteMoritz>so you don't need nginx when developing an app
<nalaginrut>any App developed based on Artanis shouldn't consider this issue, it's the SA's work to configure. If I wrote a blog-engine, the app never knows which thing is handled by nginx/artanis, it's transparent
<nalaginrut>anyway, Artanis could handle all things include static one
<nalaginrut>nginx could be a optimization part of users, but not necessary
<nalaginrut>I mean 'needed'
<DerGuteMoritz>yes that's what I mean
<DerGuteMoritz>nginx is a deployment detail
<nalaginrut>yes
<nalaginrut>seems our REPL has issue, when it's "scheme@(guile-user) [2]>", just one ctrl-D could quit
<nalaginrut>hmm...even [1]
<nalaginrut>I'm in the latest stable-2.0
<lloda>nalaginrut: i've noticed the same issue
<nalaginrut>yeah, seems it's bug
<nalaginrut>even worse
<nalaginrut>hmm, no, not worse
<DerGuteMoritz>what's the number in square brackets?
<DerGuteMoritz>I don't have that on my prompt here
<DerGuteMoritz>ah, exception handler
<nalaginrut>DerGuteMoritz: yes, you have to do something wrong in the REPL for that
***zedstar_ is now known as zedstar
<dsmith>Bah. Build failed after 151 minutes in.
<dsmith> CC libguile_2.0_la-vm.lo
<dsmith>make[3]: *** [libguile_2.0_la-vm.lo] Error 1
<dsmith>Not much of an error message.
<civodul>on what platform?
*dsmith points the Finger of Accusation at ... Flakey Hardware
<dsmith>civodul, My old mipsel box
<dsmith>civodul, It was failing at (seemingly) random points yesterday.
<civodul>ok
<civodul>could be OOM or ICE
<civodul>try "make V=1"
<dsmith>civodul, It failed first deep into compiling psyntax.
<civodul>ah
<dsmith>But I had some old libs around, so I uninstalled some source built things, like libunuistring and an older libgc
<dsmith>And installed a new libgc from source.
<dsmith>THen it failed during ./configure (!!) checking some math function.
<civodul>not a good sign
<dsmith>Very strange
<dsmith>Sneek is floating around as mere bits on a disk while I attempt to resuscitate his host.
<civodul>damn, that's sneek's home?
<dsmith>yes
<civodul>so we'll have to debug it, then
<dsmith>Probably time for a new box
***DerGuteM1ritz is now known as DerGuteMoritz
<mark_weaver>nalaginrut: I just pushed a fix for the REPL EOF issue you mentioned: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7520a9b95d2661cf40f6c1bf8be79f38ca632516
<nalaginrut>mark_weaver: thanks~
<nalaginrut>I'll pull
<mark_weaver>thanks for reporting the problem!
<nalaginrut>mark_weaver: ;-)
<nalaginrut>mark_weaver: besides, I found "define-peg-string-patterns" can't receive var
<nalaginrut>I have to write string in literal
*mark_weaver has not yet looked at peg.
<civodul>hey mark_weaver
<mark_weaver>is there any reason not to include peg in 2.0.8?
<mark_weaver>hi civodul!
<civodul>thanks for fixing my mistakes ;-)
<mark_weaver>np :)
<mark_weaver>when mucking that that code, it's a good idea to test with the #if ... changed to #if 0
<civodul>hope you're kidding about PEG in 2.0.8 ;-)
<civodul>yeah
<mark_weaver>civodul: no, I wasn't kidding, but then I don't know anything about it.
<mark_weaver>but it sounds like something that would be fairly independent of the rest of the tree.
<mark_weaver>does it depend on features only available in master?
<wingo>i'm worried about committing to its api without any use
<civodul>+1
<wingo>for that reason it should not go into the stable series
<mark_weaver>ah, okay.
<mark_weaver>fair enough.
<mark_weaver>I certainly agree that we should be careful about committing to APIs.
<wingo>besides we should start moving in the direction of 2.2
<mark_weaver>+1
<mark_weaver>we have too many ill-thought-out APIs in Guile already :-/
<DerGuteMoritz>is that a parsing expression grammar API?
<wingo>DerGuteMoritz: yes
<mark_weaver>another task, less fun, that we should probably spend some time on, is helping some of the high profile guile users get their code migrated to 2.0.
<wingo>originally a summer of code thing from 2010
<DerGuteMoritz>ah neat
<mark_weaver>like texmacs and lilypond
<wigs>mark_weaver: quite right
<DerGuteMoritz>how does it work? is it functional or syntactic?
<wigs>gnucash
<DerGuteMoritz>where can I find the docs?
<wingo>DerGuteMoritz: both
<wingo>docs are in master
<mark_weaver>yeah, gnucash too
<DerGuteMoritz>ah!
<DerGuteMoritz>so no docs on the web, yetß
<DerGuteMoritz>?
<nalaginrut>most of the work a just 'sed' work ;-P
<nalaginrut>maybe too optimistic
<wingo> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=doc/ref/api-peg.texi;h=0e16aab7e40c1b06b33a8221a120f8d98ee1062d;hb=refs/heads/master
<DerGuteMoritz>wingo: thanks!
<nalaginrut>oh...I didn't find it, I was in read-the-fucking-code way...
<wigs>nalaginrut: some of these can use a serious cleanup, and some real guile muscle
<wingo>there are string pegs and s-expression pegs
<DerGuteMoritz>looks cool
<DerGuteMoritz>probably much more efficient than my parser combinator lib
<DerGuteMoritz>(the one I used for lowdown)
<DerGuteMoritz>heh: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=doc/ref/api-peg.texi;h=0e16aab7e40c1b06b33a8221a120f8d98ee1062d;hb=refs/heads/master#l832
<mark_weaver>civodul, lloda: one big thing missing from the NEWS file is all the work on the array code. I haven't been following that, so I can't competently write the NEWS about it.
<wingo>DerGuteMoritz: that code is terrible!
<DerGuteMoritz>indeed :-D
<mark_weaver>DerGuteMoritz: where's your parser combinator lib?
*mark_weaver likes parser combinators
<DerGuteMoritz>mark_weaver: https://bitbucket.org/DerGuteMoritz/comparse/
<mark_weaver>thanks!
<DerGuteMoritz>incomplete documentation can be found here http://api.call-cc.org/doc/comparse
<DerGuteMoritz>the introduction gives a walk-through overview of how it works
<civodul>mark_weaver: i think NEWS is up-to-date wrt. arrays
<mark_weaver>Once I read about a fast parser combinator lib, written in haskell, where each parser consisted of two parts: a static part that computed things like the lookahead sets, and the dynamic part. I've forgotten the details, but it would be good to have something like that for Guile.
<mark_weaver>civodul: ah, okay.
<nalaginrut>oh...there's s-expr PEG...I'll find docs anyway next time try new things...
<DerGuteMoritz>mark_weaver: http://moritz.twoticketsplease.de/paste/todo.txt.scm.html is a slighly more interesting example
<mark_weaver>DerGuteMoritz: looks nice!
<DerGuteMoritz>the todo-line parser is a bit dirty still :-)
<mark_weaver>heh, yeah, that one sticks out a bit. but most of it is quite nice.
<DerGuteMoritz>glad you like it
<proxhotdog>hi all
<mark_weaver>chicken uses the #!optional syntax as well.
<DerGuteMoritz>yep, it's from DSSSL
<DerGuteMoritz>hi proxhotdog
<mark_weaver>hi proxhotdog
<proxhotdog>does anyone know how to set up emacs in order to support guile, i tried geiser and it doesn't work
<DerGuteMoritz>proxhotdog: do you have guile 2 installed? geiser only works with 2
<proxhotdog>hmm, let me check the version first
<proxhotdog>v1.8.8
<DerGuteMoritz>most distros still have 1.8 :-/
<DerGuteMoritz>what distro are you on?
<wingo>geiser should probably check for 1.8 and give a better message...
<lloda>mark_weaver: civodul wrote the NEWS for those changes
<wingo>i wonder how hard a chicken compat module would be to write
<civodul>lloda: let us know if anything's missing
<proxhotdog>I'm a MAC OSX user
<DerGuteMoritz>wingo: that would be interesting :-)
<lloda>the whole thing needs a serious overhaul
<mark_weaver>Djurfeldt also wants our reader to support #!optional and #!rest, for his scmutils port.
<wingo>would be nice to be able to steal^Huse all of peter's library's ;)
<proxhotdog>and i use BREW to install guile, seems the repository doesn't have the most updated version
<wingo>*libraries
<mark_weaver>proxhotdog: homebrew has guile 2, but you have to pass the --devel option
<DerGuteMoritz>hehehe
<DerGuteMoritz>wingo: which ones are you thinking of?
<wingo>DerGuteMoritz: nothing atm
<DerGuteMoritz>ah so guile doesn't support #!optional?
<wingo>just idle thoughts :)
<mark_weaver>proxhotdog: probably some of the other ones do something similar, with you having to ask specifically for 2.0
<DerGuteMoritz>wingo: ok!! *goes hiding the code*
<wingo>:)
<DerGuteMoritz>:-D
<wingo>DerGuteMoritz: it's spelled #:optional
<DerGuteMoritz>ah
<wingo>not sure what other semantic differences there might be
<DerGuteMoritz>somebody suggested to have that as alternative syntax in chicken, too
<wingo>perhaps there is a reader option to treat #!optional as #:optional
<DerGuteMoritz>#:optional is a regular keyword, right?
<wingo>yes
<DerGuteMoritz>should be compatible then
<mark_weaver>proxhotdog: try "brew install guile --devel"
<DerGuteMoritz>I mean you can support both at the same time
<mark_weaver>wingo: yeah, I was thinking of just adding that
<mark_weaver>(simple reader option specialized for #!optional and #!rest)
<mark_weaver>ideally we'd have a more general mechanism for those things, but this would cover a common case anyway.
<DerGuteMoritz>do you guys have a "safe" reader?
<proxhotdog>installing, thanks!
<DerGuteMoritz>i.e. one that can be applied to untrusted input?
<civodul>ISTR there are subtleties between DSSSL's syntax for optional/keyword formals compared to ours
<mark_weaver>DerGuteMoritz: no
<mark_weaver>not that I know of anyway
<DerGuteMoritz>I see
<DerGuteMoritz>neither does chicken :-/
<DerGuteMoritz>I hear chibi contains a pure Scheme implementation of a reader though
<wingo>we don't? usually the read-and-eval stuff is off, no?
<civodul>well, there's a problem if said untrusted input in unbounded
<mark_weaver>wingo: well, our built-in reader probably isn't too far from safe, but personally I wouldn't trust it.
<civodul>but that's hardly avoidable :-)
<DerGuteMoritz>wingo: does that also affect SRFI 10 syntax, for example?
<DerGuteMoritz>or SRFI 107 :-D
<proxhotdog>anyone is working on Bioinformatics? Do you think scheme is a good language for that?
<DerGuteMoritz>(I hope that's not supported)
<wingo>DerGuteMoritz: if the application has srfi-10 loaded, then read is unsafe.
<mark_weaver>I happened to notice recently that the array-literal reader fails to check for numerical overflows for some of the numbers it reads. I've forgotten the details.
<DerGuteMoritz>proxhotdog: I know of a Chicken user who uses it heavily in bio informatics
<DerGuteMoritz>(I think it's bio informatics)
<wingo>right, besides the read-and-eval stuff our reader is only unsafe in the sense that it's implemented in c
<wingo>gnarly, nasty c
<DerGuteMoritz>proxhotdog: e.g. http://api.call-cc.org/doc/nemo -- is that from your domain?
<DerGuteMoritz>I don't understand anything of that
<mark_weaver>wingo: what read-and-eval stuff?
<wingo>proxhotdog: i thought lloda might be doing something like that
<wingo>mario-goulart: #.
<wingo>er
<wingo>mark_weaver: #.
<wingo>sorry :)
<proxhotdog>no
<proxhotdog>actually I am new to programming but I have tried code in ruby before
<lloda>i do numerics stuff, but it's mostly em
<proxhotdog>I am thinking of creating a library for DNA sequence manipulation
<lloda>no bioinformatics at all
<ijp>mark_weaver: re parser combinators. riastradh's parscheme is on guildhall
<mark_weaver>ijp: ah, thanks! I'll take a look.
<ijp>the work on adding static info in parser combinators is what I think led to 'arrows', and thus a million people asking 'wtf are arrows?' :)
<DerGuteMoritz>where can the guildhall be browsed?
<ijp>DerGuteMoritz: I don't have a site yet
<DerGuteMoritz>ah
<mark_weaver>wingo: ugh. I didn't know about that. that's actually not in read.c, but rather installed using 'read-hash-extend' in boot-9.scm
<DerGuteMoritz>but a repo or something?
<wingo>:)
<wingo>fun fun fun
<mark_weaver>well, I'm glad it's off by default anyway.
<ijp>DerGuteMoritz: if you have it installed you can do 'guild list-available --all'
*civodul discovers #.
<ijp>#.?
<wingo>hahahaha ;-)
<ijp>for numbers?
<civodul>#. is evil
<mark_weaver>+1
<wingo>kids these days, don't read their boot-9
<mark_weaver>it's funny that almost none of us knew about that.
<wingo>tsk tsk ;-)
<civodul>wingo: indeed! :-)
<civodul>it's been there forever
<wingo>clearly the answer is to do a worse job on the manual so people have to read more source code ;)
<mark_weaver>haha
*proxhotdog
<proxhotdog>what a long compiliation time zZZ
<mark_weaver>proxhotdog: the problem is that the compiler itself is not yet compiled. so the compiler is being interpreted, while compiling itself. very slow bootstrap.
<proxhotdog>i see
<DerGuteMoritz>ijp: guild: unknown script "list-available"
<DerGuteMoritz>:-(
<mark_weaver>it's actually gets much faster as you proceed.
<ijp>DerGuteMoritz: sorry, it's not shipped with guile
<ijp> https://github.com/ijp/guildhall/wiki/Getting-Started
<proxhotdog>so the first phase of compile is to compile a small subset of guile and then use this subset to build more and more by itself to become self-hosting, am I right?
<mark_weaver>ijp: actually, I have guildhall installed, and that command didn't work for me either. I know I've used it in the past though.
<ijp>or I suppose look at http://shift-reset.com/doro/
<mark_weaver>proxhotdog: sort of.
<ijp>sorry, list-packages
<DerGuteMoritz>ijp: ah thanks
<mark_weaver>proxhotdog: more precisely, each module that hasn't yet been compiled to a .go file has to be interpreted instead.
<proxhotdog>compiler is a fun topic :)
<mark_weaver>proxhotdog: so the compiler gets gradually faster with each module that's compiled.
<DerGuteMoritz>ah neat, there is a guildhall-git PKGBUILD
<DerGuteMoritz>I wonder why I do have a "guild" command though
<mark_weaver>proxhotdog: we tried to tune the compilation order to compile the most important modules first.
<ijp>DerGuteMoritz: guild is the new name of guile-tools
<nalaginrut>I'll make a site for guildhall after I finish blog-engine, if DB and JS is unnecessary, maybe static-page compiler is proper
<ijp>so, you can use it to e.g. compile or disassemble
<mark_weaver>ijp: when I try to "guild install" a package that's already the newest version, it says "The following packages have been kept back"
<mark_weaver>that seems suboptimal.
<ijp>hmm
<DerGuteMoritz>the error on missing config file is also a bit raw
<ijp>there are quite a few niggling UI things like that
<ijp>DerGuteMoritz: yeah, I should probably just generate a basic config the first time round
<DerGuteMoritz>nice, now it works!
<DerGuteMoritz>ijp: what's the repo you were talking about?
<DerGuteMoritz>where the parser combinator library is kept?
<DerGuteMoritz>ah now I see it
<DerGuteMoritz>I skipped it due to the wak- prefix
<mark_weaver>DerGuteMoritz: guild install wak-parscheme
<DerGuteMoritz>ijp: ah nice @ pfds
<DerGuteMoritz>oh what kind of extension is .sls?
<ijp>r6rs people use it
<DerGuteMoritz>I see
<DerGuteMoritz>what does it mean?
<ijp>scheme library source, I think
<DerGuteMoritz>scheme library source?
<DerGuteMoritz>heh
<ijp>there was also an .sps for programs, but less people used that
<DerGuteMoritz>I ported the persistent hash map from clojure[script] to chicken recently
<DerGuteMoritz>did you look into functional map data structures already?
<ijp>what are they using? HAMT?
<DerGuteMoritz>yeah
<DerGuteMoritz>hamt + path copying
<mark_weaver>DerGuteMoritz: oooh, I've been meaning to write such a thing for Guile.
<ijp>DerGuteMoritz: I have a map (pfds bbtree), but it is ordered
<DerGuteMoritz>ah I think I was looking into bb trees, too
<mark_weaver>DerGuteMoritz: where's your HAMT code?
<DerGuteMoritz>ah no it was weight balances trees
<ijp>I had most of a HAMT implementation written, but I didn't get around to adding it
<DerGuteMoritz>*balanced
<DerGuteMoritz>mark_weaver: it's here https://bitbucket.org/DerGuteMoritz/persistent-hash-map but beware, it's full of nasty optimizations :-)
<mark_weaver>wingo: do you think your recent work on mingw builds should be summarized in the NEWS?
<ijp>I expect it was due to portability concerneds, but I can't even seem to find the code anymore
<mark_weaver>DerGuteMoritz: thanks!
<DerGuteMoritz>original HAMT is not functional though, is it
<DerGuteMoritz>mark_weaver: you're welcome!
<mark_weaver>DerGuteMoritz: I'm in favor of nasty optimizations under the covers if it makes a significant difference in performance.
<ijp>DerGuteMoritz: the original version wasn't, no
<mark_weaver>that's what enables people to write nice code on top with acceptable performance.
<DerGuteMoritz>mark_weaver: see http://lists.nongnu.org/archive/html/chicken-users/2013-02/msg00072.html for some discussion of the implementation
<DerGuteMoritz>mark_weaver: yeah, indeed
<wingo>mark_weaver: it is, in the build fixes and bug fixes section
<wingo>and in the sections on file names
<mark_weaver>wingo: okay, thanks!
<wingo>it was a bit of work but in the end not a lot to say about it
<wingo>"works now where it didn't" ;)
<mark_weaver>*nod*
<mark_weaver>well, I guess NEWS is in pretty good shape now. only two more items left in the TODO:
<mark_weaver>"Reorder points in order of importance and make comprehensible". I did some reordering, but maybe not a complete or optimal job.
<mark_weaver>and "Assemble thanks"
<wingo>we should write a tool to grovel commit logs for thanks information
<mark_weaver>wingo: I only looked at git commits since your initial work assembling the NEWS. I assumed that you had covered everything that came before that.
<wingo>yes i got things before then
<wingo>i think anyway
<mark_weaver>okay, good enough
<mark_weaver>I'm not sure whether "New keyword arguments for procedures that open files" belongs in the "Notable changes" or "New interfaces". I put it up top in "Notable changes" for now. It's hard to be objective about ordering though. People tend to inflate the importance of their own work :)
<wingo>:)
<mark_weaver>feel free to reorder as you see fit.
<mark_weaver>the coding scan removal is also mentioned in that same item though, so if it's moved to "New interfaces", something about the coding scan removal should probably remain in "Notable changes".
<mark_weaver>DerGuteMoritz: it's a shame that the license you use is incompatible with the GNU GPL.
<mark_weaver>DerGuteMoritz: I want to port your code to Guile, but I guess I won't be able to :-/
<mark_weaver>s/a shame/too bad/
<DerGuteMoritz>mark_weaver: EPL you mean? I pretty much had to because it's a derivative work
<civodul>i see there's another one at http://mumble.net/~campbell/scheme/hash-trie.scm
<civodul>i wonder how it compares to "vhashes"
<mark_weaver>DerGuteMoritz: ah, so the Clojure implementation is licensed under the EPL?
<ijp>yeah, a lot of clojure code is
<wingo>never heard of the epl
<mark_weaver>pity. oh well, I can reimplement them from scratch, based on Hickey's talks and the Bagwell papers.
<wingo>sounds like a typo ;)
<mark_weaver>(which is what I was planning to do anyway)
<ijp>civodul: riastradh sometimes makes curious api choices, but that probably wouldn't be too difficult to modify
<DerGuteMoritz>EPL is pretty popular in Javaland
<civodul>ijp: like repeating "hash-trie/"?
<DerGuteMoritz>heh yeah what's up with that?
<DerGuteMoritz>doesn't mit-scheme have a module system?
<civodul>apparently some module systems lack the ability to rename bindings...
<proxhotdog>still compling...
<DerGuteMoritz>proxhotdog: when compiling chicken it emits something like "don't worry - still compiling" after 30 minutes with no output or so :-)
<ijp>I've previously suggested emitting something like "hey, this can take a while. grab a coffee.", before compiling boot-9
<proxhotdog>i have already compiled guile 2 on my mac for about 40 minutes
<DerGuteMoritz>ijp: +1 for that
<tupi`>an of topic quick texinfo [5.1] quiz: if i write "... @uref{http://www.altosw.be/kise/releases.html} ..." texinfo will properly partially write the url on 1 line and the rest of the url on the next line. but if i put the url in a variable and,use it, i.e. "... @value{ukise-releases} ..." it won't do that any more and i get the url written in the right margin. does any one know how to solve this? is there an '@allowvariablecontenthiphen'
<tupi`>or something ? so far i coudn't find by myself
<tupi`>i forgot to mention using texi2pdf, it writes in the right margin ...'
<civodul>no idea
<civodul>mark_weaver: there should be a NEWS entry for FreeBSD/threads: http://bugs.gnu.org/10641
<civodul>(just saw the diff)
*nalaginrut done with the REPL src
<mark_weaver>civodul: ah, okay.
<mark_weaver>ah, bug fix is already in NEWS (though it doesn't mention freebsd specifically): "Allow for spurious wakeups from pthread_cond_wait. (http://bugs.gnu.org/10641)"
<nalaginrut>mark_weaver: I've done the ,src with comments
<nalaginrut>I'll send it then go to bed...
<mark_weaver>nalaginrut: nice!
<mark_weaver>nalaginrut: can it cope with #!curly-infix ?
<nalaginrut>mark_weaver: I need to sample code to test
<mark_weaver>but it uses 'read' from the beginning of the file?
<nalaginrut>well, I don't think so, I use regexp to parse the string, but I could do small modify for that
<mark_weaver>I was thinking about this the other day, and realized that there are some genuinely thorny questions about "what is the source code". For example, where is the source code of an accessor for a SRFI-9 defined record?
<mark_weaver>for example, where's the source code of 'promise?' as defined in srfi-45.scm?
<nalaginrut>hmm...defined in C?
<nalaginrut>or generated on the fly?
<mark_weaver>no, it's pure scheme.
<mark_weaver>you could say it's defined on line 47 of module/srfi/srfi-45.scm
<mark_weaver>or, you could say that it's defined on line 321 of module/srfi/srfi-9.scm
<mark_weaver>or, you could say it's defined on line 104 (or maybe 105) of module/srfi/srfi-9.scm
<mark_weaver>when dealing with procedures that result from macro expansion, the question of where the "source code" is becomes unclear.
<mark_weaver>(these line numbers are all from recent stable-2.0)
<nalaginrut>hmm...seems a bit changes if I use 'read' way, the code logic has to be changed, alas~do it another day...
<mark_weaver>for those without easy access to the recent code, here are links so you can follow:
<mark_weaver> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/srfi/srfi-45.scm;h=6f7ba7e047411de781a1b7ac5ecd295b20d910cc;hb=stable-2.0#l47
<mark_weaver> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/srfi/srfi-9.scm;h=d213a8656dcf3cc9fd3e9e50b450a7298d361965;hb=stable-2.0#l321
<mark_weaver> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/srfi/srfi-9.scm;h=d213a8656dcf3cc9fd3e9e50b450a7298d361965;hb=stable-2.0#l104
<mark_weaver>which of those is the source code of the procedure 'promise?' from SRFI-45 ?
<DerGuteMoritz>I'd /ope9
<DerGuteMoritz>whoops
<mark_weaver>it's a thorny question.
<DerGuteMoritz>I wanted to say: I'd say from the user's perspective the top-most macro makes most sense
<DerGuteMoritz>so the define-record-type for promise?
<DerGuteMoritz>what's the purpose of this feature?
<mark_weaver>yeah, that should probably be the default, at least in this case.
<DerGuteMoritz>right
<mark_weaver>maybe there are other cases where it's less clear.
<DerGuteMoritz>as a user I can then macroexpand my way through
<DerGuteMoritz>I wonder!
<nalaginrut>mark_weaver: I think it's not so easy to go with 'read' way, how can I parse the expr? with 'match'? if so, I have to write parser for each language
<mark_weaver>regarding the purpose: nalaginrut is working on a ",src" REPL command to show the source code of a procedure.
<mark_weaver>nalaginrut: I've explained (multiple times) how to do it, for Scheme at least. For arbitrary languages there is no obvious way to do it currently, but your current code couldn't handle it either.
<mark_weaver>the thing that could be done for every language is to simply open your editor at the appropriate file and line, which I think will be what most people want anyway.
<nalaginrut>mark_weaver: I know how to do it for Scheme procedure src, but I've no idea how to handle the generic one
<mark_weaver>which is not to say that this wouldn't be a nice addition, but I don't want to merge something into Guile git that isn't as robust as we can make it.
<mark_weaver>we should be able to handle #!curly-infix and other such reader directives. we may end up with another reader directive to enable support for #!optional and #!rest for example
<mark_weaver>and that means using 'read' from the beginning of the file until you get to the right place.
<mark_weaver>and then possibly looking at the substructure of the top-level lists, to find the procedure definition within.
<mark_weaver>(if the procedure was defined internally)
<nalaginrut>OK, I'm trying #!curly-infix
<nalaginrut>is it need !# for end?
<mark_weaver>for an example of a procedure bound at top-level but defined internally, see 'bound-identifier=?' in module/ice-9/psyntax.scm
<mark_weaver>nalaginrut: no
<mark_weaver>nalaginrut: if the #! is immediately followed by a keyword that is known to the reader, then it is not a block comment but rather a reader directive.
<mark_weaver>nalaginrut: so "#!curly-infix", "#!fold-case", and "#!no-fold-case" are all reader directives.
<nalaginrut>I forget how's definition for sweet, #! define a 1 ?
<nalaginrut>I forget how's definition for sweet, #!curly-infix define a 1 ?
<mark_weaver>nalaginrut: these are not sweet expressions. our reader doesn't support those.
<mark_weaver>nalaginrut: put #!curly-infix on its own line, somewhere near the top of the source file.
<mark_weaver>then try putting {1 + 5} somewhere, which is interpreted as (+ 1 5)
<nalaginrut>so there's no definition for it?
<mark_weaver>nalaginrut: for more examples of curly-infix expressions, see http://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html
<nalaginrut>how to define proc in curly-infix?
<mark_weaver>that page of the manual has some examples, and also a link to the full SRFI-105 document, which gives a complete definition.
<nalaginrut>the same with prefix?
<mark_weaver>right. you normally don't use curly-infix for everything; just for selected subexpressions that look nicer in infix.
<mark_weaver>so, for example, instead of writing (< i n), you could write {i < n}
<nalaginrut>ok I see, {a define 1}
<mark_weaver>you could do that, but it looks terrible :)
<nalaginrut>my purpose is to parse the definition under curly-infix
<mark_weaver>but please, this idea of using regexps to find the beginning and end of the procedure... that's not something I'd want in guile core, IMO anyway.
<nalaginrut>and if it's the same with prefix, maybe it's necessary to write one for things such like {a define 1}
<nalaginrut>s/necessary/unecessary
<nalaginrut>well, I have to go to bed
<mark_weaver>okay, good night!
<mark_weaver>wingo: would you be willing to take care of assembling the thanks?
<wingo>mark_weaver: sure :)
<mark_weaver>wingo: thanks!
<dsmith-work>Hey hey
<dsmith-work>Could someone look through their backlog and tell me the last hostname sneek used?
<turbofail>well my logs may be patchy but it looks like it may have been cpe-184-56-129-232.neo.res.rr.com
<dsmith-work>Thanks!
<dsmith-work>Ok, this is an interesting compiler error:
<dsmith-work> CC libguile_2.0_la-expand.lo
<dsmith-work>expand.c: In function 'scm_init_expand':
<dsmith-work>expand.c:1271:1: internal compiler error: Segmentation fault
<dsmith-work>Please submit a full bug report,
<dsmith-work>with preprocessed source if appropriate.
<dsmith-work>See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
<dsmith-work>The bug is not reproducible, so it is likely a hardware or OS problem.
<dsmith-work>
<mark_weaver>dsmith-work: it might be worth testing your RAM.
<mark_weaver>or maybe it's time to upgrade the box. i suspect that for $20 (US) you could get a computer several times faster than that one, and with more RAM.
<ijp>mark_weaver: how far off from a release are we?
<mark_weaver>we're basically done, just waiting for Ludovic to have a spare moment. he's travelling today I think. he said that tomorrow was a possibility.
<dsmith-work>mark_weaver: Yes. I'm finally coming to the conclusion it's time to retire that box.
<dsmith-work>Need to get something like a sheeva plug
<dsmith-work>mark_weaver: I'm looking for something with comparable watts. Like 30
<mark_weaver>nowadays you can do much better than that.
<dsmith-work>Yes? Pointers? (I haven't been looking for HW in a long time)
<dsmith-work>And I usually use stuff others throw out.
<mark_weaver>well, the Raspberry Pi uses less than 5 watts. I'm sure that many modern ARM-based devices are in the same neighborhood.
<mark_weaver>I have one that I use for serial console access to my server. It's currently has an uptime of 186 days.
<mark_weaver>256 megs of RAM.
<dsmith-work>Ooo! Twice the ram.
<mark_weaver>all for $35 USD, although in practice it's a bit more because you'll need to get a mobile USB power supply.
<dsmith-work>;^)
<mark_weaver>oh, and you'll need an SD card also.
<dsmith-work>I've been meaning to look into those.
<dsmith-work>Good suggestion
<mark_weaver>cool.
<mark_weaver>I have to go offline for a while. ttyl!