***sneek_ is now known as sneek
***cluck` is now known as cluck
***sneek_ is now known as sneek
<didi`>Is there some canonical/recommened library for writing tests for Guile? ***wleslie_ is now known as wleslie
*nalaginrut is surprised that new elf.scm takes some many time for compiling ***sneek_ is now known as sneek
***wleslie_ is now known as wleslie
<dje42>mark_weaver: Good evening! :-) I have another question: Any chance of exporting scm_i_with_continuation_barrier? <dje42>Basically, I need the functionality of both scm_c_with_continuation_barrier + scm_c_catch, without the choices scm_c_with_continuation_barrier makes for handler/pre_unwind_handler. <dje42>I'm happy to continue the discussion there ... not sure whether devs prefer here or email. <mark_weaver>I don't see a reason not to export it (although we'd have to rename it), but I'm not comfortable making that decision on my own. <mark_weaver>of course, you wouldn't be able to benefit from it without excluding all released versions of guile, but it won't help in the short term, but I agree it would be nice to make available. <dje42>Yeah. I still need to support what's there now. I still like to throw potential improvements your way as I find them. <mark_weaver>dje42: I've been distracted with GNU Guix in the last few days, and only just now noticed the recent thread on guile-devel. <mark_weaver>the proper solution that I want to implement in 2.2 is to get rid of the signal delivery thread altogether, and to make it possible to queue arbitrary asyncs for arbitrary threads from a signal handler, without delay. <mark_weaver>of course this will involve changing the data structure of the stored asyncs so that it's possible to make them both thread safe and signal-handler-safe. <mark_weaver>we need to make sure that we don't expose APIs that will become hard to implement, or ugly to keep around, after this more proper solution is implemented. <dje42>Righto. The only new thing I'm proposing is the ability to notify Guile a signal happened in an async way (part a). Part b is just a subset of what sigaction already exposes. <wleslie>what thread gets to run those asyncs? <dje42>wleslie: See what sigaction supports today (for example). <dje42>[by "sigaction" I mean the sigaction Scheme function, not the C function] <mark_weaver>so part b would basically be "pretend that I'm registering a signal handler, but don't actually call 'sigaction'". <dje42>I'd phrase it as: I have registered the "real" signal handler myself, and here's what I want you (Guile) to do when I notify you that the signal has occurred. <mark_weaver>I appreciate what you're trying to do here, don't get me wrong. <dje42>I can imagine abstracting away the signal number, and have the async registration function return a descriptor that is then later passed back when notifying Guile of the signal. That way I can register an arbitrary number of asyncs and choose later which one to invoke. <wleslie>giving the user access to guile's signal vector, effectively? <mark_weaver>when we have the arbitrary async queueing functionality from signal handlers, it will be clear in retrospect that this was just a temporary hack. <mark_weaver>if you are really impatient for this in stable-2.0, then the thing to do is to send all the information through the pipe, not just the single-byte signal number. <mark_weaver>so maybe instead of sending those things through the pipe, instead we use CAS to put an entry (with the thread and async) into an array, and then push the index through the pipe. <mark_weaver>I haven't thought it all through, but that's a basic idea. <mark_weaver>APIs are more important to keep clean than internal code. we can fix up ugly code later. APIs are much harder to clean up. <mark_weaver>we have several atomic operations available to use thanks to libatomic_ops, used by Boehm GC. We already have that dependency, we might as well use it. <mark_weaver>I guess that's the one tricky part: protecting the 'proc' from GC while it's in transit through the pipe. <dje42>And having the sigaction's semantics continue to work in this scheme. <mark_weaver>of course, any fixed-size array of slots for protecting these could overflow. <mark_weaver>I don't see what 'sigaction' has to do with it. why does it matter? <mark_weaver>as Tromey pointed out, what you need is just a way to queue an async from a signal handler. <mark_weaver>this proposed mechanism to pretend your registering a signal handler and then tell it when you want it fired is really just a poor-mans way of doing the more general thing. <mark_weaver>hmm, well, I admit there's one fundamental problem with the general interface Tromey proposed. <mark_weaver>since there's no way to do dynamic memory allocation from a signal handler, there's no way to guarantee that you won't run out of whatever pre-allocated space there is in the queued-asyncs data structure. <mark_weaver>so I guess that some kind of pre-registration will be needed after all. <mark_weaver>however, I'd prefer that this preallocation not be pretending to be a signal handler. <mark_weaver>I'd prefer to have a more general interface, where you can register a (proc,thread) pair ahead of time, and get some kind of opaque handle to it. <mark_weaver>and then provide a way to queue this handle from a signal handler. <mark_weaver>the handle could just be a data structure containing those two things, and when you register it you'd put it in some data structure to protect it from GC. <mark_weaver>well, the handle would be a pointer to that structure. <mark_weaver>and then you just push the pointer through the pipe instead of the signal numbers. <dje42>Food for thought. Gotta run (err, get some zzzs). <mark_weaver>and then the signal handling stuff could be implemented in terms of these handles. <wingo_>yeah, my network is terrible this week and i end up reconnecting :P ***wingo_ is now known as wingo
<wleslie>wingo: meow meow meow, meow meow meow meow? <didi>Could someone help me with a `syntax-case' macro? I want to (m exp0 exp1 ...) => (list (cons 'exp0 exp0) (cons 'exp1 exp1) ...) i.e., return a list of cons where the car is the expression and the cdr is the expression evaled. I can't figure out how to do it even if my life depended on it. :^( <davexunit>the input (display (foo (+ 1 1) (+ 2 3))) yields output (((+ 1 1) . 2) ((+ 2 3) . 5)) <davexunit>didi: I'm not so great with macros, either. In this case, you don't need to use syntax-case because this macro isn't procedural. <davexunit>there's no conditional expansion here. (+ 1 1) is *always* turned into ((+ 1 1) . 2) <didi>davexunit: Thank you very much. <didi>I'm still interest in a `syntax-case' if anyone wants to give it a shot, but now I have a solution and life is good again. <didi>davexunit: Thank you again. I thought I /needed/ `syntax-case'. <davexunit>didi: my general approach is to use define-syntax-rule to start with because it is the simplest. <didi>davexunit: You opened my eyes. I was trying to use the wrong tool. And for other macros too. <wingo>zomg, mark_weaver i found a thing. <wingo>the boot expander (pre-psyntax) doesn't handle internal defines -- it treats all defines as top-level defines <wingo>only used when bootstrapping, but still disgusting. <didi>I wrote a data structure for threads synchronization called Channel. If anyone is interested, it's at <git://gitorious.org/guile-concurrency/guile-concurrency.git>. It's pretty experimental at this time and I'm sure the code can be greatly simplified. There are some tests in the repository but many more are needed. <wingo>mark_weaver: only the code in boot-9 before the (load-from-path "ice-9/psyntax-pp") is processed by the boot expander <wingo>and the expanded psyntax-pp.scm itself, or rather the first form in it <wingo>it "works" right now essentially by changing the inner defines in the throw/catch code into "define!" <wingo>i'm fixing that in master, fwiw <wingo>works because it's all in the top-level environment <wingo>and because the names appear not to clash with anything else <wingo>juggling syntactic chainsaws :P <mark_weaver>I'll have to look at it later, too busy with other things right now. thanks for cleaning this stuff up though! <mark_weaver>specifically, Eli Zaretskii asked: "Which MinGW? It sounds like nowadays one needs to distinguish between the various flavors. The exact port of pthreads and gc might also matter." <madsy>mark_weaver: I'll see if I can chime in over the weekend, ok? <davexunit>I was wondering if shanecelis would do more with Emacsy. <add^_>wingo_: wow, nice "compost"! ***wingo_ is now known as wingo
<taylanub>No GSoC for Guile ? Please tell me GuileEmacs counts as Emacs! <davexunit>taylanub: Lilypond is looking for someone to upgrade their code to work with guile 2.0.x <bu^>hello, I had a race condition (I guess) starting guile2.0.9 on OpenSuse 13.1, is this something know ? <bu^>it was something like pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed <bu^>it roughtly started half of the time <bu^>same issue with guile-config <bu^>ok, not sure how related to guile it is <bu^>it was just by using a freshly instller opensuse 13.1 for 64 bits <davexunit>you could try building guile from the stable-2.0 branch <davexunit>and seeing if that version suffers from the same problem <bu^>yes, but it was not on my computer, so I will rather wait for 2.0.10 to arrive <davexunit>well 2.0.10 will be released in the coming weeks, in case you didnt know. <davexunit>add^_: I don't know because I'm not the one doing the releasing. mark_weaver would have a better idea of when 2.0.10 will be released, but there's no firm release date. <nisstyre>Hi, is there anything in Guile like Racket's #hash((a . b) (c . d)) form? Or would I have to do it with reader macros somehow? <mark_weaver>hash tables can't be serialized by the compiler, so even a reader macro won't help. <nisstyre>mark_weaver: okay, is there a built-in function that will take a list of dotted pairs and make a hash table then? <mark_weaver>I suggest you put an alist into the source code, and convert it to a hash table at module-load time. (i.e. from a top-level define) <mark_weaver>davexunit added alist->hash-table procedures which will be in Guile 2.0.10 (hopefully out in the next couple of weeks), but for now you have to roll your own. <wingo>mark_weaver: yeah, a couple times <wingo>didn't do a great job tho :) <wingo>um, i don't recall anything bad but i don't recall very well <wingo>i went into it with the idea that "i'll just say 'yes' at the right times and take money from the google for good people to hack" <mark_weaver>yeah, makes sense. I'm just rather allergic to legalese unless it's vastly better than most. <wingo>basically all you have to do is fill in forms about how your advisee is doing at mid-term and at the end <mark_weaver>(I've been asked to mentor a project for porting Guix to Hurd, last minute thing) <xdje>If you need some help from a googler, let me know. :-) <mark_weaver>xdje: I'd like to see the exact legalese I'd be asked to agree to. <mark_weaver>if someone could help me find that, I'd be grateful. <xdje>still working on it. I couldn't find anything definitive, and I tried to contact an internal person but it's lunch time here. Still working on it. :-) <mark_weaver>ouch. "6.5 Amendments. Google reserves the right at any time to amend this Agreement. Any changes made will be effective immediately upon notice, which we may give either by posting the revised Agreement on the Site or via electronic mail. Your continued participation in Google Summer of Code after such notice will be deemed acceptance of such changes." ***linas__ is now known as linas