sorry to complain late about this change. I understand that this gets
rid of a conversion warning, which is something that we want, but I am
missing the big picture here. Is there a plan for the big picture?
https://codereview.appspot.com/561350044/diff/571460330/lily/stem.cc
File lily/stem.cc (r
On Sun, Feb 2, 2020 at 11:47 PM wrote:
>
> On 02/02/2020 22:33, Han-Wen Nienhuys wrote:
> > For me, juggling 15 different outstanding code reviews at the same
> > time is the bane of the current development process.
>
> what do you suggest?
I think we should move to a git-based code review tool;
Thomas Morley-2 wrote
> Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup <
> dak@
> >:
> ...
>
> Ok, thanks for the explanation.
>
> Iiuc, this would make this patch superfluous and it should be abandoned.
> As I'm only shepherding it, I'll wait for Arnold.
> For now I'll set the issue t
On Mon, Feb 3, 2020 at 9:35 AM Han-Wen Nienhuys wrote:
>
> On Sun, Feb 2, 2020 at 11:47 PM wrote:
> >
> > On 02/02/2020 22:33, Han-Wen Nienhuys wrote:
> > > For me, juggling 15 different outstanding code reviews at the same
> > > time is the bane of the current development process.
> >
> > what d
On Mon, Feb 3, 2020 at 9:35 AM Han-Wen Nienhuys wrote:
> > > For me, juggling 15 different outstanding code reviews at the same
> > > time is the bane of the current development process.
> >
> > what do you suggest?
>
> I think we should move to a git-based code review tool; Github, Gitlab
> or Ge
On Mon, Feb 3, 2020 at 9:35 AM Han-Wen Nienhuys wrote:
> > On 02/02/2020 22:33, Han-Wen Nienhuys wrote:
> > > For me, juggling 15 different outstanding code reviews at the same
> > > time is the bane of the current development process.
> >
> > what do you suggest?
>
> I think we should move to a g
On 2020/02/02 15:28:44, dak wrote:
> On 2020/02/02 14:01:33, hanwenn wrote:
> > https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm
> > File scm/lily.scm (right):
> >
> >
>
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode111
> > scm/lily.scm:111: "This
Han-Wen Nienhuys writes:
> On Sun, Feb 2, 2020 at 11:47 PM wrote:
>>
>> On 02/02/2020 22:33, Han-Wen Nienhuys wrote:
>> > For me, juggling 15 different outstanding code reviews at the same
>> > time is the bane of the current development process.
>>
>> what do you suggest?
>
> I think we should
Han-Wen Nienhuys writes:
> On Mon, Feb 3, 2020 at 9:35 AM Han-Wen Nienhuys wrote:
>> > > For me, juggling 15 different outstanding code reviews at the same
>> > > time is the bane of the current development process.
>> >
>> > what do you suggest?
>>
>> I think we should move to a git-based code
hanw...@gmail.com writes:
> sorry to complain late about this change. I understand that this gets
> rid of a conversion warning, which is something that we want, but I am
> missing the big picture here. Is there a plan for the big picture?
As far as I can see the big picture is matching the used
On 2020/02/03 09:49:32, hanwenn wrote:
> On 2020/02/02 15:28:44, dak wrote:
> > That's what I am trying right now, but you cannot quote outer
functions as a
> > value either (the problem is the value, not the innerness) so you
need to do
> it
> > by name and I would like not to have to export it,
On Feb 3, 2020, at 06:27, David Kastrup wrote:
>
> hanw...@gmail.com writes:
>
>> sorry to complain late about this change. I understand that this gets
>> rid of a conversion warning, which is something that we want, but I am
>> missing the big picture here. Is there a plan for the big picture?
Dan Eble writes:
> I confess, I've not educated myself on how Guile stores int versus
> long, like whether it actually uses more space for scm_from_long(50)
> than for scm_from_int(50);
No difference. Needed size depends on the magnitude of the value, not
its type.
--
David Kastrup
On Feb 3, 2020, at 08:43, David Kastrup wrote:
>
> Dan Eble writes:
>
>> I confess, I've not educated myself on how Guile stores int versus
>> long, like whether it actually uses more space for scm_from_long(50)
>> than for scm_from_int(50);
>
> No difference. Needed size depends on the magni
On Feb 3, 2020, at 04:30, Han-Wen Nienhuys wrote:
>
> Instead of waiting for complaints, a change is
> pushed once it passes tests and someone LGTM'd it.
I've worked in places where commits were handled with self-discipline and
mutual accountability, and I've worked in places where a UI enforce
Dan Eble writes:
> On Feb 3, 2020, at 04:30, Han-Wen Nienhuys wrote:
>>
>> Instead of waiting for complaints, a change is
>> pushed once it passes tests and someone LGTM'd it.
>
> I've worked in places where commits were handled with self-discipline
> and mutual accountability, and I've worked
Am Montag, den 03.02.2020, 09:58 -0500 schrieb Dan Eble:
> On Feb 3, 2020, at 04:30, Han-Wen Nienhuys <
> hanw...@gmail.com
> > wrote:
> > Instead of waiting for complaints, a change is
> > pushed once it passes tests and someone LGTM'd it.
>
> I've worked in places where commits were handled with
On 2020/02/03 12:11:08, dak wrote:
> On 2020/02/03 09:49:32, hanwenn wrote:
> > On 2020/02/02 15:28:44, dak wrote:
>
> > > That's what I am trying right now, but you cannot quote outer
functions as a
> > > value either (the problem is the value, not the innerness) so you
need to do
> > it
> > > by
Just scanned the code, don't take this as a full review.
In general I'm a huge fan of unique_ptrs, it makes memory ownership
semantically clear.
https://codereview.appspot.com/573500043/diff/561420043/lily/beam-quanting.cc
File lily/beam-quanting.cc (right):
https://codereview.appspot.com/57350
Stupid question: unique_ptr has the purpose of deallocating memory when
the last reference is gone. But we have an entire Scheme allocation
system exactly for that purpose for which we are already paying the
price in overhead. Any chance this can be usefully tracked in the SCM
scheme of things?
On 2020/02/03 18:01:09, dak wrote:
> Stupid question: unique_ptr has the purpose of deallocating memory
when the last
> reference is gone. But we have an entire Scheme allocation system
exactly for
> that purpose for which we are already paying the price in overhead.
Any chance
> this can be usef
Reviewers: dak, hahnjo,
Message:
On 2020/02/03 18:01:09, dak wrote:
> Stupid question: unique_ptr has the purpose of deallocating memory
when the last
> reference is gone.
When the single, owning reference is gone. It's not reference counted.
> But we have an entire Scheme allocation system exa
On 2020/02/03 18:13:00, hahnjo wrote:
> On 2020/02/03 18:01:09, dak wrote:
> > Stupid question: unique_ptr has the purpose of deallocating memory
when the
> last
> > reference is gone. But we have an entire Scheme allocation system
exactly for
> > that purpose for which we are already paying the p
On 2020/02/03 18:27:27, dak wrote:
> On 2020/02/03 18:13:00, hahnjo wrote:
> > On 2020/02/03 18:01:09, dak wrote:
> > > Stupid question: unique_ptr has the purpose of deallocating memory
when the
> > last
> > > reference is gone. But we have an entire Scheme allocation system
exactly
> for
> > > t
Thanks for the reviews, g
https://codereview.appspot.com/573500043/diff/561420043/lily/beam-quanting.cc
File lily/beam-quanting.cc (right):
https://codereview.appspot.com/573500043/diff/561420043/lily/beam-quanting.cc#newcode1049
lily/beam-quanting.cc:1049: configs.clear ();
On 2020/02/03 17:57:
On 2020/02/03 18:53:45, Dan Eble wrote:
>
https://codereview.appspot.com/573500043/diff/561420043/lily/system-start-delimiter-engraver.cc
> File lily/system-start-delimiter-engraver.cc (right):
>
>
https://codereview.appspot.com/573500043/diff/561420043/lily/system-start-delimiter-engraver.cc#newc
The changes to lily/break-substitution.cc are exactly what I would do.
What do you think about splitting those into their own commit and
pushing them?
https://codereview.appspot.com/557190043/
On Mon, Feb 3, 2020 at 2:40 PM Dan Eble wrote:
>
> On Feb 3, 2020, at 06:27, David Kastrup wrote:
> >
> > hanw...@gmail.com writes:
> >
> >> sorry to complain late about this change. I understand that this gets
> >> rid of a conversion warning, which is something that we want, but I am
> >> missi
A-OK.
https://codereview.appspot.com/557190043/
On Feb 3, 2020, at 14:53, Han-Wen Nienhuys wrote:
> 'long', the Stem class is now inconsistent with itself, because
> Stem::duration_log is an int, instead of a long.
That sounds like a valid concern. I'll take another look.
—
Dan
Han-Wen Nienhuys writes:
> On Mon, Feb 3, 2020 at 2:40 PM Dan Eble wrote:
>>
>> Han-Wen wrote:
>> > We could globally replace [int] with int64_t which has the
>> > additional advantage of being explicit about its size.
>>
>> I'm used to using those typedefs and I think they're beneficial, but
>>
On 2020/02/03 21:33:11, Dan Eble wrote:
> Next try: http://codereview.appspot.com/565610043
It's probably more an academical remark, but a "kosher" way of doing
that might be using scm_to_int (scm_length (...)) instead of scm_ilength
(...). This will take out the length in the form it has been pr
LGTM
thanks!
https://codereview.appspot.com/565610043/diff/559450051/lily/stem.cc
File lily/stem.cc (right):
https://codereview.appspot.com/565610043/diff/559450051/lily/stem.cc#newcode99
lily/stem.cc:99: // we confident that the list is short?
Yes, I'm confident about that.
// This list repre
Reviewers: hanwenn,
Message:
In the review for the first attempt, David wrote:
> It's probably more an academical remark, but a "kosher" way of doing
that might
> be using scm_to_int (scm_length (...)) instead of scm_ilength (...).
etc.
I'll make this change because setting a good example is valu
Hello,
Here is the current patch countdown list. The next countdown will be on
February 6th.
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
***
Push:
5719 Tie formatting maintenance - Dan Eble
https://sourc
35 matches
Mail list logo
