<dsmith-work>Some people are just plain hard to get along with. They refuse to consider viewpoints other than their own could be valid. *dsmith-work has had to deal with a co-worker like that <richi235>taylanub: okay, sometimes i get the same impression from discussions on emacs-devel^^ <mark_weaver>rlb: actually, I take that back. we might have some inline assembly in there that it doesn't like. <rlb>mark_weaver: I've also asked wookey -- arm expert, so we'll see. <mark_weaver>rlb: it might be related to the asm on line 365 of vm-i-scheme.c <rlb>mark_weaver: ok, thanks <mark_weaver>I'd be very interested to hear any comments or suggestions wookey has on that asm. I wrote it, but I'm very far from an ARM expert. <mark_weaver>the asm hasn't (yet?) been adapted to the new VM in master. <mark_weaver>the asm is mainly helpful to overflow detection during fixnum multiplication, because there's no efficient way to do it in portable modern C, or at least none that I could find. <rlb>mark_weaver: not for signed values iirc <rlb>mark_weaver: very likely target for asm... <mark_weaver>in portable modern C, you must avoid overflowing signed integers. if you ever do that, the compiler has license to do whatever it wants, and modern ones do. <rlb>(and not sure even unsigned ca be efficient) <rlb>(wrt signed overflow) *rlb had to hack up some awkward functions in bup to deal with that -- which would have been much more efficient in assembly... <mark_weaver>so the only portable way I know is to divide the largest integer by one of the factors. and division is slow, of course. <bipt>i just realized one reason that many people have trouble building guile-emacs: pkg-config doesn't look in /usr/local at all on many distributions <bipt>you have to set PKG_CONFIG_PATH=/usr/local/lib/pkgconfig <mark_weaver>I'm also curious is wookey has suggestions on how to simplify or improve that huge #if above the arm asm. <bipt>paroneayea, from your paste, it looks like the guile-snarf process is going wrong somehow <bipt>paroneayea, also, guile-2.2 is not actually being used; note the -I/usr/include/guile/2.0 arguments <bipt>probably due to pkg-config looking in the wrong place as noted above <bipt>paroneayea, could you set PKG_CONFIG_PATH, do "git clean -fdx" (assuming no changes you want to keep) and try again? <bipt>paroneayea, if you get an error related to lread.x, i'd be interested in seeing both lread.x and the contents of /usr/local/bin/guile-snarf, by paste or email to robin@terpri.org <bipt>if you get the same error again, i mean <paroneayea>bipt: I need to look up the PKG_CONFIG_PATH stuff and how to do that.. <paroneayea>unless you have an easy suggestion on what I should do :) <bipt>paroneayea, "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig" should do it if you installed guile-2.2 in /usr/local <paroneayea>ah... I was trying to avoid doing a make install <bipt>in that case you can use a different --prefix for configure and set the path to $prefix/lib/pkgconfig <bipt>you also will probably need to put $prefix/bin at the start of your $PATH so that configure finds the right guile-snarf script <bipt>(in my guile branch, it has a bugfix that should prevent the error you got) <bipt>i should probably write a configure test to check that it finds the correct version of guile-snarf <rlb>mark_weaver: wookey says... <rlb><wookey> So either guile is generating incorrect assembly code, or the <rlb>about to add m68k to target.scm for debian fwiw <mark_weaver>rlb: regarding m68k, if you could post a suggested patch, we can take it upstream. <mark_weaver>rlb: regarding the arm compilation problem, those comments from wookey still leave me unclear on what the problem is. looking at our inline asm, it's not clear how those registers could be the same. if you could show me the .s file that the asm complains about, it would be helpful. <rlb>mark_weaver: will do wrt m68k (after I see if it works ;>) <rlb>mark_weaver: ok, wrt asm -- have to see what I can manage -- so far only had indirect reports *rlb hopes guile kills guile-config off for good soon (will it be in 2.2?) <mark_weaver>I think it's still too widely used by projects that use guile <rlb>certainly would have made my last day or so less work ;> *rlb and helmut are trying to fix multiarch "good enough" for now -- killing guile-config would fix it properly. <rlb>anyway, I think we may have a reasonable interim solution now -- find out soonish <mark_weaver>what difficulty does guile-config present that pkg-config does not? <rlb>it's a mess b/c pkg config understands cross-building automatically, but guile-config does not so (and I'm just hand-waving(ish)) say autogen's cross-build build-depends pulls in a host guile-2.0-dev, which then pulls in a host guile-2.0 (to run guile-config), but when it tries to run guile-config, it fails because we have a *host* guile-2.0, which we can't run on the current machine. <rlb>pkg-config side-steps all that (already knows how to deal with it) <mark_weaver>since guile-config just calls pkg-config, could that be done in such a way that it wouldn't even matter if you had the wrong one, because it would be an architecture-independent shell script that merely forwards the request to pkg-config? <mark_weaver>civodul is really the one to talk to about this. of the guile maintainers, he's the most knowledgable about build systems. <mark_weaver>rlb: regarding guile-config, I probably don't understand the issue well enough to not waste your time. could you post to guile-devel about it? Then I'll bring it to civodul's attention. <rlb>mark_weaver: once I have a better idea -- sure. It's complicated, and I don't understand it all myself yet. But I do know that the eventual plan to drop guile-config fixes the problem, so if we end up with a reasonable workaround in debian, then maybe it's fine for now. <rlb>(guile makes a cameo at the end) ***ft_ is now known as ft
<rlb>mark_weaver: #debian-bootstrap (oftc) is also knowledgable <mark_weaver>it would be useful to know whether guile-config could be fixed while remaining compatible with existing users of it. But perhaps its API is the problem, or perhaps the problem is that it's part of the guile package itself. <mark_weaver>perhaps you could patch all debian packages that use guile-config to use pkg-config instead, and then submit those patches to their upstreams? <mark_weaver>and maybe we should print some very hard-to-ignore deprecation when guile-config is used. <rlb>sounds like a good idea <rlb>and if you feel like poking at it (wrt details), I'd recommend helmut on #debian-bootstrap (oftc) <rlb>he understands things quite a bit better -- though I think all of this is still one of those (amazing imo) debian undertakings that we're still sorting out <mark_weaver>yes, making such a change in a project as big as debian is awe-inspiring. I know that it took many years to become a reality. *rlb was quite amused by the "apt-get install foo:armhf" (or whichever arch) demo (on a non-arm laptop) where (via qemu/binfmt) the presenter proceeded to run the arm foo directly. <rlb>can't recall if foo was emacs or libreoffice or what... <rlb>(couple of years ago) <rlb>I think guile's probably more complex both because it's more central these days (apparently), and because it's a compiler. <rlb>or at least the fact that it's more central is why you're getting so much attention on this front atm. <nalaginrut>Is it possible to build https server without modifying the built-in server? <mark_weaver>well, the built-in server is very modular, so you wouldn't have to rewrite much. <mark_weaver>alternatively, you could run a different web server in front and configure it to forward most of the requests to guile. that's probably a good idea anyway, so that the static pages can be served more efficiently. <mark_weaver>but if you look at (web server) there are a lot of exports. <mark_weaver>actually, I see that (web server) has this 'server-impl' record type, and 'define-server-impl', and (web server http) is one such server-impl. <mark_weaver>I guess that you just need to define a corresponding (web server https) <rlb>so am I reading read.c right -- i.e. there's no way to read just the next number from a port? <rlb>(i.e. scm_read_number() is static and not exported to the scheme side...) <taylanub>rlb: `read' always reads one Scheme object. if the next object on the port is a number, it will read that. maybe you could `read' and then test whether it's really a number; dunno what problem you're trying to solve <lloda>wingo, I sent the intern-array patches to the list. <lloda>that allowed me to try master on our internal code. <lloda>I did what you said about removing the indirection in the array object <wingo>sounds great (though perhaps some other allocator is needed; is it guaranteed to be word-aligned?) <lloda>ah, in 32 bits the header is 3*32, then the dimensions... so I guess it's not (?) <lloda>scm_words uses SCM_GC_MALLOC, is that the same? <lloda>I took it from scm_c_make_vector, that packs the header and all the elements in the same scm_words() block <wingo>scm_c_make_vector can use scm_words because it is going to be an integral number of machine words <wingo>see the implementation of scm_words, it just multiplies and calls scm_gc_malloc... <lloda>it's the same for the array object now, it's [word 0: header] [word 1: root] [word 3: base] [word 4: dim 0 lbnd] [word 5: dim 0 ubnd] [word 6: dim 0 inc] etc. <wingo>are you sure? is ssize_t always going to be the same size as scm_t_bits ? <wingo>at the very least we should add a compile-time assertion (grep the sources for "verify") <lloda>there's a long comment in __scm.h that says so... <lloda>it says that scm_t_bits & SCM are always the size of void * <wingo>right, but what about ssize_t <wingo>which is the type of the array dimensions <lloda>I thought that sizeof(ssize_t)==sizeof(size_t)==size of pointers <wingo>the first is certainly true, not sure about the last == <lloda>ok, after googling it seems it's not :-/ <wingo>the solution is easy -- just add up the word sizes to the sizeof() of the dimensions to get a byte size, then use scm_gc_malloc *wingo notes this is a situation in which c++ would be useful :P <lloda>ok, I see if I can fix that. <lloda>it bothers me that I can't test it though. <lloda>so the other question I had is, why did #2() not work in the repl, but it did work when loading a file? <lloda>there are literal arrays in arrays.test, but the interning code didn't seem to get used there. <wingo>i think arrays.test is interpreted <lloda>hm, shouldn't that be changed? <gjanssens>This string is a directory name with some non-ascii characters in <gjanssens>When I try to access that directory from guile it tells me the directory doesn't exist <gjanssens>The windows system's code page is 1252, not utf8 <gjanssens>How do I get guile 1.8 to access this directory ? <gjanssens>The string is passed from c to guile via scm_from_locale_string <wingo>things are pretty terrible regarding encodings in guile 1.8 :/ <wingo>i think probably what you would need to do is write a utf-8 -> 1252 conversion function, in scheme or c <wingo>then use the converted string when opening the file <mark_weaver>gjanssens: to add to what wingo wrote: in guile-1.8, strings are simply sequences of bytes. it has no notion of encodings at all. <mark_weaver>this is all fixed in guile-2, where strings are sequences of unicode code points. <mark_weaver>can you upgrade to guile-2? guile-1.8 is no longer supported. <gjanssens>wingo: I was afraid such function would be required :( <gjanssens>mark_weaver: re guile2 on windows - I'm trying to find the lesser of two evils <wingo>if you have your locale set correctly and iconv can convert to your locale <gjanssens>I have already spent a couple of days just trying to get it compiled <gjanssens>That was so frustrating I decided to first try and see if I could get away with it in guile 1.8 <gjanssens>I also spoke with the people from the mingw project <gjanssens>and I was informed there that guile 2.0.11 doesn't work on windows yet <gjanssens>And that was particularly in the area of unicode support :( <lloda>so... what is the status of master? any 'known not to work' issues? are all the tests using the interpreter? only some? how do I force the compiler to be used? <mark_weaver>(defined in test-suite/test-suite/lib.scm and used in various places in tests/*.scm) <mark_weaver>actually, we really should use c&e for a lot more of our tests. we've had bugs that only affected our compiler that would have been detected if we used c&e more often. <mark_weaver>though I guess we should be somewhat selective, to avoid a lot of wasted duplication of tests. <lloda>hm, it doesn't seem like I can just replace with-test-prefix by with-test-prefix/c&e, different syntax clauses. It would be useful to make them interchangeable. <lloda>the risk of letting bugs through seems to me to be way worse than the risk of making the test suite slower, specially when we're switching the foundations as in 2.0 -> 2.2. *civodul browses this year's Guile-Emacs thread <civodul>too bad bipt is absent from the discussion <Profpatsch>Guile is still missing package management afaik. <Profpatsch>davexunit: Is there a 1:1 mapping of guix files <-> nix files? <davexunit>I'm somewhat joking, but somewhat serious. guix is a general purpose package manager written in guile, so it has a bunch of guile libraries packaged. <davexunit>there's something called the "guildhall" that aims to be a guile specific package manager. <Profpatsch>I was about to propose basing a Guile package manager on nix instead of reinventing package management yet another time again. <ijp>davexunit: I've not touched it in months <Profpatsch>Where that leads is seen when you look at: Python, Haskell (cabal-hell), Ruby, JS, pick-random-language. <Profpatsch>davexunit: I see why one wants to have Scheme-based syntax, but is there a transpiler to nix? <Profpatsch>B/c I seriously think nix is going to have big momentum. <davexunit>we use the nix daemon, but we replace the programming language, command line tools, etc. <civodul>we replace the build-side tools as well <civodul>where Nixpkgs uses Bash, Perl, etc., Guix uses Scheme <Profpatsch>So simply creating packages for natix nix systems and then mapping that to %load-path should be enough to have nearly perfect package management. <Profpatsch>Plus it eliminates the need for manual tranlation for at least one package manager. <civodul>Nix language package definitions can only be translated to Guix on the surface <civodul>because a Nix package includes Bash snippets, typically <Profpatsch>Which kind of scripts you put in it doesn’t matter, because in the end you normally call userspace programs (cp, install, make). <Profpatsch>perl -e, guile -c, python -c, should be all the same to package management, right? <Profpatsch>Except nix does some kind of magic other than a chroot <civodul>Guix does the same, using the same code ;-) <Profpatsch>If you want to install a guile package, you should have guile already installed (b/c dependency), so that shouldn’t be a problem. <davexunit>yeah, our builders are written in guile instead of bash. <Profpatsch>For user local packages, strip the %load-path, so they land in .cache/guile-packages/ or somthing, instead of .cache/guile-packages/%load-path. <Profpatsch>That should be enough to make guile package management work. <Profpatsch>Optional: Create a transpiler, that enables a 1:1 mapping of nix config files to scheme config files, so that everything can be written in scheme/nix and automatically works for the other. <Profpatsch>Nix already has project-local config files afaik (like leiningens project.clj), so not even that has to be written. <davexunit>a transpiler is non-trivial, it would be *really* hard to write, and a waste of time, imo. <davexunit>Guix will have project local config files soon enough. I am going to write the code that does it. <civodul>to put it differently, he's difficult to work with... <ft>I have no idea where he takes the time for all this. I mean, he's on many lists and never gives in. <mark_weaver>maybe I should have just ignored his initial message. <mark_weaver>now he's brought up some of the functionality that wingo removed recently from stable-2.0. <mark_weaver>and of course the curried-definitions thing, which was admittedly a huge blunder on our part. <civodul>i don't get what's gained by shooting at the project <mark_weaver>this won't end until he has called attention to every mistake we've made. <ft>Nothing at all, unless you're *reall* thick-skinned and are able to distill useful critisism from all the rage. <mark_weaver>wingo told me once (maybe when I was trying to defend David, long ago) that he had a very demotivational effect when he's like this, and now I'm really feeling that. <civodul>i think it's best to ignore his comments in this thread now <mark_weaver>I wonder if his own contributions are more or less than the contributions his behavior has inhibited. <civodul>he has some points, we made mistakes, and we need to address them <civodul>but he's basically gratuitously agressive <civodul>and it's interesting to see how this whole conversation ignores the broader GNU project <ft>so guile needs a Rambo-like guy on the maintenance-team to battle in these sorts of threads. :) <ft>civodul: Yeah, I'm not fully serious about that. :) <wingo>agreed re: people judging by themselves -- the situation is pretty obvious <wingo>anyway elisp is never going way, will always be the main thing within emacs, and the right way in for guile is simply to be a better elisp, so that these arguments are useless anyway <civodul>i think it's especially pointless to argue in a speculative discussion, which is what it is <davexunit>I feel like a lot of people don't understand that using guile doesn't mean using scheme instead of elisp. <civodul>i mean, when bipt posts a merge request on emacs-devel, then we can argue :-) <mark_weaver>And now Ian Grant is insulting me on guile-devel, as if I don't know my ass from my elbow. *davexunit was waiting for this to come up <mark_weaver>I've taken enough abuse for one day, time for something else. <ijp>he seems to post a lot about things that are not guile development <civodul>yeah he's probably knowledgeable, but just off-topic and aggressive <davexunit>mark_weaver: yeah, do something rewarding/relaxing. :) <davexunit>mark_weaver: to counter all of this negativity, I think your work (and of course wingo's and civodul's) on guile is outstanding. <davexunit>I can see clearly how healthy this project is and how important to GNU it is or should be. *wingo also really appreciates mark_weaver's work <ijp><ijp> validate mark_weaver <fsbot`> mark_weaver: you are a special human being, and your life choices are reasonable and matter to me very much <paroneayea>sorry, I was trying to start a "get people excited about guile and emacs!" thread <davexunit>paroneayea: it's not your fault. :) stefan's response made it to a bunch of subreddits and HN <rlb>dsmith-work: you too <paroneayea>unfortunately negativity almost always gains more attention than anything else <davexunit>yeah, it's been disheartening to read the unjustified dislike of guile *gjanssens also appreciates the work you guys spend on guile :) <paroneayea>even though I'm a guile noob and primarily a python hacker these days, I'm very excited abou the direction it has been moving and the role it plays in the gnu project :) <paroneayea>and I think if we do have a guilemacs future, that would be amaaaaazing <davexunit>people on HN ask: "why not use llvm or lua?" :P *rlb vaguely wondered if to what extent emacs could get away with persistent structures (wrt concurrency issues) <dsmith-work>Guile has come a long way since it's beginnings. And is growing still. <dsmith-work>Hard decisions sometimes need to be made (deprectations and stuff). <dsmith-work>The guile devs need to strike a balance with correctness, bogus code, and backwards compatability. *dsmith-work goes back to convinicing the ADC converter in a PIC to read the actual analog inputs instead of Vref... <Profpatsch>What strikes me as a beginner is that it’s not very friendly to learn. I should probably write up how to get started. <Profpatsch>The manual is very intimidating (800+ pages). I fortunately found out that it’s a good idea to read R5RS first. <Profpatsch>Like: What should I read first, then what after that … <davexunit>I've been using guile for 2 years now, but I remember being pretty satisfied with the manual. <Profpatsch>Maybe it’s the ideas of Scheme and the fact that it is one of the rare cases where the specs are as good as a manual. <Profpatsch>Normally you first have to google for a tutorial because the specs are utterly horrible to read and even more so to understand. <davexunit>I think that an attractive complete beginner's guide would be cool. <ijp>Profpatsch: you and I will have to differ on this <Profpatsch>I found it to be highly entertaining, concise and informative. <ijp>it's concise because it is underspecified <Profpatsch>Yet, I’m a programming language freak and have look at quite a few now. So things like: does '() evaluet to #f or #t intriuge me. <Profpatsch>ijp: With underspecified you mean all the functions that have no specified return value? <paroneayea>davexunit: the manual is great, assuming you have some other way to learn scheme :) <Profpatsch>Can you program Scheme without relying on something not specified in R5RS? <ijp>Profpatsch: open a file <ijp>SRFIs are not standards <ijp>secondly, there are none for file handling <ijp>Profpatsch: what does (+ (values 1 2)) do? <davexunit>paroneayea: I thin a separate, approachable, beginner's tutorial would be great to have. <ijp>how do you make a new type? you can't <Profpatsch>ijp: That’s quite a big hole, yet input/output that exceeds stdin/stdout/stderr is not really necessary for a minimal spec. <ijp>how do you organise code? load? that isn't even defined for macros <ijp>Profpatsch: the minimal core isn't even well defined <ijp>Profpatsch: what numeric support does a *standards compliant* scheme need? <ijp>this is numbers, not some high faluting ivory tower concept like io <ijp>Profpatsch: which subset <ijp>hint: it can be the empty subset <Profpatsch>I know as Scheme user that I have to check with my implementation. <ijp>as long as you don't provide vectors, you don't actually need to implement numbers <ijp>Profpatsch: checking your implementation is the exact opposite of what a standard is for <Profpatsch>ijp: You have to implement vectors if you want to implement R5RS. <ijp>Profpatsch: yes, but you can set an arbitrary size limit of 0 on vectors <Profpatsch>ijp: I don’t agree with that. A standard should clearly specify things that should be standard. And it should tell which are not. <Profpatsch>And in a manner that is very well-defined. That’s good. <ijp>it's just that most of the behaviours that are important are undefined <Profpatsch>It should leave not much room for interpretation. <Profpatsch>Stating that some things are undefined leaves no room for interpretation. <ijp>if you actually only to use what is carefully defined by the r5rs, you'll never write anything of value <Profpatsch>In fact, yes, you should be able to bootstrap yourself from there. <Profpatsch>You have stdin/stdout, numbers (or a subset), eval, read, write, display and macros. <ijp>Profpatsch: what if the file already exists? <ijp>Profpatsch: if you don't open, you don't have files <ijp>Profpatsch: can you do binary IO? (think about it) <Profpatsch>Which should be all you need for further bootstrapping. <Profpatsch>The cool thing with that is that in the future, there might not even be files. <ijp>the answer is no, because you can't use read-char + char->int ***karswell` is now known as karswell
<ijp>char->number is only defined on the same chars as char<? namely A-Za-z0-9 (and note that you can only compare within those ranges, not across them) <ijp>Profpatsch: in the future we may not have to write programs at all, but that won't help you now <ijp>Profpatsch: (equal? "baz" (let ((a "bar")) (string-set! a 2 #\\z) a)) <ijp>Profpatsch: btw, I can play this game all day, I've had a lot of practice :) <ijp>the answer is #f per the standard, but more ambiguous in practice, since most people don't actually implement the standard behaviour <Profpatsch>ijp: You mustn’t change strings that have been specified literally. :) <ijp>which leads to the second point, the (beautiful! gem! 50 page!) standard is not faithfully implemented by *any* scheme <Profpatsch>ijp: Yet, that’s not the problem of the standard. <Profpatsch>Case in point, do you thing it would be implemented better if it was *longer*? <ijp>Profpatsch: I don't think schemers genuinely care about implementing their standard <ijp>they want to argue about it, they like to pretend it matters, but it doesn't <ijp>me, I just hate unspecified behaviour <ijp>about the only good standard out there is the standard ml one <ijp>hmm, here's one I hadn't noticed before "(let ((n (+ 2 3))) (eq? n n)) => unspecified" <ijp>Profpatsch: eqv? works here, but I thought eq? was specified for the (let ((a foo))(eq? a a)) case <Profpatsch>Nah, I think eq? doesn’t even work for (eq? 2 2) <ijp>a similar case for eqv? with functions was considered controversial in r6rs <Profpatsch>I still don’t see how this is a bad thing. One has to know what functions one is about to use, and if one uses eq? for things it is not specified for then it’s one’s own fault. <ijp>Profpatsch: yet *everyone* does <Profpatsch>Besides: premature optimisation is the root of all evil. <ijp>I can't make everyone use eqv? or equal? <wingo>i have been absent and to a degree this is my fault i think <wingo>has ian grant contributed anything positive to guile? <wingo>he has had ample time afaics *wingo leans towards banning from project <ijp>offer a caution to stay ontopic first <ijp>unless he's been insulting regularly (I haven't been paying attention) <Profpatsch>mark_weaver was leading dev in the export of PGP out of the US? Holy crap. <ijp>yeah, but he likes to hunt baby seals, so it's not all good <ijp>.oO(if you believe that, you'll believe anything) <Profpatsch>ijp: I couldn’t read any irony in the mail, but maybe it went right over my head. <gjanssens>My string/locale experiment on Windows is not doing very well :( <gjanssens>I have tried to write a conversion function in c that converts from utf8 to locale (using g_locale_from_utf8) <gjanssens>The conversion fails with error: invalid byte sequence in conversion input *taylanub is unsure how to feel about Ian Grant's last e-mail <joolean>taylanub: You're one of the smart ones! <joolean>I wonder if he's having some kind of metldown *gjanssens is searching for another way to deal with this <gjanssens>Can I pass a pointer to an open file from C to guile ? <richi235>Well, me too didn't really like the R5RS standard <wingo>gjanssens: i don't think so; well it's possible with a lot of work (defining a new port type) <wingo>gjanssens: what you can do is wrap an already-open file descriptor in a guile port <wingo>but that might not work for you in a windows context <richi235>currently im reading the info pages of the guile-doc package, especially Hello Scheme and Hello Guile <gjanssens>Oh, or I could avoid opening a file in guile altogether by passing the content-to-be as a string into C and have the C code write it out to the file <gjanssens>For some reason in C I can correctly access the file <gjanssens>Alternatively I can retry getting guile 2 to run <richi235>to specify it more clearly "i don't like the R5RS reference pdf as tutorial for learning scheme" <gjanssens>wingo: thanks, I'll abandon the idea of passing a file descriptor directly <gjanssens>My guile foo is definitely not that advanced :) <wingo>it works fine with file _descriptors_, but with pointers to stdio FILE* objects, that doesn't work <wingo>anyway, do the easiest thing :) <Profpatsch>Hrm, `info guile` shows the manual just fine, but there is no node for it in my emacs info tree. <dsmith-work>Profpatsch: emacs and info don't always have the same list of info dirs.