<marusich>In scheme, what is the intent behind using % at the start of some variables? I can't quite tell. <rlb>marusich: just generally at least in guile, I think, an indication that the thing is intended to be "private". <mdevos>marusich: in Guix, it's also used for read-only arbitrary constants (e.g. /location/of/key/file, /location/of/cache/dir) <rlb>yeah, I suppose %load-path isn't really meant to be private either? So maybe I'm mischaracterizing... <daviid>fwiw, it also starts some proc names, like %global-site-dir ... <leoprikler>% means "implementation detail" in some way or another most of the times <rlb>Is there a good description somewhere about the behavior of syntax-case literals, i.e. (syntax-case x (literal ...) ...)? <rlb>I ask because I've have some slightly mystifying instances where the correct clause won't match if the term is listed as a literal, but will if I rewrite the clause to explicitly check for it via a guard like (eq? 'something (datum->syntax #'x)). <rlb>(I strongly suspect my mental model is just inadequate.) <rlb>(And yeah, I'll try to create a smaller example later -- most of the cases I've noticed were in very complicated broader environments.) <rlb>But I'd assumed that syntax-case literals would *always* match. <mwette>I thought %var convention was used in GUile to denote a global variable. <soda__hobart>uh... does scheme have a way to define a partially applied function? <soda__hobart>oh, i guess it's called "cut" and it's from srfi-26. haha, that took a while to find <marusich>So % is read-only, private, an implementation detail, or global. I suppose it depends upon the context :) <marusich>At the end of the day, it's good to remember that it's just the first character of a variable name... <rlb>Is that the expected behavior? i.e. that a syntax-case literal isn't supposed to match in a clause if the symbol is both bound to a syntax in the module containing the define-syntax and the literal's symbol isn't also exported from that module. <rlb>(I'd thought that literals always matched, irrespective of any bindings in the enclosing environment.) <rlb>s/thought/imagined/? <rlb>(I mean the definition environment, I know that the *expansion* environment can override them.) <rlb>(let ((else #f)) (cond (else 'nope)) <wingo>rlb: for better or for worse, literals to syntax-rules / syntax-case match by binding <rlb>So it captures the current "value" or something? <wingo>if the literal is unbound when the macro is defined, it will match against that name as long as it isn't defined at the use <wingo>otherwise if the literal is bound, then the name matches only to the same identifier (possibly exported / re-named / etc) <wingo>the good thing about that is that you get to rename literals on module boundaries, if you want <wingo>but it requires a different mental model. matching by binding, not matching by raw name <wingo>fwiw this changed in guile to match the scheme spec in 2.2.0 <rlb>OK, much appreciated -- that unconfusesme about a lot of things I'd seen. I thought if I said "else" it meant *else* (i.e. the symbol else) unless the expansion environment had it bound. <rlb>For a while I'd just assumed I was probably doing something ill-advised somewhere in my giant pile of macros/hacks. <rlb>When you say "same identifier" are we effectively talking about the variable, or what it refers to at the time, or something else? <rlb>Ahh, I guess likely what it refers to at the time. <rlb>(given what else you said) <rlb>(and what I've seen) *rlb thanks wingo again - and wanders off <rlb>(So it's syntax bindings that matter wrt literals, i.e. an established define binding doesn't affect the matching.) <leoprikler>yep, that's why you have (syntax-rules (else) ...) for example <leoprikler>in other words: "%" means "no touching unless you know what to do" <rlb>Right, and if I want else to always match the symbol else, unless someone overrides it locally, then I need to make sure else is not bound as a syntax when I define-syntax cond. <rlb>(or I suppose you can use an (eq? 'else (datum->syntax #'x)) guard...) <leoprikler>if you want to match symbols, you can apparently just quote them as well, dunno about keywords <rlb>Right, my question was about what happens when else is defined as a syntax just before whats-this?, etc. If it is, and else isn't exported alongside whats-this?, then else won't work in an importing modules. That's what I was just trying to verify as expected (and make sure I understood). *rlb wanders off again for a while <mdevos>Why does wait-condition-variable require a condition variable? I'm using condition variables for signalling, without any data access requiring locks. <RhodiumToad>rlb: note that there's a syntax binding for 'else by default <RhodiumToad>the main thing to understand is that condition variables are subject to spurious wakeups, so you need to test a value (which is itself protected by the mutex) to know whether the wakeup is real <mdevos>RhodiumToad: I didn't know spurious wakeups are possible, thanks! <mdevos>there was no menton of spurious wakeups in the manual, however <RhodiumToad>that said, guile (at least in the guile3 code I'm reading) is using its own wrapper around the actual pthread primitives, with another layer of mutexes <wingo>i think it is subject to spurious wakeup fwiw <wingo>like guile has no way to know whether the wakeup would be spurious or not <RhodiumToad>I'm reading threads.c, and it looks like guile is representing a condition variable as a mutex and a queue of guile threads, <mdevos>the (im)possibility of spurious wakeups should be mentioned in the manual I think <RhodiumToad>and a thread sleeping on one puts itself on the queue and sleeps on its own condition var <mdevos>as this is apparently not a trivial issue, and varies with platform *mdevos writes bug report <RhodiumToad>so... maybe spurious wakeups are possible, I wouldn't bet against it <RhodiumToad>anyway, you should use the mutex as intended to protect the condition you're actually sleeping for <mdevos>IIUC, I should run (let loop () (wait-condition-variable!) (with-mutex MUTEX (if VARIABLE-SET DO-STUFF loop)) until the VARIABLE-SET is actually true? <mdevos>(I've one thread A that initializes a data structure D then notifies another thread B that D is ready) <mdevos>Actually, I think I don't need a full-fledged mutext, inserting the initialized data into an atomic box should be enough. <RhodiumToad>no, the with-mutex goes outside the wait-condition-variable <RhodiumToad>you have to be already holding the mutex when you wait on the condition <RhodiumToad>you should acquire the mutex, check the variable, if not set then wait on the condition variable and loop <wingo>mdevos: depends on your use case, but you might like fibers & channels a bit better <mdevos>wingo: I like fibers & channels better, but I'm hacking on an (ice-9 threads) code base now (tests/publish.scm from Guix) <wingo>i wonder if we should move fibers into guile at some point; dunno <mdevos>wingo: you might want to consider documenting the difference between ‘fibers conditions’ and ‘(ice-9 threads) conditions’ ... <mdevos>in ‘fibers condition’, you can signal a condition, then wait for it. As the condition stays signalled, the wait returns <mdevos>but with (ice-9 threads) the wait blocks forever untill the condition is signalled again (I think) <wingo>yeah, different cultural lineages there (pthreads vs concurrent ml) *mdevos almost introduced a concurrency bug in Guix test suite <civodul>wingo: i enjoy Fibers but i think we need to do a bit more polish work <civodul>it's too easy to shoot oneself in the foot by calling something that happens to be blocking <civodul>mothacehe has experienced it the hard way with Cuirass <wingo>mostly ports-related I guess? <mdevos>are there still continuation barriers in "soft ports" and "R6RS custom binary port callbacks"? Maybe (fibers)Barriers needs an update <wingo>i haven't done any work in that area for a little while so i suspect that documentation is indeed up to date <mdevos>wingo: while we're talking about Fibers, would a ‘wait-until-fd-readable-operation’ and ‘wait-until-fd-writable-operation’ be possible? <mdevos>I worked around its absence by using a pair of fibers using current-read-waiter and current-write-waiter and condition variables. <mdevos>But ideally, I would be able to write something like ‘(choice-operation (wait-until-fd-readable-operation A) (wait-until-fd-writable-operation B) more-stuff-unrelated-to-fds)’ <wingo>yes i think it is probably possible to build those with the current api -- lemme see <wingo>might not be an ideal coordination mechanism tho, because the fd being readable at operation wakeup time doesn't mean that it will be readable when you go to do something with it <mdevos>wingo: I can live with that, spurious wakeups aren't problematic for my usecase <mdevos>wingo: also, these fds in my use case are only written to and read from from a single fiber. Let me find the source code URL ... <mdevos>it ents GNUnet's task scheduler on top of fibers (all tasks are still run in a single fiber, however, as the GNUnet libraries do not expect concurrency). <civodul>wingo: it's about things that block in general: could be i/o like 'read', which is blocking, or guile-sqlite3 procedures (we ended up setting up a "database server" running as a thread, which we would send messages to) <wingo>database server as a thread totally makes sense <civodul>prolly Cuirass was kind of an extreme case though <wingo>i get what you are saying about blocking in general but some specifics can help guide future work <civodul>these are two specific examples of problems we had <civodul>but it does mean bad surprises and extra work for someone not familiar with the internals <wingo>maybe lookahead-u8 isn't the right check there in that operation <wingo>would need to replace with char-ready? i think <wingo>which, and this is wild, doesn't actually ensure that a char is ready... just a u8 <civodul>heh, it comes from the old times :-) <mdevos>wingo: looks much nicer than the workaround I've cobbled up! Can you add a copyright+license header? <mdevos>When I get around to also implementing wait-until-port-writable-operation and testing both operations, I'll submit a patch <ex_nihilo>I just installed Guile 3.0.5 and did sudo ldconfig after, getting the error: <ex_nihilo>"ldconfig: /usr/local/lib/libguile-3.0.so.1.3.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start." <ex_nihilo>This happened when I did an ldconfig some time after installing Guile 3.0.4, too. <ex_nihilo>Both times I just renamed the offending libguile file, and then ldconfig worked, but this doesn't seem right. <ex_nihilo>Are other people having this problem? Is renaming or removing libguile-3.0.so.1.3.0-gdb.scm going to cause any problems? <mdevos>wingo: did you receive my PM? The IRC client made a sound suggesting it couldn't be send <spk121>ex_nihilo: that file is a scheme file, so the error is right <spk121>ex_nihilo: if you have a version of GDB with Guile extensions enabled, it uses that file to add functions to gdb. I guess the real question is if it is being installed in the right place for gdb to use it <spk121>but feel free to remove it if you don't use GDB in that fashion <civodul>i'm getting more and more frequent peaks of anxiety regarding this GnuTLS/GMP issue, after trying to stay calm for a while :-) <civodul>wingo: you proposed disabling custom GMP allocators in Guile to work around it <civodul>did you have "local" workarounds in mind too? <spk121>civodul: selfishly, for the sake of portability, I think now would be a great time to pull mini-gmp into the Guile tree and get rid of another build dependency for Guile. wingo already started w/ working to eliminate libltdl <spk121>assuming mini-gmp is up to the task, and is not too slow <civodul>mini-gmp is apparently a bit slower, but we don't rely that much on bignums[*] <civodul>to me that's clearly a medium-term goal <civodul>but i'm also looking for a workaround to that problem that we could deploy easily, even with current Guile versions <ex_nihilo>spk121: on my system GDB was looking in /usr/share/gdb/guile/ for Guile scripts, so I moved libguile-3.0.so.1.3.0-gdb.scm to that directory. <ex_nihilo>That gets it out of the way for ldconfig, and GDB can still use the Guile extensions. <ex_nihilo>I still don't really understand why it got dropped in the /usr/local/lib/ directory to start with, though.... <spk121>ex_nihilo: might be a bug in guile/libguile/Makefile.am maybe. It looks like there is some hackiness there with regards to how that file is installed. But I don't know <ex_nihilo>The first time I tripped over this I had run somebody else's Makefile to install something, and it used ldconfig at the end and failed <ManDay>Hi, I got a strange e-mail from the devel list sayinv <ManDay>Your membership in the mailing list guile-devel has been disabled due <ManDay>to excessive bounces The last bounce received from you was date <ManDay>I haven't written anything to the list in a long time, and certainly not bounced anything either <wingo>ManDay: dm me your email and i will check <mdevos>that means the mails from the mailing list to YOU have bounced, I think <wingo>there is a program that automatically manages the mailing list, more or less <ManDay>mdevos: does that mean the server replied with "send it <there> instead"? <wingo>indeed you are marked as subscribed but not receiving mail delivery because of excess bounces from your mail provider <mdevos>ManDay: I don't know what that means <wingo>check with your mail provider, perhaps? and check that you actually receive recent guile-devel mails <mdevos>I haven't ever gotten such a notice <wingo>when you have it fixed lmk and i will re-enable delivery <ManDay>from the archives it looks like I've only received a fraction <ManDay>I don't know what "excess bounces" means, though <ManDay>do you think my mail provider knows? <mdevos>bounce = X tries to send a mail to Y, the mail server replies with "Nope!" (or mail server is offline, idk). As you didn't send any mail yourself, I believe X = guile-devel and Y = ManDay <mdevos>maybe the mail provider hasn't heard of the concept ‘mailing lists’, multiple accounts at the provider are subscribed to guile-devel@gnu.org mailing lists and now the provider thinks guile-devel@gnu.org is a spammer due to the many e-mails sent? <ManDay>well, vfemail has had some pecularities in the past, but I doubt that that's it <ManDay>So Rick from vfemail replied and he said you should have error messages on the mailing list server which explain this better <ManDay>Well, The maintainers should have the error messages to your address - <ManDay>that's the easy way to find out. <ManDay>He also explained something about something called RBL list and UCEProtect hits and said he adjusted some settings to see that it doesn't happen again, but I guess if you had some sort of error message it would be helpful to return to him <ManDay>if you have anything, please e-mail me with it or leave an memo so I can forward it, thanks! ***metro is now known as metreo
<spk121>is there a library for n-ary trees and doing depth-first traversal, such as for a tree of build events with prerequisites <wingo>prolly not, i guess only (let visit ((node node)) (if (leaf? node) (visit-leaf node) (for-each visit (branch-children node)))) or so <wingo>for appropriate values of leaf? visit-leaf? and branch-children <wingo>a bit of a sloppy answer, clearly i should go to bed