<madsy>Can I create a module without using scm_c_define_module() ? <madsy>I want to create a new module, make and make it current for scm_shell <ijp>the way you usually do it in scheme is by calling resolve-module with some fresh name (there is a lower level constructor, but it isn't documented) <madsy>ijp: Yeah, but I'm doing this from C <madsy>ijp: I don't want my C guile functions to be put into the default module <madsy>Hmm.. scm_c_define_module() doesn't seem to do anything. My functions aren't put into scope with use-modules <madsy>Do I need to flag the functions for exporting as well? <madsy>davexunit: Yes, I'm doing proper snarfing <madsy>davexunit: So I gave my snarf setup function as an argument to scm_c_define_module() <madsy>scm_c_define_module creates a new module and takes a function f, such that the module is current for the call of f <madsy>My function f in this case contains: <madsy> #if !defined(SCM_MAGIC_SNARFER) && !defined(SCM_MAGIC_SNARF_DOCS) <madsy>davexunit: Or is scm_c_export something not done by the snarfing? <madsy>I mean.. it *should* work. If I don't use scm_c_define_module, but call f() directly, the function works like it should, but is put into the guile-user module <madsy>davexunit: Seems like I have to call scm_c_export, yep. <madsy>In my opinion that should have been a boolean argument to SCM_DEFINE <davexunit>well, what if you didn't want all of your scheme functions exported? <madsy>davexunit: As I said, it could have been a boolean argument to SCM_DEFINE <madsy>true for export, false otherwise <nalaginrut>it's amazing that mu-guile can be used to write recipes easily, which is what I was dreaming for <nalaginrut>but if it's OK, I'll put it in the server of my community <nalaginrut>I was planing to write mail parser myself, but it's unnecessary now <nalaginrut>well, and mu can easily import all my mails from evolution, seems my problem can be solved soon <nalaginrut>good, I've done the import and I can read my mails, it's very good <nalaginrut>mark_weaver: it's very strange that my fencepost account in msmtp always 535 error, but it's OK in evolution <mark_weaver>nalaginrut: I'm sorry, I don't understand that sentence. <nalaginrut>well, I have some problem to setup gnu account in msmtp, do you have so experiences? <mark_weaver>I know what SMTP is, but I don't know what MSMTP is. <mark_weaver>fencepost has its own system for sending mail, you should probably just use its sendmail program. <mark_weaver>anyway, I'm sorry, I don't have experience with msmtp on fencepost. I've had my own personal mail server since about 1994. <nalaginrut>I'm using msmtp to connect to fencepost's mail server <mark_weaver>so both are run on your local machine, and connecting to fencepost to send mail>? <nalaginrut>mark_weaver: could you post your config of your mail client for fencepost? <mark_weaver>I don't send mail via fencepost. I send it via my own server. <mark_weaver>a mail server like fencepost is going to need authentication from you, to avoid being an "open relay" for spammers. my guess is that the two programs are configured differently, and that msmtp is configured incorrectly. <nalaginrut>the passwd shouldn't be wrong, because I copied from evolution's config, and fencepost account works fine in evolution <mark_weaver>you could use wireshark to log the traffic and see what's happening. *nalaginrut is opening wireshark <mark_weaver>apart from passwords, there are different authentication methods. <nalaginrut>mark_weaver: alright, it's bad username, should be exclude @postfix <nalaginrut>anyway, I'll use mu4e for main client after I done my own recipes <taylanub>Is there a nice way of achieving the same thing as injecting object literals into macro output ? I understand that the code that will generate those objects *must* run at run-time of the program since there is no way to actually inject unserializable objects into macro (compilation) output, but I could e.g. run that code once and bind the object to some top-level ... <madsy>taylanub: Interesting idea, but why is that necessary? Performance reasons? <taylanub>madsy: "Porting" a procedural implementation of something to the domain of macros, so to say, forcing certain computations to happen at compile-time. ***ceverett is now known as _zxq9_
<_zxq9_>Any distros that package guile2 instead of one, by chance? <_zxq9_>Alternately, is there a standardish way (other than using something like the alternatives system) of packaging guile2 for a distro as an add-on that doesn't interfere with guile 1.x? <wingo>don't all of them do guile 2.0 now? <_zxq9_>Most still have guile 1.8, actually. At least the Debian stuff I deal with, RHEL, and even Gentoo (whoa!). <wingo>i thought the last stable debian had guile-2.0 as a package <_zxq9_>I think most of that is to support gnucash, actually, since third-party stuff that uses guile2 tends to bundle it with the package in /opt. <wingo>rhel is of course special :) <ft>Debian has a 2.0 package in stable. <ft>and 1.8 and 1.6 as it seems. :) <_zxq9_>How is it referenced? /usr/bin/guile2 or /usr/bin/guile? <wingo>zxq9: /usr/bin/guile-2.0 or (if it's the only guile installed) /usr/bin/guile <_zxq9_>ft: So that's what I'm getting at. The well-known legacy stuff is still written against 1.8, so I'm looking for a standardish way of packaging guile2 for other platforms (its really easy to build, fortunately) <wingo>if you make packages like this, use "-2.0" as the suffix; see "effective versions" in the manual <ft>I'd guess, that the packages use the alternatives mechanism to determine who provides /usr/bin/guile <_zxq9_>Ah, there we go -- didn't see that in the docs. Thanks, wingo. There are recommendations for parallel installations. <wingo>basically everything is parallel installable except for the binary and the help files; for those you can configure with a --program-suffix <_zxq9_>Whew! OK, this will probably be pretty easy then. <_zxq9_>I'm always struck by the utility of guile -- and wonder why its not used more often. It totally blows me away that projects like OpenSCAD, for example, aren't using it. <madsy>Is there a nicer way to export scheme functions as a part of a public interface from C than using scm_c_export on every symbol? <madsy>That is, I have a module made current while the code from the snarfing is executing. So they become a part of that module. <madsy>But none of the functions are visible without a scm_c_export, even when I use snarfing <wingo>madsy: there are hacky things that can be done :) <madsy>Adding 350 scm_c_export calls is something I'd like to avoid if possible <wingo>if you're snarfing, you can get the macro to include the scm_c_export call <madsy>wingo: That's exactly what I want :) <wingo>seems it's part of guile, even <wingo>documentation patches welcome :) <madsy>Another thing, what is preferred; scm_c_define_module, or scm_c_resolve_module() and scm_c_use_module() together? <madsy>Is it just a matter of taste? <madsy>That is, you want to create a module, then make it current and add some functions to it <wingo>i usually don't define modules from C <wingo>i usually define them in scheme and then use load-extension to initialize the C bits <wingo>but i don't know what's "preferred" <madsy>Okay. Then I'm going with scm_c_define_module. It seems cleaner. <madsy>It only makes the module current for the scope of a function callback <madsy>Which is my snarfing function <madsy>I have a bug I can't track down in guile 2.0.9. scm_join_thread never returns if my guile thread calls run-server. <madsy>Not even calling stop-server-and-clients! from the REPL connection helps. In addition, if I call stop-server-and-clients! from the connection, an exception is thrown. <wingo>i think mark_weaver fixed that bug recently <madsy>Ah, nice. Maybe I should properly install the snapshot he gave me a week ago ***didi` is now known as didi
<mark_weaver>madsy, wingo: I posted a patch to improve 'stop-server-and-clients!', but there's still a problem if locks are held while a REPL is killed that way, so I haven't yet pushed it. More work necessary. <madsy>mark_weaver: Thanks for working on it <madsy>mark_weaver: Let me know if you need someone to test that :) <madsy>10 OpenGL functions implemented, only 340 more to go.. <mark_weaver>the problem I'm stuck on with 'stop-server-and-clients!' is this: how to portably interrupt an arbitrary thread if it's blocked in a system call? <wingo>you aren't going to solve that problem, methinks <mark_weaver>yeah, so then the next best thing is to avoid ever blocking, but I don't know how to do that portably without various other nasty problems. <wingo>a wakeup fd and select would do it for the accept case <mark_weaver>(O_NONBLOCK turns out to have nasty problems, and we couldn't really do it in 2.0 anyway) <mark_weaver>wingo: yes, that part of the problem is solved, and that's what I do in the patch. <mark_weaver>the problem is how to deal with the REPL threads, which could be running arbitrary code. <wingo>i think you also overestimate the importance of o_nonblock -- fds coming in from the parent process or over a socket are in a small minority and can be explicitly flagged <wingo>or do the wakeup fd + select thing <wingo>and pray that you win the race <mark_weaver>well, as you pointed out before, select doesn't tell you how much data is available. <mark_weaver>well, there's also a race, but I'm not even talking about that. <wingo>and it's only stdin anyway right? isn't it possible to know how many bytes may be written to stdout without blocking? perhaps i am being too optimistic <mark_weaver>I'm talking about this: it's time to fill the input buffer of an arbitrary FD. select tells me there's data available. how much can I read without blocking? <wingo>mark_weaver: didn't you suggest that the os would return fewer bytes than the requested amount if fewer were available? <wingo>that's non-portable, but perhaps it's good enough <mark_weaver>after select, Bernstein ended up setting up an alarm for 10ms, and letting the SIGALRM interrupt the 'read'. <mark_weaver>but he could only do that because he doesn't use multiple threads per process. <mark_weaver>wingo: yes, I did suggest that, but now I have doubts. <mark_weaver>I can think of only one proper and portable solution, and that is to use other threads to do the reads and writes, communicating via a private pipe that we can set O_NONBLOCK on. <mark_weaver>and in the case where we don't have threads, we can instead use signals. <mark_weaver>but of course this has potential implications such as increasing the number of file descriptors quite a bit. <mark_weaver>and I'm nervous about making such a big change in stable-2.0. <mark_weaver>on platforms that support asynchronous I/O, we could use that instead. gnulib has modules for it, but unfortunately the modules do not implement it on platforms that don't have it. <wingo>async io or using a separate thread sound terrible <madsy>mark_weaver: Hm.. can't you just block on a join until the thread returns? Like, be polite? :) <mark_weaver>madsy: I'm sorry, I don't understand what you're suggesting. <wingo>madsy: not if the other thread is stuck in accept, or read, or whatever... <madsy>mark_weaver: As when used in the read-eval-print-loop? <wingo>accept also has the same issues <wingo>mark_weaver: there's still a race. <madsy>sockets and file descriptors can be made nonblocking, even on Windows <madsy>A bit hairy, but it's possible <mark_weaver>wingo: yes, if anything else tries to 'accept' on the same socket. <wingo>mark_weaver: yep, or the client could go away <mark_weaver>wingo: in general, there's definitely a problem there. but at least for the REPL servers, one thread owns the socket and can set O_NONBLOCK on it without a problem. <mark_weaver>madsy: the problem with O_NONBLOCK is that on POSIX at least, it is not a property of the file descriptor. it is a property of the underlying ofile. <mark_weaver>in the case of stdin/stdout/stderr, for example, the O_NONBLOCK leaks out of the process that sets it, and affects other processes that aren't expecting it and can't deal with it. <mark_weaver>and also, in Guile we make it easy to get the underlying file descriptor, and a lot of programs in fact do this, and most of them probably aren't prepared for O_NONBLOCK/ <madsy>Isn't it possible to put some extra responsbility on the user of spawn-server and stop-server-and-clients!, so that it's guaranteed to work in at least some specific cases? <mark_weaver>well, the patch I posted works beautifully as long as the programs running in the REPLs aren't holding a mutex when they get killed. <mark_weaver>if we asked users to set a thread cleanup handler to clean that stuff up, then it could perhaps be done. but that seems unworkable to me. <mark_weaver>wingo: would it be possible to set a pthread cleanup handler that unwinds the stack of the killed thread properly? <madsy>Any mutex, like stdlib's internal mutexes, or just user-defined locks? <wingo>mark_weaver: i doubt it; i think you have to be signal-safe in those handlers <wingo>for per-thread things i found pthread key destructors to work better but still, it's a nasty thing <mark_weaver>pthreads are only canceled at certain well-defined points. they are called "cancelation points" <wingo>and it's scary to think about changing things like this in a stable series <mark_weaver>but what we have now in 'stop-server-and-clients!' is utterly broken already. <madsy>mark_weaver: If the users only have to care about their own mutexes, before calling stop-server-anc-clients!, that sounds very reasonable to me. <mark_weaver>we could leave the exposed 'cancel-thread' alone and make a new interface that does the unwind, if it's doable. <wingo>frankly i think it is unimportant. that could be my personal priority set, though. <mark_weaver>it's probably true that we don't really need to have something like 'stop-server-and-clients!'. but unfortunately, it has been a documented part of our API for several (widely deployed) versions of guile. <mark_weaver>personally, I wish it had never been added, if it couldn't be implemented properly. <davexunit>I have never actually used that procedure except to test to see if it worked at all. ***mario-go` is now known as mario-goulart`
<mark_weaver>someone should really implement the 'nonblock_read' and 'nonblock_write' system calls that Bernstein has long been asking for. <wingo>i wonder if recv can be used for this purpose (as someone in an lkml thread suggested) <mark_weaver>in the best case, it would be several years before it could make a difference to user code, but at least there'd be hope for a saner solution to these problems some day in the future. <wingo>we could deprecate stop-server-and-clients!, if that's the thing to do... <mark_weaver>it's tempting, but if we ever want to support something like green threads, we'll need to figure out a way to avoid blocking. <mark_weaver>and if we solve that problem, then stop-server-and-clients! becomes implementable, I think. <mark_weaver>for all its ugliness, I'm tempted to say: use O_NONBLOCK when we know we're the only one with access to the ofile, otherwise read/write using separate threads. <mark_weaver>we could perhaps avoid using pipes (and their associated extra file descriptors). <wingo>i really think we should not do this work in stable-2.0, fwiw <davexunit>I wonder how many people really use stop-server-and-clients! since it took so long for this bug to be discovered. <wingo>who knows; few people report bugs, the fact that two or three people have found it means it's not unimportant <wingo>(contradicting myself, of course :) <madsy>For me it's useful because it allows hotpatching code <madsy>That's why I decided to use a scheme for my demo engine in the first place <davexunit>madsy: well you use the REPL server like a lot of people, but you use this particular procedure as well? <madsy>davexunit: Stop-server-and-clients? Yes, I have to shut down the server thread to close my app. <mark_weaver>for now, I'm tempted to just push the patch that I posted, which does proper shutdown of the listener using a wakeup fd, and cancel-thread for the REPLs, and document the problems. <mark_weaver>davexunit: would you like to look over my modified version of your coop-repl-server commit? it's on the 'coop-repl-servers' branch in git. <madsy>davexunit: But maybe you know of a way I can avoid it? I'm basically calling start-server on a separate thread in my C++ application. In order for my application to gracefully close, start-server must return at some point, so I can join. <mark_weaver>but that doesn't include the later (much smaller) changes I made to adapt to the new 'stop-server-and-clients!' regime. <mark_weaver>and there might have been one or two other minor changes I made since then. <mark_weaver>Caveat to 'stop-server-and-clients!' in the manual: "Please note that in the current implementation, the REPL threads are cancelled without unwinding their stacks. If any of them are holding mutexes or are within a critical section, the results are unspecified." <mark_weaver>madsy: if you want to try the new implementation of 'stop-server-and-clients!', pull from stable-2.0. <madsy>mark_weaver: I think I found a workaround for me. I don't mind waiting until all connections are closed gracefully, so cancel-thread worked beautifully <madsy>If that's bad practice, I didn't get any exceptions or warnings <mark_weaver>it's true that the new implementation of 'stop-server-and-clients!' uses it, but we'll fix that later. <madsy>Okay, I'll use cancel-thread until I build the latest guile again <davexunit>mark_weaver: I'll review that patch shortly. <mark_weaver>note that although REPLs created by the standard REPL server are cancelled, I couldn't do that with cooperative REPLs because they run in the same thread as the main program. <mark_weaver>so for cooperative REPLs, I close the underlying file descriptor and arrange to hide the resulting errors from the user. <davexunit>mark_weaver: I really like that use of parameterize to handle that ugly nesting of input/output/error ports. <davexunit>I haven't had a chance to actually test this, but if it worked for you then I say it's okay to push. <mark_weaver>please do test it in guile-2d when you get a chance, just in case :) <davexunit>hopefully I can test this out tonight before I go to the brattle theatre. :) <mark_weaver>if you don't have a chance to test tonight, no big deal. <davexunit>the new Hayao Miyazaki movie "The Wind Rises" <davexunit>this one stirred some controversy in Japan because it's about a world war II plane engineer. <mark_weaver>(avoid the english dubs, btw. far inferior voice acting, IMO) <davexunit>mark_weaver: subtitles in the showing tonight. :) <madsy>If my finished texinfo files (after doc snarfing) ignores newlines, am I doing something wrong? <madsy>I gave up eventually and let texinfo just wrap all the text. <wingo>i think that's what texinfo does, yes <wingo>there are probably texinfo commands to force newlines if needed <dsmith-work>@* forces a line break. Of course two newlines is a new paragraph. <madsy>It's nice to have variables start on their own line for readability <mark_weaver>madsy: I'd think that you should use @defvr for that, no? <mark_weaver>probably there's some higher-level texinfo construct that you should be using, anyway. <zacts>mark_weaver: any news on when guile-2.0.10 might be released? <zacts>is there anything I can help with? <zacts>(I don't yet know C, and I'm still learning scheme) <madsy>mark_weaver: I'm using @var{foo} for variables. <madsy>scm_to_latin1_stringn seems to allocate a new string instead of returning a pointer to the SCM. Do I clean it up with scm_malloc? <mark_weaver>@var is for meta-syntactic variables, not for program variables. <madsy>Oh, okay. I stole the usage from the libguile code ;) <mark_weaver>well, within a procedure definition, use @var to refer to one of the arguments listed in the procedure signature. <madsy>In what you just said. I use @var in the procedure signature. <madsy>And one would think texinfo would put them on separate lines <madsy>Well, it's not "wrong", just harder to read when the formatting is bad <madsy>I'll dig more in the texinfo docs. Maybe I can give it more hints. <madsy>But I swear the libguile documentation has better formatting, by doing the same amount of work as I do <mark_weaver>in guile, we don't use @var in the signature, only in the description of the procedure. <mark_weaver>I can't say definitively if this is correct or not, but it seems to yield good results. <mark_weaver>madsy: but I can say this: if you're referring to a global variable that's actually defined in the software, then you should use @code for that, not @var. <LRN>how do i debug guile compiler hangups? <mark_weaver>what's happening? what version of guile, and what version of libgc? <LRN>guile-2.0.9, libgc 7.4.0 <LRN>i'm building guile, and it hangs up while building fix-letrec.go <LRN>(consumes no cpu, just hangs there indefinitely) <mark_weaver>there are issues with parallel marking, at least on master. it can be worked around by setting GC_MARKERS=1 in the environment while compiling. we didn't think it affected 2.0.9, but maybe it does. <LRN>Well, I don't generally build stuff on other platforms <LRN>Anyway, no strace here <ijp>well, strace is probably not available for w32 <mark_weaver>fwiw, last I checked Boehm's web site recommended libgc-7.2e as the most stable version. 7.4 is very new. <ijp>there may be something similar, but I have no idea what it would be called ***wingo_ is now known as wingo
<LRN>if GC_MARKERS=1 doesn't work, i'll try to roll back gc version <LRN>didn't even try that <LRN>(probably wasn't a good idea to not to test it; i remember that previous gc version did take a lot of time to build it right, while the new one i just built without giving it much thought) ***Shozan is now known as SHODAN
<mark_weaver>it has quite a large number of bug fixes. we'll be releasing 2.0.10 in the next couple of weeks, and those tarballs are fairly close to what 2.0.10 will be. <LRN>GC_MARKERS=1 did help it go through <LRN>gnutls complains that there's no code for module (ice-9 popen) <LRN>i don't remember whether i had this problem before, or is it a new one <LRN>will probably know shortly - if it fails to find some files for packaging <mark_weaver>(ice-9 popen) is a core guile module. if it can't find it, then gnutls is not looking in the right place. <wingo>or perhaps it's not there on windows <LRN>where would it be, if it was there? <LRN>(i'll look at older guile packages to see if it was there previously) <LRN>it's not in lib/guile/2.0/ccache/ice-9 <mark_weaver>it would be in the same place where boot-9.scm (or boot-9.go) is found. <LRN>that's lib/guile/2.0/ccache/ice-9 (for .go files) <mark_weaver>okay, then I guess you don't have it. did you configure with --disable-posix? if so, it seems that's no longer needed. <LRN>i configured with --disable-posix <mark_weaver>madsy, here on channel, built a recent tarball with mingw64, without --disable-posix, and it seems to work better than the one where he disabled posix. <mark_weaver>gnulib helps us by provide posix wrappers for native windows functions in many cases. <mark_weaver>we could do better on that front, btw. for example, there's a gnulib module for lstat that's implement on windows, but we don't yet import that gnulib module. <mark_weaver>having said this, I don't know whether the (ice-9 popen) module works on windows. I wouldn't be surprised either way. <mark_weaver>it wouldn't be hard to greatly improve our windows support, but in order to do that we need help from windows users. <wingo>i'm having my first real "wtf why is peval not unrolling this" moment <wingo>haha, i'm finding that i added this part of peval about a year ago, probably related to figl ;-) <madsy>mark_weaver: Do you know if gnulib is feature complete? <madsy>Or if it's still missing something? I might be able to contribute there <wingo>madsy: each feature in gnulib has different completeness levels <wingo>and certainly you would be able to contribute :) <madsy>Do libguile get gnulib upstream, or do you guys maintain your own version? <wingo>we fetch as needed from upstream <wingo>gnulib is a copy-into-your-source-tree library <wingo>it has different modules, so we specify the ones we need, and the tools copy just those modules (and their dependencies) <wingo>so there is a very short cycle between patch in gnulib and utility in guile :) <mark_weaver>so, two gnulib modules I notice off-hand that we're missing are 'lstat' and 'mkstemp', which would give us implementations of those on windows. <mark_weaver>(thanks to madsy for running Guile's test suite on windows, and giving me the output) <mark_weaver>we're also not using the 'select' that gnulib makes available. <mark_weaver>wingo: can you help me understand the logic of things like #ifndef HAVE_MKSTEMP \\n extern int mkstemp (char *); \\n #endif \\n <unconditional definition of scm_mkstemp> (filesys.c line ~1473) <mark_weaver>I don't understand how that results in 'mkstemp!' not being defined in windows. I don't understand why it doesn't result in a link error. <mark_weaver>there's something similar but slightly different with scm_std_select in threads.c <wingo>4f68365d libguile/posix.c (Marius Vollmer 2001-11-02 00:16:46 +0000 1471) extern int mkstemp (char *); <wingo>pry open the jaws of the chronophage :) <civodul>anyone tried to gdb guile linked against libgc 7.4? <wingo>i am using libgc from git, fwiw <wingo>civodul: are you using the patch to libgc ? <civodul>wingo: no, actually it's gdb master that fails; 7.7 works <wingo>hum, i have master from a week or two ago <mark_weaver>wingo: thanks. I'm glad I'm not the only one who's confused here :) <wingo>it's fair to assume that anything that old related to portability is completely borken <wingo>ok, -> z. i solved my peval issue without having to hack peval. night :) <mark_weaver>well, thanks to gnulib, we should be able to clean up a bunch of this old compatibility cruft. <civodul>ooh, it's when GDB is built with Guile support with libgc 7.4 that it fails to debug the same GUile