<canssss>Is there kind of test suite for interpreter of Guile? <ft>Like the "test-suite" subdirectory in the source tree? <cky>canssss: What ft said. ***mario-go` is now known as mario-goulart
<sneek>Welcome back wingo, you have 1 message. <sneek>wingo, daviid says: that I've sent a request for inclusion for guile-cairo <wleslie>forgot to mention I enjoyed your ghm talk. <wingo>i realized that i introduced an n^2 thing into the 2.2 compiler <wingo>which is making it slow down terribly <wleslie>oh that's what that tweet was about (: <wingo>i knew it was n^2 beforehand but i didn't respect that fact ;) <wingo>everyone has to get burned sometime <wingo>it's something i haven't written about yet -- (language cps types) <wleslie>I've done O(n^2) effect analyses before <wingo>fortunately writing about things is a good forcing function to fix embarassing things elsewhere <wingo>wleslie: this one is really local -- it just computes effects for small expressions <wingo>the complexity of e.g. cse is another question <wingo>i think it's n^2 as well, though the constant factors aren't so bad -- anyway will look at fixing that too <wleslie>might not be so true with lots of inlining or macros <wleslie>yet that's the case you stand most to benefit. <wingo>well if you have 4000 labeled expressions, n^2 is 16e6, which is already not small... <wingo>functions can get big after inlining and contification and such <dje42>civodul: parameters in gdb are the way they are. :-( If this is important enough, then I suspect adding support for gdb parameters (not guile parameters) to gdb-guile will be held off indefinitely (barring someone else taking on fixing everywhere that gdb is broken :-)). <dje42>python parameters support will have to be permanently broken (or at least maintain support for the old broken interface ... we can't change that one) <civodul>dje42: ah ok, then it's OK to keep the proposed interface <civodul>i suspected GDB's internal interface wasn't optimal in the first place <dje42>Hmmm, looking at the python API, it doesn't provide a similar API anyway, so there is no published API to preserve. <dje42>Still, gdb's internals would have to be fixed - not sure how many parameters depend on the current design. <wingo>dje42: sorry i haven't been able to do gdb things recently -- been otherwise busy :/ <civodul>dje42: well, yes, but i understand there's a risk of that forcing us to postpone the whole thing <wingo>i can follow up on weds/thurs if there is something useful for me to do <dje42>I can only get to gdb-guile on weekends anyway ... <wingo>i like their approach to gc; perhaps we can do something like that eventually <wingo>it's a long article with a few parts; gc is just one of them <wingo>and the gc thing links to some scheme paper from the 80s ;) <wingo>i think that approach meshes particularly well with how people use guile's c api <wingo>anyway, thoughts for another day <wingo>the gc is a vertiginous black hole :) <civodul>wingo: i think Guile's previous GC was a Bartlett GC :-) <civodul>the idea looks nice, but it takes a lot of engineering <civodul>well ok, the previous GC didn't attempt to move objects etc. <civodul>it wasn't able to tell which objects were referenced from the heap, and which were referenced from the stack <ArneBab>taylanub: that’s logical: Even if they were honest, they would optimze the browsers for their benchmarks. You have to decide on some metrics after all. <ArneBab>(I’m not suggesting, that they are honest…) <wingo>civodul: seems that moving vs non-moving is an important difference ;) <wingo>and the interior pointer thing is important as well ***fangism-ctrl-Z is now known as fangism
<bhattigurjot>I am sorry to bother you all again but I still haven't figured out why my software's "./configure" file is showing <bhattigurjot>these two methods, both failed to provide the solution to me. <dsmith-work>sneek: later tell bhattigurjot Running ldconfig allows libguile.so to be found. Has nothing at all to do with the .m4 file. <GermanGT>How can I use a macro defined in other scm file, which is not a module. Or I should define a module to do that? Thanks. <taylanub>GermanGT: optimally you should define a module, but if you really want you can use 'include' or 'load' <GermanGT>taylanub: I'm trying to update TeXmacs to use guile 2. The first idea come to my mind was define a module. I don't want change to much the code, but I think that use modules is the natural way in scheme. Thanks, I will try defining a module. Although I expect will be more problems.