Re: Problems with compilation on Trisquel 5.5
On Wed 02 May 2012 23:15, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >> Some versions of libgc do produce one SIGSEGV at startup, when >> determining certain aspects of the process's memory layout. Just FYI :) > > Woow. :-) Do you know which versions/arches are affected? I don't recall. It's an expected SIGSEGV, not an erroneous one. I get it: Program received signal SIGSEGV, Segmentation fault. 0x7732f4f6 in GC_find_limit_with_bound (p=0x401f4c "", up=0, bound=0x0) at os_dep.c:957 warning: Source file is more recent than executable. 957 GC_noop1((word)(*result)); (gdb) bt #0 0x7732f4f6 in GC_find_limit_with_bound (p=0x401f4c "", up=0, bound=0x0) at os_dep.c:957 #1 0x7732f5f9 in GC_init_linux_data_start () at os_dep.c:472 #2 0x7732df53 in GC_init () at misc.c:899 #3 GC_init () at misc.c:643 #4 0x77ee59ed in scm_storage_prehistory () at gc.c:639 Regards, Andy -- http://wingolog.org/
Re: Problems with compilation on Trisquel 5.5
Andy Wingo skribis: > On Wed 02 May 2012 23:15, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo skribis: >> >>> Some versions of libgc do produce one SIGSEGV at startup, when >>> determining certain aspects of the process's memory layout. Just FYI :) >> >> Woow. :-) Do you know which versions/arches are affected? > > I don't recall. It's an expected SIGSEGV, not an erroneous one. Aaah, OK, makes sense. Thanks, Ludo’.
Re: [PATCH] Turn on more documentation
Replying to myself, I've attached two more patches, which document two more modules. The approach I've been taking is to take the comments that modules already have and convert them to the documentation format that (texinfo reflection) understands. If people agree that this is a good approach, there are a few more modules I can convert easily, but I'd like to check that we want to use this approach before doing a lot of work and getting out of sync with the main repository. I can say more about the tradeoffs if anyone is interested, but I think this is the right choice because we can use it right now. Other options would give prettier documentation, but would be more work. Noah On Wed, May 2, 2012 at 11:20 PM, Noah Lavine wrote: > Hello all, > > As part of my investigation into modules that don't have > documentation, I discovered that several modules in ice-9/ actually > have usable documentation that we are just not using in our build > process. (For reference, everything in the "Standard Library" section > of the manual is snarfed from .scm source files.) This patch makes > Guile build documentation for (ice-9 binary-ports), (ice-9 > common-list), (ice-9 documentation), (ice-9 gap-buffer), (ice-9 runq), > (ice-9 serialize), and (ice-9 time). It gets incorporated into the > manual as part of the "Standard Library" section. > > This seems like an easy way to get documentation for a few more > modules. What do you think? > > (You may have to do "rm doc/ref/standard-library.texi && rm > doc/ref/guile.info*" in order to build with the change. The makefile > doesn't know about all of the dependencies that it should.) > > I also discovered while working on this that several modules have > in-line commentary and also hand-written texinfo pages. The list is > expect.scm, ftw.scm, futures.scm, getopt-long.scm, i18n.scm, > optargs.scm, q.scm, regex.scm, threads.scm, and vlist.scm. Was there a > reason for this? Perhaps the inline documentation format isn't as > flexible as writing it by hand? > > Thanks, > Noah 0001-Document-ice-9-and-let-star.patch Description: Binary data 0002-Document-ice-9-calling.patch Description: Binary data
Re: Patches for module/ice-9/occam-channel.scm
Hello, Thanks a lot for submitting them! Micro-commits are exactly what we want. These patches raise an interesting issue. I do not use occam-channel, and in fact I have no idea what it does since it has no documentation and no tests. Normally I only reply to emails if I think I know enough to give an intelligent response, but in this case no one else is replying either. This might be wrong, but it's entirely possible that no one except you on this list has any way to check that these are correct. (Or if they do, the people who know are not replying.) So I propose this: if no one replies to this email in two days, I will merge the patches. And I hate to ask you for more after you've already contributed, but if you are able, could you write some documentation or tests for this module? It could badly use both of those things. Thanks a lot, Noah On Mon, Apr 30, 2012 at 8:42 AM, Daniel Krueger wrote: > Hi, > > I've done some work on (ice-9 occam-channel) and fixed the module > exports, the alt macro and extended it a little bit. Here are the > patches, but they are all just micro-commits, I hope that is okay. > > - Daniel
Re: Patches for module/ice-9/occam-channel.scm
Well, I think it's something like Actors but little different. And I think it would be nice if there's a document for it. On Fri, May 4, 2012 at 10:58 AM, Noah Lavine wrote: > Hello, > > Thanks a lot for submitting them! Micro-commits are exactly what we want. > > These patches raise an interesting issue. I do not use occam-channel, > and in fact I have no idea what it does since it has no documentation > and no tests. Normally I only reply to emails if I think I know > enough to give an intelligent response, but in this case no one else > is replying either. This might be wrong, but it's entirely possible > that no one except you on this list has any way to check that these > are correct. (Or if they do, the people who know are not replying.) > > So I propose this: if no one replies to this email in two days, I will > merge the patches. > > And I hate to ask you for more after you've already contributed, but > if you are able, could you write some documentation or tests for this > module? It could badly use both of those things. > > Thanks a lot, > Noah > > On Mon, Apr 30, 2012 at 8:42 AM, Daniel Krueger > wrote: >> Hi, >> >> I've done some work on (ice-9 occam-channel) and fixed the module >> exports, the alt macro and extended it a little bit. Here are the >> patches, but they are all just micro-commits, I hope that is okay. >> >> - Daniel >
