IRC channel logs


back to list of logs

<zacts>hello guile hackers
<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>i am happy to browse through texinfo docs
<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
<zacts>but I love emacs
<zacts>emacs rocks
***petercom1and is now known as petercommand
<mark_weaver>sneek: sneek wingo
<mark_weaver>sneek: seen wingo
<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.
<mark_weaver>sneek: seen mhw
<sneek>Sorry, no.
<mark_weaver>sneek: seen mark_weaver
<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>Will do.
<mark_weaver>sneek: seen dsmith
<sneek>I last saw dsmith on Sep 14 at 10:33 pm UTC, saying: sneek, seen dsmith.
<mark_weaver>sneek: seen dsmith-work
<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.
<sneek>Got it.
<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> ^
<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> from mallocx.c:17:
<jmd>/usr/local/include/pthread.h:235:0: note: this is the location of the previous definition
<jmd> #define PTHREAD_KEYS_MAX 256
<jmd> ^
<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.
<mark_weaver>(which is the default for it, 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
<mark_weaver>no it doesn't
<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?
<mark_weaver>wingo: no doubt
<mark_weaver>I think we should try to fix this.
<wingo>that's hard in 2.2
<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>what makes it hard?
<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>what if we enabled GC interior pointers?
<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>yeah totally
<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.
<mark_weaver>if you could think about how to fix this properly, I would be grateful. here's the relevant bug report:
<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
<wingo>like by 80% or so
<wingo>perhaps that can be sped up
<mark_weaver>we might want to consider providing separate tarballs with precompiled .go files, to reduce the pressure on us to make bootstrap fast.
<wingo>yeah maybe!
<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
<mark_weaver>right, I can totally get behind that :)
<wingo>like, reliable space safety whether or not we're compiled
<amirouche>what does the following error mean:
<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>specifically, the 'album' macro.
<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
<mark_weaver>jmd: posix threads are the only ones supported.
<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 ##
<jmd>configure: WARNING: ## -------------------------------- ##
<amirouche>too late...
<Sleep_Walker>this is not :b
<mark_weaver>jmd: look in config.log for the details of the test program it tried to compile and what went wrong. please use a paste service (e.g. ) for pasting.
<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>most likely, anyway.
<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 ?
<mark_weaver>we've not received bug reports about this before
<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 try.
<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.
*mark_weaver looks
<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 is doubtful
<jmd>Ok I will try that.
<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.
<mark_weaver>(although I'd keep the existing kernel)
<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.
<mark_weaver>(my 2 cents)
<amirouche>(and/or you can chroot into it)
<mark_weaver>sure, although chroots are a bit tricky also.
<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>install onto an external USB drive
<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>jmd: you have ubuntu?
<amirouche>what then?
<amirouche>(ubuntu is pain; it's the last time I install it)
<jmd>Its a barebones system.
<amirouche>hmm... doesn't seem like a legit distro
<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.
<mark_wea`>that's what I did, anyway.
<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.
<jmd>What did you use?
<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.
<mark_weaver>well, of course my system had a compiler.
<jmd>Then you had an advantage, which I don't
<mark_weaver>again, I think you should install debian first.
<mark_weaver>it's a *lot* easier than what you're doing now.
<mark_weaver>anyway, this discussion belongs on #guix, not #guile.
<jmd>right. Or #debian.
<jmd>Maybe we could go back to the original problem?
<mark_weaver>remind me what that is again?
<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?
<mark_weaver>it depends on the patch you come up with
<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>jmd: sorry, I only just now looked at and I see what you mean.
<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>Yes. I did.
<jmd>It compiled without complaint.
<mark_weaver>okay, interesting
<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
<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
<mark_weaver>civodul is the resident autoconf expert.
<jmd>he's the expert on everthing.
<mark_weaver>heh :)
<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
<daviid>only, re-exports if ...
<mark_weaver>I guess we should be using this:
<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.
<mark_weaver>jmd: I guess we should be using this:
<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}"