***karswell` is now known as karswell
***heroux_ is now known as heroux
<please_help>Not sure if it's the library I'm wrapping, my code, guile, or a mix of them all, but pointed-to data keep being deleted without my intervention. I know the code I'm wrapping makes use of C++ shared_pointer (I'm wrapping their C API which may make use of it), so that might be causing problems. ***michel_mno_afk is now known as michel_mno
<lloda>please_help, you can take Guile data on a shared_ptr if you use a null deleter I guess <wingo>good news regarding cps2 -- optimizations on cps2 during boot time take much less memory <davexunit>wingo: were you expecting (hoping) that to be the case? <wingo>in a bootstrap compile of boot-9.scm it uses 180MB after expansion, and about 320 MB after optimization (resident). then lowering to CPS and optimizing the old CPS ups resident size to something closer to 700 MB <wingo>davexunit: yes, i was hoping that would be the case, but doubting my instincts :) <wingo>so i'm hoping that when we skip the old CPS step then memory usage at bootstrap time will be less <davexunit>I don't grok it yet, but the big block comment at the top of the cps2 (I think) implementation was a nice explanation of what was going on. <davexunit>and the EDSL formed by the macros is also quite interesting. <ijp>news for ->js. fact: works. fib: works. map: works. using call/cc for early loop exit: in progress. <ijp>I'll try and get the seasoned schemers interpreter working afterwards <wingo>might be easier to get guile's interpreter to work, dunno <wingo>but i guess it's not self-contained as it includes the expander and an external call to memoize-expression... <paroneayea>so wait, does guile's javascript as a top-layer language also compile to tree-il? <paroneayea>ijp: will there both be a way to mark a symbol as accessible to the rest of javascript <paroneayea>and I'm assuming there will be ways also to do the reverse, to call arbitrary js functions which are in the environment from the outputted program <ijp>as it stands, you kind of can <ijp>but you'd want to wrap it automagically so that you don't need to supply the initial cont, or explicitly convert arguments / return values <wingo>what a relief to have finally gotten a handle on these memory issues <wingo>a bootstrap compile of cps2 takes 400 MB after CPS2 optimization, then optimizing CPS balloons it to 770 MB <davexunit>we need to have some kind of guile 2.2 release party <wingo>i'm convinced that the issue is recursion over cps -- in the interpreter the stacks are much bigger, also incur a lot of heap allocation, and the pending stack frames hold on to a lot of garbage <wingo>all of those are fixed with a more iterative approach <wingo>i still like recursion but not while bootstrapping :) <wingo>eliding the cps optimization pass eliminates the memory usage spike <wingo>which is good because the cps2 optimization pass completely replaces the cps optimization pass <paroneayea>new mediagoblin release announcement ETA 30 minutes :) <davexunit>wingo: interesting, though I guess it's no big surprise that an iterative approach uses less memory. <davexunit>but coming up with a workable iterative approach can be very challenging. <wingo>with compiled code i would expect recursion to use the same or less memory *wingo worked hard for that to be the case :) <wingo>heh, i wasn't fishing :) but you're welcome anyway :) <davexunit>really, your work on the compiler makes me feel that Guile is a serious language for serious work and it's worth investing time and energy into it. <davexunit>Guix makes me feel the same way about Guile. This ain't a toy, it's meant for real work and I hope that the uninitiated will see that. <davexunit>someday I hope to convince an employer of that, but perhaps that employer will have to be myself. <paroneayea>davexunit: time to get some VC money into GuixOps ;) <paroneayea>though in all seriousness, there may well be money to be made in hosting for people using guixops as a basis <davexunit>yes, I think Guix could generate some financial opportunities like that. <davexunit>more Guix packages, more Guile libraries, and we could have something strong. <davexunit>I'd love to see someone talk about Guile at something like strangeloop or equivalent. <civodul>and congrats to wingo for the optimization work that pays off! <civodul>(because i guess there's sometimes optimization work that happen not to pay off ;-)) <lloda>please_help: when you create a shared_ptr you can pass it a 'deleter' object that it will call when it's time to delete the pointer. If they pointer belongs to a 3rd party, you want the deleter to do nothing --a null deleter. <lloda>struct NullDeleter { template <class T> void operator()(T * p) {} }; <lloda>auto p = std::shared_ptr<T>(guile_owned_pointer, NullDeleter()); <please_help>lloda, but it's the other way around, I have the shared_ptr in guile. <lloda>I do not understand. You're passing a pointer you own to Guile? <wingo>wow. found a bug in the slot allocator. nasty stuff. <wleslie>you were recently in the slot allocator <wingo>hoooooo i don't know how i didn't run into this one before. strange stuff. <ijp>wingo: I see a call to builtin-ref, is that only for 'apply', 'values', 'abort_to_prompt', 'call-with-value' and 'call/cc'? <ijp>I guess this is because those need vm knowledge to be implemented? <androclus>hey, all.. i had kind of a newbie guile question.. okay to ask here? <wingo>& usually it's best to ask directly, instead of asking to ask :) <androclus>i've looked over the docs for eq? , eqv? and equal? and think i understand them, but <androclus>i seem to have hit different behavior with functions. <androclus>(eq? "hello" "hello") returns #f (as we would expect) <mark_weaver>androclus: eq? returns true for strings if they are literally the same object. two literal strings with the same character may or may not be the same object. it is up to the implementation. <mark_weaver>our compiler tries to combine equal strings (and other composite objects) into the same object. <ijp>hmm, I thought I had a scoping issue in cps (which would be weird) but turns out it's my fault <mark_weaver>however, I confess that I'm not sure why it is that (eq? "hello" "hello") typed at the REPL returns #f but (equal3? "hello" "hello") typed at the same REPL returns #t. I don <mark_weaver>but in any case, the result of (eq? "hello" "hello") is unspecified <mark_weaver>but it's only unspecified for _literals_, which are immutable. scheme implemented are _not_ allowed to combine equal mutable strings, because the user might mutate one of them, and the other one must be left unmodified. ***michel_mno is now known as michel_mno_afk
<mark_weaver>if you put that into a file and compile it, the answer will probably be #t <mark_weaver>at the REPL, each line you type is compiled separately <mark_weaver>or rather, the input of each REPL prompt is compiled separately <mark_weaver>so in your 'c' and 'd' example above, each definition is compiled separately, so the string literals aren't combined. <mark_weaver>but really, you shouldn't depend on these details of Guile's implementation. they may change. <mark_weaver>two literals with the same contents may or may not be coalesced into a single object by the compiler. scheme allows this but does not require it. <ijp>I've separated out a kfun onto its own line, and that makes a primcall to free-ref with 35, which is the self slot in the kfun <ijp>I don't really understand that, shouldn't freeref only be called on closure objects? <mark_weaver>please_help: what evidence do you have that the ffi is broken? <mark_weaver>lots of people are successfully using Guile's FFI, which is based on the widely-used libffi. <please_help>mark_weaver: guile 2.0.9 -> perfectly fine. Current version -> any attempt to use the ffi results in a segfault with the same code <please_help>hence, something must be broken, and if the code hasn't changed... <mark_weaver>if your code relies on unspecified behavior, it may work or not work depending on the phase of the moon <mark_weaver>and if you are writing to invalid pointers, you may get lucky and write to something unimportant in one version of the library and cause a segfault in another version <mark_weaver>maybe there's a new bug, that's certainly possible. but it's also possible that the bug is in your code. <please_help>but my code doesn't rely on unspecified behavior. I am not writing to pointers either. <mark_weaver>that's a bold claim. I wonder how you can be so sure of yourself to assert that the bug is definitely somewhere else. <ijp>in any case, until the fsf telepaths are fixed, we can only fix bugs we have examples of <mark_weaver>right, we need a minimal self-contained example that demonstrates the bug <mark_weaver>please_help: well, current master is a major new version that's still in flux <mark_weaver>but also there are also changes in the way finalizers are invoked, for example. in master they are invoked in a separate thread, whereas in 2.0 they are invoked from an existing thread. <mark_weaver>the branch from git that will eventually become 2.0.12 is the 'stable-2.0' branch. <wingo>yeah mark_weaver++, don't use master unless you know what you're doing, especially not right now <wingo>with the compiler in a middle of a rewrite it's easy to run across a bug that wouldn't make it into a release <wingo>but yeah the real question is when the fsf telepaths will be unbroken :) <wingo>ijp: humm, i ran into some related bugs recently with that pass <wingo>i actually have that pass disabled locally for other reasons... <wingo>ijp: so free-ref takes two arguments, the closure and the index <wingo>in that case 35 is the closure i think <wingo>(the closure can be an actual closure object or it could have been allocated to something else, perhaps a single value or a pair or a vector) <wingo>it's the "optimizing closures in o(0) time" thing <ijp>right, but it is the self slot in a kfuns, and those aren't necessarily closures, I thought <ijp>this could be a mistake on my part <wingo>i might not understand the question properly either <wingo>after closure conversion free variables are referenced through the closure <wingo>the closure is passed to the function and bound to the "self" variable <wingo>so it's right that a free variable reference would be via free-ref on the self variable <ijp>hmm, this could be where I went wrong then <ijp>I took "self" to be the kfun, not the closure object that contains the kfun <ijp>It does make more sense that way <wingo>yeah the kfun isn't really even a value, it's a label <ijp>okay, tomorrow I need to sort out multiple values, since I think that is the reason for my other issue <ijp>(which I haven't mentioned, so saying that was very unhelpful now that I think about it) <wingo>what a day, found a vm bug too <wingo>welp, looks like there is an off-by-one somewhere in the stack remapping code