IRC channel logs

2013-05-01.log

back to list of 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