Likely bug: SMOBs and mark functions [Was: Re: [bug #30480] VM: load looks for files in the wrong directory]

2011-02-15 Thread Luca Saiu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/2011 07:51 PM, Andy Wingo wrote: > Update of bug #30480 (project guile): > Fixed, by turning load into a macro that expands to a call to > load-in-vicinity. Nasty or awesome? We report, you decide! Awesome :-). This solves the load problem

Re: Likely bug: SMOBs and mark functions [Was: Re: [bug #30480] VM: load looks for files in the wrong directory]

2011-02-15 Thread Luca Saiu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/15/2011 12:59 PM, Luca Saiu wrote: > The current thread is at (nil); Segmentation fault Don't worry about the "The current thread is at (nil); ". That was the output of my debug printf :-), which I forgot to delete in that one case. Testing ag

Re: Likely bug: SMOBs and mark functions [Was: Re: [bug #30480] VM: load looks for files in the wrong directory]

2011-02-15 Thread Ludovic Courtès
Hi Luca! Luca Saiu writes: > I've reproduced the problem by using the example in > doc/example-smob/ > which is much simpler than my own code; the failure is identical. > > [luca@optimum > ~/projects-by-others/guile-from-git-mainline/doc/example-smob]$ ./myguile > GNU Guile 1.9.15.114-b81eb >

Re: Typos in the manual

2011-02-15 Thread Marijn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 02/13/11 08:00, Ralf Wildenhues wrote: > Hi Neil, > > * Neil Jerram wrote on Sun, Feb 13, 2011 at 01:49:43AM CET: >> Ralf Wildenhues writes: >>> --- a/doc/ref/compiler.texi >>> +++ b/doc/ref/compiler.texi >>> @@ -855,7 +855,7 @@ for more infor

Re: Likely bug: SMOBs and mark functions [Was: Re: [bug #30480] VM: load looks for files in the wrong directory]

2011-02-15 Thread Luca Saiu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Hello Ludovic, Andy, and all :-)). On 02/15/2011 04:38 PM, Ludovic Courtès wrote: > I can’t reproduce the problem on x86_64-linux-gnu with a recent CVS > snapshot of libgc. Which libgc do you use? 7.2.4, compiled from sources; I think I've enabled

Re: Typos in the manual

2011-02-15 Thread Mark Harig
>>> --- a/doc/ref/compiler.texi >>> +++ b/doc/ref/compiler.texi >>> @@ -855,7 +855,7 @@ for more information about the Brainfuck language itself. >>> At this point, we break with the impersonal tone of the rest of the >>> manual, and make an intervention. Admit it: if you've read this fa

Re: Typos in the manual

2011-02-15 Thread Mark Harig
> - Some abbreviations are spelt creatively. The Latin 'id est' is > usually abbreviated 'i.e.' without an intervening space, and for good > spacing you either need a comma right afterwards, or '@:'. Same with > 'e.g.'. Find lots of instances with: > git grep '\<[Ii][. ]*e\.[^,@

Re: Typos in the manual

2011-02-15 Thread Ralf Wildenhues
Hello Mark, * Mark Harig wrote on Tue, Feb 15, 2011 at 09:48:24PM CET: > Both "i.e." and "e.g." should always be followed by a comma. Well. Let me tell you. I've written those kinds of patches before, adding a comma unconditionally and all. After a few maintainers of some packages rejected the

Re: Typos in the manual

2011-02-15 Thread Mark Harig
> Both "i.e." and "e.g." should always be followed by a comma. Well. Let me tell you. I've written those kinds of patches before, adding a comma unconditionally and all. After a few maintainers of some packages rejected them, I've become less enthused. Something that's long been a mystery

Re: Typos in the manual

2011-02-15 Thread Neil Jerram
Marijn writes: > Reading the quoted text I can't help but wonder what a "sublimated > desire" is. According to wiktionary "sublimated" is the past tense of > "sublimate" which has 3 meanings[1] none of which I recognize as the > intended meaning. Perhaps "subliminal desire"[2] is meant, that is,

Re: Typos in the manual

2011-02-15 Thread Neil Jerram
Mark Harig writes: > Likewise, "make an intervention" implies that the author intends to > intervene or stop or prevent something. But the author is not hoping > to stop compiler junkies from continuing their habit of writing code > for compilers -- to the contrary. Given the text that follows

Re: Typos in the manual

2011-02-15 Thread Neil Jerram
Mark Harig writes: >> >> > Both "i.e." and "e.g." should always be followed by a comma. >> >> Well. Let me tell you. I've written those kinds of patches before, >> adding a comma unconditionally and all. After a few maintainers of >> some packages rejected them, I've become less enthused. >> >

Re: Typos in the manual

2011-02-15 Thread Mark Harig
> Likewise, "make an intervention" implies that the author intends to > intervene or stop or prevent something. But the author is not hoping > to stop compiler junkies from continuing their habit of writing code > for compilers -- to the contrary. Given the text that follows this > phrase, "

guile make error

2011-02-15 Thread Fu-Gangqiang
Hi,all, Today, I built guile from Git repository, but have some warnings and 2 errors. warnings and errors : ->cut here:start<- gc.c: In function 'scm_gc_dump': gc.c:333: warning: implicit declaration of function 'GC_dump' memoize.c:478:***Mismatching FUNC_NAME. Should be: `#define FUNC_N

Re: Typos in the manual

2011-02-15 Thread Mark Harig
>> Also, while the Chicago Manual of Style recommends it, some other > online >> grammar sites mention that it is American English style, but British >> English would not add a comma afterwards. My feeling is consistent with that. I'm British, and I'd say there are lots of cases where it

Re: Typos in the manual

2011-02-15 Thread Mark Harig
Some of the discussion below was getting too far off-topic from the question of whether to follow "i.e." and "e.g." with commas in all instances or not to follow "i.e." and "e.g." with commas in any instance, so I have written a response in a separate message. >> >> > Both "i.e." and "e.g." s