<sneek>vijaymarupudi, you have 1 message! <sneek>vijaymarupudi, daviid says: i just pushed a GObject (opque) boxed types auto free mechanism - so you may comment(delete) your *-free calls in these situation, such as you don't need to free gtk-tree-path anymore, it is now done by g-golf when the ffi pointer becomes unreachable ... please test, let me know (devel branch still ...) <vijaymarupudi>daviid: Interesting solution to the problem there, I wonder if it's thread safe? ***chris is now known as Guest3995
<daviid>nothing is thread safe when using a GLib main loop anyway - not a g-golf problem ... a GLib requirement <daviid>it is not even that is safe or not, it is just not allowed by design - to make gnome lib calls outside the main thread i mean ... you may mutli thread your scheme 'calculus of course', but gnome lib calls must always be done in the thread that has the GLib mainloop <vijaymarupudi>Ah got it! I was just thinking of non-gnome gobject libraries, I was thinking of using that system and getting guile bindings for me <vijaymarupudi>daviid: But not really a blocker for me, just good for me to know! ***Guest3995 is now known as chrislck
<daviid>vijaymarupudi: this is a (completely) diff context/problem, to free a mainlop you unref, not free, GLib low level bindings are manually done, so it doesn't use any of the added code, which exclusively addresses GObject (opaque) boxed types auto free, not GLib 'pointers to ...' unref/free ... <daviid>vijaymarupudi: what would be nice is to try to stress any GObject (opaque) boxed type code, such as GtkTreePath ... and see if the solution fulfill the objective, no mem leak... <daviid>vijaymarupudi: that would be nice ... let's see:) <vijaymarupudi>daviid: Been testing for 15 minutes, 12000000 textiters later, I'm pleased to report that there is no leak, memory usage is barely changing :) <daviid>vijaymarupudi: great! tx for stressing g-golf :):) <daviid>vijaymarupudi: though textiters stresses the previouspatch, scheme allocated gobject filled malloc/free... <daviid>*malloc as in memory allocation, not using malloc in fact ... those non opaque types are scheme allocated gobject filled, scheme free'd ... diff from gtk-tree-path ... <daviid>vijaymarupudi: it seems ok, here is what i tried - https://paste.gnome.org/puvxfcnzh - then 'just' monitoring mem consumption using top, i'm not an expert in this domain, but mem consumption seems quite stable - the 'amateur' mem leak check passes :) <vijaymarupudi>daviid: I've tried many other iterations, interspersing with different operations and using the objects (text-paths) <sneek>hackyhacker, you have 1 message! <sneek>hackyhacker, leoprikler says: I'm using guile-sdl2, AMA <hackyhacker>if I do (use-modules (sfri sfri-1)) I get some error back <lloda>if we have trained people not to read the error bc so often they contain no information, that's a tragedy <lampilelo>"no code for module" is indeed not very descriptive <vijaymarupudi>daviid: Something you might by interested in <https://paste.gnome.org/p9jlyok9d/bt27y7/raw>. I profiled the creation of a million text iters, and this is what the statprof data looks like. Looks like most of the time is spent freeing them using the guardian. Interestingly, looks like 62% of the time is spent in the GC. ***chris is now known as Guest6232
***Guest6232 is now known as chrislck
<sneek>I've been running for 22 days <sneek>This system has been up 10 weeks <lispmacs[work]>Hi, I'm trying to figure out how to get my guile program in some kind of raw input mode so that characters are immediately received, rather than line-buffered. (setvbuf (current-input-port) 'none) doesn't seem to do anything <dsmith-work>lispmacs[work]: Raw mode happens at the tty/fcntl/ioctl level. <dsmith-work>This was asked here recently. Within the last month or so I think. <dsmith-work>lispmacs[work]: Might need to ffi call a C function. <lispmacs[work]>hmm, yes, docs says that guile buffering is completely separate from the tty line discipline <dsmith-work>lispmacs[work]: guile ncurses can probably do what you want. <lispmacs[work]>hmm, now I need to decide if I want to switch my program over to using guile-ncurses, or just use guile-termios <lispmacs[work]>guile-ncurses happens to have a Guix package, which is a point in its favor <lispmacs[work]>but it sounds like I wouldn't have to change as much in my program if I used guile-termios <lispmacs[work]>I wonder how guile-ncurses does with output on really high baud rates <ft>I have done the guix packaging actually. I've just not gotten around to submitting it with guix itself. <dsmith-work>lispmacs[work]: Alternatively, you could shell out to an stty command... (assuming non-windows) <dsmith-work>Someting to carefully consider is restoring the original settings on exit. <lispmacs[work]>dsmith-work: that seems like a good idea for starters. Am trying (system "stty raw -echo") but I still seem to be getting line buffering somehow <dsmith-work>lispmacs[work]: Hmm. Are you also disabling the port buffering? <lispmacs[work]>(setvbuf (current-input-port) 'none) and (setvbuf (current-output-port) 'none) <lispmacs[work]>it looks like there is code in .guile that enables readline. I think it is skeleton file code <lispmacs[work]>does some checks to see if readline is available and then executes (module-ref module 'activate-readline) <dsmith-work>lispmacs[work]: I was thinking maybe readline was messing with your tty and buffer settings? (Maybe does it's own buffering?) <dsmith-work>lispmacs[work]: Don't have any definitive answers, sorry. <lispmacs[work]>thinks seem to be working as I expect if I run "guile -q" to avoid using .guile <dsmith-work>Next up would be to run the whole mess under the mighty strace and see what syscalls were happening when.