IRC channel logs


back to list of logs

<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: ok
<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>or /usr/share/emacs/ for elisp
<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
<ijp>mark_weaver: have you seen
<davexunit>hey ijp. picking up my frp module again after a few days.
<davexunit>I have code like this:
<davexunit>(define-signal foo (make-root-signal 100))
<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
<davexunit>is that even possible?
<davexunit>or sane/
<ijp>the way I did it was to make the box a part of the node itself
<davexunit>ijp: ah, I see
<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?
<davexunit>okay, I suppose I should try that approach.
<ArneBab>mark_weaver: here’s an example which uses that:
*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?
<nalaginrut>morning guilers~
<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
<mark_weaver>thanks for the pointer though
<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>the variable is persistent even after you redefine.
<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>*keep a reference to _that_ box
<mark_weaver>ijp: btw, what's the status of ?
<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
<mark_weaver>well then, please push! :)
<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
<civodul>Hello Guilers!
<ArneBab_>Hi civodul
***Shozan is now known as SHODAN
<nalaginrut>well, still need some time to adjust, but it works fine now
<nalaginrut>I have to say it's a temporary domain name
<nalaginrut>based on tekuti
<ArneBab_>Did you get new information on statically linking guile (bug #13848)? → Latest I found is this: — 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.
<nalaginrut>ArneBab_: never tried Guile under windows
<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”).
<civodul>ArneBab_: i don't think so
<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
<civodul>by Eli Z.
<ArneBab_>can people then execute it in arbitrary locations?
<civodul>ah no, not out of the box
<ArneBab_>patches floating around sounds like they could get lost…
<civodul>bug again, there are patches around
<civodul>there's one in Guix
<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
<civodul>probably even
<ArneBab_>if he uses Windows - what speaks against that?
<nalaginrut>civodul: it's behind nginx
<nalaginrut>but I forward the header from tekuti, so you may not see it
<civodul>oh and tekuti runs the Guile HTTP server?
<nalaginrut>it's the same principle with Artanis
<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>with some rules
<civodul>ah, ok
<nalaginrut>hmm...dunno, but I don't see wingo for a while
<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>ah, but sounds it could effect Artanis too ;-P
<nalaginrut>I was planed to use Artnanis for blog, but my host expired, so I have to build the blog on new VPS quickly
<nalaginrut>anyway, hope it works fine
<civodul>howdy jemarch
<civodul>any activity on cgen? :-)
<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_>here the sun is shining…
<davexunit>it is freezing and windy here in Boston
<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
<jemarch>weird weather
***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.
<civodul>dje42: sounds like a nice plan
<civodul>dje42: i would avoid GOOPS, though
<dje42>how come?
<civodul>well, it's a long story
<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>ah, ok
<civodul>didn't know it already had its object system
<civodul>then it makes sense, yes
<dje42>biaw ...
<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`> ?
***dsmith-w` is now known as dsmith-work
<dsmith-work>That's from before goops. And mentions hobbit!
<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.
<jemarch>when was the last hobbit release?
<jemarch>end of 90s?
<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 :)
<jemarch>Yes I read your gdb/guile patches
<jemarch>very nice work
***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>which is good
<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...'
<mark_weaver>sure, but that's secondary.
<tupi>yes and controling that would be rewriting par-map
<mark_weaver>you need to limit the number of active processes.
<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.
<mark_weaver>(sorry for the repeat)
<tupi>and gnome-system-monitor shows all other core at 0 [zero] cpu usage
<tupi>ok tx
<mark_weaver>and how many of the java processes are running?
<mark_weaver>s/are running/exist/
<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?
<mark_weaver>I have no idea which one you're using.
<tupi>GNU Guile
<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.
<mark_weaver>I still have the patch though.
<mark_weaver>I can send it to you if you like.
<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>although I guess you'd get EPIPE in that 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.
<tupi>ok i'll try that
<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
<mark_weaver>okay, good luck!
<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...
<mark_weaver>in case you want to try the alternative 'par-map'
<mark_weaver>okay, ttyl!