<mark_weaver>madsy: scm_shell doesn't return. maybe the new cooperative REPL servers would be a better fit for your needs? <madsy>mark_weaver: Not a big deal :) <madsy>scm_shell doesn't start in a new thread, right? ***ijp is now known as ijp-lurking
***ijp-lurking is now known as ijp
<ArneBab_>mark_weaver: do you know off the hat who wrote the xcb bindings? <aidalgol>You know, every time I read that, I think of MoinMoin Wiki, which makes me think of Python. You worsen my mornings. :P <aidalgol>Or evenings, considering the time difference. <aidalgol>ijp: What's the sugar cbot module for, again? (I want to add a blurb header comment.) <wingo>though we do an ok job, i'm thinking we should avoid gendered language here, and call out use of it <ijp>by and large, "you" always struck me as more appropriate than "he" or "she" for docs <ijp>no point talking to the user like they aren't there <ArneBab_>wingo: what do you mean by calling out use of it? <wingo>i mean considering general gendered language use as not welcome <nalaginrut>it's interesting that R7Rs no longer guarantee that "15##" == 1500.0, but R5Rs did. I'm curious why it <nalaginrut>this feature is only useful when I was writing chaos code <mark_weaver>wingo: I asked civodul to add a 32-bit clang job very recently. maybe he made a mistake in the nix code. <wingo>since guile-2-0 is also carping <wingo>so what's the deal with mips mutex slowness? <mark_weaver>well, I'd expect mutexes to be very slow compared with what's essentially just a pointer compare (buffer overflow check) and add element. <mark_weaver>what surprises me much more is how small the intel ratio is. <mark_weaver>regarding not wanting any data structure to crash, that means that we'd have to add mutex locking to *everything*. <wingo>i don't think that's a significant cost to pay be default, fwiw <wingo>putchar is the worst benchmark for this use case <wingo>and a worst-case 3x (or 5x) for me is fine <wingo>and there are ways to improve that further (java's locks are cheaper, for example) <wingo>but that doesn't magically solve mips though :) <mark_weaver>if we disregard the performance on non-intel, then we are effectively helping to enforce their near monopoly, which would I think be rather disastrous for free software. <wingo>i want mips to succeed too :) <wingo>but surely there is something bogus in the existing mips abi that is causing this <mark_weaver>well, that's unclear. memory barriers are extremely expensive, no matter how you cut it. intel has some special sauce here, I think. <wingo>if you strace the test case, can you see if it's doing syscalls each time? <wingo>dunno, if the cpu you are running already has exclusive access on the cache line, it should be cheap... <mark_weaver>the problem is not flipping the bit on the mutex. the problem is flushing the write buffers, and things of that sort. <mark_weaver>things are nicer on intel, because their weak memory model is not quite as weak the ones mandated by the modern standards (e.g. in C11). they do some dependency tracking that allows some of the barriers to be avoided altogether. <mark_weaver>the really terrible thing is that it's possible for a thread to see a pointer update before the thing it's pointing to has been initialized. <mark_weaver>this means that there's no way to avoid crashes in code with races unless you build mutex locking into every data structure that contains pointers. <wingo>i don't think it's a memory model issue -- if you have layers of caches, you have a cache coordination protocol <wingo>and ultimately you end up owning a piece of memory by default <wingo>what's a cpu write buffer? :) <mark_weaver>I might be misremembering the proper name for it, but basically it tries to postpone writes as long as possible. <mark_weaver>part of what memory barriers do is to flush that thing. <mark_weaver>but the end result is in the absence of the needed memory barriers, writes to the cache system may be made in a different order than that specified in the program. <mark_weaver>intel has some magic stuff that gets the order right most of the time, even without barriers. <mark_weaver>well, that's a crude description, but I'm trying to get some other things done right now :) <wingo>ok :) still i really disagree with you regarding the importance of perf versus noncrashiness here <wingo>and in the case of the standard output/error/warning ports the default locking behavior is almost always what you want <mark_weaver>26x is a high price for me to pay, for the sake of enabling badly written code to merely generate garbage instead of crashing. <mark_weaver>especially when we can't avoid the crashes anyway, without adding locking to vectors, hash tables, cons cells, etc. <mark_weaver>I can think of just one case where this is likely to be a problem in practice with reasonably written programs: printing warnings and errors to stderr, but there are other solutions we could use to deal with that. <mark_weaver>I have very little sympathy for someone who has multiple threads writing to any other port without locking. that's just broken code. <wingo>hash tables do but we should add mutexen there too :) <mark_weaver>if you create an object and store it into a vector or cons cell, another thread could see the pointer and find that the memory it points to has not yet been initialized (from its point of view). <wingo>i don't think crashes are acceptable and i am amused to see that we find ourselves on what i would think to be opposite to our normal positions :) *wingo usually the one to trade correctness for speed <mark_weaver>if I could think of a reasonable solution to the problem, I'd be all for it. but if you actually read up on the details of modern weak memory models, I think you'll be hard pressed to find a way to avoid crashes in multithreaded programs without extreme overuse of barriers. <mark_weaver>personally, my answer is to do explicit message passing with independent processes. <mark_weaver>I think that the various modern shared-mutable-memory models are *horrible*. almost no one understands how to get it right. <wingo>i actually think the existence of the jvm is a great counterargument <wingo>maybe we need to nail down a memory model for guile <mark_weaver>you are a great hacker, wingo, really top-notch, and even you don't fully understand the implications of modern weak memory models. I've had to remind you multiple times that it's possible for one thread to see a pointer update before the memory it points to has been initialized. if even you don't fully understand this stuff, how many programmers out there do? <mark_weaver>these models are popular because they vaguely approximate an intuitive notion of a single memory that multiple mutators are working on, but that's just the reality. <wingo>hoo, don't go too far with praise, because the second part is totally true :P <wingo>guile's memory model is completely undefined right now, just wishes and fairy dust -- but that's not an unfixable problem <mark_weaver>the fact is, in order to be scalable to large numbers of processors, you need independent CPUs with local memories that communicate with message passing. (or perhaps somethign even more radical like propagators) <mark_weaver>and in fact, that's what's really happening under the hood, and the vaguely sort-of-shared-memory is just a crude illusion. it's smoke and mirrors. <wingo>that's not an argument for allowing crashers <wingo>and again, the jvm does very well on very big systems <wingo>while you might be right (and I suspect you are) about the 10 year horizon, guile in this respect is still 10 years behind :P <wingo>is it possible in weak memory models to cause a crasher if you barrier after initializing fresh objects? <wingo>is it possible to see an uninitialized object? (of course it's possible to see one in an inconsistent state if the object is mutable) <wingo>i think we should ensure that the answer to "can uninitialized objects be seen by other threads" be no <mark_weaver>so you want to commit us to doing a barrier on every allocation? <wingo>you already have to acquire the memory for the local cpu <mark_weaver>there's no inherent reason why that's needed. with a moving GC, allocation can be as simple as bumping an allocation pointer. <wingo>what about other threads seeing uninitialized objects? <wingo>maybe we could barrier on assigning objects or something *wingo needs to understand more about this <mark_weaver>right, that's my point. there's no way to avoid that without committing us to making things that should be cheap vastly more expensive. <wingo>in my work "memory barrier" usually refers to something related to generational gcs and not threading :P <mark_weaver>and all for the sake of a multiprocessing model whose future is far from certain. <wingo>javascript engines being single-threaded <wingo>well, single-threaded from the js perspective <wingo>lots of parallel compilation and gc going on... <wingo>dunno, you are asking people to pay with crashers for an architectural speculation *wingo headed sleepwards soon anyway *tupi suggest a nice fresh and very light break exchanging ideas upon guile-gnome-3 [haha] <taylanub>I don't remember if I skimmed it, read part of it, or read all of it. <taylanub>But IIRC it boils down to common sense. :P When it comes to documentation I like to look up to Emacs. <didi>taylanub: I recommend it. <civodul>it draws conclusions similar to that of the GNU Coding Standards in a way <civodul>in a world of Doxygen, Javadoc, etc. <taylanub>I tend to forget that common sense is not necessarily common <civodul>but still, it seems many people think in terms of tools <civodul>and the fashionable tools invite you to write poor documentation <tupi>civodul: great presentation! (I also remember slides you wrote to compare C with scheme programming ...) nice work <ArneBab_>the shapes of the letters match and the versions are in the right order of magnitude, too ☺ <ArneBab_>civodul: can I forward your presentation to a friend of mine who does software documentation? <ArneBab_>☺ — I pointed that out as an example how hard it is to actually censor some information. If that had been sensitive information (and not public documentation: I could have just googled the documentations sentences, I guess) then pixelating would not have been enough (blacken it instead) and you would have had to kill the version number, too. <ArneBab_>(best blacken some space around it, so I could not guess the length of the name) <ArneBab_>besides: From my experience the Guile documentation is a mix of really good documentation and stuff which still needs lots of work… <ArneBab_>civodul: on man-pages: They rule over info. And I think I found one reason for that: man <program> tells me how to call that program. <ArneBab_>I tried implementing something similar with info, but wasn’t able to really replicate that. <civodul>well, there are the "Invoking" nodes <ArneBab_>I tried to use them, but they do not fail if the program isn’t there. Try `info --usage missing` <DeeEff>hey all, I just installed guile-2.0.11 on debian testing, but I ran into an issue (think it's a bug). <DeeEff>When you run `guile-config --version` after `sudo make install`, it lists guile 2.0.11 (correct version), but when you call the guile interpreter, it says that you're running guile 2.0.9-deb+1-1 <DeeEff>this can't be right, since I know that 2.0.9 was removed `sudo aptitude purge guile-2.0` beforehand <DeeEff>thoughts on why the interpreter lists the wrong version and guile-config lists the right version? <civodul>DeeEff: most likely the old (2.0.9-deb) libguile-2.0.so is still around <civodul>ArneBab_: yeah, bug-texinfo@gnu.org :-) <ArneBab_>civodul: I think I already sent it there <DeeEff>currently I'm running make and make install again to see if anything changes, but if libguile-2.0.so is still around, I'd like to get rid of it first <civodul>try "ldd $(which guile) | grep libguile" <civodul>and then "dpkg -S /path/to/libguile-2.0.so" <DeeEff>ah, it seems guile-2.0-libs was still installed. Not sure why it didn't get changed. <tupi>DeeEff: "aptitude purge that-package" is probably better <didi>Is it guaranteed that `signal-condition-variable' will return only after `wait-condition-variable' return? <dsmith-work>DeeEff: Were you installing 2.0.11 from source or a package?