Re: Infinite loop with GCC 4.3

On Wed, May 28, 2008 at 3:15 PM, Joe Neeman <joeneeman <at> gmail.com> wrote:
> On Wed, 2008-05-28 at 11:02 -0300, Han-Wen Nienhuys wrote:
>> Could someone put this into a init_fpu() function with appropriate
>> #ifdefs, and call that from main() ?
>
> Done.

Hi Joe,

I am still experiencing this infinite loop after your fix.  However,
if I remove the #ifdef structure and keep the function and function
call, the latest git build runs successfully.  Using the
--disable-optimising option with ./autogen.sh also works, but of
course LilyPond runs more slowly.

The autogen.sh script detects my machine as "i686-pc-linux-gnu", if
that makes a difference.

Thanks,
Patrick

Re: Infinite loop with GCC 4.3

On Sat, 2008-05-31 at 20:20 -0700, Patrick McCarty wrote:
> On Wed, May 28, 2008 at 3:15 PM, Joe Neeman <joeneeman <at> gmail.com> wrote:
> > On Wed, 2008-05-28 at 11:02 -0300, Han-Wen Nienhuys wrote:
> >> Could someone put this into a init_fpu() function with appropriate
> >> #ifdefs, and call that from main() ?
> >
> > Done.
> 
> Hi Joe,
> 
> I am still experiencing this infinite loop after your fix.  However,
> if I remove the #ifdef structure and keep the function and function
> call, the latest git build runs successfully.

Does it work if you change __x86__ to x86 in the #ifdef?

Re: Infinite loop with GCC 4.3

On Sat, May 31, 2008 at 8:30 PM, Joe Neeman <joeneeman <at> gmail.com> wrote:
> On Sat, 2008-05-31 at 20:20 -0700, Patrick McCarty wrote:
>>
>> Hi Joe,
>>
>> I am still experiencing this infinite loop after your fix.  However,
>> if I remove the #ifdef structure and keep the function and function
>> call, the latest git build runs successfully.
>
> Does it work if you change __x86__ to x86 in the #ifdef?

No, it doesn't.  Attached is the patch I just tried to use against the
latest git, just in case I missed something.

Thanks,
Patrick

diff -ru lily/lily/main.cc lily-build/lily/main.cc
--- lily/lily/main.cc	2008-05-31 16:05:13.000000000 -0700
+++ lily-build/lily/main.cc	2008-05-31 20:32:06.000000000 -0700
 <at>  <at>  -172,7 +172,7  <at>  <at> 
    unpredictable places. To get around this, we tell the x87 FPU to use only
    double precision. Note that this is not needed for x86_64 because that uses
    the SSE unit by default instead of the x87 FPU. */
-#ifdef __x86__
+#ifdef x86

 #include <fpu_control.h>
 static void configure_fpu() {

Re: Infinite loop with GCC 4.3

On Sat, 2008-05-31 at 21:11 -0700, Patrick McCarty wrote:
> On Sat, May 31, 2008 at 8:30 PM, Joe Neeman <joeneeman <at> gmail.com> wrote:
> > On Sat, 2008-05-31 at 20:20 -0700, Patrick McCarty wrote:
> >>
> >> Hi Joe,
> >>
> >> I am still experiencing this infinite loop after your fix.  However,
> >> if I remove the #ifdef structure and keep the function and function
> >> call, the latest git build runs successfully.
> >
> > Does it work if you change __x86__ to x86 in the #ifdef?
> 
> No, it doesn't.  Attached is the patch I just tried to use against the
> latest git, just in case I missed something.

What if you change __x86__ to __i386__? (Sorry to turn you into a guinea
pig, but I don't have an array of different x86 configurations at my
disposal).

Joe

Re: Infinite loop with GCC 4.3

On Sat, May 31, 2008 at 10:29 PM, Joe Neeman <joeneeman <at> gmail.com> wrote:
>
> What if you change __x86__ to __i386__? (Sorry to turn you into a guinea
> pig, but I don't have an array of different x86 configurations at my
> disposal).

Great!  Changing it to __i386__ works for me.  Thanks a lot, Joe!

-Patrick

Re: Detailed plan for documentation translations

On 2008/05/31, Graham Percival wrote:
> > unfretted-strings.itely
> > fretted-strings.itely
> 
> Could be changes to these.  I told people to work on subsections
> inside the existing structure, but that we could discuss
> rearranging them further after they're done.
> 
> > percussion.itely
> > wind.itely
> > ancient.itely
> 
> IIRC these haven't been touched yet, so any section changes
> probably won't happen for at least two months.
> 
> > chords.itely
> 
> There may be further changes to these headings.

Whatever further changes that may happen in sectioning, we must follow
the current structure of English docs even if it's temporary, because
it's already much better than titles like "Chords fix TODO" or "Guitar
sections FIXME".

Cheers,
John

Re: Infinite loop with GCC 4.3

On Sun, 2008-06-01 at 00:07 -0700, Patrick McCarty wrote:
> On Sat, May 31, 2008 at 10:29 PM, Joe Neeman <joeneeman <at> gmail.com> wrote:
> >
> > What if you change __x86__ to __i386__? (Sorry to turn you into a guinea
> > pig, but I don't have an array of different x86 configurations at my
> > disposal).
> 
> Great!  Changing it to __i386__ works for me.  Thanks a lot, Joe!

I've pushed a fix to git. Please complain if it doesn't work.

Cheers,
Joe

Re: Bugtracker cleanup/update

On 2008/05/30, Graham Percival wrote:
> Slight update from my "you'd have to be crazy..." comment: how
> about we have a two-month "beta releases" period?  We're
> occasionally criticized for not doing this anyway, and if the code
> is stable but the docs need more work, calling it a "beta" sounds
> like a great match.

I propose to announce releases as beta as soon as texi2html is used on
master.

Cheers,
John

Re: Bugtracker cleanup/update

On 2008/05/31, Graham Percival wrote: 
> On Sat, 31 May 2008 09:28:50 +0200
> John Mandereau <john.mandereau <at> gmail.com> wrote:
> 
> > An unsure question is, should big doc work like GDP go on on master
> > after 2.12?
> 
> No, because barring a miracle, there won't be anybody[1] left to do
> big doc work.

It's almost sure that there won't be one person alone left that will
have enough time and energy to do as much as you do, but I hope we are
enough people to be able to make GDP live for a few months after you've
gone.  If this is productive enough, I may want to manage doc
contributions in various formats (patch, plain file, ...) as you're
doing.  The detail I'm afraid of is the amoount of time spent in
answering time-consuming or a lot of questions via email; if we can
share the emails load between several people, this would be viable.

> * the one caveat is docs about programming in scheme; I believe
> that Trevor would like to rewrite that chapter.  I highly
> doubt that we'll get to that stage during GDP... but it will be
> easy enough to backport an entire .itely file to stable when he's
> done.

Scheme programming and Application Usage are kind of big doc work, and
it could be productive to do at least the latter under GDP.

Cheers,
John

Re: Bugtracker cleanup/update

On Sun, 01 Jun 2008 11:33:56 +0200
John Mandereau <john.mandereau <at> gmail.com> wrote:

> It's almost sure that there won't be one person alone left that will
> have enough time and energy to do as much as you do, but I hope we are
> enough people to be able to make GDP live for a few months after
> you've gone.

The basic problem is that reviewing, discussing, fixing, and
committing doc updates from other people takes longer than it
would to do it from scratch yourself.  For the first month or two
for each contributor, at least.  And assuming that you're skilled
with git, the doc policies, etc -- which you need to be in order
to review the changes in the first place.

Also, contributors understandably like to get feedback and see
their changes ASAP, especially those that can't build the docs
themselves.  This means that you have an unpredictable workload...
a week and a half ago I spent 4 hours just dealing with updated
.itely files.  And that was /all/ new material that day; it wasn't that
I let work pile up.

It makes sense to do this if you want to train the next generation
of contributors, but I think we've managed this.  If the goal is
simply to improve the docs, it would be better for you (or whoever
might manage GDP) to simply edit the files themselves.  Especially
since AU and scheme are advanced topics anyway -- you can't just
call on any random user to rewrite the docs on lilypond-book, for
example.