IRC channel logs

<nalaginrut>morning guilers~

<b4283>hiya

<nalaginrut>b4283: heya~

<adhoc_>afternoon =)

<b4283>if i delay my response for 45 mins, it would be like i'm living on mars

<adhoc_>b4283: i thought it was 45 minutes from here to Mars and then 45 minutes back ?

<wingo>morning, guilers

<wingo>happy may day :)

<b4283>adhoc_: indeed, that i would have to delay for 90 mins :D

<adhoc_>b4283: but it depends on where the two planets are in their respective orbits, sometimes it can be much longer

<hiato>Hey guys :)

<hiato>I was just wondering if anyone here has had any luck with building freetalk using guile 2+ ?

<wingo>hi

<wingo>i've never tried to do that

<wingo> https://bugzilla.redhat.com/show_bug.cgi?id=704522 is a related bug

<hiato>Yeah, it seems to rely on some rather specific guile 1x stuff

<wingo>you interested in fixing its build?

<wingo>usually it's not too difficult

<hiato>I can give it a whirl, sure

<hiato>(I really like freetalk, and I need guile 2+ for geiser so yeah)

<wingo>cool

<wingo>it's probably worth it to read the NEWS entry for guile 2.0.0 (the first release in the 2.0 series) before you start

<wingo>takes about 20 minutes, but will answer some of your questions i think

<wingo>when you find things that don't compile, search for them in the NEWS and if you don't find it, give me a ping

<taylanub>Is there an `assert' in any standard library ? If not, should I try to implement one that can be enabled/disabled, or rely on other mechanisms altogether ?

<lloda>there's one in (rnrs base)

<taylanub>Ah, neat.

<taylanub>Hrm, I don't seem to have it, using 2.1.0.155-180ac (couple months old from git).

<wingo>C-h i i assert RET :)

<shanecelis>hey guilers. does guile normally run single-threaded? Or does it have some kind of background threads doing stuff?

<shanecelis>I'm guessing it's single-threaded since guile -c '(display (all-threads))' only shows one thread, which I expect is its own thread, right?

<CaptainLex>Who, guilers, why is the gnu.org site down?

<fds>It's not down for me.

<CaptainLex>Hmmm

<CaptainLex>downforeveryone lied to me! :(

<CaptainLex>Or I guess it's just back up now

<CaptainLex>fds: Is your name "file descriptors"?

<fds>No, it's "functional dependencies"

<CaptainLex>fds: That's good; C naming convention are very un-Scheme ;)

<CaptainLex>What is the concept of "functional dependencies"?

<mark_weaver>shanecelis: it's normally single-threaded, except that there's a signal handling thread, and libgc is also capable of doing marking in other threads. also note that in guile 2.2 finalizers will be run in a separate thread.

<fds>CaptainLex: The truth is it's just my initials. :-P

<CaptainLex>fds: I've been had! But that's very classic

<mark_weaver>also, I wouldn't rule out the possibility that we will use futures in the compiler in some future 2.0.x release, which would use multiple threads on multi-core machines.

<shanecelis>mark_weaver: That'd be so cool.

<hiato>:q

<ijp>>:|

<CaptainLex>:&

<lloda>hey, I've just seen that there's a benchmark suite in Guile... > tunnel vision <

<mark_weaver>lloda: it's easy to miss. it would be nice to make it more useful to detect performance regressions. one idea would be to add a make target that runs all the benchmarks and writes the data to a "baseline benchmark results" file. and then "make check" would verify that nothing had gotten significantly slower than the baseline.

<mark_weaver>lloda: btw, I looked at the benchmarks for your array work. very impressive. I hope to take a close look at your patches soon, though again, we'll have to be careful with compatibility issues in 2.0.x.

<lloda>thanks. Of course I only benchmarked the stuff that I knew I was improving :p

<mark_weaver>hehe

<lloda>about the compatiblity, yes.

<lloda>But it's interesting to see what parts of Guile fail when you make those changes.

<lloda>For example I fixed a couple of could-be bugs in compile-assembly.scm

<lloda>where it was being assumed that (array-contents) always returned a 'vector'

<lloda>that kind of thing.

<mark_weaver>ah yes, I noticed a while ago that some kinds of array literals failed to compile.

<mark_weaver>the specific example I noted in my TODO list was: #2a(("foo") ("bar"))

<mark_weaver>did you fix that one?

<lloda>no, but I know why it fails

<lloda>I mention it in the mailing list.

<lloda>it is because uniform-array->bytevector cannot handle a CHAR array

<lloda>because those don't have a valid 'elements' pointer in their array_handle.

<lloda>so the conversion must be done in some other way

<mark_weaver>it's not obvious to be how that conversion should be done, unless an encoding is provided.

<mark_weaver>s/to be/to me/

<lloda>yeah, not an obvious fix.

<mark_weaver>it may be that we simply need to handle some of these as separate cases during assembly.

<lloda>that should be feasible, it's only a case or two.

<mark_weaver>lloda: but regarding compatibility, I think it might make more sense to rebase your branch onto master, and then (optionally) see if a subset of it could be adapted to stable-2.0.

<lloda>np. I do rebase on stable-2.0, I don't expect conflicts.

<mark_weaver>yeah, it shouldn't be too bad. I merged your recent array changes into master and there were no non-trivial conflicts. the most common trivial conflicts are updates to the copyright dates.

<lloda>good

IRC channel logs

2013-05-01.log