IRC channel logs


back to list of logs

<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>do we have any alternative of thread_kill?
<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>what are you trying to do?
<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>why do you want to send a signal to a thread?
<mark_weaver>what are you trying to do, at a higher level?
<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.
<mark_weaver>You'd best look for another solution.
<nalaginrut>fortunately it's not critical in my current program, I just have an idea to try to suspend a thread temporarily
<nalaginrut>maybe 'stop' is proper...
<mark_weaver>I suggest you arrange for thread to suspend itself voluntarily at certainly well-defined points, perhaps using a mutex.
<mark_weaver>ugh, too many typos. let me write that again:
<mark_weaver>I suggest you arrange for the thread to suspend itself voluntarily at certain well-defined points, perhaps using a mutex.
<nalaginrut>well, that's another way I'm going to try
<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>no, it doesn't send SIGTERM.
<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>anyway, I don't know if it's a good design
<mark_weaver>why do you want to suspend your threads, anyway?
<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
<nalaginrut>or all green threads are blocked
<nalaginrut>at least it's a way to drop the blocked one
<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>(or simply avoiding doing I/O)
<mark_weaver>but we've had this conversation before.
<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>for an instance, I can use edge-triger in epoll
<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)
<sneek>Got it.
<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.
<mark_weaver>the latest version of the SRFI-64 reference implementation is here:
<mark_weaver>the docs for SRFI-64 are here:
<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>Is tail call safe in 'match'?
<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::)."
<nalaginrut>alright, I'll check it out
<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
<nalaginrut>about tail call
***sethalves is now known as sethAway
<civodul>Hello Guilers!
<mark_weaver>hi civodul!
***sethAway is now known as seth
***seth is now known as sethalves
<dsmith-work>Happy Friday, Guilers!!
<mark_weaver>hey dsmith-work!
<civodul>Happy Friday!
<mark_weaver>taylanub: I didn't implement the box reader notation #&foo. I don't think it's a good idea.
<wingo>meep meep
<mark_weaver>hey wingo!
<wingo>greets :)
<civodul>howdy wingo
<wingo>appears merged about a month ago; i will build and test
<wingo>doesn't work.
<mark_weaver>oh well :-/
<mark_weaver>I have to go offline for a while. ttyl!
<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
<amgarchIn9>these people might be interested in new guile internals:
<amgarchIn9>I dont have an account
<taylanub>(assoc key alist) vs (assoc-ref alist key) makes me sad :(
<davexunit>amgarchIn9: wingo posted in this thread
<wingo>with parallel markers, a mark procedure can be called multiple times
<wingo>ah, perhaps not
<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
<dsmith-work>wingo: Oh sweet!
<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