headers
Robert Goldman | 2 Jun 2010 15:19

Re: Proposed documentation patch

On 5/30/10 May 30 -10:28 AM, Christophe Rhodes wrote:
> Robert Goldman <rpgoldman <at> sift.info> writes:
> 
>> I'm enclosing a patch file that adds docstrings to
>> sb-ext:disable-debugger and sb-ext:enable-debugger.
>>
>> It also adds these functions (and some other information about the
>> debugger) to the function and concept indices.
>>
>> This is all intended to make it easier to find information about
>> controlling the debugger.
> 
> Thanks.  I've merged something like this into a branch for improving the
> manual that I hope to commit to CVS sometime soon (this month, rather
> than this year :-)
> 
>> The only oddity I can see in the patch file is that when I ran the emacs
>> texinfo mode command to update every node, it added previous and next
>> links to nodes in the debugging texinfo file that didn't have them.  As
>> far as I can tell, those links are correctly computed, so I left them in.
>>
>> I'm not entirely sure of the patch submission procedure.  Please let me
>> know if this one is not prepared properly, and I will try to fix it.
> 
> Well, ideally not having a whole bunch of noise in the patch would have
> been good -- I know emacs put them there, and I know that they were
> "right", but they still made it hard to see what you were actually
> adding.

Sorry about that.  I understand and sympathize, but I confess to not
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christophe Rhodes | 2 Jun 2010 15:35
Favicon

Re: Proposed documentation patch

Robert Goldman <rpgoldman <at> sift.info> writes:

> Sorry about that.  I understand and sympathize, but I confess to not
> knowing how to avoid this in the future.  Hand-editing the Node lines is
> not just a big nuisance, but is also very error-prone, and there's no
> way that I know of to leash emacs and tell it to minimize its
> modifications.

I'm not sure where the node lines come from, or why Emacs wants to put
in all those (apparently unnecessary?) extra arguments.  Anyway.

> I suppose if I were to do this again with git, instead
> of with CVS, I could give two separate patches, one for the text, and
> one for the node-shuffling.  That's the best I can think of.  Perhaps
> someone on the list can suggest something better.

Git and selectively including bits of patch is one way; you can also
edit the diff with emacs' diff mode, and it generally gets updating all
the diff metadata at least approximately right.

Cheers,

Christophe

------------------------------------------------------------------------------
Permalink | Reply | 3 comments |
headers
Robert Goldman | 2 Jun 2010 15:44

Re: Proposed documentation patch

On 6/2/10 Jun 2 -8:35 AM, Christophe Rhodes wrote:
> Robert Goldman <rpgoldman <at> sift.info> writes:
> 
>> Sorry about that.  I understand and sympathize, but I confess to not
>> knowing how to avoid this in the future.  Hand-editing the Node lines is
>> not just a big nuisance, but is also very error-prone, and there's no
>> way that I know of to leash emacs and tell it to minimize its
>> modifications.
> 
> I'm not sure where the node lines come from, or why Emacs wants to put
> in all those (apparently unnecessary?) extra arguments.  Anyway.

The node lines are necessary for using the texinfo files to generate
emacs-readable info files.  They aren't used in the Tex processing.  I
don't know if they are used in HTML processing.

I'm not sure what you mean by "extra arguments".  do you mean the lines
like this:

- <at> node Debugger Entry
+ <at> node Debugger Entry, Debugger Command Loop, Debugger, Debugger

If so, those aren't extra arguments --- those specify the next node,
previous node, and parent node for navigation when reading with emacs or
command-line info programs.

So it really /is/ The Right Thing to have those lines in there; the
arguments are essential and not unnecessary.

best,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christophe Rhodes | 2 Jun 2010 16:45
Favicon

Re: Proposed documentation patch

Robert Goldman <rpgoldman <at> sift.info> writes:

> On 6/2/10 Jun 2 -8:35 AM, Christophe Rhodes wrote:
>> Robert Goldman <rpgoldman <at> sift.info> writes:
>> 
>>> Sorry about that.  I understand and sympathize, but I confess to not
>>> knowing how to avoid this in the future.  Hand-editing the Node lines is
>>> not just a big nuisance, but is also very error-prone, and there's no
>>> way that I know of to leash emacs and tell it to minimize its
>>> modifications.
>> 
>> I'm not sure where the node lines come from, or why Emacs wants to put
>> in all those (apparently unnecessary?) extra arguments.  Anyway.
>
> The node lines are necessary for using the texinfo files to generate
> emacs-readable info files.

They're just not, though.  They might have been once, but the info files
generated without these entries work (as far as I can tell) fine for
navigation with info and emacs.

> I'm not sure what you mean by "extra arguments".  do you mean the lines
> like this:
>
> - <at> node Debugger Entry
> + <at> node Debugger Entry, Debugger Command Loop, Debugger, Debugger

Yes.

Cheers,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Goldman | 2 Jun 2010 16:57

Re: Proposed documentation patch

On 6/2/10 Jun 2 -9:45 AM, Christophe Rhodes wrote:
> Robert Goldman <rpgoldman <at> sift.info> writes:
> 
>> On 6/2/10 Jun 2 -8:35 AM, Christophe Rhodes wrote:
>>> Robert Goldman <rpgoldman <at> sift.info> writes:
>>>
>>>> Sorry about that.  I understand and sympathize, but I confess to not
>>>> knowing how to avoid this in the future.  Hand-editing the Node lines is
>>>> not just a big nuisance, but is also very error-prone, and there's no
>>>> way that I know of to leash emacs and tell it to minimize its
>>>> modifications.
>>>
>>> I'm not sure where the node lines come from, or why Emacs wants to put
>>> in all those (apparently unnecessary?) extra arguments.  Anyway.
>>
>> The node lines are necessary for using the texinfo files to generate
>> emacs-readable info files.
> 
> They're just not, though.  They might have been once, but the info files
> generated without these entries work (as far as I can tell) fine for
> navigation with info and emacs.
> 

You are quite right, as witness http://preview.tinyurl.com/ycjjyw
(texinfo manual).

Not sure why emacs's texinfo mode writes all those links --- seems like
makeinfo does the job.  Indeed, writing those links is deprecated....

OK, I'll avoid letting texinfo-mode write the  <at> node lines in the future.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bart Botta | 3 Jun 2010 02:28
Picon

sb-concurrency:queue garbage hard to collect

Using a sb-concurrency:queue in a loop tends to produce large amounts
of uncollectable garbage, for example in

(require 'sb-concurrency)
(progn
 (let ((q (sb-concurrency:make-queue)))
   (loop repeat 10000
      do (sb-concurrency:enqueue (make-array 1234 :element-type
'(unsigned-byte 7)) q)
      count (sb-concurrency:dequeue q))
   (format t "done loop~%")
   (room)
   (format t "~%gc..~%")
   (gc :full t)
   (room))
 (format t "~%out of scope~%")
 (gc :full t)
 (room))

the arrays survive the first GC (tested on x86-64 linux, 1.0.38.6 and
.38.12), and sometimes the second.

Attached patch breaks the links between the garbage nodes so that
conservative GC is less likely to keep all of them alive at once. I
don't really understand the code well enough to tell if that is the
correct place to do so, or if it is even the right thing to do, but it
seems to fix the problem for me, and hasn't broken obviously yet.

-b
(Continue reading)

Permalink | Reply | 0 comments |
headers
Attila Lendvai | 3 Jun 2010 12:22
Picon
Gravatar

1.0.39.3 broke non-darwin builds?

i think 1.0.39.3 broke non-darwin builds.

with the change below i can build it on linux x86_64.

diff --git a/tools-for-build/grovel-headers.c b/tools-for-build/grovel-headers.c
index ce8b6ed..a735b51 100644
--- a/tools-for-build/grovel-headers.c
+++ b/tools-for-build/grovel-headers.c
 <at>  <at>  -39,6 +39,8  <at>  <at> 
   #include <poll.h>
   #ifdef LISP_FEATURE_DARWIN
     #include "../src/runtime/darwin-langinfo.h"
+  #else
+    #include <langinfo.h>
   #endif
   #ifdef LISP_FEATURE_DLSHIM
     #include "../src/runtime/darwin-dlshim.h"

--

-- 
 attila

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Permalink | Reply | 1 comment |
headers
Cyrus Harmon | 3 Jun 2010 21:45

Re: 1.0.39.3 broke non-darwin builds?

Sorry 'bout that. Fixed in 1.0.39.4.

Cyrus

On Jun 3, 2010, at 3:22 AM, Attila Lendvai wrote:

> i think 1.0.39.3 broke non-darwin builds.
> 
> with the change below i can build it on linux x86_64.
> 
> diff --git a/tools-for-build/grovel-headers.c b/tools-for-build/grovel-headers.c
> index ce8b6ed..a735b51 100644
> --- a/tools-for-build/grovel-headers.c
> +++ b/tools-for-build/grovel-headers.c
>  <at>  <at>  -39,6 +39,8  <at>  <at> 
>   #include <poll.h>
>   #ifdef LISP_FEATURE_DARWIN
>     #include "../src/runtime/darwin-langinfo.h"
> +  #else
> +    #include <langinfo.h>
>   #endif
>   #ifdef LISP_FEATURE_DLSHIM
>     #include "../src/runtime/darwin-dlshim.h"
> 
> -- 
> attila
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nikolaus Demmel | 4 Jun 2010 13:32
Picon
Favicon

Posix tests fail on darwin (OS X 10.6)

Hi,

could a maintainer with access to darwin (OS X 10.6) maybe have a look at
https://bugs.launchpad.net/sbcl/+bug/421779 if time allows. There has been a small (and working)
patch around since december but the bug is still unconfirmed. Thank you.

Best regards,
Niko
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Permalink | Reply | 0 comments |
headers
Nikolaus Demmel | 4 Jun 2010 13:35
Picon
Favicon

lexical binding of the symbol (RUN-TESTS::*BREAK-ON-ERROR*)

Hi,

the test suite spits out a lot of these warnings:

; caught STYLE-WARNING:
;   using the lexical binding of the symbol (RUN-TESTS::*BREAK-ON-ERROR*), not the
;   dynamic binding, even though the name follows
;   the usual naming convention (names like *FOO*) for special variables

Should this be worrying or is it to be expected? I'm on darwin (OS X 10.6) and latest checkout (1.0.39.4).

Best regards,
Niko
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Permalink | Reply | 0 comments |

Gmane