IRC channel logs

<mark_weaver>(on mingw)

<civodul>so, what do we do?

<mark_weaver>2.0.9?

<civodul>it hasn't been announced...

<dsmith-work>But it HAS been tagged

<mark_weaver>and uploaded

<civodul>why doesn't Hydra have that LIBGUILEREADLINE thing?

<civodul>the upload & tag can be overwritten

<mark_weaver>it's up to you.

<mark_weaver>but I think wingo's 'times' patch should be reverted.

<mark_weaver>I guess it's fine to upload, since the build will fail for everyone anyway.

<mark_weaver>it's not like anyone is going to fail to notice ./configure failing.

*fangism looks away while things get fixed...

<mark_weaver>the tag will be a pain though, for anyone who has already fetched the tag.

*dsmith-work waves

<ijp>yay, two guile releases

<ijp>the power of positive thinking

<dsmith-work>Ok, actually lol'ed on that

<cky>mark_weaver: Meh, it'll be fine, I think.

<cky>mark_weaver: Re refetching the tag.

<cky>Yes, they will have to delete the tag first.

<cky>But that can be mentioned in the announcement.

<cky>civodul: ^

<cky>FWIW, I'll be happy to reupload the tag onto my GitHub mirror too.

<mark_weaver>I still don't understand why there's a github mirror. you can create branches on savannah. why not do that instead?

<cky>mark_weaver: The GitHub mirror allows people to create forks if they want to, even if they don't have any access on Savannah.

<cky>mark_weaver: The forking aspect is what makes GitHub "social coding".

<cky>mark_weaver: GitHub has its own peculiar workflow, which a subset of developers are very familiar with.

<mark_weaver>github is based on non-free software.

<ijp>because certain silly branches I would like to write, but don't want to put on savannah, can go there

<ijp>like support for 7xx http statuses :)

<cky>Yes, that is true, and that's why it's not an official mirror per se. But if you Google for "guile site:github.com", my mirror is the top hit, so it's about as close to unofficially official as it gets. ;-)

<cky>ijp: :-D

<mark_weaver>have you looked at gitorious?

<cky>Yes, I have an account there. I can probably mirror to there too.

<ijp>github is based off non-free software, but so was sourceforge

<mark_weaver>how about mirror it there /instead/? well, whatever, i can't tell you what to do.

<mark_weaver>ijp: I don't like sourceforge either.

*tupi would try to keep it to 2.0.8 [if possible of course]

<mark_weaver>gitorious is based on free software. you can download it and run it on your own servers if you want.

<ijp>the same thing will probably happen with github, as with sourceforge. Everyone will move to $next-shiny-thing, and they'll release the code.

<ijp>anyway...

<youlysses>Oh yeah!

<youlysses>civodul: Vi parolas Esperanton?!

<mark_weaver>well, we shouldn't get distracted with this right now. the important thing is: what to do about the broken 2.0.8 tarball.

<mark_weaver>youlysses: yes, but don't distract him right now :)

<civodul>youlysses: jes :-)

<youlysses>mark_weaver: Sorry. ;-)

<civodul>mark_weaver: i'm testing a fix for the MinGW thing

<mark_weaver>civodul: okay

<civodul>the readline thing was my fault: i configured without readline

<youlysses>civodul: I've recently started learning and at some-point I think I way legitimately try and take-over the "Esperanto Translation Team"... But seeing you're busy atm, I'll talk more-so about it later. :-)

<mark_weaver>I've spent a lot of time learning esperanto about 8-10 years ago, but never got to use it regularly, and now I'm in serious need of a refresher.

<youlysses>mark_weaver: FYI, Kurso_de_Esperanto is a Free-software course (Gplv3 I believe?) that's fairly good.

<mark_weaver>youlysses: Thanks for the pointer! So far, I mostly learned by working through "A Complete Grammar of Esperanto" by Ivy Kellerman, which is available from Project Gutenberg.

<mark_weaver>though I didn't get all the way through that book.

<mark_weaver> http://www.gutenberg.org/files/7787/7787-h/7787-h.htm

<mark_weaver>but I'll definitely take a look at that software.

<dsmith-work>I'm always amazed at the competency in english that non-native speaker have. Like civodul here.

<mark_weaver>civodul's english is better than most native english speakers I know :)

<dsmith-work>Yes. That was my next point.

<civodul>i think i'll just go to bed and wake up earlier tomorrow

<civodul>so i get feedback from Hydra

<mark_weaver>civodul: Okay. IMO, it should be 2.0.9, especially if we wait that long.

<civodul>i deleted the tarball and removed the tag

<civodul>i think that's fine

<mark_weaver>I wonder if any mirrors got it.

<civodul>it's been on-line for 30mn at most

<mark_weaver>okay

<civodul>that's very unlikely

<cky>Indeed, I've removed the tag in my GitHub mirror (and not pushed the tag at all in my minty fresh Gitorious mirror).

<dsmith-work>And how do I locally removed the tag?

<cky>dsmith-work: git tag -d v2.0.8

<ijp>civodul: I'd still include a note in the release, just in case any guile contributors had already pulled.

<ijp>like those two ^^

<civodul>well, those who pulled must be here, no? :-)

<civodul>i could add a line in the announcement, but honestly, it seems like those who should know already know

*tupi would not add that line in the annoucment

<civodul>well i can still send an email on guile-{devel,user}

<cky>That sounds like the best plan. A heads-up on-list, but not in the announcement itself.

<civodul>yeah

<mark_weaver>civodul: several of the mirrors have already picked it pu.

<civodul>URL?

<mark_weaver>ftp://mirror.csclub.uwaterloo.ca/gnu//guile/guile-2.0.8.tar.gz.sig

<civodul>crap

<mark_weaver>ftp://mirror.vexxhost.com/gnu/guile/guile-2.0.8.tar.gz.sig

<tupi>really too bad!!

<cky>Wow, that's insane.

<mark_weaver>ftp://mirrors.kernel.org/gnu//guile/guile-2.0.8.tar.gz.sig

<mark_weaver>ftp://open-source-box.org/gnu//guile/guile-2.0.8.tar.gz.sig

<civodul>ok ok

<mark_weaver>ftp://gnu.mirrorcatalogs.com/gnu//guile/guile-2.0.8.tar.gz.sig

<mark_weaver>I could go on :)

<ijp>c'est la vie

<cky>2.0.4 was botched, and so was 2.0.8. Hopefully 2.0.12 would fare better. ;-)

<civodul>i guess the tarball will vanish from the mirrors

<civodul>anyway, 2.0.9?

<cky>Well, since you're releasing tomorrow morning, you can check the mirrors again then.

<cky>*shrug*

<mark_weaver>I think so, yes.

*civodul looks for a volunteer for 2.0.10

<civodul>or .11?

<mark_weaver>btw, I made some mistakes when pasting those urls. some of them are not real, but the mirrors.kernel.org one is really there.

<ijp>lol

<dsmith-work>cky: Thanks

<civodul>mark_weaver: kernel.org is even the *only* one

<mark_weaver>no, it's not the only one.

<civodul>kernel.org sucks

<cky>Lol.

<civodul>among those, i mean

<mark_weaver>*nod*

<ijp><ijp> ,flame kernel.org <fsbot> kernel.org: You basic-using, C#-loving level 61 moron

<mark_weaver>when I was searching through the 'wget' output, I made a mistake. I'll try again.

<dsmith-work>I think it's obvious. Last digit even means beta relese....

<cky>Lol.

<mark_weaver>haha

<dsmith-work>or -RC

<mark_weaver>other mirrors that have it include download.polytechnic.edu.na, gnu.xl-mirror.nl, and psg.mtu.edu

<mark_weaver>(my script is still working)

<civodul>.9 won

<dsmith-work>civodul: Will you rerag .8 ? I dont

<dsmith-work>think you need to.

<dsmith-work>retag

<ijp>I didn't know we had so many mirrors

<civodul>dsmith-work: dunno, doesn't seem very useful

<dsmith-work>An where are they when you want one?

<mark_weaver>let's try to forget about .8 :)

<mark_weaver>ijp: I count 143 GNU mirrors, not including rsync mirrors or ones that only mirror alpha.

<cky>Yeah, in my GitHub mirror I already nuked the 2.0.4 and 2.0.8 tags. I don't keep tags for known-busted releases. ;-)

<mark_weaver>civodul`: I'd probably be willing to do 2.0.10

<civodul`>mark_weaver: thanks, that'd be very welcome :-)

<cky>mark_weaver: Nice, I was thinking about nominating you when civodul suggested it. :-)

*tupi is happy to try a 2.0.9 tarball if that can be of any help

<ijp>cky: you did the coursera crypto course right?

<cky>ijp: Yes, I liked it.

<ijp>How long did it take you to decipher the two time pad in the first programming assignment?

<cky>ijp: I skipped that assignment, but I did all the other programming assignments.

<ijp>ah

<ijp>well, the ciphertexts were all crypto quotes

<cky>Hahaha, nice.

<mark_weaver>two time pad, haha. nice.

<ijp>well, in this case 10 time pad

<mark_weaver>they gave you 10 files encrypted with the same one-time pad?

<civodul>the stime fix worked on MinGW

<ijp>not files, they were somewhat short strings

<ijp>I think the longest was like 200 characters

<mark_weaver>apparently, one time pads are one of the primary things that diplomatic pouches are used to transport these days.

<ijp>cky: it wasn't worth it, you only got 1 point

<mark_weaver>it's the only encryption method that I understand well enough to fully trust :)

<mark_weaver>civodul: excellent!

<ijp>in related news, emacs has a great mode for deciphering substitution ciphers

<mark_weaver>ijp: what's it called?

<ijp>M-x decipher

<mark_weaver>nice!

<ijp>I know, I was surprised myself

<mark_weaver>I just noticed that there's a very short, very old NEWS file in doc/

<mark_weaver>and doc/oldfmt.c (?!)

<mark_weaver>doc/guile.1 needs to be updated for -C

<mark_weaver>not just for -C; it's quite out of date.

<mark_weaver>I don't know nroff

<mark_weaver>and doc/THANKS is very old too

<cky>ijp: I don't know about the scoring scheme in this iteration of the crypto course, but in the last iteration, programming assignments were worth 10x that of the quizzes.

<cky>ijp: So don't shrug off their value too quickly.

<ijp>maybe you're right, I'd need to doublecheck

<cky>mark_weaver: And are you generating your one-time pad using hardware entropy? :-) Otherwise you're at the mercy of your PRNG. ;-)

<cky>mark_weaver: I know man pages well enough to work on it.

<cky>mark_weaver: Do you want me to try to update guile.1?

<cky>I will grant that I prefer the BSD man format than the pre-BSD format, but, for a one-line change, it doesn't faze me that much.

<mark_weaver>cky: yes, of course if your one time pad comes from a PRNG, you might as well be using a more traditional encryption method.

<mark_weaver>cky: sounds great, thanks!

<mark_weaver>(regarding guile.1)

*tupi has to go, good luck all with 2.0.9 and thanks for the fantastic work that's being done!

<cky>:-)

<mark_weaver>tupi: thanks

<mark_weaver>cky: -x is also missing, and a bunch of other options.

<mark_weaver>cky: you could base it on the output of "guile --help"

<cky>mark_weaver: Sounds like a plan!

<mark_weaver>cky: thanks!

<cky>:-)

*civodul keeps a lock on the repo

<dsmith-work>civodul: How do you do that?

<mark_weaver>by saying so on irc :)

<cky>So I guess guile.1 isn't going to be updated, then? :-O

<mark_weaver>cky: yeah, this can wait until after 2.0.9. it's already a few years out of date anyway.

<cky>Okie dokie.

<cky>ijp: Speaking of Coursera, currently I'm doing the songwriting course.

<cky>It's pretty neat.

<mark_weaver>civodul: in the first NEWS entry, wingo forgot to include 'open-file' in the list of procedures that support keyword arguments.

<mark_weaver>civodul: would you like to fix that?

<mark_weaver>(since you have the lock :)

<civodul>probably not, i have distcheck running, etc.

<mark_weaver>okay, that's fine.

<mark_weaver>did you bump the version number to 2.0.9?

<mark_weaver>(in GUILE-VERSION) ?

<civodul>yep

<civodul>i just haven't pushed, because i'm still testing

<mark_weaver>okay, just making sure :)

<civodul>exactly :-)

<civodul>tarball to test: http://www.fdn.fr/~lcourtes/tmp/guile-2.0.9.tar.xz

<mark_weaver>civodul: downloading now

<civodul>cool

<mark_weaver>civodul: it's 2am where you are, isn't it?

<civodul>it is!

<civodul>send me an email if i get disconnected

<mark_weaver>okay

*mark_weaver builds 2.0.9

<mark_weaver>I'm compiling eval.go now.

<mark_weaver>now psyntax-pp.go

<mark_weaver>now vlist.go

<mark_weaver>civodul: it passed "make check" on my Debian wheezy system.

*dsmith-work runs ./configure

<dsmith-work>On a debian 6.0.7 64bit

<mark_weaver>I've started to build it on stallman.org now, which is a Debian stable system.

<mark_weaver>(and we'll see if it breaks my guile script that I have running there)

<dsmith-work>currenlty language/tree-il/primitives.go

<dsmith-work>with make -j4 && make check

<dsmith-work>-j5

<dsmith-work>wingo used to have this disgusting 8 core box that did build (seemingly) in seconds.

<dsmith-work>Yey! make check passes all

<mark_weaver>dsmith-work: excellent, thanks for testing :)

<dsmith-work>I've been waiting for this.

<dsmith-work>I can't use the automake from experimental, as it breaks my crosstools-ng build for some reason.

<mark_weaver>dsmith-work: you can always use the tarballs from hydra

<mark_weaver>I've also got builds started on my Sparc system (running Debian stable) and my Raspberry Pi. Both of those need some prerequisite libraries built first though.

<mark_weaver>(and of course will be much slower to build than my thinkpad)

<dsmith-work>I always forget about the snapshots

<dsmith-work>What disro is on your rpi ?

<mark_weaver>raspbian

<mark_weaver> http://www.raspbian.org/

<dsmith-work>soft-float?

*dsmith-work heads out...

<mark_weaver>dsmith-work: the raspberry pi has hardware floating point, and I assume that raspbian is compiled to use it, but I don't know for sure off hand.

<mark_weaver>(in fact, I think that's part of the reason raspbian was created)

<youlysses>Is there anyone actively working on better W32 support? I was asked in #gnunet and wasn't sure what to say... I assume no?

<mark_weaver>youlysses: wingo did a bunch of work recently for mingw cross builds.

<mark_weaver>youlysses: there are some recent successful cross builds here: http://hydra.nixos.org/job/gnu/guile-2-0/xbuild_mingw

<mark_weaver>unfortunately, it looks like some last-minute patches broke the mingw build.

<mark_weaver>last-minute patches intended for 2.0.8, that is.

<nalaginrut>morning guilers~

<mark_weaver>youlysses: what OS do you use?

<mark_weaver>and what version of guile do you have installed there?

<mark_weaver>hi nalaginrut!

<mark_weaver>nalaginrut: if you would be willing to try building the proposed Guile 2.0.9 tarball on your systems, it would be a helpful test before release.

<mark_weaver><civodul> tarball to test: http://www.fdn.fr/~lcourtes/tmp/guile-2.0.9.tar.xz

<nalaginrut>mark_weaver: 2.0.9?!

<nalaginrut>where's 2.0.8?

<mark_weaver>haha, yeah 2.0.8 turned out to have problems.

<mark_weaver>it's a repeat of 2.0.4 all over again :)

<nalaginrut>OK,I'll try it on centOS

<mark_weaver>great, thanks!

<nalaginrut>BTW, openSUSE always works nice

<mark_weaver>a test of opensuse would also be helpful

<mark_weaver>well, whatever you're motivated to do would be great :)

<mark_weaver>I know there are some BSD users around here. I wish I remembered who they were.

<nalaginrut>I always use guile from git on opensuse

<nalaginrut>is it necessary to test it anyway?

<mark_weaver>there's always the possibility that the tarball will be different. different versions of autotools used to bootstrap, etc.

<nalaginrut>ok

<mark_weaver>(the 2.0.8 tarball failed to build even though git worked for me)

<nalaginrut>which definitely needs verrry long time ;-P

<mark_weaver>needless to say, when testing the tarball, start with "./configure".. don't run autoconf or automake or anything like that.

<nalaginrut>yup

<nalaginrut>so you need make check right?

<mark_weaver>great, thanks very much! :)

<mark_weaver>yes, definitely.

<nalaginrut>hah~then you may get the result after 10 hours ;-P

*nalaginrut is configuring

<mark_weaver>nalaginrut: I thought your machine was faster than mine, based on benchmarks you posted for 'string-join' :)

<nalaginrut>my machine is fast, but many process opened for working, and the centOS on VPS may not so fast

<nalaginrut>anyway, it takes time

<mark_weaver>*nod*

<mark_weaver>I'm testing on every machine I have access to, which includes my Raspberry Pi, my Sparc-based server, stallman.org, and of course my laptop.

<mark_weaver>(sadly my Yeeloong is not usable at present)

<mark_weaver>oooh, I just remembered fencepost.gnu.org

<mark_weaver>which runs trisquel

<nalaginrut>how's trisquel

<nalaginrut>so RaspberryPi work for guile?

<nalaginrut>nice

<nalaginrut>I'll write a home server-site on RaspberryPi for my home

<nalaginrut>mark_weaver: I wonder if all the OS of GNU servers are using the latest autoconf/automake/libunistring/libgc

<nalaginrut>centOS-6.0-LFSed run into *.go stage ;-)

<mark_weaver>nah, fencepost is running fairly old software. I'll have to build some prerequisite libraries first.

<nalaginrut>mark_weaver: ah~so you face the same situation like me

<nalaginrut>hmm...if fencepost.gnu.org has the latest Guile, I could write mail filter with Guile...

<mark_weaver>indeed!

<nalaginrut>mark_weaver: how can you upgrade GCC & glibc & kernel on GNU servers?

<nalaginrut>is it needed?

<mark_weaver>I don't need to upgrade all of that.

<mark_weaver>I think a new libgmp and libgc will probably be enough on fencepost. we'll see.

<nalaginrut>guile tarball don't need the latest auto*, right?

<mark_weaver>right, you don't need auto* at all when you build from tarball

<mark_weaver>I'll need to configure those libraries with --prefix=$HOME/local-packages

<mark_weaver>and then set my LD_LIBRARY_PATH to $HOME/local-packages/lib

<mark_weaver>since I don't have root there.

<mark_weaver>I had to do something similar on stallman.org

<nalaginrut>what's the database of these servers?

<mark_weaver>I don't understand the question.

<nalaginrut>I mean dbm

<nalaginrut>mysql?

<nalaginrut>maybe don't need?

<mark_weaver>it's like asking what "the compiler" of these servers. there's no reason why it has to be just one.

<mark_weaver>I don't know off-hand.

<mark_weaver>I haven't worked on GNU's web server in many years, and no longer have shell access to it.

<nalaginrut>alright~

<nalaginrut>I just want to know the prefer dbm of GNU

<mark_weaver>I think that they generally prefer mysql of the mature SQL db's, because it's GPL-licensed.

<nalaginrut>hmm...my machine is very fast indeed, it started compiling after 10 minutes, but now it faster then VPS, working on tree-il, and VPS working on boot-9

<mark_weaver>But as I recall, the fsf.org web site is now running Plone, which has its own database written in python.

<nalaginrut>oh~done

<nalaginrut>make check

<mark_weaver>nalaginrut: nice!

<nalaginrut>VPS is struggling with boot-9...

<nalaginrut>mark_weaver: so there's no official web-framework huh?

<mark_weaver>my old sparc server only just started compiling eval.go. the raspberry pi isn't even done with the C code yet.

<mark_weaver>nalaginrut: no, not yet. Maybe something based on Guile, I hope :)

<nalaginrut>I wouldn't compile guile on rapberrypi, cross-compile is prefered

<mark_weaver>well, it's an interesting test anyway.

<nalaginrut>oh it's done on opensuse

<nalaginrut>Totals for this test run:

<nalaginrut>passes: 39641

<nalaginrut>failures: 0

<nalaginrut>unexpected passes: 0

<nalaginrut>expected failures: 6

<nalaginrut>unresolved test cases: 14

<nalaginrut>untested test cases: 1

<nalaginrut>unsupported test cases: 9

<nalaginrut>errors: 0

<nalaginrut>PASS: check-guile

<nalaginrut>=============

<nalaginrut>1 test passed

<nalaginrut>=============

<nalaginrut>anyway, yes, I confess my machine is very fast

<nalaginrut>but I wonder if it's so fast for the older Guile

<nalaginrut>;-)

<mark_weaver>nalaginrut: great, thanks very much! that's on opensuse, right?

<mark_weaver>ah, you already said that.

<nalaginrut>I'll give you more info

<nalaginrut>Linux Renee-desktop.suse 3.4.33-2.24-desktop #1 SMP PREEMPT Tue Feb 26 03:34:33 UTC 2013 (5f00a32) x86_64 x86_64 x86_64 GNU/Linux

<mark_weaver>what version of opensuse?

<nalaginrut>gcc-4.7.1

<nalaginrut>opensuse-12.2

<mark_weaver>great, that's enough. thanks much!

<mark_weaver>(I'm still curious about the centos build, of course :)

<nalaginrut>I'll try it on opensuse-12.3, but I haven't installed it

<mark_weaver>I wouldn't worry about it. mainly I just wanted some diversity of systems to test on.

<nalaginrut>oops, VPS server power off!

<mark_weaver>oh no!

<mark_weaver>why would that happen? I wouldn't have expected a VPS to do that.

<nalaginrut>ok, it's OK now

<nalaginrut>I don't know, it's shared, so...

<nalaginrut>shared with my friends

<nalaginrut>hmm...

<nalaginrut>it's still srfi-1

<nalaginrut>mark_weaver: any benchmark of 2.0.9?

<mark_weaver>I haven't really been concentrating on benchmarks, except for individual procedures that I've worked on where I worried about performance.

<mark_weaver>nalaginrut: maybe when your VPS comes back up, you can resume the build.

<mark_weaver>did it power off, or did you just lose the connection?

<nalaginrut>yes, it's OK now

<nalaginrut>there's a broadcast telling me shutoff now

<nalaginrut>I suggest add a NOTE: be patient, I'm not halting!

<mark_weaver>oh well.. thanks for trying :)

<nalaginrut>and I'm serious

<nalaginrut>mark_weaver: it's OK now, continuing

<nalaginrut>anyway, racket compiling is slow too, but when 'make install'

*ijp building 2.0.9

<mark_weaver>ijp: thanks! what system are you running?

<nalaginrut>ijp: bsd?

<ijp>nothing glamorous

<ijp>fedora 16 (don't ask) on a pentium 4

<mark_weaver>ijp: great! diversity of testing :)

<nalaginrut>I guess everyone faster then this VPS

<mark_weaver>my raspberry pi is still working on the C files. I suspect that actually has more to do with the slowness of its SD card than anything else. I wasn't intending to compile on it.

<mark_weaver>and my sparc server is still working on psyntax-pp.go

<mark_weaver>(10 minutes so far on that one file)

<nalaginrut>mark_weaver: I bet one week for *.go

<mark_weaver>haha

<nalaginrut>anyway, it's only 512M

<nalaginrut>ram

<ijp>I don't think it's the ram that's the problem there

<mark_weaver>damn, the compile on fencepost failed. the compiler doesn't seem to like some of the code in gnulib.

<mark_weaver>gcc 4.4.3

<nalaginrut>ah~pevel~

<nalaginrut>ah~peval~

<nalaginrut>ijp: yes, it's CPU I think

<nalaginrut>why it's so slow? any analysis?

<ijp>because if it was fast, it would cost more

<nalaginrut>how many passes while it's doing compile optimization

<mark_weaver>ah, I think I just need a newer libunistring

<nalaginrut>it's 8 cores Xeon, why it's so slow, hmm...

<nalaginrut>maybe make -j7

<mark_weaver>guile compiles the first files slowly because its compiler has not yet been compiled. so you have a slow interpreter running the compiler.

<nalaginrut>ah~I see

<nalaginrut>I saw may implementations claim that support r7rs, but it seems haven't out

<nalaginrut> http://the-concurrent-schemer.github.io/scm-doc/

<nalaginrut>s/may/many

<ijp>schemers claim a lot of things

<ijp>some of them are even true :)

<ijp>okay, I think the build is almost done

<mark_weaver>hmm, libunistring-0.9.3 failed "make check" on fencepost.gnu.org (Trisquel 4.1)

<mark_weaver>well, proceeding anyway.

<mark_weaver>my sparc server and raspberry pi are both working on psyntax-pp.go now :)

<ijp>so, no failures here

<ijp>well, no unexpected failures

<ijp>the expected failures fail

<mark_weaver>ijp: great, thanks much! :)

<mark_weaver>well, installing new libunistring fixed the build problem on fencepost.

<dsmith>mark_weaver, How long does your pi take to build guile?

<nalaginrut>make check

<nalaginrut>expected failures

<nalaginrut>so I have to develop artanis based on 2.0.9

<mark_weaver>dsmith: I've never tried building guile on it yet.

<mark_weaver>but it's been running 'make' for about 1h40m so far, and it's currently working on psyntax-pp.go

<mark_weaver>nalaginrut: ah, so it passed "make check" on centos?

<nalaginrut>mark_weaver: yes

<nalaginrut>it's OK

<mark_weaver>nalaginrut: great, thanks very much for the testing! this is very helpful :)

<nalaginrut>I do hope there's a new stable release that I can develop artanis based on

<mark_weaver>2.0.9 will surely be out within a day.. probably in a few hours.

<nalaginrut>nice~

<mark_weaver>my R Pi has been working on psyntax-pp.go for 30 minutes so far.

<ijp>like watching a baby punch a boxer

<mark_weaver>it took my old sparc server 27 minutes to build boot-9.go

<mark_weaver>R Pi is still working on psyntax-pp.go. 38 minutes and counting :)

<mark_weaver>I don't think the R Pi results will be ready before the release :)

<mark_weaver>well, the fact that it's even doing this much is promising.

<nalaginrut>mark_weaver: is there anyway to import 'unexported' symbols in a row?

<nalaginrut>all un-exported symbols

<mark_weaver>why do you want to do this?

<nalaginrut>I don't want to export some inner thing, but I need to use them in test-case

<nalaginrut>for testing

<nalaginrut>there're a lot, so I don't want to use (@@ for redefine them

<mark_weaver>hmm

<nalaginrut>module-export-all! can't do this

<mark_weaver>nalaginrut: well, for now anyway, you can do #:use-module ((module name) #:select (id1 id2 id3 ...))

<nalaginrut>oh~select could handle un-exported things?

<mark_weaver>yes, though I'll propose deprecating that at some point, or at least generating warnings.

<mark_weaver>personally, I think it's a mistake.

<ijp>that's kinda wierd

<mark_weaver>(that #:select allows that)

<mark_weaver>I suspect it's actually a bug.

<nalaginrut>hmm...I'd prefer you keep this feature but generating warnings

<nalaginrut>since we do need to use un-exported things sometimes

<mark_weaver>nalaginrut: here's my suggestion: write a macro that, given a list of names, generates (define name (@@ (module name) name))

<mark_weaver>so something like: (define-syntax-rule (import-unexported module (name ...)) (begin (define name (@@ module name)) ...))

<mark_weaver>I think you should do this rather than rely on the #:select bug

<nalaginrut>anyway to export all

<nalaginrut>?

<mark_weaver>it's a bad idea. that idea is incompatible with compilation.

<ijp>racket manages

<mark_weaver>racket provides a way to import all the unexported identifiers from a module?

<nalaginrut>ok, I got it

<ijp>oh sorry, I misunderstood

<ijp>I thought he was just after a way to export all the definded identifiers

<nalaginrut>module-for-each with module-define!

<nalaginrut>it's OK for a test-case

<nalaginrut>not a productive code

<mark_weaver>okay. you'll need to do it from within 'eval-when'. and you'll need to force re-compilation of the test code if the module changes.

<mark_weaver>beware that the code may break in future guile versions.

<mark_weaver>52 minutes and counting...

<mark_weaver>1 hour (and counting) compiling psyntax-pp.go on the R Pi. Yeah!

<nalaginrut>eval-when? I do it in proc

<nalaginrut>test-case don't need efficient ;-P

<nalaginrut>OK, so even I don't use macro, eval-when is needed huh?

<nalaginrut>(eval-when (eval load compile)

<nalaginrut> (define (export-all-from-module! module-name)

<nalaginrut> (let ((mod (resolve-module module-name)))

<nalaginrut> (module-for-each (lambda (s m)

<nalaginrut> (module-define! (current-module) s m)) mod))))

<nalaginrut>this?

<mark_weaver>you probably need 'module-add!' instead of 'module-define!'.

<mark_weaver>and you'll probably need to call 'export-all-from-module!' from within 'eval-when' as well.

<mark_weaver>maybe the 'eval-when's are not needed if you're not importing macros. I'm not sure off hand.

<mark_weaver>finished building psyntax-pp.go on R Pi, after about 83 minutes.

<mark_weaver>(for that one file)

*mark_weaver looks into cross-compiling :)

<nalaginrut>mark_weaver: IMO, you should test how long to build it on RaspberryPi

<nalaginrut>;-D

<nalaginrut>what's the difference between module-add! and module-define! ?

<mark_weaver>well, the import thing here is that the second argument to 'module-add!' is a variable, whereas the second argument to 'module-define!' is a *value*.

<mark_weaver>and the 'm' that you receive from 'module-for-each' is a variable, not a value.

<mark_weaver>nalaginrut: do you have an account on fencepost?

<nalaginrut>mark_weaver: yes

<mark_weaver>nalaginrut: okay, since you asked about guile on fencepost: you can use the one in /home/m/mhw/bin/guile

<mark_weaver>hopefully I set that up so that it'll work from your account.

<nalaginrut>but I didn't write a mail filter

<mark_weaver>well, it's there anyway.

<nalaginrut>OK~thanks~

<mark_weaver>:)

<nalaginrut>well...let me see, what's the rest work for a blog-engine...

*dsmith pinged rlb that 2.0.8 is out... hint hint

<dsmith>s/8/9

<mark_weaver>hi civodul!

<mark_weaver>good news!

<civodul>'lo!

<civodul>so it works? :-)

<mark_weaver>we've done some testing of your tarball. the only thing I have to add to it is that libunistring-0.9.3 seems to be needed.

<mark_weaver>compiling against libunistring-0.9.1 fails

<civodul>how?

<mark_weaver>the same problem described in http://bugs.gnu.org/11872

<mark_weaver>anyway, it's been tested in Debian testing + stable, and on fedora 16 (by ijp), and on opensuse-12.2 and centos-6.0 (by nalaginrut).

<civodul>wow, thanks

<civodul>i would go ahead, no?

<mark_weaver>and I'm close to having a "make check" on sparc (debian stable), and on the raspberry pi (raspbian, based on debian testing)

<civodul>i tested on sparc yesterday

<civodul>well, that was ~2.0.8

<mark_weaver>I think the README should be updated to mention that libunistring-0.9.3 is needed.

<mark_weaver>(maybe 0.9.2 would work, dunno)

<mark_weaver>but 0.9.1 definitely not

<nalaginrut>all these dependencies I'm using the latest

<nalaginrut>and besides, I added "export LC_ALL=en_US.UTF-8" to /etc/profile

<nalaginrut>on centOS

<civodul>mark_weaver: ok

<nalaginrut>and "export ACLOCAL_PATH=/usr/share/aclocal"

<nalaginrut>on centOS too

<mark_weaver>other than that, I should have "make check" complete on raspbian fairly soon.

<mark_weaver>(I gave up and copied the .go files from another machine though; it was taking too long)

<mark_weaver>(e.g. 82 minutes to compile psyntax-pp.go)

<nalaginrut>mark_weaver: for that purpose, you may need NFS

<civodul>mark_weaver: when using 0.9.1, lib/unitypes.h did get instantiated, right?

<mark_weaver>I have no idea, but I can send you the build log if you want.

<mark_weaver>I was using the libunistring packages from trisquel 4.1

<mark_weaver>(this was on fencepost)

<civodul>mark_weaver: can you paste it?

<mark_weaver>okay, hold a sec.

<mark_weaver>civodul: http://www.netris.org/~mhw/guile-2.0.9-build-failure-trisquel-4.1-log1

<civodul>heh, kernel.org lost the 2.0.8 tarball...

<mark_weaver>I wiped that build directory though.

<mark_weaver>I guess I could reproduce it though, if needed.

<mark_weaver>I don't see any mention of unitypes.h in the build log though.

<civodul>yeah

<mark_weaver>"make check" passed on my sparc system. the raspberry pi is still working.

<civodul>gl_LIBUNISTRING_LIBHEADER([0.9], [unitypes.h])

<mark_weaver>/usr/include/unitypes.h exists on fencepost.

<mark_weaver>I'm not sure how this is supposed to work though. I just know that it failed.

*civodul tries

<civodul>in short, there's no requirement on 0.9.3, it's supposed to adapt

<civodul>checking for libunistring version... 0.9.1

<civodul>ok, so the above gl_LIBUNISTRING_LIBHEADER line is buggy, it should read "0.9.2" or "0.9.3", whichever introduce _UC_ATTRIBUTE_CONST

<civodul>mark_weaver: could you report it?

<mark_weaver>I'm sorry, I don't understand this problem well enough to report it.

<civodul>ok

<civodul>i'm updating README and uploading the tarball, is that oK?

<mark_weaver>updating the README to say libunistring 0.9.3 required?

<civodul>yes

<mark_weaver>okay, sounds good!

<civodul>good

<mark_weaver>the raspberry pi is at srfi-67.test.. all good so far.

<mark_weaver>I think it's safe to say that it's in good shape.

<mark_weaver>the raspberry pi (running raspbian) passed "make check"

<nalaginrut>we don't have request-cookie parsing?

<civodul>mark_weaver: great

*civodul passed distcheck, now uploads

<nalaginrut>is it intended? or missing/

<mark_weaver>it's on ftp.gnu.org. woohoo!

<nalaginrut>OK, I see, it need to get from request-headers

<civodul>mark_weaver: sounds like a déjà vu ;-)

<mark_weaver>civodul: what's the story with mingw builds? is guile supposed to be buildable on mingw32?

<civodul>yes, i cross-built it before going to bed, and it went fine

<civodul>bug reports no longer allowed ;-)

<nalaginrut>anyway, I do think there should be (define (request-cookie req) (assoc-ref (reqeust-headers req)))

<mark_weaver>I'm trying to help LRN on #gnunet, and he says it doesn't work. e.g. we're using mmap, which is not available.

<civodul>well, at least it builds :-)

*civodul goes for breakfast

<mark_weaver>okay, ttyl!

<civodul>hey wingo

<jmd>What's fprintf in guile?

<mark_weaver>jmd: format

<mark_weaver>different format string syntax though

<mark_weaver>hi wingo!

<jmd>Yeah it uses ~ instead of % or something.

<mark_weaver>it's completely different

<mark_weaver>wingo: did you ever try running the mingw build of guile?

<mark_weaver>wingo: over on #gnunet, LRN is trying (and failing) to get it working.

<mark_weaver>he wrote: <LRN> mark_weaver, /me tried to build Guile from git, but it uses posix_memalign and mmap, which are not available. There aligned allocaters exist, but they must be matched with appropriate de-allocators - something you don't need for posix_memalign()

<mark_weaver>and: <LRN> If i hack around mmap and allocation issues, guile throws a GC error when it runs: Too many heap sections

<jmd>mark_weaver: Well the manual says: " C programmers will note the similarity between `format' and

<jmd>`printf', though escape sequences are marked with ~ instead of %" .

<mark_weaver>*nod* that's certainly the first difference you notice.

<mark_weaver>btw, beware that guile actually contains two implementations of format. the one that you get by default is very simple, with few features. you must import the (ice-9 format) module to get the full featured version.

<jmd>"C programmers will note the SIMILARITY ..." but you say they are "completely different".

<wingo>morning

<mark_weaver>well, for simple things like %d, %e, %f, %g, you can just change % to ~

<wingo>no i was unable to cross-run mingw

<mark_weaver>but the syntax for specifying more complex options is different.

<mark_weaver>wingo: ah, so more work still needs to be done. okay.

<wingo>we don't use mmap if the platfor doesn't provide it

<mark_weaver>what about posix_memalign?

<wingo>mark_weaver: actually it sounds like lrn was building from master

<mark_weaver>yeah, I asked him to use stable-2.0

<wingo>i think we use posix_memalign on master bit not stable-2.0

<wingo>it's related to elf alignment

<wingo>that will need additional work :)

<mark_weaver>okay, thanks.

<wingo>aw, so did i bork the release with my times thing?

<mark_weaver>hehe

<wingo>damn

<mark_weaver>civodul fixed it

<mark_weaver>LRN says: install-exec-hook: in meta/Makefile.am is wrong. it adds EXEEXT to "guild", but "guild" is a shell script

<mark_weaver>does that sound right to you?

<mark_weaver>I guess it sounds right to me, but I

<mark_weaver>I'm utterly ignorant of windows (and happily so)

<mark_weaver><LRN> guile-039300a1ebee116082d50d61e6b3aeafc8a741ec/test-suite/standalone/test-unwind.c:213: undefined reference to `mkstemp'

<wingo>that's a test

<mark_weaver>*nod*

<wingo>mark_weaver: probably meta/Makefile.am is indeed wrong then

<mark_weaver>he said: "3 guile instances hung up while compiling stdlib."

<wingo>can you ask him to send a mail to bug-guile with his findings? :)

<mark_weaver>will do

<wingo>that way we can be sure they get fixed

<wingo>although, it seems i didn't fix lloda's values-related bug for this release; humm.

<mark_weaver>I don't even know what stdlib is in this context.

<mark_weaver>any idea what that's about?

<wingo>no idea :)

<wingo>but if he got to the point of compiling test-unwind.c that's already pretty good

<wingo>that would mean he got through compiling the .go files

<mark_weaver>*nod*

<jmd>Now I need a getline. What's getline in guile?

<wingo>that question assumes we know what getline is

<wingo>pro tip: if you load guile's manual in info, C-s lets you search its full text

<wingo>then you'll find read-line, if that's what you're after

<mark_weaver>jmd: 'read-line' from (ice-9 rdelim)

<jmd>Thanks.

<jmd>read-line returns a "line of text" so why do I get an error when I do (display (read-line port))

<mark_weaver>what is the error?

<jmd>ERROR: Wrong type to apply: "SFRNAME,SF ...."

<mark_weaver>this is guile 1.8?

<jmd>Yes

<jmd>Actually there seems to be a more general problem.

<mark_weaver>it sounds like you are trying to call a string as if it were a procedure.

<jmd> (let* ((x (read-line csv)) (display x)) (display "Done"))

<jmd>

<mark_weaver>a string that contains "SFRNAME,SF"

<jmd>Yes. Thats the value of x

<mark_weaver>ah, you are defining "display" to be equal to "x" there.

<mark_weaver>your parens are mismatched.

<jmd>Oh right. Sorry.

<wingo>heya civodul

<wingo>sorry for borking the release with that times patch!

<civodul>np, i was able to bork it by myself too ;-)

<wingo>:)

<wingo>waiting until the morning was a good plan :)

<civodul>:-)

<mark_weaver>jmd: if you use an editor that auto-indents scheme code, and if you put each binding on its own line in a 'let', then mismatched parens will usually be immediately apparent.

<jmd>mark_weaver: My problem wasn't mismatched parens, it was forgetting to assign something in (let)

<mark_weaver>well, the error you mentioned here on channel was caused by mismatched parens.

<jmd>I wish there was the possibility to assign to a "dummy" variable.

<mark_weaver>what do you mean?

***ArneBab_ is now known as ArneBab

<mark_weaver>why assign it at all, if you don't care about the value?

<jmd>Well yes. I mean if I could call something in let* without assigning.

<mark_weaver>ah, yes.

<mark_weaver>I often think it would nice if inner definitions could be freely mixed with non-definitions.

<mark_weaver>I'm not sure why that's not allowed, since you can do the same thing by assigning to a dummy variable that's never used.

<DerGuteMoritz>jmd: you could weave it into another binding value by wrapping it with begin

<mark_weaver>and in fact a good letrec optimizer will eliminate the variable.

<DerGuteMoritz>I usually use something like (_ (do-something)) though

<mark_weaver>DerGuteMoritz: yeah, I've thought of that too, but it's ugly.

<DerGuteMoritz>yeah

<DerGuteMoritz>underscore is the convential "don't care" name

<mark_weaver>*nod*, that's a better solution IMO.

<mark_weaver>jmd: yeah, just use _

<jmd>ok

<mark_weaver>DerGuteMoritz: although it should be mentioned that binding _ will break the special meaning of _ in macros such as 'match' from (ice-9 match)

<mark_weaver>wingo: fyi, I asked LRN about his statement "3 guile instances hung up while compiling stdlib."

<jmd>I don't understand what the manual is saying that read-line returns under eof conditions.

<mark_weaver>wingo: and he meant during compilation of the Guile modules; presumably during a GUILEC. he said that the cpu usage was 0

<mark_weaver>jmd: it returns an "eof object", which you can detect using the 'eof-object?' predicate.

<jmd>eof-object? should be called on the port, or on what was returned?

<mark_weaver>so you should check (eof-object? x) where x is the result from read-line

<mark_weaver>on what was returned.

<mark_weaver>that's the case for virtually all of the procedures that read from a port in scheme.

<jmd>ok

<DerGuteMoritz>mark_weaver: hm that's odd, can you give an example?

<DerGuteMoritz>the pattern clauses in match are quoted, aren't they

<DerGuteMoritz>at least in matchable they are

<mark_weaver>DerGuteMoritz: (match '(1 2) ((_ _) #t))

<mark_weaver>DerGuteMoritz: and then try: (let ((_ 5)) (match '(1 2) ((_ _) #t)))

<mark_weaver>in the first case, '_' is recognized as the special "don't care" literal token.

<mark_weaver>in the second case, '_' is treated like any other identifier, i.e. as if it were (x x)

<mark_weaver>(as if (_ _) were (x x), that is)

<DerGuteMoritz>why, indeed

<DerGuteMoritz>I was not aware of this, thanks

<mark_weaver>that's because when macros recognize literal tokens, the match only occurs if the identifier is bound to the same variable in both the macro definition and the macro usage... (or the identifier is unbound in both places)

<DerGuteMoritz>right

<DerGuteMoritz>same for else in cond, right?

<mark_weaver>yes

<DerGuteMoritz>(let ((else #f)) (cond (else 1)))

<DerGuteMoritz>I find this rather stupid

<DerGuteMoritz>OTOH it's more general that way

<mark_weaver>I'll grant that it's a debatable point, but it's certainly not stupid. there are good reasons for it.

<DerGuteMoritz>yeah

<DerGuteMoritz>stupid was the wrong word :-)

<DerGuteMoritz>debatable, maybe that, yeah

<mark_weaver>Alex Shinn took that position (that literal tokens should be matched unhygienically) on the scheme-reports list not long ago, and he was schooled by Eli Barzilay :)

<DerGuteMoritz>yeah I read that one

<mark_weaver>wingo: LRN reports a hang while compiling rnrs/arithmetic/fixnums.scm

<mark_weaver><LRN> from the look of the thread table, it's a lockdown

<mark_weaver><LRN> http://pastebin.ca/2354502

<mark_weaver><LRN> ntdll!RtlUpdateClonedSRWLock() is used by WaitForSingleObjectEx()

<jmd>What's the most efficient way to test that a string starts with a particular prefix?

<mark_weaver>'string-prefix?'

<mark_weaver>e.g. (string-prefix? "blah" "blah-blah") => #t

<jmd>tthanks

<mark_weaver>civodul, wingo: am I correct in believing that guild compile shouldn't normally create more than one thread?

<mark_weaver>or is there something in there that does some parallelism?

<civodul>yes (except for the signal thread and GC marker threads)

<mark_weaver>thanks!

<civodul>but we could use par-map et al. in there

<mark_weaver>it turns out that he build libgc with parallel marking enabled.

<mark_weaver>*built

<mark_weaver>he's going to try rebuilding gc without that.

<DerGuteMoritz>guile has a concurrent GC?

<nalaginrut>and a generational GC

<DerGuteMoritz>pretty neat

<mark_weaver>actually, not by default.

<nalaginrut>but easy to enable

<DerGuteMoritz>the concurrent one?

<mark_weaver>I don't know the details. civodul might know.

<mark_weaver>there's an environment variable that will enable an incremental mode, where some marking is done on every allocation to reduce pause times.

<mark_weaver>beyond that, I don't know.

<mark_weaver>I guess that recent libgc supports parallel marking, but I don't know if it works robustly or not. seems to be causing random hangups in guile on windows (but maybe that's only on windows, dunno)

<wingo>DerGuteMoritz: it's not concurrent; it's still stop-the-world but with parallel marking

<wingo>we use whatever libgc gives us, which is that by default

<DerGuteMoritz>wingo: ah I see

<DerGuteMoritz>libgc is boehm?

<DerGuteMoritz>thanks for clarifying

<mark_weaver>DerGuteMoritz: yes

<wingo>there are some options for incremental marking but we don't turn those on by default

<wingo>mark_weaver: on master, finalizers run in their own thread

<wingo>fwiw

<mark_weaver>wingo: *nod* these lockups on windows are happening on stable-2.0 though.. (but with parallel marking enabled in libgc)

<mark_weaver>e.g. http://pastebin.ca/2354502

<wingo>you can export GC_MARKERS=0 to disable parallel marking

<wingo>somethign like that

<wingo>see a note from mike gran on the ml a few months ago

<mark_weaver>ah, thanks.

<mark_weaver>civodul: the hydra cross-builds are failing with this error: configure: error: building Guile 2.0.9-dirty but `/nix/store/896al4k29krlc1sbkf15fdbmsygm8lqg-guile-0pre/bin/guile' has version 2.0.7"

<civodul>i think it has to do with tags

<mark_weaver>the version.test failures before had to do with tags

<mark_weaver>I suspect this is different

<nalaginrut>may I call for benchmark of 2.0.9?

<DerGuteMoritz>ok now that 2.0.9 is released I shall polish up my guile2 PKGBUILD

<mark_weaver>DerGuteMoritz: excellent!

<civodul>mark_weaver: it's a version check; the native guile that's used claims to be 2.0.7, whereas it should be .9

<wingo>it will probably be fixed with the next pushed patch

<civodul>yes, i think so

<wingo>the hydra cross-builds use the previous build's native guile, no?

*DerGuteMoritz builds

<mark_weaver>ah, okay

<civodul>wingo: yes

<add^_>Oh? 2.0.9? I thought it was going to be 2.0.8..

*add^_ git pull

*civodul too

<wingo>bonus release

<DerGuteMoritz>indeed, what happened to 2.0.8?

<DerGuteMoritz>heh

<mark_weaver>2.0.8 was botched

<add^_>Broken?

<civodul>odd micro version numbers denote super cool versions

<wingo>interestingly, we have now had more micro releases than 1.8

<DerGuteMoritz>"I accidentally the release"

<wingo>:)

<civodul>even micro version numbers denote non-existent versions

<DerGuteMoritz>no problem, I have a few version numbers spare if you run out

<add^_>:-)

<nalaginrut>where's the release news?

<wingo>in NEWS of course!

<nalaginrut>on site?

<wingo>wat

<DerGuteMoritz>in tarball

<wingo>you can find it all from gnu.org/s/guile

<wingo>click NEWS, then there is a link.

<nalaginrut>nice

<wingo>but it's in the repo

<nalaginrut>I'll report it to geek site

<DerGuteMoritz>geek site?

<nalaginrut>DerGuteMoritz: somewhere like slashdot, in china it's solidot

<DerGuteMoritz>haha, nice, I see it

<DerGuteMoritz>is that a slashdot partner site or a ripoff?

<DerGuteMoritz>ah looks like a partner site

<nalaginrut>I don't know ;-)

<nalaginrut>what's the highlight feature should I mention, for 2.0.9?

<jmd>"alist" is not in the Guile Tutorial index. I would have thought it was rather important for a tutorial.

<wingo>jmd: there is no more guile tutorial, if you are referring to the outdated documentation from 1.8

<wingo>it was folded into the manual

<jmd>ok.

<jmd>Does the new one have an index entry for "alist" ?

<wingo>why don't you compile 2.0 and see? :)

<mark_weaver>jmd: yes

<jmd>oh good.

<mark_weaver>jmd: but I second wingo's suggestion. guile 2.0 is a *major* improvement over 1.8.

<jmd>I'm sure it is. But it's not yet ubiquitous

<mark_weaver>jmd: what are you working on, btw?

<jmd>Right now, or in general?

<mark_weaver>what are you using guile for?

<jmd>Right now, I'm just hacking up a script to process a csv file for a rather special purpose.

<jmd>But did you look at my hack-pot entry I submitted a few months back?

<mark_weaver>ah yes, I do remember that. it sounded interesting :)

<mark_weaver>I should take a look at your code

*mark_weaver git clones

<mark_weaver>jmd: here's a nicer way to define 'ldisplay': (define (ldisplay l) (for-each write-line l))

<mark_weaver>you'll need to import (ice-9 rdelim) for write-line

<mark_weaver>jmd: in the top expression of a lambda or let, you don't need to use 'begin', so in line 54 of statistics.scm, you can get rid of the begin.

<mark_weaver>jmd: on line 64 of statistics.scm, (lambda (elem cum) (+ cum elem)) can simply be replaced by +

<mark_weaver>jmd: in line 98 of jco.scm, use 'for-each' instead of 'map'. 'map' needlessly creates a list which you then throw away.

<mark_weaver>jmd: 'calculate' and 'los-gehts' could be more elegantly written using 'for-each'

<mark_weaver>jmd: (srfi srfi-26), which includes 'cut', would also help. for example: (define (calculate reader args) (for-each (cut jco-reader-iterate reader the-statistics <>) args))

<jmd>mark_weaver: Thanks. I've made a note of those comments.

<mark_weaver>jmd: on line 42 of jco.scm, you use 'eq?' to compare two numbers. that's not safe. 'eq?' cannot safely be used on numbers or characters.

<mark_weaver>use '=' there

<mark_weaver>same on line 36

<DerGuteMoritz>hehe @ los-gehts

<DerGuteMoritz>(the name)

<jmd>I couldn't think of a better name at the time.

<DerGuteMoritz>= for comparing characters?

<DerGuteMoritz>jmd: reminds me of http://api.call-cc.org/doc/heap-o-rama/do-the-dance :-)

<mark_weaver>no, '=' is only for comparing numbers. 'char=?' for characters.

<DerGuteMoritz>mark_weaver: thanks for pointing this out, I always use eq? for comparing chars!

<DerGuteMoritz>maybe it works reliably in chicken though

<mark_weaver>'eq?' is really just an efficiency hack. 'eqv?' is the better version of 'eq?'.

<DerGuteMoritz>right :-)

<DerGuteMoritz>so eqv? works for chars, too?

<mark_weaver>in practice, 'eq?' currently works on characters and small integers, in Guile and most Scheme implementations.

<mark_weaver>DerGuteMoritz: yes.

<mark_weaver>but beware that 'eqv?' on inexact numbers probably means something different than what you want. it means "operational equivalence", i.e. that any numerical operation that you might do on the two numbers will result in the same answer. so it's the right thing for memoization.

<mark_weaver>so (eqv? 0 0.0) is false, but (= 0 0.0) is true.

<mark_weaver>and when we support inexacts of different precisions, then (eqv? x y) will be false if x and y are both inexact numbers of the same value but different precisions.

<mark_weaver>so, 'eqv?' is fine on exact numbers, but for inexact numbers you probably want '=' instead.

<mark_weaver>jmd: in 'args-cmp-e', the use of 'and' and 'or' could make the code nicer.

<mark_weaver>jmd: (define (args-cmp-e args1 args2 i) (or (>= i (vector-length args1)) (and (= (vector-ref args1 i) (vector-ref args2 i)) (args-cmp-e args1 args2 (+ i 1)))))

<mark_weaver>jmd: btw, using (srfi srfi-42), available in guile 2, you could write that as (define (args-cmp-e args1 args2 i) (every?-ec (:parallel (: x args1) (: y args2)) (= x y)))

<mark_weaver>jmd: well, that's not quite right. I mean: (define (args-cmp v1 v2) (and (= (vector-length v1) (vector-length v2)) (every?-ec (:parallel (: x v1) (: y v2)) (= x y))))

<mark_weaver>(my use of '=' there assumes that the vectors contains numbers)

<jmd>mark_weaver: You wanna email me with this ? I'm working on something else right now, but I value your input.

<mark_weaver>okay

<DerGuteMoritz>somehow I'm reluctant to list comprehensions

<DerGuteMoritz>I guess for the same reason I'm reluctant to format strings :-)

<DerGuteMoritz>even in clojure where list comprehensions are part of the core library and don't introduce an extra dependency I never use them

*civodul has a hard time wrapping his head around comprehensions

<DerGuteMoritz>yeah it's a sublanguage, too

<DerGuteMoritz>OTOH I do use match extensively!

<DerGuteMoritz>I guess it's that list comprehensions don't seem to yield much for the extra syntax they introduce

<civodul>yeah

<mark_weaver>I can sympathize with the reluctance, but I came to love them when I was competing in google code jam.

<mark_weaver>it would help if we had srfi-43 in guile though.

<civodul>43?

*civodul checks

<mark_weaver>vector library

<mark_weaver>I actually have a partial implementation for guile written.

<civodul>ah indeed

<civodul>looks useful

<mark_weaver>it's on my todo list

<DerGuteMoritz>I don't particularly like the API of SRFI 42, too

<DerGuteMoritz>foof-loop is something I find quite appealing for this purpose

<DerGuteMoritz>but in practice I never used it so far

<DerGuteMoritz> http://mumble.net/~campbell/scheme/foof-loop.txt <- that one

<mark_weaver>yeah, I know about foof-loop.

<jmd>how do I create an empty alist ?

<DerGuteMoritz>jmd: '()

<mark_weaver>'()

<DerGuteMoritz>:-)

<jmd>mark_weaver: That's what I thought, but something wierd happends when I call (assv-set! '() "foo" 3)

<DerGuteMoritz>jmd: you are mutating a literal

<DerGuteMoritz>jmd: try (list) instead

<mark_weaver>that's only part of the problem.

<DerGuteMoritz>not sure what assv-set! does exactly

<mark_weaver>jmd: you need to store the result of 'assv-set!' back into the variable where you want to keep the mutated alist.

<DerGuteMoritz>jmd: anyway, you can just use cons, no need for mutation

<jmd>mark_weaver: I thought the ! indicated that the procedure had side effects.

<mark_weaver>jmd: also, you can't use assv-* reliably when the keys are strings.

<mark_weaver>jmd: yes, it does have side effects. it is allowed to mutate the list, and will do so.

<jmd>So why do I need to store the result?

<mark_weaver>jmd: if the element is not yet in the alist, then there's nothing in there to mutate. it has to add a new element to the front of the alist.

<jmd>ah ok.

<mark_weaver>an alist is a singly linked list of pairs.

<jmd>how can I use symbols instead of strings?

<mark_weaver>'() is like the NULL pointer in C

<mark_weaver>(assv-set! '() 'foo 3)

<mark_weaver>the apostrophe in front of "foo" quotes it, so it's a literal symbol instead of a variable reference.

<mark_weaver>'eqv?' on strings (which is what assv-* uses) does pointer equality, i.e. identity.

<jmd>Thanks.

<jmd>If I use symbols, then assq-* will work won't it?

<mark_weaver>yes

<mark_weaver>for strings, you'd want 'assoc-*'

<mark_weaver>but symbols are better for this purpose, and much faster.

<mark_weaver>symbols are interned, so two symbols with the same name are always represented by the same object, so they can be compared very quickly, by pointer comparison.

<mark_weaver>"interned" means that they are looked up in a hash table, mapping string to unique object.

<DerGuteMoritz>if your alist may become large you might consider switching to a "proper" associative data structure instead

<DerGuteMoritz>I don't know what options guile offers in this area though

<mark_weaver>there's nothing improper about alists.

<mark_weaver>for many purposes they are the right thing.

<DerGuteMoritz>right, thus the "

<DerGuteMoritz>:-)

<mark_weaver>it's true that lookups are O(n) time in the number of items, but hash tables have other problems, e.g. you cannot make modified versions of them without copying the entire thing.

<DerGuteMoritz>another issue that comes to mind is that they are not of a distinct type

<DerGuteMoritz>which can be inconvenient sometimes

<DerGuteMoritz>and yeah, mutable hash-tables suck in other way :-)

<DerGuteMoritz>s

<DerGuteMoritz>but if you use assv-set! and friends you have the same problems

<DerGuteMoritz>with alists

<mark_weaver>*nod*

<mark_weaver>alists are still more convenient though in that you can use the standard list operations on them like 'map' and 'for-each'

<DerGuteMoritz>srfi-69, say, provides those, too

<mark_weaver>if you really want the best of both worlds, the vlists and vhashes in guile 2.0 are the bees knees.

<DerGuteMoritz>ah what are vhashes based on?

<DerGuteMoritz>ah, based on vlists :-D

<mark_weaver> http://www.gnu.org/software/guile/manual/html_node/Compound-Data-Types.html

<DerGuteMoritz>looks excellent

<mark_weaver>though they are currently much less efficient than lists and alists when the number of items is small.

<DerGuteMoritz>brb, lunch :-)

<mark_weaver>as usually, the constant factor goes up when you use a more clever algorithm for better asymptotic behavior.

<mark_weaver>okay, ttyl!

<dsmith>mark_weaver, real 271m38.208s

<dsmith>make time on my rpi

<mark_weaver>ah, you already have it!

<dsmith>yes

<dsmith>Picked it up during lunch yesterday

<mark_weaver>cool, we've been missing sneek :)

<mark_weaver>is that 2.0.9?

<dsmith>I have a 2G sd card. Spent a while last night purging stuff to free space. Like X.

<dsmith>IT's the 2.0.9 tarball from last night

<mark_weaver>raspbian?

<dsmith>yes

<mark_weaver>excellent.

<dsmith>Hmm. make check has 3 failures

<mark_weaver>I have an 8G card in mine. 4G would have been enough though.

<mark_weaver>dsmith: what failed?

<dsmith>/bin/bash: line 5: 18126 Segmentation fault top_srcdir="../.." srcdir="." builddir="." CHARSETALIASDIR="/home/pi/src/guile-2.0.9/lib" GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 "../../meta/uninstalled-env" ${dir}$tst

<dsmith>FAIL: test-with-guile-module

<dsmith>PASS: test-scm-with-guile

<dsmith>/bin/bash: line 5: 18189 Segmentation fault top_srcdir="../.." srcdir="." builddir="." CHARSETALIASDIR="/home/pi/src/guile-2.0.9/lib" GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 "../../meta/uninstalled-env" ${dir}$tst

<dsmith>FAIL: test-scm-spawn-thread

<dsmith>/bin/bash: line 5: 18222 Segmentation fault top_srcdir="../.." srcdir="." builddir="." CHARSETALIASDIR="/home/pi/src/guile-2.0.9/lib" GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 "../../meta/uninstalled-env" ${dir}$tst

<dsmith>FAIL: test-pthread-create

<dsmith>Hmm.

<mark_weaver>I compiled gc-7.2d and installed it in /usr/local before building guile

<mark_weaver>I've noticed that while gc-7.1 (from debian) mostly works, it does sporadically fail some tests, even on x86

<dsmith>Yes, I am using the packaged libgc

<mark_weaver>I would recommend building and installing http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz

<mark_weaver>and then rerunning ./configure and make in guile's build directory.

<mark_weaver>you won't need to recompile the .go files though.

<mark_weaver>just the C files.

<mark_weaver>also, a useful trick: you can simply copy the .go files from a 32-bit x86 box.

<dsmith>I do (did) have guile-2.0 installed from packages. Just purged that. Shouldnt really matter for make check I think.

<mark_weaver>no, that's not the issue.

<mark_weaver>I'm pretty sure it's because of the old GC

<mark_weaver>it's a damn shame that debian didn't upgrade that in wheezy.

<dsmith>THis feels about the same speed as the mipsel box

<dsmith>I do think something in the wheezy upgrade broke my mips box. It was working fine before that.

<dsmith>I may try to downgrade it. Or maybe reinstall.

<dsmith>squeeze

<mark_weaver>you may just not have noticed.

<mark_weaver>if it was just running sneek, the chances of such errors are much less.

<mark_weaver>sneek was crashing periodically, wasn't it?

<dsmith>no

<dsmith>Well, it has a leak in bobot++ code.

<mark_weaver>ah

<dsmith>About 700K per irc message, iirc

<mark_weaver>I'm puzzled though, why you would want to go back to a box that uses about 10x as much power and is stuck with older software.

<mark_weaver>(and half the RAM)

<dsmith>So I had a cron job restarting it.

<dsmith>Oh, I won't go back to it.

<dsmith>I'm just curious if it really is flakey HW or something in wheezy

<mark_weaver>certainly, it's possible the wheezy doesn't work as well on mipsel.

<mark_weaver>I never tried wheezy on my yeeloong, only squeeze.

<mark_weaver>yeah, it would be good to know one way or the other.

<dsmith>mark_weaver, One nice thing about that qube2 is that it has a pci slot in it. I've got a soundcard in there. was planning on using it as a streaming music player or something. The pi has that built in already, so doesn't really matter I guess.

<janneke>and get ... event->type being: #<<gdk-event-type> 86c9eb0 delete>

<janneke>(guile:15101): GLib-GObject-CRITICAL **: g_value_set_enum: assertion `G_VALUE_HOLDS_ENUM (value)' failed

<janneke>hmm, oh wait :-)

*janneke starts to see something, thanks!

<civodul>does the latest guile-gnome release work with Guile 2?

<mark_weaver>yes

<jmd>In format, how do I insert a literal ~

<jmd>~~

<jmd>nm

<janneke>hmm (guile:19487): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.36.0/./gobject/gvalue.c:190: cannot initialize GValue with type `GInterface', this type has no GTypeValueTable implementation

<mark_weaver>wingo, civodul: LRN on #gnunet reports that 2.0.9 (well, 039300a1ebee116082d50d61e6b3aeafc8a741ec, but close enough) builds and runs successfully (and apparently reliably) when using a libgc without parallel marking enabled.

<mark_weaver>with parallel marking, there are random lockups.

<DerGuteMoritz>:-(

<mark_weaver>makes me curious if the same thing happens on GNU/Linux

<civodul>mark_weaver: on MinGW?

<mark_weaver>civodul: yes

<civodul>nice

<civodul>i could only report that it builds ;-)

<mark_weaver>the only issue he had to patch up was a problem in meta/Makefile.am. install-exec-hook incorrectly adds EXEEXT to "guild", which is a shell script and shouldn't have the EXE extension.

<mark_weaver>the other issue he noticed was: test-suite/standalone/test-unwind.c:213: undefined reference to `mkstemp'

<wingo>mark_weaver: good news :)

<mark_weaver>indeed!

<wingo>mark_weaver: if you are able to ask, does the libgc test suite pass for LRN?

<wingo>wondering whether it is a guile or libgc problem

<mark_weaver>good question.

<DerGuteMoritz>voila https://aur.archlinux.org/packages/guile2/

<mark_weaver>sweet!

<DerGuteMoritz>so now there are guile, guile2, guile-devel and guile-git for arch :-D

<mark_weaver>DerGuteMoritz: it turns out that we need libunistring >= 0.9.3

<DerGuteMoritz>ah

<DerGuteMoritz>good, let me fix that

<DerGuteMoritz>hm wtf, guile-devel is actually guile2, too!

<DerGuteMoritz>I assumed it was for development snapshots

<davexunit>congrats on guile 2.0.9, devs!

<DerGuteMoritz>is it possible to activate paredit in the geiser repl?

<davexunit>yeah?

<davexunit>M-x paredit-mode ?

<DerGuteMoritz>I mean by default

<DerGuteMoritz>there is probably some hook

<civodul>DerGuteMoritz: geiser-repl-mode-hook

<civodul>i seem to recall that it's not convenient, though

<DerGuteMoritz>having paredit in the repl?

<DerGuteMoritz>I have it in nrepl and am quite fond of it actually!

<davexunit>if it was annoying, maybe just autopair-mode or something would suffice.

<mark_weaver>wingo, civodul: the gc-7.2d test suite fails on windows when built with parallel marking. gctest busyloops. multiple threads, half of them suspended, only one thread consumes CPU. http://pastebin.ca/2354671

<mark_weaver>so maybe it's not our problem :)

<civodul>argh, indeed

<mark_weaver>(the test suite passes when build without parallel marking)

<mark_weaver>*built

<wingo>the test suite passes???

<wingo>wow

<civodul>ntdll!RtlEnableEarlyCriticalSectionEventCreation () from C:\\Windows\\SysWOW64\\ntdll.dll

<wingo>we are so great & stuff

<civodul>which test suite? ours?

<mark_weaver>it passes when built without parallel marking, and fails when built with parallel marking.

<wingo>ours

<civodul>woow, indeed

<wingo>ah theirs

<mark_weaver>no

<civodul>no what?

<civodul>:-)

<mark_weaver>our test suite still has some problems on mingw, regardless.

<wingo>ah ok :)

<DerGuteMoritz>windows makes me sad :-(

<mark_weaver>but nothing too serious

<civodul>good :-)

<wingo>DerGuteMoritz: yeah for real. but mingw + gnulib makes things better

<mark_weaver>guile seems to run reliably when built with a gc that doesn't do parallel marking.

<wingo>that is great news

<wingo>did LRN use a prefix of the form c:\\foo\\bar or c:/foo/bar?

<civodul>backslashes fail with shells

<civodul>they inevitably get lost at some point

<wingo>i guess we should quote more things in our makefiles

<wingo>yes

<wingo>the same thing happens with spaces

<davexunit> http://www.reddit.com/r/scheme/comments/1c214s/gnu_guile_209_released/c9c9m0e

<wingo>who is that guy

<DerGuteMoritz>shell quoting also makes me sad :-D

<wingo>we have a stable api, dunno what he is talking about

<davexunit>I do not know. just sharing.

<davexunit>was wondering what you guys thought of that.

<dsmith>Using \\ as a path separator makes me sad

<wingo>and we are doing exactly what gtk people are doing

<wingo>witness gtk 2 vs gtk 3

<DerGuteMoritz>or ruby 1.8 vs ruby 1.9

<DerGuteMoritz>wtf he even cites gtk as a good example :-D

<DerGuteMoritz>probably a common lisp troll!

<DerGuteMoritz>:-D

<mark_weaver>anyway, regarding the guile test suite on mingw32: <LRN> mark_weaver, as for mkstemp problem, i i've fixed one in the unwind test, but all files in vm subdir failed to compile - ERROR: In procedure mkstemp!: No such file or directory

<dsmith>scwm! That already only builds with 2.0

<mark_weaver><LRN> there's also a gnulib problem: ../../lib/time.h:468:1: error: expected identifier or '(' before '{' token <LRN> _GL_FUNCDECL_SYS (localtime_r, struct tm *, (time_t const *restrict __timer,

<mark_weaver>that gnulib problem apparently doesn't show up until the test suite is compiled.

<dsmith>Yey! make check passes on my rpi !

<wingo>neat :)

<mark_weaver>dsmith: it passes with gc-7.2d, but failed to pass with gc-7.1 from debian, right?

<dsmith>with 7.2d libgc

<dsmith>mark_weaver, Yes

<mark_weaver>yeah, there are definitely issues with gc-7.1. I've noticed problems on x86_64 as well.

<mark_weaver>so now, I always build gc-7.2d before building guile, anywhere.

<mark_weaver>wingo: the prefix was simply /mingw

<mark_weaver>he sent me the build script he used, which was derived from one he got for libcdio

<mark_weaver>he says: <LRN> that's the prefix that every responsible mingw packages should use

<wingo>orly

<Fulax>some guile-1.8 texi files are failing with texinfo-5

<civodul>not a big surprise

<civodul>it's another incentive for people to upgrade :-)

<DerGuteMoritz>hehe

<mark_weaver>if we want that to happen, I think we're going to have to take a more active involvement in helping some projects upgrade.

<Fulax>civodul: hehe. I should close the gentoo bug as "upstream won't fix" then :p

<dsmith>No, it *is* fixed in upstream. Just install 2.0.9

<wingo>we'd accept a patch but another release of 1.8 is not urgent

<dsmith>;^)

<civodul>Fulax: better: fix it on behalf of upstream :-)

<mark_weaver>ugh

<wingo>spending a couple months on a 2.0 release doesn't really leave a lot of energy for 1.8, does it...

<Fulax>dsmith: I know :-) I don't have yet enough privileges to put guile-2 into Gentoo, but i'm working on it

<mark_weaver>I'm not blaming anyone, of course. I very much appreciate everyone's efforts here, as you know. but the fact is that the larger projects that are stuck on 1.8 and cannot easily upgrade are in a bad position, and if we don't somehow help them, we are giving other projects reasons to avoid guile for fear of getting left in the cold.

<dsmith>unknown_lamer, What's the latest bobot++ ?

<cky>mark_weaver: You're doing Google Code Jam? I'll be happy to add you to my scoreboard if you want. :-) (My handle is cky.)

<unknown_lamer>dsmith: whatever the last tarball on my site was

<unknown_lamer>there's some stuff in darcs

<dsmith>I have a 2.2.0

<mark_weaver>cky: I did code jam last year. is it already time again this year?

<cky>mark_weaver: http://www.go-hero.net/jam/09/name/cky <-- my "Decision Tree" solution was my shining moment in all of GCJ. It was a very short Scheme solution that exploited (read) to great effect. ;-)

<cky>mark_weaver: Yes, it is.

<cky>mark_weaver: Qualification round starts this Friday.

<dsmith>More like 2.2.2

<mark_weaver> http://www.go-hero.net/jam/12/name/mhw

<mark_weaver>ugh, this friday?

<cky>Yes.

<dsmith>unknown_lamer, WHat's your site?

<unknown_lamer> http://savannah.nongnu.org/news/?group=bobotpp I guess savannah has the latest

<unknown_lamer> http://unknownlamer.org/darcsweb/browse?r=bobot%2B%2B;a=shortlog;topi=15

<cky>"mhw is already your friend"

<cky>Nice, I see I must have added you at last year's contest.

<mark_weaver>indeed :)

<dsmith>unknown_lamer, Ok, so you think the 2.2.3 tarball has the latest darcs ?

<unknown_lamer>no, darcs has a few patches past it but not much

<dsmith>unknown_lamer, Both seem to date around 2009

<unknown_lamer>yeah

<unknown_lamer>I got the idea that I'd make scripts thread safe and then trailed off...

<unknown_lamer>turns out being forced into the hcoop presidency is time consuming!

<dsmith>Well, I'm going for the tarball at this point.

<mark_weaver>convenient that the problem used sexpr format :)

<cky>mark_weaver: Very, very convenient. :-D

<janneke>*woot* /me can create gdk-events

<mark_weaver>a lisper must have had a hand in crafting that problem :)

<janneke>...now hope i can emit them

<cky>mark_weaver: Apparently not, if you read the contest analysis. They expected the parsing to be the challenging part of the problem.

<unknown_lamer>because writing a recursive descent parser for sexps is hard!

<cky>Lulz.

<cky> https://code.google.com/codejam/contest/186264/dashboard#s=a&a=0 <-- analysis

<dsmith>Ah fouey. I'm getting a ton of these. Time to quit and go to work

<dsmith>Interp.C:188:3: error: invalid conversion from ‘SCMFunc {aka scm_unused_struct* (*)()}’ to ‘scm_t_subr {aka void*}’ [-fpermissive]

<wingo>gcc version?

<wingo>is it g++ ?

<dsmith>g++

<dsmith>g++ (Debian 4.6.3-14+rpi1) 4.6.3

<mark_weaver>cky: getting that problem would have made my day.

<nalaginrut>too bad, I may not join codeJam since I have some personal issues on Friday&Saturday ;-(

<cky>mark_weaver: :-)

*dsmith wonders why darcs installs exim...

<dsmith>unknown_lamer, any chance you can/will move bobot to git instead of darcs?

<unknown_lamer>neeeeeever

<unknown_lamer>darcs probably just wants an MTA

<dsmith>Hmm. the get is going horribly slowly, not much cpu useage or network traffic..

<dsmith>And now it's done

<unknown_lamer>I think I have old style repos

<unknown_lamer>I should probably update them now that hcoop is running a reasonable version of darcs server side

<unknown_lamer>also, you can just grab them from /afs/hcoop.net/user/c/cl/clinton/darcs ;)

<unknown_lamer>much faster than http!

<civodul>AFS!

<unknown_lamer>Yep

<unknown_lamer>hcoop is built entirely around it

<civodul>woow

<unknown_lamer>I think we are the only publicly joinable afs cell

*dsmith sighs

<dsmith>need makeinfo

<dsmith>unknown_lamer, What's the aversion to git?

<unknown_lamer>nothing much nowadays

<unknown_lamer>I think it's overcomplicated, and ... darcs is written in Haskell

<unknown_lamer>plus work!

<unknown_lamer>if a converted git repo appeared, I guess I could set that up instead

<unknown_lamer>since I'm not hacking on it, and if people who want to actually hack on it prefer git... who am I to stop anyone!

<dsmith>understood

<dsmith>Ok. I'm really gone now.

<davexunit>are gstreamer bindings are available via guile-gnome?

<davexunit>s/are avaialable/available/

<cky>davexunit: Yes.

<cky> http://git.savannah.gnu.org/cgit/guile-gnome.git/tree/PACKAGES

<davexunit>thanks cky

<cky>Sure.

<davexunit>just didn't seem clear from http://www.gnu.org/software/guile-gnome/docs/ that the gstreamer bindings were here.

<nalaginrut>hmm...seems savannah will rewrite

<nalaginrut>but it's suggested python/django

<wingo>davexunit: they are outdated.

<wingo>they won't work.

<davexunit>wingo: okay.

<wingo>i don't think, anyway.

<davexunit>:(

<davexunit>mark_weaver threw out the idea of building a game library by tying together figl, gstreamer, etc.

<wingo>i wouldn't use gstreamer fwiw...

<wingo>i would use some more special-purpose library

<davexunit>yeah

<wingo>sndfile to load the data, and pulseaudio or something directly...

<wingo>dunno

<DerGuteMoritz>how do I get srfi 9 define-record?

<wingo>DerGuteMoritz: (use-modules (srfi srfi-9))

<davexunit>DerGuteMoritz: (use-modules (srfi srfi-9)

<DerGuteMoritz>ah

<wingo>:)

<davexunit>missed a paren. wingo wins.

<DerGuteMoritz>I only tried (use-modules (srfi 9))

<DerGuteMoritz>HOW REDUNDANT

<DerGuteMoritz>ah wait that only gives me define-record-type

<DerGuteMoritz>where's define-record defined?

<wingo>define-record isn't srfi-9, is it?

<DerGuteMoritz>yeah

<DerGuteMoritz>I assumed wrongly

<DerGuteMoritz>I'm not used to loading it explicitly as it is part of chicken core

*DerGuteMoritz rummages

<DerGuteMoritz>srfi 17!

<DerGuteMoritz>no

<DerGuteMoritz>is there a srfi for that at all?

<fbs>check the manual,

*DerGuteMoritz cheks the manual

<DerGuteMoritz>ok doesn't seem to be in guile

<DerGuteMoritz>I'll go with srfi-9 for now then :-)

<fbs>does 'define-record' even exist?

<davexunit>I guess it existed in chicken?

<DerGuteMoritz>in chicken at least

<DerGuteMoritz>it's an unhygienic shorthand

<wingo>racket went super-minimal with that

<DerGuteMoritz>see http://api.call-cc.org/doc/chicken/special-forms/define-record

<wingo>(struct foo)

<DerGuteMoritz>geiser's integration with the manual is nice!

<DerGuteMoritz>ooh, and the source, too

<DerGuteMoritz>very cool

<wingo>yeah jao did a super job

<DerGuteMoritz>absolutely

<wingo>you trying to figure out what it will take for chicken to work with geiser? :)

<wingo>or does chicken do slime

<DerGuteMoritz>we have a slime egg (eeeew)

<wingo>i have felix down as a vi kind of person

<DerGuteMoritz>but chicken is not introspective enough to make it work properly

<DerGuteMoritz>ah no, felix uses emacs

<DerGuteMoritz>but not even with paredit

<DerGuteMoritz>so he's a bare emacs user :-)

<wingo>hehe

<fbs>o0

<DerGuteMoritz>no fancy modes

<fbs>anyone tried smartparens instead of paredit?

<DerGuteMoritz>no, what does it do?

<DerGuteMoritz>the word "smart" raises suspicion

<wingo>haha, indeed ;)

<fbs>kinda similar things, but it seems to work better with latex

<fbs> https://github.com/Fuco1/smartparens

<wingo>i want paredit for c and c++

<davexunit>is there a case where one would use something like make-struct over record types?

<fbs>wingo: i think smart parens tries to be that

<wingo>davexunit: only when building other kinds of record types

<davexunit>wingo: okay thanks.

<DerGuteMoritz>is there a way to look a symbol up in the global procedure index?

<DerGuteMoritz>from geiser?

<fbs>,a maybe?

<nalaginrut>so I'm a bare Emacs user

<nalaginrut>;-|

<DerGuteMoritz>fbs: hmm also seems to search currently loaded modules only

<wingo>DerGuteMoritz: of course there is C-h i and searching in the manual

<wingo>i don't think we have an index for all modules, though perhaps geiser builds one; dunno

<fbs>maybe with emacs-helm

<wingo>DerGuteMoritz: if your info is somewhere else use C-u C-h i of course

<DerGuteMoritz>wingo: right, I'm using that right now

<DerGuteMoritz>thanks!

<DerGuteMoritz>good enough for the time being

<jaaso>yi

<DerGuteMoritz>now that was a quick visit

<DerGuteMoritz>is it possible to define a custom record printer?

<DerGuteMoritz>ah, set-record-type-printer!

<davexunit>I believe that is (srfi srfi-9 gnu)

<DerGuteMoritz>ah you're right

<DerGuteMoritz>do I need both imports?

<DerGuteMoritz>or is the gnu one enough?

<davexunit>the gnu one is enough I think

<DerGuteMoritz>ah no it isn't

<davexunit>shit. my bad.

<DerGuteMoritz>hehe no prob

<DerGuteMoritz>could have just tried it

<DerGuteMoritz>ok strange

<DerGuteMoritz>I have defined a record type here and passing an instance of it to an accessor procedure for one of its slots gives me a type error!

*DerGuteMoritz tries to boil it down

<davexunit>if the code is short: paste it somewhere

<DerGuteMoritz>yep I'm trimming it down

<DerGuteMoritz>it's in the context of a larger program

<DerGuteMoritz>ah-ha!

<DerGuteMoritz>it seems to happen when the record instance is bound to a top level variable

*DerGuteMoritz trims down furthter

<wingo>did you define the record type twice?

<DerGuteMoritz>no

<wingo>like maybe you made it with a previous definition of the constructor...

<wingo>you can use struct-vtable on a record to get a pointer to its type

<DerGuteMoritz>ran the program with guile -s

<wingo>the type is also bound to the record type name

<wingo>so you can compare them

<DerGuteMoritz> http://moritz.twoticketsplease.de/files/invalid-record-type.scm

<DerGuteMoritz>this prints 1 and then errors out

<DerGuteMoritz>ice-9/eval.scm:387:11: In procedure foo-bar: Wrong type argument: #<foo bar: 2>

<DerGuteMoritz>can't be a different type reference in that case, or can it?

<wingo>that's pretty bizarre

<DerGuteMoritz>bizarro world

<wingo>haha, i know what it is ;)

<DerGuteMoritz>the top level is hopeless

<wingo>it is "foo" conflicting with "foo" ;)

<DerGuteMoritz>what is it? :-)

<DerGuteMoritz>ah, the type itself gets a binding, too!

<wingo>wow, mathew flatt would be pleased

<DerGuteMoritz>maybe a warning for redefining toplevel bindings would be good

<wingo>*matthew

<wingo>not a bad idea

<wingo>though sometimes that's what you want to do...

<wingo>certainly when going from syntax to value or vice versa

<DerGuteMoritz>yeah but then you should be using set!, no?

<wingo>there should be a warning

<wingo>i guess

<wingo>dunno :)

<DerGuteMoritz>there is precedence of such a warning in chicken

<DerGuteMoritz>if that helps :-)

<wingo>we should do it then :)

<DerGuteMoritz>cool!

<DerGuteMoritz>I didn't consider this cause since chicken doesn't define a binding for the type name

<DerGuteMoritz>is that an extension of SRFI 9?

<wingo>it's unspecified

<DerGuteMoritz>ah ok

<wingo>i think r7rs does say that some binding gets defined there

<DerGuteMoritz>cool

<DerGuteMoritz>I like first-classy things

*wingo too

<wingo>though you would think that those accessors would close over the type they check against...

<DerGuteMoritz>good point

<DerGuteMoritz>maybe that should be changed as well

<wingo>yeah, dunno

<DerGuteMoritz>but that's a bit more invasive

<DerGuteMoritz>might be annoying in interactive development

<wingo>i don't think we can change it, but who knows

<DerGuteMoritz>hmmmmm wtf I can't provoke the redefinition warning in chicken now either :-D

<DerGuteMoritz>I'm sure I've seen it before

*wingo afk for a bit

<DerGuteMoritz>later!

<dsmith-work>I have a C extension, and a .scm file. I want to compile the .scm file during make, and then install it during make install. The problem is, the .so is only in the source tree.

<dsmith-work>My Makefile.am has this:

<dsmith-work>.scm.go:

<dsmith-work> guild compile -o "$@" "$<"

<dsmith-work>I got around that by LD_LIBRARY_PATH=$(pwd) make

<dsmith-work>What *should* I be doing?

*taylanub doesn't get the manual section on traps. :\\

<taylanub>First question: Does everything just boil down to VM hooks, or are there other "fundamental" things ?

<ijp```>DerGuteMoritz: ryan culpepper coined the term "morally hygienic" for macros like define-record

<ijp```>oops, apparently I'm suffering a tick infestation

***ijp``` is now known as ijp

<ijp>better

*taylanub boasts his IRC client that regains his nick before joining channels.

<DerGuteMoritz>ijp: ah, yes, now that you mention it :-)

<ijp>when did we add #:headers to http-get?

<ijp>ah, that was a 2.0.8/9 change

<wingo>yep

*wingo loves keyword arguments

<wingo>i love using them anyway

<wingo>implementing them is a pain :P

<ijp>I've had to change it back to #:extra-headers in guildhall for compatibility with <2.0.9

*DerGuteMoritz likes keyword arguments, too, even more so with colon suffixed keywords!

<wingo>DerGuteMoritz: there's a reader option for that

<wingo>;)

<wingo>"there's an X for that"

<DerGuteMoritz>heh

<DerGuteMoritz>aka "annoy your users by using non-default reader options"

<DerGuteMoritz>I was surprised today by the fact that auto-compile was a default in guile!

<dsmith-work>wingo: So I want to compile (from make, before make install) a .scm that is basically the exporter for a .so, like guild compile -o "$@" "$<" But that fails, because the .so is in the current dir. Any suggestions?

<wingo>DerGuteMoritz: it mostly works; in fact we should make it happen more quietly

<wingo><wingo> dsmith-work: i think futzing ld-library-path is fine

<wingo><wingo> sometimes i generate a "config.scm" that has a path to the so, and i rewrite it on install

<wingo><wingo> but that's a bit of work

<wingo><wingo> guile-cairo is probably like that

<wingo>* wingo doesn't trust library search paths very much

<wingo>^ i think i was disconnected when i wrote that

<dsmith-work>wingo: Ahh, sorry, didn't see that.

<wingo>i think it didn't make it through

<DerGuteMoritz>wingo: hmm I'm not sure, it might be considered a security issue!

<wingo>DerGuteMoritz: in what way?

<DerGuteMoritz>it replicates the path in ~/.cache

<DerGuteMoritz>well and it places the resulting .go file there, too

<DerGuteMoritz>which can contain verbatim strings, for example

<DerGuteMoritz>so I would at least keep it as verbose as it is now

<wingo>never thought about that :)

<DerGuteMoritz>well I'm no expert either

<DerGuteMoritz>:-)

<wingo>it's an interesting thought

<cordawyn>ijp: thanks for fixing that bug ;)

<DerGuteMoritz>at least something to keep in mind!

<wingo>rage against guile's fat mutexes

<DerGuteMoritz>deadlocking in the name of

<ijp>take the lock back

<wingo>|..|,

<ijp>bullet in the git HEAD

<ijp>s/git //

<davexunit>that's a good john woo film

<DerGuteMoritz>sleep() now in the critical section

<ijp>cordawyn: no problem, mark_weaver was pretty insistent I make things easy for 2.0.5 people

<wingo>threads.test is hanging for me on master

<wingo>...but only as part of a full check-guile run

<wingo>fml

<wingo>so in my Copious Free Time (TM) i think i would like to focus on the new VM for 2.2

<wingo>finishing the debugging infrastructure for rtl code, getting debug things into separate ELF sections, etc

*tupi wishes wingo and mark_weaver keep some time for guile-gnome-platform

<mark_weaver>so much to do, so little time. we could really use more help :)

<mark_weaver>wingo: what can we do about mutexes? I confess I don't understand exactly what you mean by "fat mutex". Is that a technical term? What's the alternative you see? (I see alternatives such a memory barriers, and/or implementing our own mutexes in a more lightweight fashion perhaps)

<wingo>mark_weaver: threads.c:631

<wingo>if you feel nauseated, perhaps ludo can give you the brown paper bag from 2.0.8

<mark_weaver>wow.

*mark_weaver runs vc-annotate

*wingo goes to sleep, peacefully ignoring the issues :)

<wingo>night!

<mark_weaver>good night wingo!

<cordawyn>guile-2.0.5 cli bails out with "Illegal instruction" on Debian GNU/Hurd. And here I thought to occasionally check my stuff for compatibility ;-)

<mark_weaver>cordawyn: see http://lists.gnu.org/archive/html/guile-user/2013-02/msg00036.html

<mark_weaver>cordawyn: it looks like installing gc-7.2d would help quite a bit

<mark_weaver>(and that's good advice for *anyone* by the way, even on x86 GNU/Linux)

<mark_weaver>it's a damn shame that Debian wheezy is still on 7.1

<cordawyn>hmm, ok, point taken

<cordawyn>thanks

<mark_weaver>np!

*ijp rebasing lua

IRC channel logs

2013-04-10.log