<ArneBab>mark_weaver: In case you answered me a few days back: my quasselcore went down on 2013-12-30, so I missed all messages since then till now… <mark_weaver>ArneBab: I didn't answer, but I think we should fix the problem properly. I'm not satisfied with the status quo. <ArneBab>mark_weaver: I think the cleanest way would be to have a keyword argument to use-modules which specifies the language to use. This would also allow using modules from different paths - for example /usr/share/lua/ for lua. <ArneBab>and the packages of the other language would work as usual <ArneBab>example: (use-modules (bbdb bbdb) #:language elisp) <ArneBab>this would give me the full bbdb functionality, even though bbdb itself does not know it is being executed in a cross-language way <ArneBab>(it would load /usr/share/emacs/site-lisp/bbdb/bbdb.el) <ArneBab>(but it would ignore a possibly existing /usr/share/guile/site/bbdb/bbdb.scm <davexunit>hey ijp. picking up my frp module again after a few days. <davexunit>(define-signal bar (signal-map sqrt (box foo))) <davexunit>but I would like to make it unnecessary to manually box signals when in the define-signal macro <ijp>the way I did it was to make the box a part of the node itself <ijp>whatever way you do it, it's better that your user doesn't have to do the boxing themselves <davexunit>yeah exactly, that's what I'm trying to prevent <davexunit>I was thinking of maybe writing a helper macro for defining procedures that work with signals <davexunit>(define signal-map (signal-lambda (proc (boxed input-signal)) <body>)) <ArneBab>mark_weaver: besides: wisp now handles paren-prefixes for syntax-case macros. Example: #' foo → #'(foo) <davexunit>ijp: so, in your case, you were always working with boxes rather than the nodes directly? *ArneBab needs to go offline, but the IRC daemon runs again and will provide a backlog tomorrow. <mark_weaver>ijp: if the box is part of the node itself, then a new box is created when you reevaluate the 'define' that binds the node, and then other connections to that node are lost, no? <mark_weaver>ijp: wow, racket-cas changes quote to do algebraic simplification? I think that's a terrible decision. <ijp>mark_weaver: well, you can probably get around it by not importing the new definition of quote <ijp>it struck me as unusual too <ijp>the first box is a location, not a value <mark_weaver>I think I don't have enough context to understand what this code does. <ijp>it's an SKI reduction machine <mark_weaver>but I don't see how double boxing would help with the problem davexunit is trying to solve. <ijp>and I'm not sure it does <ijp>it's just simpler to deal with one box per value, than n boxes, and trying to update them <ijp>you point to the box, update that one box, everyone else sees it <mark_weaver>specifically, he want to be able to define nodes using 'define', such that he can replace individual nodes later by reevaluating a single 'define' form, and the new definition to effectively be inserted into the existing graph. <mark_weaver>reevaluating (define foo <box-constructor>) will discard the old box, of course. <mark_weaver>however, there is a box behind the scenes, namely the variable object that's bound to 'foo'. <mark_weaver>so my idea was to get a keep to _that_ box, the variable object, using a closure. <ijp>a closure is a better solution then, since you can refer to the name <mark_weaver>are you reasonably confident that you have the right fix, or do you have doubts? <mark_weaver>I confess I haven't taken the time to grok that code, but it would be good to get that fix in. <ijp>I'd say I'm reasonably confident <ijp>hmm, weird, the url isn't working <ijp>FAIL: bit-operations.test: bit-extract: documented? <ijp>ah, nvm, that one was caused by some accidental modification to the file ***jao is now known as Guest99859
***Shozan is now known as SHODAN
<ArneBab_>Did you get new information on statically linking guile (bug #13848)? → Latest I found is this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13848#130 — I’m not sure whether it is really fixed here (means that guile can be linked statically and compiled on windows) or whether the reporter stopped working on it. <ArneBab_>I asked, because that would be the deployment story I still see as lacking for guile. <nalaginrut>I don't try it because I don't have windows now ;-) <ArneBab_>civodul: you helped in the bug report - did you get additional information later? <nalaginrut>but I think it'd be great if there's better solution for Guile under Win, since many guys ever told me they want to try it very much <ArneBab_>nalaginrut: I don’t have windows either: It’s the possibility which matters to me (as in “it has been done successfully: Do it like this”). <ArneBab_>nalaginrut: and if I manage to build something in guile which I might want to show my windows-using friends, I’ll have to be able to make it work on windows… <civodul>nalaginrut: is it running Apache, or ... ? <ArneBab_>civodul: a pity, since in the report it looked like it was really, really close to become a portable application under Windows… <civodul>ArneBab_: note that building a statically-linked Guile on GNU/Linux works just fine <civodul>i think there are patches around to improve the MinGW port <ArneBab_>can people then execute it in arbitrary locations? <ArneBab_>patches floating around sounds like they could get lost… <civodul>the problem is that it's a bit difficult for us to review, and we don't use it at all <civodul>perhaps we should just give Eli access to the repo <ArneBab_>if he uses Windows - what speaks against that? <nalaginrut>but I forward the header from tekuti, so you may not see it <civodul>oh and tekuti runs the Guile HTTP server? <civodul>i was wondering if you had hooked it up in Artanis or something <civodul>i think wingo had to restart it once in a while <nalaginrut>anyway, all static files like js/css/png... are handled by nginx directly <nalaginrut>civodul: do you know what's the problem why wingo has to restart? <civodul>well i think the Guile process would leak, somehow <civodul>initially that was do to the iconv descriptor issue, which is now fixed <civodul>but i wonder if there's something left <civodul>would be good to see how well it works for you <nalaginrut>I was planed to use Artnanis for blog, but my host expired, so I have to build the blog on new VPS quickly <jemarch>civodul: nope. I am busy with other stuff <jemarch>civodul: what was the plan for cgen anyway? to port it to guile2? <civodul>jemarch: dunno if there's actually a plan, just wondering <civodul>actually dje42 may be the cgen person, from what i see <dsmith>Was down to about -11 last night. <ArneBab_>in Spanish TV I saw that the US has a pretty rough winter… <add^_>We haven't even had winter yet :-/ Well, if you don't count the ONE week we had snow and minus something.. <add^_>But that was like October/November <davexunit>winter can be rough, but a lot us are quite used to it and it's fine. <davexunit>it's people like my girlfriend that have only been in the northeast for a few years that hate it. :P <jemarch>today we are having a sprig-like day in Frankfurt ***ijp is now known as i-jpg
***i-jpg is now known as ijp
<dje42>civodul, jemarch: My plan is to port cgen to guile2 (w/goops). But it'll have to wait until gdb+guile is reasonably far along. <dje42>cos (cgen's object system) is fun and all, but I was always hoping to switch to something more "native" <civodul>nowadays i try to favor a functional programming style <civodul>didn't know it already had its object system <civodul>have there been new arches added to cgen lately? <jemarch>civodul: I did some work on the sparc, but stopped sending patches after the first one was never acknowledged <civodul>then you know who to talk to now ;-) ***dsmith-w` is now known as dsmith-work
<tupi>guilers, facing a strange multi theading problem. using a small test code [by Mark, which uses call-with-new-thread] all available cores always work. my code, which uses par-map, [very] regurlarly 'hangs' in a mono core 'state': is there any reason that call-with-new-thread would work better then par-map? <dje42>dsmith-work: The hobbit effort was fun. <dje42>presumably ages ago. cgen doesn't use it anymore. <dje42>[I'm not sure the hobbit support ever got into a release. Easy enough to check.] <jemarch>talking about cgen.. do you still maintain it? <dje42>more or less. Back then it was part of my day job. Now all I have is personal time. <dje42>I'm not sure how much cygnus^Wredhat uses it anymore. <jemarch>I have some sparc stuff to contribute, and probably will have more soon. <dje42>I never know how much authority I have since redhat "owns" it. <dje42>But I'd say submit the patches, and ping once in awhile. I'm back doing a lot more scheme stuff these days (for fun's sake). <jemarch>probably you have all authority, since it looks like that no one there is reviewing cgen patches :) ***ijp` is now known as ijp
<mark_weaver>tupi: 'call-with-new-thread' always creates a new native posix thread. 'par-map' uses futures, which use a preallocated thread pool. <mark_weaver>if any of the futures you create get stuck waiting for something, then some of the preallocated threads will get stuck waiting, and will never be used. <mark_weaver>in short: 'par-map' assumes that all of your jobs will use full CPU and work until finished. if you violate that assumption, then you'll effectively lose cores, as far as futures/par-map are concerned. <tupi>mark_weaver: tx. i re-wrote your test using par-map, but it worked well, which makes sence following what you just said. i know beleive that, unlike your example, it because the processes running in each threads are triggering java, then octave... which for some reasons [principaly java] enters in S mode <tupi>in the perpective of what you said, would it make any difference to call call-with-new-thread? [sorry, i don't fully undertand yet...] <mark_weaver>well, the thing is, because 'par-map' uses the thread pool, it limits the number of posix threads to be equal to the number of cores. <mark_weaver>so if you run 'par-map' on a list of 10000 items, it won't create 10000 posix threads running simultaneously, which might use too much memory. <tupi>yes, mostly, it catch results in a list. <mark_weaver>if you simply switch everything over to 'call-with-new-thread', then you might create too many threads and use too much memory. <tupi>i mean 'and it returns the results as a list...' <tupi>yes and controling that would be rewriting par-map <mark_weaver>the problem is, if one of those processes goes to sleep, then you effectively lose one of threads from your fixed-size thread pool. <tupi>but deep, call-with-new-thread would not suffer the problem i am facing? <mark_weaver>well, you'd replace one problem with another problem. <mark_weaver>somehow, you need to limit the number of concurrent threads. <mark_weaver>but no matter what limit (N) you choose, that will become a problem if N of your processes get stuck sleeping. <mark_weaver>it seems to me that there's no good solution but to find out what's going to sleep and fix that. <tupi>i need to further try to understand, it really is weird because somtimes it work like a charm, sonetimes not <tupi>and i need to confirm but my little analysis till now is that it is due to java <tupi>the par-map pool would always be the number of cores right? <tupi>or could that pool somwhow be reduced because of the OS tasks... ? <mark_weaver>I believe so, but that's Ludovic's code, which I'm not very familiar with. <mark_weaver>my alternative implementation of 'par-map' certain does, though. <mark_weaver>the pool would never be depleted by anything outside of guile. <tupi>ok, but using top, i can see that when i am facing that problem, only one core is used ... <mark_weaver>the pool certainly would never be reduced by tasks outside of guile. <tupi>and gnome-system-monitor shows all other core at 0 [zero] cpu usage <tupi>well when i enter this situation, only 1 but i will double check [tomorrow] <mark_weaver>if you have any doubts about 'par-map', then use the version I wrote. <tupi>what i don't get is why java enter sleep mode [but nothing to do with guile of course] <tupi>i can try, but in the long run i always will prefer to use a guile internal thread control [i always havew between a couple of hundreds to 16000 process...] <mark_weaver>well, I thought you had already established that the java subprocesses were sleeping, long ago. <mark_weaver>I'm surprised that there's still any doubt about that, at this late date. <tupi>i thought it only occured while working remotly [sshd interfering...] <mark_weaver>but if you still suspect 'par-map', then you can try my simpler version; that's all I'm suggesting. <tupi>mark_weaver: sure, what i don't understand is when i face the problem, i never see [saw] as much java processes then cores <mark_weaver>my alternate 'par-map' doesn't use a global thread pool. instead, each invocation of 'par-map' allocates its own new private thread pool of size 'numcores', which is freed after completion of that 'par-map' call. <tupi>i really wish i could sit next to someone while this happens... <tupi>but this alternate par-map is not the one i use right? <tupi>GNU Guile 2.0.9.106-7bc28 <mark_weaver>Long ago I made a branch for you with the alternative 'par-map'. Then you told me that wasn't the problem, so I deleted the branch. <tupi>would it make, from my 'bad' explanation that it would make a difference? <mark_weaver>I can't tell where the problem is from what you've told me. <tupi>i'make further tests, i don't either :) <mark_weaver>if it was simply that the java subprocesses were stuck sleeping, then I'd expect to see as many java processes as cores. <mark_weaver>so maybe the java subprocesses are dying and guile is waiting to read their output, or something. <tupi>and that is _not_ the case <mark_weaver>hmm.. although I'm not sure the native guile par-map handles exceptions in the threads gracefully. <mark_weaver>you might want to wrap the threads in a (catch #t ...) <mark_weaver>I've suggested it before, and I'd suggest it again: keep a log of when threads start and stop, and then analyze that log afterwards. <mark_weaver>though keep in mind that guile 2.0 ports are not thread-safe, so you'll need to protect any such logging port with a mutex. <mark_weaver>if a subprocess dies, then your attempt to read from it should, I think, raise an exception. <mark_weaver>it would be good to catch that exception within the 'par-map', because I have no idea what will happen to the 'par-map' if you don't catch it. <mark_weaver>the alternative 'par-map' I wrote tried to handle exceptions by killing all threads and then propagating the exception up out of the 'par-map', but I think my exception handling had at least one race problem in it. (I wrote it in a hurry :) <tupi>mark_weaver: i have a stupid keyboard roblem. anyway, need to digest what you wrote <tupi>i don't think any process die though, i can see it does not launch as many as it should... <tupi>and as it random, i just have no idea, so far, why... <tupi>w'll talk, many thanks again, have to go...