<drdanmaku>davexunit: guile can create texinfo from scheme code? <drdanmaku>heh, there's a big argument over texinfo on the emacs mailing list atm <drdanmaku>but really it seems like texinfo isn't so bad <drdanmaku>info-mode is nice, and this guile feature sounds cool as well <civodul>i think someone™ should work towards replacing the Perl makeinfo with a Guile-based one <nyarlshub>but i've heard that the texinfo format is not very pleasant to write <nyarlshub>on the other hand, how could it possibly be worse than html? <ijp>you need more imagination <civodul>it's pretty easy to write, except for menus <zacts>I wish I could configure vim or neovim to work with guile indent <zacts>I'll figure this out eventually <zacts>It's been really difficult for me to give up my bindings <zacts>and evil-mode is just too slow ***petercom1and is now known as petercommand
<sneek>wingo was here Apr 29 at 02:46 am UTC, saying: we could start by deprecating string-set! and see where that gets us. <sneek>I last saw mark_weaver on May 02 at 03:25 pm UTC, saying: sneek: seen mark_weaver. <mark_weaver>sneek: later tell dsmith: sneek thinks it's early May. <sneek>I last saw dsmith on Sep 14 at 10:33 pm UTC, saying: sneek, seen dsmith. <sneek>dsmith-work was here May 01 at 02:52 am UTC, saying: Bah perl. <mark_weaver>sneek: later tell dsmith-work: sneek thinks it's early May. <jmd>Are there any particular requirements for building guile with threading? I'm having problems finding a set of configure flags that work. <mark_weaver>jmd: guile compiles with posix threads by default, if they are available. <jmd>mark_weaver: You mean it *attempts* to. <jmd>What thread libraries are known to work? <jmd>And how does it determine if it is available? <jmd>Lots of warnings like this: include/bits/local_lim.h:64:0: warning: "PTHREAD_KEYS_MAX" redefined [enabled by default] <jmd> #define PTHREAD_KEYS_MAX 1024 <jmd>In file included from ./include/private/../gc_pthread_redirects.h:34:0, <jmd> from ./include/private/../gc.h:1443, <jmd> from ./include/private/gc_priv.h:46, <jmd>/usr/local/include/pthread.h:235:0: note: this is the location of the previous definition <jmd> #define PTHREAD_KEYS_MAX 256 <jmd>are also not a very encouraging sign. <mark_weaver>that's coming from boehm gc. the string "PTHREAD_KEYS_MAX" literally does not occur anywhere in the guile source code. <mark_weaver>note that boehm gc must be configured to use threading also. <jmd>Yep. It also seems to be temperamental regarding thread libraries. <mark_weaver>tell me about the system you are trying to build on. <jmd>Linux nitrogen6x 3.0.35-4.1.0+yocto+g5809938 #1 SMP PREEMPT Wed Jul 16 13:23:31 CEST 2014 armv7l GNU/Linux <mark_weaver>that only tells me about your kernel, which is irrelevant. what C library are you using? <jmd>gc is looking for a library called /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-cross-armel-linux-gnueabihf-2.20/lib/libpthread_nonshared.a which does not exist. <jmd>The C library is the guix bootstrap one. *wingo trying flat closures in the interpreter, to see what effect is on bootstrap memory usage <mark_weaver>you'll have to ask civodul about that one, on #guix. files like that will never actually exist. <jmd>There's not even anything which approximates it. <jmd>I also tried installing GNU pth, which only made things worse. <mark_weaver>pth is something totally different. you need posix threads <jmd>pth provides posix threads <jmd>According to the documentation, it does. <mark_weaver>wingo: we have a space problem in 'load', in both 2.0 and master. repeatedly loading the same file (which contains only "#f") makes memory use grow without bounds. <mark_weaver>ah, it provides a posix compatibility layer. I stand corrected, sorry. <wingo>mark_weaver: due to mapping it into memory multiple times, i guess? <wingo>without the ability to precisely iterate over the heap, anyway... <wingo>perhaps there are conservative approximations that can be useful; dunno tho <mark_weaver>(I thought it was hard for reasons unrelated to precision, namely the use of mmap) <wingo>because the 2.2 vm is designed to be able to link to code and data directly in the image, without heap allocation <wingo>how would you know if a statically allocated pair escaped to the heap? <wingo>or whether a closure that is on the heap refers to a code address in the image? <mark_weaver>and then somehow made the entire mmap'd region treated like a single GC block <wingo>i think we would do better if we could iterate over all possible pointers in the heap <wingo>or ask the gc in a blocking way whether a memory region is still in use <mark_weaver>maybe we could propose enhancements to boehm gc that would allow this? <wingo>i don't know if we can make the existing API do what we need but certainly the gc is the right place to do this <mark_weaver>I'd be satisfied if we could fix it, even if it was only truly fixed for newer libgc. <wingo>interesting, initial results show that flat closures decrease maximum heap image size by about 2x for a fresh bootstrap psyntax.scm compile, but also slow down bootstrap considerably <mark_weaver>we might want to consider providing separate tarballs with precompiled .go files, to reduce the pressure on us to make bootstrap fast. <mark_weaver>I'm more interested in how the performance of the evaluator is affected in general. although I suppose that if it makes our compiler that much slower, it would probably make lots of other code slower also. <mark_weaver>although more precision for GC might be more important <wingo>well we have flat closures already in the compiler <wingo>flat closures in the evaluator would be for space safety <wingo>like, reliable space safety whether or not we're compiled <amirouche>ERROR: In procedure #<syntax-transformer album>: <amirouche>ERROR: Wrong type to apply: #<syntax-transformer album> <mark_weaver>amirouche: it sounds like a macro is being used before it is defined. <mark_weaver>improving the error messages for that is on my TODO list. <jmd>Is there a way I can force guile to build with threading enabled? <mark_weaver>jmd: you could pass --with-threads=yes, but that's the default anyway, I doubt it will make a difference. <amirouche>thx mark, I will adventure to say that errors are not very helpful in guile <jmd>It seems "yes" isn't enough anyway. You have to tell it *which* thread library to use. <mark_weaver>amirouche: there's a lot of work to be done there, I agree <jmd>... whereupon it says to report the bug to bug-guile@gnu.org <jmd>Yeah but which implementation. <jmd>configure: WARNING: pthread.h: present but cannot be compiled <jmd>configure: WARNING: pthread.h: check for missing prerequisite headers? <jmd>configure: WARNING: pthread.h: see the Autoconf documentation <jmd>configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" <jmd>configure: WARNING: pthread.h: proceeding with the compiler's result <jmd>configure: WARNING: ## -------------------------------- ## <jmd>configure: WARNING: ## Report this to bug-guile@gnu.org ## <jmd>configure: WARNING: ## -------------------------------- ## <mark_weaver>jmd: it would be good if you didn't suggest that this is guile's problem. clearly you are building on top of a broken base, during your guix porting attempt. <jmd>You are suggesting that the base is broken? <mark_weaver>guile certainly builds out of the box on GNU/Linux systems at least, including Guix. <jmd>But you can't build Guix without guile! <mark_weaver>anyway, look in config.log please to find out the details of what went wrong with the pthread.h check <jmd>I'm looking now. But it is not clear. <jmd>(but I suspect pthread.h is included too late in the test prog) <jmd>Yep. It is included after stdio.h <jmd>I don't know how to correct that. <mark_weaver>at the risk of showing ignorance: is there a standard requirement that pthread.h must be included before stdio.h ? <jmd>Well I don't know about "standard" requirement, but clearly if stdio itself includes pthread.h tthings will go wrong. <jmd>It leads to redefinitions of symbols <mark_weaver>it is standard procedure to prevent that in headers by setting a preprocessor macro indicating that the file has been included already, and checking for it. <jmd>In the case of pthread.h there is a whole bunch of them. So if it is not included first, then subsequent includes will go wrong. <mark_weaver>jmd: can you please paste your config.log somewhere? <jmd>I'll paste the relevant bit. <mark_weaver>jmd: anyway, if your theory is correct, I don't see how changing the order of includes would help. if including 'pthread.h' more than once causes problems, and 'stdio.h' includes 'pthread.h', that would imply that our only option would be to not include 'pthread.h' at all. <jmd>Have a look at the top of pthread.h <jmd>Hopefully that should make the problem clear. <jmd>pthread.h must be included before other stuff, so that all these #defines get defined right at the start. <mark_weaver>jmd: why don't you try copying that test program into a file, switching them around, and see if it helps. <mark_weaver>it looks to me like conflicts between the stuff in /usr/local/include and the stuff in /home/john/bsb/include <mark_weaver>if I were you, I would start by installing Debian on that box, and working from there. <jmd>How can that be done? <mark_weaver>you can install debian from an existing system onto another partition. <mark_weaver>keep your existing bootloader and kernel, but replace the userspace. <jmd>I don't have unlimited diskspace. This is an embedded micro PC <mark_weaver>keeping the existing kernel would also require copying /lib/modules/xxx to the installed debian partition <mark_weaver>anyway, building guix is going to require a lot more disk space than installing a minimal debian system <mark_weaver>s/building guix/bootstrapping the gnu system using guix/ <jmd>Once I get *something* working I can proceed. <jmd>mark_weaver: Anyway, to answer your question, moving pthread.h from the bottom to the top of the program causes it to compile without error. <jmd>(which one would expect) <mark_weaver>given how long you've been banging your head against this wall so far, I suspect that you'll save a lot of time by starting from a sane system. <jmd>I'm trying to get one!!! <amirouche>(ubuntu is pain; it's the last time I install it) <jmd>Its a barebones system. <mark_wea`>fwiw, I bootstrapped the MIPS port of Guix using a barebones self-build system (based on Cross [GNU/]Linux from Scratch) <mark_wea`>jmd: fwiw, I would try to build guile on your barebones system without using anything from guix at all. <jmd>The only thing I'm using is the bootstrap binaries. Have you a better idea? <mark_weaver>I built guile and guix on my barebones system, without using anything from guix at all. <mark_weaver>I'm not sure that the guix bootstrap binaries are good enough to build guile and guix directly. <mark_weaver>jmd: I built the necessary prerequisites for guile and guix manually, without guix. <jmd>from what? You needed a compiler. <jmd>Then you had an advantage, which I don't <mark_weaver>anyway, this discussion belongs on #guix, not #guile. <jmd>Maybe we could go back to the original problem? <jmd>Guile fails to properly detect pthread.h <mark_weaver>I'm sorry, but I think you're mistaken. I think the system on which you're trying to build guile is broken. <jmd>In what way do you believe it is "broken" ? <mark_weaver>my guess is that you've got some mixture of include files from /usr/local and /home/john/bsb/include that don't play well together <jmd>Indeed. Those issues are what autoconf is supposed to resolve. <mark_weaver>I'm sorry, but I don't have time to work on this more today. <mark_weaver>anyway, in a few weeks I'll have my Novena and will do the arm port if you don't beat me to it :) <jmd>Anyway, IF I manage to resolve the problem, will you accept a patch? <daviid>mark_weaver: how much time would it take you to write a patch for guile's module #:export behaving like #:re-export? <mark_weaver>daviid: they behave differently for a reason, namely to produce useful warnings about duplicate imports in the common case. <mark_weaver>I don't think we'd want #:export to behave like #:re-export in guile by default. the scheme standards are further in the other direction: duplicate imports are supposed to be an error. <mark_weaver>that said, it would be easy to do, if you just want it for your private use ***karswell` is now known as karswell
<mark_weaver>still, it's interesting that we haven't received other problem reports about this. <mark_weaver>did you try running the failed test program with the pthread.h include moved up? <jmd>It compiled without complaint. <jmd>My hack now is to put #include <pthread.h> at the foot of config.h ... <jmd>like you have been hinting, my current set-up is not a run of the mill system. <mark_weaver>so, the relevant autoconf code that's running that test program is the call to AC_CHECK_HEADERS in configure.ac <mark_weaver>maybe there is some better way to check for the header, or some special magic that needs to be done when checking for that particular header, dunno. <mark_weaver>but I vaguely recall that autoconf automatically inserts includes for previously found headers in test programs, or something like that. <jmd>YEah the autoconf manual talks about using the 4th arg in AC_CHECK_HEADERS <jmd>he's the expert on everthing. <jmd>Once I get a "sane" system I'll try to find a sane solution - but for now I'm applying insane solutions. <daviid>mark_weaver: the actual behavior "... to produce ..." is what one expects from a package/module system, but for procedures. it is not, at all, the expected behavior for accessors, getters, setters and methods, but i didn't want to talk about why again. 'just for me is fine', i can finance this patch, which is why i asked how much time it would take you... _but_, it would only be usefull if it is a/g/s/m 'aware' and in these cases <mark_weaver>daviid: okay, it sounds like you don't just want #:export to behave like #:re-export, but that you want it to do something different. otherwise, it would suffice to simply use #:re-export everywhere instead of #:export <mark_weaver>daviid: so first, I'd need to understand more clearly what you want it to do. <jmd>It would be worth considering. <davexunit>hmm, guile's texinfo generation is different than the format I see used in the Guile and Guix texinfo manuals. <davexunit>"@defun" instead of "@deffn {Scheme Procedure}"