***_zxq9_ is now known as zxq9
***nalaginrut_ is now known as nalaginrut
<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 ***unCork is now known as Cork
<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 <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. <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