<dthompson>I excluded source files from my experimental binary bundle thing and it worked! last time I tried it did not. I wonder what's different. <dthompson>I don't remember all the details, but I remember errors about not being able to find source files. <dthompson>probably I just did something wrong that I didn't understand at the time. <lispmacs[work]>my application is running about 23% of the time in GC. Are there any tricks to improve that by, e.g., turning GC on and off manually? <dthompson>the only real answer I know is: profile and reduce allocation. <daviid>clone1: I just pushed a soluyion to your 'invalid iter' problem/snipset, thanks! when you have some time, please pull (g-golf devel branch), run the autotool chain danse and try/test ... let me know if eveything is ok <daviid>clone1: this fixed, let me share with you that it is not 'common' to keep an iter per row, rather you grab those either by user click (signal), or get first ... or search, then 'increment' ... fwiw <lispmacs[work]>dthompson: is there any time to be saved though, say, by walking the object tree less often? <lispmacs[work]>or does the internal algorithm handle that intelligently enough? <vijaymarupudi>daviid: I wonder if the fix to clone1's issue means that opaque struct autofree is fixed? It's not clear to me whether my issue and theirs were the same. <vijaymarupudi>daviid: Additionally, optional arguments in the documentation for g-main-loop-new are not optional arguments in the code, it seems like I have to pass the two #f #f arguments. <dthompson>lispmacs[work]: I don't know of any way to control that. the gc is triggered by allocations, so if you allocate less, it will run less. <lispmacs[work]>okay, well, if there isn't a way, there isn't a way. I seem to recall in other lisps there was ways to do things like pause the garbage collector, or tweak stuff like the frequency of how often you do the garbage collection walk <lispmacs[work]>in the manual I see you can force a gc run, but doesn't seem to be a procedure to prevent them <dthompson>there are some environment variables that libgc, the library that guile uses, recognizes. <dthompson>so any tweaks would likely be through that. I don't know them off-hand. <daviid>vijaymarupudi: to the former quiz, it fixes scheme allocated gobject filled mem protection and auto free ... that is when the doc tells you the mem is allocated by the caller, such as for all *-iter-* functions, but not when mem is glib/gobject allocated (yet, maybe i can, but as things are, not yet when the mem is callee allocated ...) <vijaymarupudi>daviid: Ah yes, not imported GLib fixed the issue, thanks! I had no idea it was in the base environment <vijaymarupudi>daviid: I want to clarify your second response, so when mem is callee allocated, nothing has changed, i.e. no autofree yet? <daviid>vijaymarupudi: right, then you need to call the lib free function for that 'boxed' type <daviid>i hope i can do that to, let's see ... but ... we'll see <vijaymarupudi>daviid: No rush, happy to just call the -free functions for now :) <vijaymarupudi>daviid: Is there a reason why g-unix-fd-source-new is not in the default environment? <vijaymarupudi>Wow, I've failed to read the manual two times in a row, sorry about that! <daviid>vijaymarupudi: i realize there are a few important (yet undocumented) higher level procedures, glib based, in (g-golf hl-api glib) <daviid>you might be intersted by g-unix-fd-add <daviid>by all actually, but as yu did ask about g-unix-fd-source-new, g-unix-fd-add is doing a lot for you ... <daviid>vijaymarupudi: there is an example of use for g-unix-fd-add in guile-a-sync2 and guile-a-sync3 - in a-sync/g-golf/await-ports.scm <vijaymarupudi>daviid: I just discovered g-unix-fd-add, that's a more convenient API :) <daviid>yes, i wrote it for chris vine, the guile-a-sync* author maintainer ... <vijaymarupudi>I wasn't aware of this library, that's very interesting, thanks for sending it <daviid>vijaymarupudi: and for the other (g-golf hl-api glib) procs, there is an example in g-golf ./examples/gtk-4/revealer.scm, and some in the test-suite <vijaymarupudi>daviid: Another clarifying question about clone1's bugfix, I'm not sure if you remember it, but I sent you an example where calling gtk-text-iter-free caused a segfault. Can I free the text-iters now? <daviid>you shouldn't - iters are allocated by scheme, auto free <daviid>vijaymarupudi: you only need to free when the documentation of the lib you are using says the mem is allocated by the calle <vijaymarupudi>I see. Just to make it concrete, what's a function that requires manual free, so I can refer to it in the future? <vijaymarupudi>Ah okay, that helps! I'm going to use double pointer out parameters as a heuristic ***b4283_ is now known as b4285
<daviid>vijaymarupudi: tx, it would be ideal indeed ... <fnstudio>hi, is it good practice to use "format" to apply some padding to a string? i had the impression format is meant for displaying a string, whether here i'm looking at string manipulation <flatwhatson>fnstudio: format is for formatting strings, and either sending them to a port or returning them <flatwhatson>so yes, it's fine for padding, though string-append might do the job more clearly <ss2>Why can I not include a file, where the path to its relative location was stitched together with, say (string-append ...)? <ss2>I rather not have it hardcoded, and it isn't meant to be a module either, so it will never exist in any load-path. ***Guest4840 is now known as chrislck
<ss2>Ah, it works with (load ...). ***janneke_ is now known as janneke