<cky>wigs: I'll respond to your messages on IRC, since I'm lazy. ;-) <wigs>I just had a better look at the core promises as well <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>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 <wigs>#<promise and #<srfi-45:promise <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>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>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>so actually, SRFI-45 is not semantically a superset. <wigs>imo the same should be done with streams <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 ...> <mark_weaver>and hopefully we can use just one underlying promise type for all non-legacy promises for the foreseeable future. <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. <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. <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. <mark_weaver>wigs: in SRFI-45, eager is a procedure, so it can't accept a single expression that yields multiple values. <mark_weaver>but that potentially breaks compatibility with code written for SRFI-45. <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? <cky>mark_weaver: Tricky part is precompiled .go files. It would still try to look for an eager procedure. <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>as Eli wisely advised, it's more important to promise the best API we can than to preserve strict SRFI-45 compatibility. <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>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>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>would you use this to prevent e.g. (force $stream) <wigs>and other low-level fiddling <mark_weaver>wigs: really, each new type of promise needs a new set of procedures to operate on it. <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>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>(more standard for object printers) <dsmith>In other news.., Now building psyntax-pp.go <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. <dsmith>wigs, My cobal qube 2 where sneek lives <cky>wigs: This is the machine that sneek runs on. <wigs>is this a typical compile time? <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>sneek should be especially sluggish.. <dsmith>Doen't like the new libgmp that came with the upgrade I guess <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: does the debian wheezy package of guile 2.0 work? <dsmith>No. But ldd shows it trying to use the libguile from /usr/local/lib <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>just for kicks, what happens if you set LANG=en_US.utf8 ? <dsmith>$ LANG=en_US.utf8 guile --version <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>dsmith: I'm back. any luck now running guile from git? <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>building+installing Boehm gc-7.2d in /usr/local and then reconfiguring and rebuilding would probably be worth a try. <mark_weaver>but a more direct approach would be to try to reproduce the illegal instruction in gdb and see where it's happening. <wigs>ubuntu has 7.2 which works on wheezy <mark_weaver>personally, I would avoid using any ubuntu packages on stock debian. <wigs>I did have some problems with 7.1 package installed and local build of 7.2 <wigs>even with 7.2 installed in /usr/local <wigs>mark_weaver: thats a point <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 <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>Well, I just moved those to try the packaged guile. I've since uninstalled that <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>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: 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 <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>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... <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>Starting the guile ./configure and make <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>and it'll be great to have 2.0.8 tested on your box before release <dsmith>Though civoduls build farm is great <dsmith>checking whether ldexp() can be used without linking with libm... Segmentation fault <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>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. <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. <mark_weaver>it might be worth running "make check" a few more times. <dsmith>Currently re-running ./configure in guile. <dsmith>checking whether ldexp() can be used without linking with libm... yes <dsmith>checking for libunistring... yes <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>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..... <dsmith>And bed for me. We'll see how it goes in the morning. <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>$1 = ("/usr/share/guile/2.0" "/usr/share/guile/site/2.0" "/usr/share/guile/site" "/usr/share/guile") <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") <wigs>cordawyn: $ export GUILE_LOAD_PATH *nalaginrut is stealing something from tekuti... <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>blog is important for hackers, but I still don't find a nice blog-engine for me, so I have to write it... <wigs>nalaginrut: you are serious? there are *loads* <nalaginrut>cordawyn: it's cool, but the only problem is 'non-Scheme' ;-P <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? <wingo>does it use htmlprag or somethign for the html? <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>DerGuteMoritz: for that reason, I can't find it with google <DerGuteMoritz>no problem though, I'm working on a successor to hyde anyway right now <wingo>anything can work with guile with a small matter of programming! <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 <DerGuteMoritz>nalaginrut: no, it's in chicken's (old) central egg svn repo right now *nalaginrut is cloning chicken <nalaginrut>DerGuteMoritz: would you mind if I put it on github after I made it compatible with Guile? <DerGuteMoritz>beware though, the code contains some WTFs, it has grown over time <DerGuteMoritz>if you find scratching your head over something, feel free to bug me <nalaginrut>anyway, chicken site is slow in my network, include git <DerGuteMoritz>yeah I will put it on a different hoster with the next update <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>if I were to choose my tools by popularity I wouldn't be programming Scheme after all :-P *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: no, you may configure it as reverse proxy <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>artanis based on guile's inner server which could be 10K concurrency, if work with Nginx, I believe it's enough <nalaginrut>just run Artanis on your favorite port, and it's done ;-) <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 <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 <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>seems our REPL has issue, when it's "scheme@(guile-user) [2]>", just one ctrl-D could quit <lloda>nalaginrut: i've noticed the same issue <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>make[3]: *** [libguile_2.0_la-vm.lo] Error 1 *dsmith points the Finger of Accusation at ... Flakey Hardware <dsmith>civodul, It was failing at (seemingly) random points yesterday. <dsmith>civodul, It failed first deep into compiling psyntax. <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. <dsmith>Sneek is floating around as mere bits on a disk while I attempt to resuscitate his host. ***DerGuteM1ritz is now known as DerGuteMoritz
<nalaginrut>mark_weaver: besides, I found "define-peg-string-patterns" can't receive var *mark_weaver has not yet looked at peg. <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 ;-) <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 <wingo>for that reason it should not go into the stable series <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>we have too many ill-thought-out APIs in Guile already :-/ <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 <wigs>mark_weaver: quite right <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 <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! *mark_weaver likes parser combinators <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. <nalaginrut>oh...there's s-expr PEG...I'll find docs anyway next time try new things... <mark_weaver>heh, yeah, that one sticks out a bit. but most of it is quite nice. <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 <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 <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 <mark_weaver>proxhotdog: homebrew has guile 2, but you have to pass the --devel option <mark_weaver>proxhotdog: probably some of the other ones do something similar, with you having to ask specifically for 2.0 <wingo>DerGuteMoritz: it's spelled #:optional <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 <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. <civodul>ISTR there are subtleties between DSSSL's syntax for optional/keyword formals compared to ours <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. <proxhotdog>anyone is working on Bioinformatics? Do you think scheme is a good language for that? <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 <wingo>right, besides the read-and-eval stuff our reader is only unsafe in the sense that it's implemented in c <wingo>proxhotdog: i thought lloda might be doing something like that <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 <ijp>mark_weaver: re parser combinators. riastradh's parscheme is on guildhall <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?' :) <ijp>DerGuteMoritz: I don't have a site yet <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 <ijp>DerGuteMoritz: if you have it installed you can do 'guild list-available --all' <wingo>kids these days, don't read their boot-9 <wingo>clearly the answer is to do a worse job on the manual so people have to read more source code ;) <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. <ijp>DerGuteMoritz: sorry, it's not shipped with guile <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>sorry, list-packages <mark_weaver>proxhotdog: more precisely, each module that hasn't yet been compiled to a .go file has to be interpreted instead. <mark_weaver>proxhotdog: so the compiler gets gradually faster with each module that's compiled. <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" <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 <ijp>scheme library source, I think <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 <ijp>what are they using? HAMT? <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 <ijp>I had most of a HAMT implementation written, but I didn't get around to adding it <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: 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. <wingo>mark_weaver: it is, in the build fixes and bug fixes section <wingo>and in the sections on file names <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>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. <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 <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 :) <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 :-/ <DerGuteMoritz>mark_weaver: EPL you mean? I pretty much had to because it's a derivative work <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 <mark_weaver>pity. oh well, I can reimplement them from scratch, based on Hickey's talks and the Bagwell papers. <ijp>civodul: riastradh sometimes makes curious api choices, but that probably wouldn't be too difficult to modify <civodul>apparently some module systems lack the ability to rename bindings... <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 <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 ...' *nalaginrut done with the REPL src <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? <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. <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>which of those is the source code of the procedure 'promise?' from SRFI-45 ? <DerGuteMoritz>I wanted to say: I'd say from the user's perspective the top-most macro makes most sense <mark_weaver>yeah, that should probably be the default, at least in this case. <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>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: 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) <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. <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>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} <mark_weaver>wingo: would you be willing to take care of assembling the thanks? <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>expand.c:1271:1: internal compiler error: Segmentation fault <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. <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>mark_weaver: I'm looking for something with comparable watts. Like 30 <dsmith-work>Yes? Pointers? (I haven't been looking for HW in a long time) <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>all for $35 USD, although in practice it's a bit more because you'll need to get a mobile USB power supply.