<catonano>(pointer->bytevector outcome-ptr (sizeof int)) <catonano>how can I make it return a proper scheme integer number ? <catonano>I managed to get a proper number out of a int* pointer <CustosLimen>it seems its just increasing and I'm not sure how to figure out why <CustosLimen>I tried using solaris umem+umem_debug+mdb to check but I don't think that is working at all <CustosLimen>I think if I LD_PRELOAD libumem which implements free/malloc it just ends up breaking boehmgc <CustosLimen>GC_FIND_LEAKS work on assumption that free is being used by program <CustosLimen>GC_PRINT_VERBOSE_STATS shows heap size is increasing <catonano>CustosLimen: recently I read that there's a leak in Guile 2.2.2 <CustosLimen>catonano, see I think it may be problem in guile code <CustosLimen>like someone is just adding more to some data structure or something <catonano>CustosLimen: I'm really a beginner at this, it's better if you discuss this wit someone else <catonano>I managed to manipulate pointers fro te first time yesterday ! <catonano>where does te guile manual discuss unit testing ? <random-nick>catonano: check out SRFI-64 in Guile Modules > SRFI support <catonano>CustosLimen: I would suggest you to write on the mailing list <CustosLimen>nah is ok will just dig through the code I guess ;)( <CustosLimen>so if I look at dump output from boehmgc - it seems like boehmgc is not aware of increasing memory usage based on `Blocks in use:` dumps at least <CustosLimen>bot according to boehmgc heap size is staying constant <CustosLimen>anybody have experience porting guile code to clojure ? <daviid>CustosLimen: if it because you want/have to be 'on top' of java, use kawa not clojure (unless you are forced to of course) <CustosLimen>maybe not best place to ask -but I see there is Bigloo, Kawa, SISC and JScheme Scheme implementations for JVM - any iea which is best choice for production ? <cmaloney>CustosLimen: Yeah, sadly if you're moving from guile to clojure you're going to be re-writing your code <CustosLimen>ok well actually I just don't want to have to deal with boehmgc <daviid>kawa is excellent, part of GNU, extremely well supported, fast start-up time, a lot better integrated with the jaa class system then clojure, does _not_ impose an 'echo system' on you to compile ... <CustosLimen>anyway let me try tune boehmgc to see if heap size according to solaris stops growing then <daviid>CustosLimen: the channel is inactive, the way to talk to kawers is the mailing list, ***micro`_ is now known as micro`
<ijp>it's kinda funny when your ,locals has 3 called val, 3 called tmp, and one called arg <ijp>unhelpful, but funny <paroneayea>ijp: yeah ,locals could be a lot more useful; there was a guile-user or guile-devel thread about this recently <ijp>paroneayea: minor success for today, I have managed to get some code to compile through cps2 <bavier`>I'd like to do some concurrency within guile, where one thread is started for each character read from a port, and that character is written to another port when the thread terminates. <bavier`>I've not written any concurrent/asynch code in guile besides par-for-each. Any suggestions on an appropriate paradigm for such a situation? <paroneayea>bavier`: a thread started *for each character read*? <paroneayea>bavier`: but... you might find that the (ice-9 suspendable-ports) stuff is a good foundation <paroneayea>bavier`: both 8sync and fibers use it, and from what you're saying, maybe you'd like to look at fibers. <bavier`>paroneayea: the characters will be written in a controlled manner <bavier`>paroneayea: thanks, I'll look at the suspendable-ports docs <bavier`>I was hoping to stick to core guile modules, since this is ultimately aimed at guix <paroneayea>is it provides a mechanism to "suspend" the existing code by aborting to a prompt whenever (well, some) ports will block. <paroneayea>bavier`: I recommend reading both the suspendable-ports docs and the fibers docs <paroneayea>bavier`: so if this is for guix, what's it for in guix out of curiosity? <bavier`>paroneayea: having build-aux/compile-all.scm interact with make's jobserver for "better" 'make -j' <bavier`>so, not so much for guix, but for its developers, I guess <daviid>ijp: wrt your bug report on master, maybe you should actually work using the stable-2.2 branch? master is for wingo to prepare 3.0, I guess it will be very unstable for a while ... <ijp>stable-2.2 and master were merged recently, and have the same issue <ijp>hmm, maybe the merge is in the other direction. Anyway, I could swear both have it