IRC channel logs


back to list of logs

***_zxq9_ is now known as zxq9
<nalaginrut_>morning guilers~
***nalaginrut_ is now known as nalaginrut
<civodul>Hello Guilers!
<janneke>Morning civodul!
<nalaginrut>will it be faster if compiling guile with llvm?
<taylanub>nalaginrut: clang (the C compiler of the LLVM project) is generally known to compile much faster than GCC, dunno if that holds for Guile as well. what it certainly will *not* help with is the .go compilation because it's Guile itself compiling those, not GCC
<taylanub>the C parts of Guile don't take that long to compile anyway so it won't make much of a difference. in fact, GCC still produces somewhat faster code, so compiling the .go files could be faster with GCC because Guile itself gets a bit faster
<nalaginrut>yes, good explain ;-)
<nalaginrut>seems the key point is the backend of Gulie
***unCork is now known as Cork
<dsmith-work>Hey hey
<stis>heya guilers!
<davexunit>hey stis!
<stis>Hmm isn't it possible to write a memoized index to byte function for string
<stis>that is efficient enough for most uses re the lilipond issue on the mailing list
<stis>Anybody: how do I tell autotools to place the libs in the correct place
<stis>right now I need to use --prefix in configure
<dsmith-work>stis: perhaps ./configure --libdir=DIR
<dsmith-work>stis: (from ./configure --help)
<mark_weaver>stis: I plan to write an efficient procedure to determine the utf8 byte length of a string.
<stis>mark_weaver: yeah it looks like it is needed.
<rlb>mark_weaver: the detection for lilypond only needs to work wrt guile-1.8, perhaps?
<rlb>i.e. just to find/fix the problem cases
<mark_weaver>rlb: there's still no version of lilypond that works in guile 2.0 (not even in their git repo), but it's being worked on.
<mark_weaver>and there's been some progress
<rlb>sure -- but I was talking about your earlier discussion with wingo -- i.e. presumably you might only need any "fix" for guile-1.8 so they can find/fix their problems. It wouldn't need to work with 2.0.
<rlb>(I'm guessing supporting that kind of laziness might also have potentially negative effects on compiler optimization -- though if that's true, then perhaps it could be made to only affect the performance of the code that relies on it.)
<mark_weaver>rlb: regarding putting the warning only in 1.8, that would certainly be an option, but I think it makes sense for 2.0.x to report a warning in these cases anyway. also, we haven't support 1.8 in a long time, and I'm not very familiar with the 1.8 code.
<mark_weaver>regarding the laziness: you're right, it would have a very bad effect on optimization, so if we support it at all, it would only be when using the primitive evaluator.
<mark_weaver>anyway, it sounds like they found an acceptable workaround, so we probably won't need to implement lazy expansion.
<rlb>mark_weaver: ok, good
<lloda->hello mark_weaver, could you take a look at the 1st patch in ? A number of cases produce errors when run through the compiler but they don't get counted in the test suite summary. Do you know why? The patch is against master.