***linas__ is now known as linas
<adhoc>is there a module to support MariaDB ? <nalaginrut>adhoc: as I know, guile-dbi only supports mysql/sqlite3/postgresql now, but I'd like to have mariaDB too <mark_weaver>Given that MariaDB is supposed to be a drop-in replacement for MySQL, I guess it would be super easy to get it working with guile-dbi. <mark_weaver>I already have too much on my Guile TODO. It would be great if someone else could do that. *nalaginrut sent the mail <adhoc>ok, i found a bit of doco on guile-dbd-mysql, but none of it seemed recent <adhoc>and there being a few different guile postrgesql modules led me to thing that there was enough churn or perhaps the older guile-dbd-posgres maybe unsupported <Fuuzetsu>I see http://lists.gnu.org/archive/html/guile-devel/2013-09/msg00005.html but the author says “Note that the fairness of this implementation relies upon the fairness of Guile's mutexes and condition variables, which I have not checked.” which is rather important if you're going to be using MVars; namely, GHC's fairness policy is what assures that no thread is blocked indefinitely. Has this been checked in Guile since the posting? <mark_weaver>Guile's mutexes and condition variables are supposed to be fair, and I have no reason to doubt that they are. I'm not sure why I wrote that. I guess I was feeling unusually cautious that day. <mark_weaver>if you're concerned about it, feel free to check yourself and report back. <mark_weaver>If you experiment with it, make sure to use the corrected code that I followed up with later. <Fuuzetsu>‘Supposed to be fair’ is not too convincing… Experimentation can only show so much, I was hoping about something of ‘yep, here are the formal semantics of the thread scheduler’ or someone who wrote it being able to point to the source. <Fuuzetsu>Right, but isn't this being proposed to go into standard libs? I'd imagine _someone_ should be concerned about whether the concurrency mechanism behaves as expected. Correct me if I'm wrong. <mark_weaver>if there are bugs in guile's mutex and/or condition variable implementation, those bugs already exist, and I wouldn't be creating them. <mark_weaver>I'm just building on top of what's already there. If we halted all work until the core of Guile was formally verified, nothing would get done. <mark_weaver>we simply don't have a big enough community of contributors to pull that off. <mark_weaver>if you think this is a problem, then feel free to do the work yourself. <mark_weaver>sincerely, I would appreciate it if you were willing to. <Fuuzetsu>I'm not accusing you of creating bugs, I'm simply pointing out that MVars work in Haskell because we know how GHC will schedule threads. That is, we know that no thread will be indefinitely blocked given regular putMVar calls. If this is not the case in Guile then anything built upon such assumption is inherently broken, hence my questions. <mark_weaver>well, threads.c has the fat mutexes code, which is used as the basis for mvars. <mark_weaver>I get the impression that you might be competent to look over the code and see if it meets the requirements. <mark_weaver>the condition variables are implemented there as well. <Fuuzetsu>I don't think I'm competent enough either in C nor Guile to look over concurrency code, sorry. <mark_weaver>well, I'm not sure what to do about this, then. I guess maybe you're suggesting that I do a bunch more work, or that I withdraw my proposal to include mvars. <Fuuzetsu>I'm just hoping that if your MVar code is ever to make it into the libs, someone will actually first check that the assumption it's based on actually exists rather than rather blindly committing it. <Fuuzetsu>I have no problem with it as a library but if something is to make it into core language as you suggest, we should at least have some confidence that it's not completely broken rather than just hoping, right? <mark_weaver>the thing is, any code committed to the repository has the potential to break something if it's not done right. <mark_weaver>well, it wouldn't be in the "core language" per se. it would just be distributed with guile, as a library. <mark_weaver>you're suggesting that even testing is not good enough; that really I should develop a formal semantics for the core threading code, etc. you might as well make the same demands about a great deal of the code that goes into the repo. <mark_weaver>there's a tradeoff here. if you make the standards for commits too difficult, then work will slow to a stand-still. <mark_weaver>I'm sorry, but Guile may simply not be a good fit for you. Maybe look at VSCM, a formally-verified Scheme implementation. <Fuuzetsu>I'm not asking for formal semantics out of you, I'm asking for someone who wrote the initial concurrency code to step up and say ‘yes, we have such fairness policy’ or ‘no, we don't have such fairness policy’ and then act upon that decision: either keep your proposal as-is or change it so that it works with Guile's semantics. <mark_weaver>the truth is, I'm sympathetic to your concerns. it's just that I have too many important things to work on and not enough time. <mark_weaver>maybe you're right that it shouldn't go in. feel free to voice your concerns on the mailing list. <mark_weaver>help with the verification or testing would be even better. <Fuuzetsu>I would but I have only subscribed to it few minutes ago so I don't have the thread to reply to in my inbox. <mark_weaver>well, you could import the mbox format files that are available in the archive. <Fuuzetsu>Oh, I did not know this. Let me have a look… <mark_weaver>Fuuzetsu: would you like to write some scheme code that tests the fairness of the mvars? <Fuuzetsu>I would not have the chance to do so until about next month ;P <Fuuzetsu>I don't have the Guile expertise to make it a good experiment anyway. <mark_weaver>I don't see why Guile expertise is required. If you know R5RS, that's almost all you need to know. The number of Guile-specific procedures needed would be very small. <Fuuzetsu>I don't know R5RS anywhere near enough, trust me. Scheme/Lisp is not my language of choice. <mark_weaver>Out of curiosity, what brought your attention to Guile and to my MVar proposal? <Fuuzetsu>I saw davexunit post the link in this channel in my backlog at which point I thought ‘huh, they lifted MVars from us, neat’ and followed the link. Then I saw your uncertainty about the underlying principles and that davexunit is going to (or already has) used it in his guile-2d project and as I hope to dabble in that, I thought I should find out how well-founded your implementation is, especially because I'm 99% confident that davexunit <Fuuzetsu>doesn't know what makes MVars tick (he's not a Haskeller). <Fuuzetsu>As you can imagine, indefinite thread blocks in a game engine (or else) are not the ideal thing to have. <mark_weaver>I'm sorry to say that our small community has vastly fewer resources than the Haskell community. <mark_weaver>Guile is not nearly as rigorous as what you're accustomed to. <Fuuzetsu>I wouldn't say Haskell community is rigorous but anyway that's beyond the point. I just feel that something proposed to go into the core language should have some more review about its sanity. <mark_weaver>Fuuzetsu: do you know of any free test suite for mvars written in haskell? <Fuuzetsu>Cool. I'd post to the mailing list but I seem to be losing the fight with Thunderbird. <Fuuzetsu>Hmm… I can't say I do, at least not something that's portable considering it's GHC specific stuff <Fuuzetsu>Hmm… There are probably some tests in the GHC test suite that could be dug out <mark_weaver>if you could find something, it would be very helpful. <Fuuzetsu>ghc/tests/concurrent have a bunch of stuff which looks promising <Fuuzetsu>browsing locally, let me try to find an online link <mark_weaver>well, I can do that. I thought you might have it handy. <Fuuzetsu>Oh, brilliant, managed to import the mbox file <mark_weaver>if you could help find the specific test(s) that deal with fairness, that would be helpful <mark_weaver>searching that directory for 'fair' and 'starv' didn't turn up anything. <Fuuzetsu>I don't think I'll be able to right now but I'll look around a bit later. <Fuuzetsu>mark_weaver: GHC's fairness is fairly easy to observe. An easy example is two threads where one prints A and other one (such as main thread) prints B. With the fair sharing semantics, we should very quickly start seeing the ABABABABABABABABABABABAB pattern. Occasionally this might skip a letter due to pre-emptiveness but the general pattern should be like that. <Fuuzetsu>Out of interest, have you written any programs using your MVars? How did they do? <mark_weaver>I wrote it for David Thompson, who used it in guile-2d, a game library. <mark_weaver>of course I was planning to write a test suite for them. <Fuuzetsu>Mhm. See page 125 onwards of Parallel and Concurrent Programming in Haskell for some simple programs which you might be able to implement. <mark_weaver>and your challenge to me will no doubt cause me to work harder on that. <mark_weaver>As I recall, I did do some basic tests like two threads writing to the same MVar, and seeing an ABABABABAB pattern (with occasional skips, iirc), and two threads reading from the same MVar. <mark_weaver>alas, I did the tests from the REPL and probably didn't save the code. <Fuuzetsu>Well, I sent out the e-mail for now, hopefully someone can step in and answer clearly how the scheduler works. <Fuuzetsu>By the way, I can't find the details of formal verification of VSCM, have you got any links? <Fuuzetsu>Shame. I think you heard misinformation because I can't even find a mention of it. <mark_weaver>I suspect it's been a long time since work was done on VSCM. <Fuuzetsu>the FAQ doesn't mention anything about VSCM being formally verified; vscm certainly exists, I just can't find anything about it ever being verified <Fuuzetsu>The VLISP paper does have the title ‘VLISP: A Verified Implementation of Scheme’ so maybe that's what it was. <mark_weaver>okay, it might have been VLISP that I was thinking of. <mark_weaver>the one I was thinking of was based on Scheme48, as I recall. <Fuuzetsu>Mhm. In any case, I have not hear of this paper before, I'll certainly enjoy it when I find some time. <mark_weaver>which is indeed a very elegant implementation, with an emphasis on correctness. <nalaginrut>adhoc: I removed MySQL then installed MariaDB, and using it just like MySQL, it works fine with my site <nalaginrut>sneek: later tell mark_weaver I realized that MariaDB can work just like MySQL, so there nothing work to do with guile-dbi, just use it like MySQL ;-) <civodul>so, where do we report Guile-WM bugs? :-) <sriharsha>Hello guilers, I am having a test case failure with guile-2.0.9, can someone point me to what is going wrong there? <sriharsha>that string is not present in the test-command-line-encoding2 <civodul>sriharsha: that test has a "coding: " cookie at the end <ArneBab>sriharsha: what is your terminal encoding? <ArneBab>sriharsha: what do you get from echo $LANG? <nalaginrut>can you paste test-suite/standalone/test-command-line-encoding2 ? <ArneBab>sriharsha: also with env | grep ISO? <ArneBab>sriharsha: then the string should not be comming from your env… <civodul>sriharsha: can you show the strace output? <civodul>it looks as though the file read is cut <ArneBab>regarding the build time of guile: For me it took 24 minutes with make -j8 <ArneBab>I’ll gladly test master, if it helps <civodul>it might actually be slightly faster with -j4 <civodul>because fewer modules are interpreted when the compiler starts being compiled <ArneBab>I worked a bit on the example code and mark said I should talk to you about the line length limit <civodul>i have no idea what you're talking about <ArneBab>this is the basic example for using guile as integrated interpreter. <ArneBab>I worked on the documentation to make it easier to read <ArneBab>civodul: for that I shortened the code and added some subsections. <ArneBab>But for one of the changes I needed to make the codelines a bit longer. <ArneBab>What is the maximum line length I can use in the documentation to avoid bringing other problems? <ArneBab>civodul: you can pull the changes to the stable-2.0 branch from git://gitorious.org/guile/arnebabs-guile.git <civodul>lines should be < 75 characters, roughly <civodul>you can check the PDF output also, to make sure it gets out properly <civodul>please send a git format-patch patch to guile-devel, with a paragraph giving the rationale <ArneBab>civodul: can you give me the exact command line for producing the patch? <ArneBab>(I use Mercurial to interface with git-repos - we need not go into the details why…) <ArneBab>(sorry for being absent - I had to go AFK on short notice) <ArneBab>I have a git repo here which has the changes as 287c551 and 49cde57. <ArneBab>I have a merge in there - that does not work :( <civodul>but really, use the interface that pleases you, but don't expect maintainers to tell you how it works :-) <ArneBab>I asked how git works, not how the interface that pleases me works… <ArneBab>(and I spent the last 12 minutes searching for a command which does it right…) <civodul>git format-patch --help should have the relevant info <ArneBab>that’s what I spent the first few minutes on, then I switched to google… <civodul>but i just don't want to spend too much time explaining git or git-to-hg or whatever <ArneBab>my hg-interface works just fine. All the changes are pushed into a git-repo. It’s git format-patch which gives me trouble… <ArneBab>I can generate two patches, which won’t be marked as consecutive. <ArneBab>so I can just send the patch inline? <ArneBab>ok - I’m currently amending one of the patches to fix the author-line, then I can send it. <nalaginrut>heh, an interesting bug in a particular usage ;=P <nalaginrut>FWIW, why not adding a delimiter for the encoding scanner <ArneBab>building guile master with -j8 took 1:29:37 ***mario-go` is now known as mario-goulart