<gmaggior>Hi. I have just run "guile". At the interactive prompt what should I do to recall last expression I entered? I mean pressing "Up" only prints ^[[A. Thanks <nalaginrut>but cancel-thread can't send a specified signal to a thread <mark_weaver>sadly, POSIX provides no portable way to send a signal to a specified thread. <mark_weaver>the only way I know of to do it is to make sure that exactly one thread in the process blocks the signal. <mark_weaver>you can use system asyncs to do it, but that won't work if the thread is blocked in a system call. <nalaginrut>I'm not going to cancel a thread, but send a signal to it <mark_weaver>I'm not trying to be difficult. It's just that signals are terrible, and sadly you can't really do what you want portably in any sane way, as far as I know. <nalaginrut>fortunately it's not critical in my current program, I just have an idea to try to suspend a thread temporarily <mark_weaver>I suggest you arrange for thread to suspend itself voluntarily at certainly well-defined points, perhaps using a mutex. <mark_weaver>I suggest you arrange for the thread to suspend itself voluntarily at certain well-defined points, perhaps using a mutex. <mark_weaver>suspending a thread at some arbitrary point is dangerous. what if it's holding a mutex when you suspend it? <nalaginrut>btw, I thought cancel-thread may send SIGTERM, then I tried to throw exception in SIGTERM handler, but it never work <mark_weaver>cancel-thread uses pthread_cancel. you can read about posix threads for more details on that. <nalaginrut>maybe it's dangerous, but I guess I can do some clean work before suspend actually happens, I mean it doesn't have to occur immediately <nalaginrut>just trying, then I realized it's so hard to do it <nalaginrut>this feature maybe needed if a green thread is blocked somewher <mark_weaver>I think you need to avoid blocking in the first place, to implement green threads. <mark_weaver>I know of no way to implement green threads on top of Guile without rewriting most of the I/O system. <mark_weaver>well, really you'd have to rewrite almost anything that might block, to avoid blocking. I/O, mutexes, sleeps, etc. <nalaginrut>yes, I remember part of it, but I still think something could be done before things became perfect <nalaginrut>If I consider web server only, I think it's not so hard to avoid block in IO <nalaginrut>of course I have to wrap epoll myself at present <lloda>sneek: later tell gmaggior put this in ~/.guile: (use-modules (ice-9 readline)) (activate-readline) <impaktor>Are there some unit testing capabilities in Guile like the (check-expect <func> <expected return>) in Racket? <mark_weaver>SRFI-64 will be in Guile 2.0.10, which should be released in the next couple of weeks. <mark_weaver>in the meantime, you can use the SRFI-64 reference implementation. <impaktor>You're answer is a bit too advanced for me, but I'll Google the cryptic spells spoken, and thank you for pointing me in the right direction. <impaktor>Yeah, I was just reading that last link. Seems cool. Thanks. <impaktor>BTW, anyone using Emacsy? I haven't tried it, but I'm loving the idea. <mark_weaver>I don't know off-hand. It's a fairly recent development. <nalaginrut>Considering 'match' will be expanded with bunch of if/else, I guess it's safe. But it's better to confirm it <taylanub>nalaginrut: You could try it and see ... e.g. make an infinite recursion and see if you get a stack overflow. :P <nalaginrut>taylanub: well, I just worry about if there's some strange situation I can't cover ;-) <nalaginrut>now that 'match' doesn't appear in 'safe tail call' list <taylanub>nalaginrut: Does Guile have such a list ? <taylanub>I would expect `match' to clarify its tail-calls. That list seems to be for primitives. <taylanub>"The above are just core functions and special forms. Tail calls in other modules are described with the relevant documentation, for example SRFI-1 `any' and `every' (*note SRFI-1 Searching::)." <taylanub>And AFAIK our match documentation comes from upstream somehow, in fact there's things documented that we don't really support, like #&foo <taylanub>(Or maybe Mark implemented that reader syntax along with the recent implementation for boxes.) <taylanub>(But it's been documented for a long time now even though it didn't work.) <nalaginrut>hmm..I didn't find any description in this module ***sethalves is now known as sethAway
***sethAway is now known as seth
***seth is now known as sethalves
<mark_weaver>taylanub: I didn't implement the box reader notation #&foo. I don't think it's a good idea. <wingo>appears merged about a month ago; i will build and test <wingo>maybe it "didn't work" because I had mucked with the default stack size, and the test for stack overflow paged in gb's of memory, and that was the indicator i was using <wingo>yes i think perhaps that was it <wingo>need to hook up something to madvise(DONTNEED) on gc <wingo>to return stack memory to the os <taylanub>(assoc key alist) vs (assoc-ref alist key) makes me sad :( <wingo>with parallel markers, a mark procedure can be called multiple times <taylanub>If only I had any idea what that means. :P <wingo>i guess that's only if you have multiple threads... humm <wingo>woo i have guile giving back stack memory to the os <wingo>ah nice, good to see rss going up then going back down <wingo>that's tricky to do with the heap as a whole... <taylanub>I'm playing around with a toy-pseudo-Scheme I made, and have an instruction for my "VM" that makes it not reference a variable but instead wrap it in an object together with a reference to the current lexical scope and output it; this alleviates the "reference to identifier outside its scope" error one gets when doing (let-syntax ((foo (let ((var val)) (syntax-rules () ((_) var))))) (foo)). How plausible would this be with the Guile VM