commit fb98d6be7ed06969a8eeab7b974e8734d8cd21b1
Author: Han-Wen Nienhuys
Date: Sun Apr 12 13:32:01 2020 +0200
Shortcut Rational addition if either operand is zero
https://codereview.appspot.com/551690046/
Oh, you are right. Thanks for checking!
On Fri, Apr 17, 2020 at 11:49 AM wrote:
>
> On 2020/04/17 09:25:03, hanwenn wrote:
> > I pushed this to staging by accident; sorry.
> >
> > I apparently have no permission to do a force-push.
>
> If you want to, you have to remove :staging and re-create it.
On 2020/04/17 09:25:03, hanwenn wrote:
> I pushed this to staging by accident; sorry.
>
> I apparently have no permission to do a force-push.
If you want to, you have to remove :staging and re-create it. However
the latest Patch Set 3 is only an artifact of rebasing and the
reordering already hap
ional.hh
> >
> > In any case, noting your findings in a concise comment would help
future
> > maintainers avoid erasing your gains.
>
> It's the only one I investigated. The rational addition shows up
because we add
> Moments together in many places. Since those
maintainers avoid erasing your gains.
It's the only one I investigated. The rational addition shows up
because we add Moments together in many places. Since those generally
have grace == 0, it's doing a lot of unwarranted
multiplication/division.
I'll move the zer
LGTM
https://codereview.appspot.com/551690046/diff/573690043/flower/rational.cc
File flower/rational.cc (right):
https://codereview.appspot.com/551690046/diff/573690043/flower/rational.cc#newcode257
flower/rational.cc:257: if (is_infinity ())
The hazard of reviewing this class is that there's al
LGTM. Maybe you can add a comment w.r.t. speed improvement.
https://codereview.appspot.com/551690046/
LGTM
https://codereview.appspot.com/577710043/
LGTM
https://codereview.appspot.com/577710043/
LGTM
https://codereview.appspot.com/577710043/
On 2020/02/25 08:07:14, hanwenn wrote:
> LGTM
>
> (I wonder if we should bite the bullet and use uint64_t iso. U64.)
Just for the record: the big bullet would be a Simple_smob wrapper class
around Guile's rational data type. Showstopper in the current setup:
Moments in data stru
LGTM
(I wonder if we should bite the bullet and use uint64_t iso. U64.)
https://codereview.appspot.com/573570043/
Very nice, thanks! LGTM.
https://codereview.appspot.com/573570043/
LGTM
We probably have quite a number of those leftovers that are completely
irrelevant by now. I almost lean towards stipulating that any code for
pre-Guile-1.8.8 can be removed directly without review, but then if
something does go wrong by accident, we at least have a bit of a trace
to see what
Thanks for the review. I agree with all your points.
https://codereview.appspot.com/581400043/
Frankly, I am disconcerted that the original code runs through a float
conversion in the first place. This is not as much about removing a
warning rather than fixing bad code since the warning had a point.
https://codereview.appspot.com/581400043/diff/577250043/flower/rational.cc
File flower/ra
Andrew Bernard writes:
> Hi David,
>
> Well spotted Sir. The guile 1.8.8 install done by me was in fact half-baked
> as you say, since the documentation did not build,
I think that origin/branch_release-1-8 has been updated to build by
Thien-Thi Ngyen. That's a few commits on top of 1.8.8. Pro
Hi David,
Well spotted Sir. The guile 1.8.8 install done by me was in fact half-baked
as you say, since the documentation did not build, and I was not interested
in that. But allowing make -k install to carry on libguile.h gets copied
and all now works.
Many thanks to your for your great assistan
Andrew Bernard writes:
> From configure:
>
> hecking for guile-config... /usr/local/bin/guile-config
> checking /usr/local/bin/guile-config version... 1.8.8
> checking guile compile flags... -I/usr/local/include -pthread
> checking guile link flags... -pthread -L/usr/local/lib -lguile -lltdl
>
Thanks.
Only guile 1.8.8 in /usr/local. No guile 2 on the system. Debian 9.6.
ldconfig -p output:
ldconfig -p | grep guile
libguilereadline-v-17.so.17 (libc6,x86-64) =>
/usr/local/lib/libguilereadline-v-17.so.17
libguilereadline-v-17.so (libc6,x86-64) =>
/usr/local/lib/libguilereadline-
Andrew Bernard writes:
> I am trying to build lilypond 2.19.82 from the source tarfile on Debian
> 9.6. I built guile 1.8.8 just fine.
>
> Running configure, I am down to one issue:
>
> ERROR: Please install required programs: GUILE-with-rational-bugfix
>
> What i
I am trying to build lilypond 2.19.82 from the source tarfile on Debian
9.6. I built guile 1.8.8 just fine.
Running configure, I am down to one issue:
ERROR: Please install required programs: GUILE-with-rational-bugfix
What is this and how to get it?
I searched the archives but the
metachromatic writes:
If you want an answer, ask a question. Just stating something in the
hope that the correction will work as an answer is trying your luck.
>
>What's the point of asking a question on this forum? The answer
> always seems to be: "Go fix it yourself. Dig into th
>>> If you want an answer, ask a question. Just stating something in the
>>> hope that the correction will work as an answer is trying your luck.
What's the point of asking a question on this forum? The answer
always seems to be: "Go fix it yourself. Dig into the Lilypond code,
and get busy,
Hi Hans,
> On May 23, 2018, at 12:45 PM, Hans Åberg wrote:
>
>> If you want an answer, ask a question. Just stating something in the
>> hope that the correction will work as an answer is trying your luck.
>
> I will try to remember that these are your rules.
In my 34+ years on electronic netw
Hi,
> Let's assume that I'm a moron with a room-temperature IQ and, as
> our friend Kieran McMullen
I assume you mean me, Kieren MacMillan?
> has remarked, "You have no idea what you're talking about."
Could you please remind me where I remarked that?
Thanks,
Kieren.
__
> On 23 May 2018, at 19:32, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> But scm_malloc does not use GC_malloc_uncollectable, it seems, so it
>> too would require explicit markups in order to get internally in
>> Guile.
>
> Getting "internally in Guile" is done by SCM_NEWSMOB. Cf
> lily/
Hans Åberg writes:
>> On 23 May 2018, at 18:58, David Kastrup wrote:
>
>> If you bothered looking at the LilyPond code base, you'll find that _no_
>> STL containers are created containing SCM objects in the expectation
>> that they will automagically marked for garbage collection. Any STL
>> co
> On 23 May 2018, at 18:58, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 18:36, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
> On 23 May 2018, at 18:12, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> I ended up using GC_malloc_uncoll
Hans Åberg writes:
>> On 23 May 2018, at 18:36, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
On 23 May 2018, at 18:12, David Kastrup wrote:
Hans Åberg writes:
> I ended up using GC_malloc_uncollectable, because it turned out too
> tricky to use malloc.
> On 23 May 2018, at 18:36, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 18:12, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
I ended up using GC_malloc_uncollectable, because it turned out too
tricky to use malloc.
>>>
>>> This is C++, so we basica
Hans Åberg writes:
>> On 23 May 2018, at 18:12, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
>>> I ended up using GC_malloc_uncollectable, because it turned out too
>>> tricky to use malloc.
>>
>> This is C++, so we basically end up with operator ::new and operator
>> ::delete unless ove
> On 23 May 2018, at 18:12, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> I ended up using GC_malloc_uncollectable, because it turned out too
>> tricky to use malloc.
>
> This is C++, so we basically end up with operator ::new and operator
> ::delete unless overriden by individual classes.
y
>>>> files and nowadays pretty exclusively encapsulate all Scheme-related
>>>> memory management.
>>>
>>> As long you don't have pointers into that, as you suggested with
>>> Rational and other data that uses it.
>>
>> Look, yo
sively encapsulate all Scheme-related
>>> memory management.
>>
>> As long you don't have pointers into that, as you suggested with
>> Rational and other data that uses it.
>
> Look, you are just stabbing around in the dark here. Quite a few of
> your statement
on't have pointers into that, as you suggested with
> Rational and other data that uses it.
Look, you are just stabbing around in the dark here. Quite a few of
your statements don't even make sense. You need to get yourself
acquainted with the code if you want to get anywhere. Rationa
> On 23 May 2018, at 15:46, David Kastrup wrote:
>
> Try actually reading the code. lily/include/smobs* are not that many
> files and nowadays pretty exclusively encapsulate all Scheme-related
> memory management.
As long you don't have pointers into that, as you suggest
Hans Åberg writes:
>> On 23 May 2018, at 14:34, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
>>> I mentioned that the GC supports traditional allocations/deallocation,
>>> but they must be traced so as to not end up with dead pointers.
>>
>> Hans, please. You are proferring utter trivia
> On 23 May 2018, at 14:34, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> I mentioned that the GC supports traditional allocations/deallocation,
>> but they must be traced so as to not end up with dead pointers.
>
> Hans, please. You are proferring utter trivialities. There is a reason
>
Hans Åberg writes:
>> On 23 May 2018, at 13:10, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
On 23 May 2018, at 12:20, David Kastrup wrote:
... work on "the problem" has moved beyond the stage where one can
just propose a generic solution, everybody slaps his forehea
> On 23 May 2018, at 13:10, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 12:20, David Kastrup wrote:
>>>
>>> ... work on "the problem" has moved beyond the stage where one can
>>> just propose a generic solution, everybody slaps his forehead and
>>> gets to work and d
thread is offspring from an endless row of
>> rather insulting and condescending rants about LilyPond's
>> limited-precision rational numbers and you jump-started...
>
> I started a new thread to get away from that.
>
>> ...a set of lectures on the Boehm GC on it predi
row of rants, and
>> now you fill in with those.
>
> Just as a reminder: this thread is offspring from an endless row of
> rather insulting and condescending rants about LilyPond's
> limited-precision rational numbers and you jump-started...
I started a new thread to get away from t
ts, and
> now you fill in with those.
Just as a reminder: this thread is offspring from an endless row of
rather insulting and condescending rants about LilyPond's
limited-precision rational numbers and you jump-started a set of
lectures on the Boehm GC on it predicated on the premi
> On 23 May 2018, at 11:04, Werner LEMBERG wrote:
>
>> The ultimate in self-assertion is to disagree with those that agree
>> with you.
>
> Hans, such remarks aren't helpful. You sound like you are lecturing.
> Maybe this is not your intention and you have serious questions – if
> this is so,
> The ultimate in self-assertion is to disagree with those that agree
> with you.
Hans, such remarks aren't helpful. You sound like you are lecturing.
Maybe this is not your intention and you have serious questions – if
this is so, please be more careful in formulation.
Werner
_
> On 23 May 2018, at 10:39, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 00:41, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
> On 22 May 2018, at 23:28, David Kastrup wrote:
>
> Hans Åberg writes:
>
I wrote a C++ wrap for that lat
Hans Åberg writes:
>> On 23 May 2018, at 00:41, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
On 22 May 2018, at 23:28, David Kastrup wrote:
Hans Åberg writes:
>>> I wrote a C++ wrap for that latter, too. As it turns out to be
>>> difficult to keep of pointe
> On 23 May 2018, at 00:41, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 22 May 2018, at 23:28, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
>> I wrote a C++ wrap for that latter, too. As it turns out to be
>> difficult to keep of pointers into the GC heap, I had to
tle tuplet?
>
>Because all the tuplets are prime. Evidently, no programmer ever
> imagined any composer would want to use a bunch of tuplets that were
> prime numbers.
Well, evidently no composer with the brains to apply rational
adjustments to his note lengths to coax LilyPond into
> From: metachromatic
> Subject: Re: Rational
>
> ===
>
> \version "2.18.2"
>
> \score {
>
> <<
>
> \new Staff {
> \clef "treble"
> \override TupletNumber.text = #tuplet-number::calc-fraction-text
>
Lilypond to generate a score.
What does Lilypond say the position of that note is?
2038354784/1481803521.
That's 203 million over 1.4 billion, roughly, whereas the previous
rational fraction was about 115 million over 97 million.
Now, why did Lilypond's internal position jump to such
Hans Åberg writes:
>> On 22 May 2018, at 23:28, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
>>>> On 22 May 2018, at 22:53, David Kastrup wrote:
>>>>
>>>>>> This was somewhat complicated by some Midi classes being heap-a
> On 22 May 2018, at 23:28, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 22 May 2018, at 22:53, David Kastrup wrote:
>>>
>>>>> This was somewhat complicated by some Midi classes being heap-allocated
>>>>> and containi
Hans Åberg writes:
>> On 22 May 2018, at 22:53, David Kastrup wrote:
>>
>>>> This was somewhat complicated by some Midi classes being heap-allocated
>>>> and containing Rational/Moment members: those Midi classes would have to
>>>> become SCM-con
> On 22 May 2018, at 22:53, David Kastrup wrote:
>
>>> This was somewhat complicated by some Midi classes being heap-allocated
>>> and containing Rational/Moment members: those Midi classes would have to
>>> become SCM-connected. I did some work on that, don&#
Hans Åberg writes:
>> On 22 May 2018, at 22:07, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
>>>> On 22 May 2018, at 20:45, David Kastrup wrote:
>>>>
>>>> LilyPond's "rational" type should indeed get replac
> On 22 May 2018, at 22:07, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 22 May 2018, at 20:45, David Kastrup wrote:
>>>
>>> LilyPond's "rational" type should indeed get replaced
>>> by Guile's rational types which
Hans Åberg writes:
>> On 22 May 2018, at 20:45, David Kastrup wrote:
>>
>> LilyPond's "rational" type should indeed get replaced
>> by Guile's rational types which would seriously shift the threshold
>> where things start breaking apart at th
> On 22 May 2018, at 21:10, Hans Åberg wrote:
>
>
>> On 22 May 2018, at 20:45, David Kastrup wrote:
>>
>> LilyPond's "rational" type should indeed get replaced
>> by Guile's rational types which would seriously shift the threshol
> On 22 May 2018, at 20:45, David Kastrup wrote:
>
> LilyPond's "rational" type should indeed get replaced
> by Guile's rational types which would seriously shift the threshold
> where things start breaking apart at the cost of efficiency.
>
> That&#
Neil and Han-Wen,
Thanks so much for the change to 64-bit! I have tried the original test case I
sent to the user list, and it now compiles without error! Also, I tried one of
the parts for the score I'm working on that was similarly breaking, and it
seems to work fine, too.
Below is the tes
On Wed, Sep 24, 2008 at 7:42 PM, Neil Puttock <[EMAIL PROTECTED]> wrote:
> 2008/9/21 <[EMAIL PROTECTED]>:
>
>> http://codereview.appspot.com/5889/diff/1/6
>> File lily/moment.cc (right):
>>
>> http://codereview.appspot.com/5889/diff/1/6#newcode134
>> Line 134: {
>> If you want to be paranoid, you
2008/9/21 <[EMAIL PROTECTED]>:
> http://codereview.appspot.com/5889/diff/1/6
> File lily/moment.cc (right):
>
> http://codereview.appspot.com/5889/diff/1/6#newcode134
> Line 134: {
> If you want to be paranoid, you could check that the most significant
> bit is 1 here.
That would imply a negativ
Reviewers: Neil Puttock,
Message:
LGTM - this is what I meant.
http://codereview.appspot.com/5889/diff/1/6
File lily/moment.cc (right):
http://codereview.appspot.com/5889/diff/1/6#newcode134
Line 134: {
If you want to be paranoid, you could check that the most significant
bit is 1 here.
Descr
2008/9/19 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> They appear if you use -Wall with compiling lilypond. I'm on fedora
> 9, which has a pretty recent gcc though.
That's the default setting though, isn't it? I'm on Ubuntu hardy
x86_64, using gcc 4.2.3; the only warnings I've ever seen are from the
They appear if you use -Wall with compiling lilypond. I'm on fedora
9, which has a pretty recent gcc though.
On Thu, Sep 18, 2008 at 3:49 PM, Neil Puttock <[EMAIL PROTECTED]> wrote:
> 2008/9/18 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
>> Neil, could you also fix the warnings that this change generat
2008/9/18 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> Neil, could you also fix the warnings that this change generated? You
> should use scm_from_int64, scm_to_int64 for conversions, otherwise
> we'll get truncations in various corner cases.
Sorry Han-Wen, I haven't seen any warnings. Are they from
Neil, could you also fix the warnings that this change generated? You
should use scm_from_int64, scm_to_int64 for conversions, otherwise
we'll get truncations in various corner cases.
On Fri, Sep 12, 2008 at 3:42 AM, <[EMAIL PROTECTED]> wrote:
> LGTM
>
> please apply.
>
>
>
> http://codereview.
LGTM
please apply.
http://codereview.appspot.com/5058/diff/11/12
File flower/include/flower-proto.hh (right):
http://codereview.appspot.com/5058/diff/11/12#newcode2
Line 2: fflower-proto.hh -- typenames in flowerlib
ff?
http://codereview.appspot.com/5058
___
2008/9/11 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> Go for it!
Revised patch is up.
OK to apply?
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Go for it!
On Thu, Sep 11, 2008 at 1:21 PM, <[EMAIL PROTECTED]> wrote:
> On 2008/09/09 22:18:07, hanwenn wrote:
>
>> I wonder if we should have a typedef long long, though. Maybe int64
>
> or similar.
>
> Yes, it would be an improvement.
>
> We already have I64 in flower-proto.hh, so it would ju
On 2008/09/09 22:18:07, hanwenn wrote:
I wonder if we should have a typedef long long, though. Maybe int64
or similar.
Yes, it would be an improvement.
We already have I64 in flower-proto.hh, so it would just be a case of
adding a typedef unsigned long long.
http://codereview.appspot.com/50
Reviewers: Neil Puttock,
Message:
LGTM .
I wonder if we should have a typedef long long, though. Maybe int64 or
similar.
Please review this at http://codereview.appspot.com/5058
Affected files:
M flower/include/rational.hh
M flower/include/std-string.hh
M flower/include/string-conver
> Karl Hammar wrote:
>
> >[EMAIL PROTECTED]:
> >
> >
> >>Rune Zedeler escreveu:
> >>
> >>
> >>>Where can the famous patch be found?
> >>>(Unable to compile latest guile-cvs).
> >>>
> >>>
> >>see install.txt
> >>
> >>
> >
> >There is no install.txt, and the INSTALL.txt I found does
> Rune Zedeler <[EMAIL PROTECTED]> writes:
> > Where can the famous patch be found?
...
> http://lilypond.org/vc/gub.darcs/patches/guile-1.8-rational.patch
...
Got the patch and build debian guile debs for i386.
If anybody would need them, they are available at:
http://kalle.csb.ki.se/pub/l
Karl Hammar wrote:
[EMAIL PROTECTED]:
Rune Zedeler escreveu:
Where can the famous patch be found?
(Unable to compile latest guile-cvs).
see install.txt
There is no install.txt, and the INSTALL.txt I found does not mention it:
At www.lilypond.org, click on the docume
[EMAIL PROTECTED]:
> Rune Zedeler escreveu:
> > Where can the famous patch be found?
> > (Unable to compile latest guile-cvs).
>
> see install.txt
There is no install.txt, and the INSTALL.txt I found does not mention it:
$ git-pull
remote: Generating pack...
...
rename input/{no-notation
Rune Zedeler escreveu:
> Where can the famous patch be found?
> (Unable to compile latest guile-cvs).
see install.txt
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
__
Rune Zedeler <[EMAIL PROTECTED]> writes:
> Where can the famous patch be found?
In GUB, pull from http://lilypond/vc/gub.darcs, or
http://lilypond.org/vc/gub.darcs/patches/guile-1.8-rational.patch
> (Unable to compile latest guile-cvs).
(You may want to report that too)
Jan.
--
Jan Nieuw
Where can the famous patch be found?
(Unable to compile latest guile-cvs).
-Rune
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Nicolas Sceaux escreveu:
>> Hi Han-Wen,
>>
>> I've just downloaded guile-1.8.1 from gnu.org, it seems that
>> libguile/numbers.c has your rational patch applied, even though
>> numbers.h still has SCM_FR
Nicolas Sceaux escreveu:
> Hi Han-Wen,
>
> I've just downloaded guile-1.8.1 from gnu.org, it seems that
> libguile/numbers.c has your rational patch applied, even though
> numbers.h still has SCM_FRACTION_REDUCED_BIT and friends #defined. So
> the GUILE-with-rational-bugf
Hi Han-Wen,
I've just downloaded guile-1.8.1 from gnu.org, it seems that
libguile/numbers.c has your rational patch applied, even though
numbers.h still has SCM_FRACTION_REDUCED_BIT and friends #defined. So
the GUILE-with-rational-bugfix test in configure.in may be bit too
strict, and pe
84 matches
Mail list logo
