od reason why we should have port for the entire
file. If you have a .ly file that doesn't have a single # , then there is
no reason to have a port at all.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ot;Originally
> reported / posted by" lines at the beginning of every issue and comment
> (unless it had already been migrated from Google Code). Another
> shortcoming is that I could not reproduce the threaded structure on SF,
> so all comments are sorted chronologically.
>
> Please all take a look and let me know what you think!
> Jonas
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
t's probably easiest to scale the heap as this patch
> does.
>
> https://codereview.appspot.com/561390043/diff/567180043/lily/smobs.cc#newcode23
> lily/smobs.cc:23
> <https://codereview.appspot.com/561390043/diff/567180043/lily/smobs.cc#newcode23lily/smobs.cc:23>:
> #include
>
here the left and right hand do grace notes in
a synchronized way. I don't if that exists in practice, but it is one of
the reasons for the current approach.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
new graphical regtest result
> which means we will have "dramatic" changes of the C++ code later in
> the cycle.
>
We'd make them as often as necessary. My thinking is that we don't have to
do this on every commit.
> Jonas
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Feb 7, 2020 at 9:48 PM Dan Eble wrote:
> On Feb 7, 2020, at 15:21, Han-Wen Nienhuys wrote:
> >>> * use a headless browser to take a image snapshot of the top of
> regtest
> >>> result page.
> >>>
> >> Sounds convoluted. Why not a
he point is that you can take a snapshot of the full build at a point in
time. As long as the C++ code doesn't change dramatically between that
point and the commit to be tested, you'd get cache hits on a "clean" build
at a new commit, making the whole thing faster.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
a new thread for every heap resizing doesn't sound like a
> good idea. But I'll wait for you to post the patch and then take a
> look.
>
it's already there. You can take a look.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
churn.
>
> --
> David Kastrup
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Feb 7, 2020 at 7:27 PM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > Single threaded, the numbers make more sense:
> >
> >
> > MAX=INIT=2G
> > gc time taken: 1.843968805
> > User time (seconds): 49.36
> >
> > MAX=INIT=1G
On Fri, Feb 7, 2020 at 9:48 PM Dan Eble wrote:
> On Feb 7, 2020, at 15:21, Han-Wen Nienhuys wrote:
> >>> * use a headless browser to take a image snapshot of the top of
> regtest
> >>> result page.
> >>>
> >> Sounds convoluted. Why not a
On Fri, Feb 7, 2020 at 8:55 PM Dan Eble wrote:
> On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
> >
> > * runs (make ; make test-baseline)
>
> If this says "(make ;" because you think that "make test-baseline"
> requires a prior make, I thi
ards,
> —
> Dan
>
>
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Feb 7, 2020 at 9:12 PM Dan Eble wrote:
> On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
> > * use a headless browser to take a image snapshot of the top of regtest
> > result page.
>
> Sounds convoluted. Why not attach the difference images directly?
>
Th
to GC_expand_heap on a different thread.
Would you know what is the best way to do this in C++ nowadays?
thanks,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
eanest manner. But it would seem that even if part of them is
> likely to eventually be superseded, giving Han-Wen a better starting
> place would make him work and plan more effectively.
>
Thanks, David!
Can you mark the commits with some prefix ("GUILE2: blah") so they stand
ou
On Fri, Feb 7, 2020 at 5:53 PM Han-Wen Nienhuys wrote:
> Thanks, I ran the carver score successfully now.
>
> I took some pauses between runs so thermal throttling wasn't an issue.
>
> My standard guile2.2 branch (with 40M initial heap), takes about 2m wall
> time, 1m of GC t
On Fri, Feb 7, 2020 at 5:39 PM David Kastrup wrote:
>
> Private reply intended? Feel free to copy this to the review if you
> want to.
>
yes, but if you are fine, then back to the list.
> Han-Wen Nienhuys writes:
>
> > Just so you know, I am confused by this co
at 1:45 PM Jonas Hahnfeld wrote:
> Am Donnerstag, den 06.02.2020, 00:27 +0100 schrieb David Kastrup:
> > Han-Wen Nienhuys <
> > hanw...@gmail.com
> > > writes:
> >
> > > On Wed, Feb 5, 2020 at 12:33 PM <
> > > jonas.hahnf...@gmail.c
On Fri, Feb 7, 2020 at 5:09 PM Jonas Hahnfeld wrote:
> Am Freitag, den 07.02.2020, 12:09 +0100 schrieb Han-Wen Nienhuys:
> > n the spirit for providing competing options, I hereby offer a Gerrit
> > RFC. Note that I'm an obvious fan of Gerrit, but Gitlab seems an
> > acce
ontext going to change? Not likely.
>
You have a good point, but hopefully, I will be able to make enough time to
comment on technical feasibility so design questions can get better answers
henceforth.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
it easier to intuitively understand what is going on.
Finally, I want to encourage everyone to write Why something was
changed rather What. One can deduce what changed by looking at the
commit message. It is much harder to fathom Why some change was
necessary.
--
Han-Wen Nienhuys - hanw...@gmail.
>
Rather than working on GUILE 3, I think it would be better if we got GUILE
2.2 completely supported in mainline. The fewer versions of GUILE that we
have to support, the easier it will be to keep everything working.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Feb 7, 2020 at 3:36 PM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > n the spirit for providing competing options, I hereby offer a Gerrit
> > RFC. Note that I'm an obvious fan of Gerrit, but Gitlab seems an
> > acceptable solution to me too.
d the issue number,
> so that would be rather something to discuss on the list rather than as
> a side note.
>
>
I'll do that.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Wed, Feb 5, 2020 at 9:20 AM Han-Wen Nienhuys wrote:
>
>
> On Wed, Feb 5, 2020 at 9:14 AM Jonas Hahnfeld wrote:
>
>> Am Dienstag, den 04.02.2020, 23:14 +0100 schrieb Han-Wen Nienhuys:
>> > Somehow
>> > https://codereview.appspot.com/577410045/
>> &
t
be fragile if you meddle with timing if there are multiple staves.
If changing C++ (which the change under review also does) is on the table,
it would probably be easier to simply detect the 'timing going from #f to
#t and reset measurePosition directly in C++.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
into review, but likely, it should require a manual step in the
review process to kick off, eg. in Gerrit "Run-Regtest" +1 vote.
* For security, the host should use https://github.com/google/gvisor
to avoid being hacked by malicious code in proposed changes.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Feb 7, 2020 at 12:30 PM Federico Bruni wrote:
> Il giorno ven 7 feb 2020 alle 12:09, Han-Wen Nienhuys
> ha scritto:
>
> Gerrit lacks an issue tracker or integrated CI solution
>
>
> This is a big disadvantage IMO.
> It means we should keep using SourceForge, ri
l be easier manage takeout and self-host, and is
a better solution if we desparately care about service-continuity.
Compared to GL, it has a higher bar of entry, because it requires more
Git fluency, and is less integrated with other tools.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
e you tried Y instead? I think might make things cleaner.
This will get the same outcome coding-wise, but avoids treading on the ego
of the person on the other side.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
orse. How about focusing on the success mode instead of the
> failure mode?
>
> "
> I aim to communicate with empathy. Have I failed? Reply "OUCH!"
> "
>
I like this one better too.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
is
> not intended as a personal attack, despite the fact that it is being
> carried out in a way that does not make this clear.
>
>
>
> Elaine Alt
> 415 . 341 .4954 "*Confusion is
> highly underrated*"
> ela...@flaminghakama.com
> Producer ~ Composer ~ Instrumentalist ~ Educator
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
many
> people can/do execute them, and what the precise toolchain options are (or
> could be), talk of automating them seems premature to me.
>
with regard to the patch process, there is only one step that can't be
automated away, and that is visual inspection of the regtest results,
On Thu, Feb 6, 2020 at 12:19 AM Han-Wen Nienhuys wrote:
> Um, that outputs a lot. Anything in particular?
>>
>
> when you see things like:
>
> World-stopped marking took 187 msecs (77 in average)
> In-use heap: 51% (40071 KiB pointers + 6357 KiB other)
>
>
file=sys.stderr)
^
SyntaxError: invalid syntax
Is there still work left for the python3 conversion?
> https://codereview.appspot.com/561390043/
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
is a tool to manage the community atmosphere that can
outlive individuals responsible for doing so, and that spells out what the
community can expect from those individuals.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
concrete proposals, I guess you'll have to wait
> until the rest of us come to that point.
>
> Okay.
>
> Jonas
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
tainers for particular aspects, eg. Dan for C++ specific
questions, or Jonas for Python related issues.
I call these people maintainers as opposed to contributors, who would come
and go more frequently.
>Coordinated, larger efforts across the code base should start out
> >with a discussion. The mailing list could work here, but I find
> >discussion in an issue tracker is often easier to manage, because
> >it is easier to search, and by its nature, discussion in an issue
> >tracker drifts less off-topic. -
> >
> >We have a patch meister whose job it is to hound the project
> maintainer
> >to look at patches that don’t find traction or otherwise.
>
> That is not their current job description.
>
Yes, we would change the role of the patch meister. We could call it scrum
master or something else.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
den 05.02.2020, 00:11 +0100 schrieb David Kastrup:
> > Han-Wen Nienhuys <
> > hanw...@gmail.com
> > > writes:
> >
> > > My experiences with the current Lilypond development process.
> > >
> > > For context, I have a busy daytime job. I wo
On Wed, Feb 5, 2020 at 9:14 AM Jonas Hahnfeld wrote:
> Am Dienstag, den 04.02.2020, 23:14 +0100 schrieb Han-Wen Nienhuys:
> > Somehow
> > https://codereview.appspot.com/577410045/
> > got lost in the process.
> > OK to push?
>
> This was part of https://source
SIZE , eg.
GC_MAXIMUM_HEAP_SIZE=100M
Also, it would be interesting to GC_PRINT_STATS=1 and see how much time is
spent in GC, and how much a typical GC runs reclaim across the process.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ttps://sourceforge.net/p/testlilyissues/issues/5703
> http://codereview.appspot.com/549480043
>
> 5700 Add a tentative .clang-format for LilyPond. - Han-Wen Nienhuys
> https://sourceforge.net/p/testlilyissues/issues/5700
> http://codereview.appspot.com/561340043
>
> 5682 Only
erwise.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
shift out the
lower order tag bits to get to the integer. This means you get around
60 bit of space for integers on 64-bit. However, GUILE supports
arbitrary precision integers, so there is no C type that is guaranteed
to fit an SCM integer.
Speaking of rationals, it would be interesting to move to SCM values
for Rationals instead of the current C++ class, but we'd need to be
guile 2.x to garbage collection for values on the stack.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
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
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-ba
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 curre
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 gi
> Unbound variable: ol
>
> The preceding line is
>
> col =
>
> so this is likely a matter of passing the wrong part of the file into
> Guile when encountering # . The file contains two 3-byte UTF-8
> sequences above which could be thought to throw off the interpretation
&
ort it, so I
> try with (@@ guile-user define-session-internal) but haven't found the
> right incantation yet. Still fiddling. If it cannot be avoided, it
> will end up as an exported define-session-internal .
I guess we would have to inline the function (effectively changing it
from functio
who does those tests with considerably more manual effort
> than previously.
I'm confused then. Can you sketch what happens after a patch was
LGTM'd on Rietveld? How does it get to staging, and how does master
advance?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
am still unsure about the final push process. As I understand
it, you have to push to staging, and then someone (David?) runs patchy
over the staging branch, verifies the regtest output, and pushes to
master. Is that roughly correct?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
m/lilypond/lilypond/blob/c5ffa540fdbe52486b9575567ede70be575adb47/scm/define-markup-commands.scm#L305
and seeing how the error message changes.
I still don't understand why some code is executed compile time (the
expansion of the markup macro) while other is not (defining the
make-x-markup functi
+lilypond-devel for visibility.
On Sat, Feb 1, 2020 at 10:54 AM Han-Wen Nienhuys wrote:
>
> Here is an example that shows better how things work, and what might
> be the cause of my problems. Is it right that programmatically set
> contents of "current-module&qu
g commits.
Well, I'm trying to follow the established process here which involves
waiting for the code review to be LGTM'd, after which other magical
steps happen.
Or do I get to bypass process?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Adapted description.
On Fri, Jan 31, 2020 at 8:36 AM Han-Wen Nienhuys wrote:
>
> On Fri, Jan 31, 2020 at 8:30 AM Han-Wen Nienhuys wrote:
> > Locally, I have
> >
> > Clean up embedded scheme parsing/evaluation.
> >
> > Renames and reorder
On Fri, Jan 31, 2020 at 8:30 AM Han-Wen Nienhuys wrote:
> Locally, I have
>
> Clean up embedded scheme parsing/evaluation.
>
> Renames and reorders functions to clarify the mechanism. No
> consequential functional changes.
>
> Separates input and output par
ask to expand the description to reflect the change
> more accurately.
Locally, I have
Clean up embedded scheme parsing/evaluation.
Renames and reorders functions to clarify the mechanism. No
consequential functional changes.
Separates input and output parameters.
but I can't find a button to edit the change description.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
diffs and not get reviews on style.
2. Recognize clang-format as recommended, and document how to set it
up for contributors
3. Recognize clang-format as standard, and setup a formatting test on
diffs in the Makefile.
4. Recognize a certain version of clang-format as standard, and setup
a formatting test on the source tree in the Makefile. Users can setup
integration with emacs, vim, CLion, Eclipse etc.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
on a syntax for a
I agree with David here. Let's solve the hard problem first before we
care about cosmetics.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
oth .ly and/or .scm components.
>
> --
> David Kastrup
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sat, Jan 25, 2020 at 1:47 PM Han-Wen Nienhuys wrote:
> 7.2 seconds end-to-end includes 1.7s of GC, and 2.0s of reading/compiling SCM.
>
> On guile 1.8, with GS disabled, the end to end runtime is
>
> 3.568s including 0.33s for GC and 0.32s for reading the SCM.
>
> These t
ls the use of define ,
> and the first argument of define is the symbol to be defined which must
> not be evaluated before define-session is being called.
Thanks, I got it now. I sent a mail to the guile-devel list to
inquire what is going on.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Tue, Jan 28, 2020 at 12:18 AM David Kastrup wrote:
>
> David Kastrup writes:
>
> > Han-Wen Nienhuys writes:
> >
> >> On Mon, Jan 27, 2020 at 11:49 AM David Kastrup wrote:
> >>> > I want to propose to move to automated formatting for our C++ c
l = ...
addTweak = ...
}
\import edition.addTweak
that would let you define constructs in a package that doesn't pollute
the global namespace, and let .ly packages control explicitly what
symbols they want to use.
I think we should aim to avoid textual inclusion as a mechanism that
powers packaging.
--
H
ces over the
code base. (This is probably not a big factor for LilyPond, but it's
what makes large scale automated refactoring feasible at places like
Google.)
> Clang is a pretty big dependency for developers.
You'd think that, but it's not that bad:
$ rpm -qi clang| grep Size
Size: 1695283
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
,
which seems fishy.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
://clang.llvm.org/docs/ClangFormatStyleOptions.html
for further options.
Obviously, reformatting code makes patches harder to transport, so
we'd have to do it on all active branches at the same time.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Hey David,
before we go into formal review, could you have a look at
https://github.com/hanwen/lilypond/commit/3402c61aa0d6f36b8dce984947d61ba01b0a6350
The commits fix Unicode lyrics, but maybe we want to change the
setlocale() calls in main instead.
--
Han-Wen Nienhuys - hanw...@gmail.com
On Sun, Jan 26, 2020 at 3:45 PM David Kastrup wrote:
>
> Han-Wen Nienhuys writes:
>
> > Can we fast-track the submission of
> >
> > http://codereview.appspot.com/571430046
> >
> > I otherwise have to reconfigure and recompile the whole thing for
> > G
ackport of
> Py3-only code would entail cutting its support in the middle of the 2.20
> lifetime. To be honest, I already had suggested cutting it before 2.20
> but was met with resistance.
OK. So what is your proposal for how to proceed with Jonas' patch?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
equire the new python3 package as a
> dependency. This will (obviously) not work for packaging 2.20.
Fair enough, but that would only be a problem if we ever have to
produce a 2.20.1 . We could delay 2.21.0 for a while. If we get lucky,
we never have to produce a 2.20.1. If we do, we might have to backport
the py3 patch.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Can we fast-track the submission of
http://codereview.appspot.com/571430046
I otherwise have to reconfigure and recompile the whole thing for
GUILE v1 every time I have to address a review comment.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
version of Python 3 available. This should be
> > sufficiently easy (see above), but I'd like to have consensus on this.
>
> When we switch over GUB, we also need to switch over the 2.20 branch.
> It's not just master that is affected.
But we only need to switch GUB to py3 when we pa
See https://github.com/hanwen/lilypond/pull/1
This has a stack of dependent commits (see below). I don't know how to
deal with this on Rietveld.
commit 3c8081d25b53529efe687ffe9e92ef48f5d11ea2
Author: Han-Wen Nienhuys
Date: Sun Jan 26 12:19:56 2020 +0100
Parse inline scheme using
hon 3.5 and passes check & doc on my system.
> But with nobody responding on lilypond-devel I'm not sure how to
> proceed...
>
> https://codereview.appspot.com/553430047/
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
I gave up after I encountered the 'imp' thing. I'll just keep patching
[TARGET_]PYTHON to be python2.
On Sun, Jan 26, 2020 at 1:37 PM wrote:
>
> I object, please take a look at
> https://sourceforge.net/p/testlilyissues/issues/5646/
>
> https://codereview.appspot.com/573440043/
gt; Operand stack:
> > false --nostringval--
>
> Pretty sure this is an encoding problem.
Yeah, the output port for the PS file must be configured as Latin1.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
s binary data) into a string without
considering any encoding. The string then gets dumped onto the PS
file.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
placed in the public "
and
$ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
-dAutoRotatePages=/None -dPrinted=false -sOutputFile=mozart-hrn-3.pdf
-c.setpdfwrite -f/tmp/lilypond-OCyOzh
Error: /r
e documentation to refresh my memory.
>
> An alternative to using a lambda would be to move this stuff to a
> private member function, or maybe a static function in this file.
Thanks for the explanation!
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
name after a page break?
>
> https://codereview.appspot.com/553400043/
I think you could build that in a similar fashion, yes.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
GC overhead".
> Could you explain?
Compiling the .scm files happens once, and is a fixed cost. The fixed
cost is large when you process a tiny .ly file, but it is neglible if
the file is large.
The overhead of the new Garbage Collector is likely proportional to
the size of the input, and is the cau
(and in the process, I erroneously clobbered
https://github.com/lilypond/lilypond, which I am fixing now.
On Sat, Jan 25, 2020 at 2:01 PM Han-Wen Nienhuys wrote:
>
> I've pushed all my local branches to
> https://github.com/hanwen/lilypond , which make the rebasing and such
> eas
+ei.x_ = head_ext.center ();
> }
>else
> ei.x_ = col->extent (common_[X_AXIS], X_AXIS).center ();
>
> That last part applies part of a patch from an unrelated issue of
> Han-Wen. Please don't do stuff like that, if necessary using
>
> git reset --hard
>
> Took me about half an hour of head-scratching to figure out why the
> diffs would differ here.
>
> --
> David Kastrup
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
or GC might be worth it.
I think it is clear that we should not be targeting GUILE 2.0, but GUILE 2.2.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
; \override Stem.french-beaming = ##t
> r16 f d f
> }
>
> Looking into scores from French publishers this behaviour seems to be
> incorrect.
>
>
> Werner
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Jan 24, 2020 at 6:09 PM Han-Wen Nienhuys wrote:
> Both your hunches were correct:
>
> the code below works, but it makes the GC time go from 2s to 5s.
Probably a lot of overhead would go away if we could properly pair up
GC_FREE with GC_MALLOC from libgc, but I can't get thi
e. GC_free manipulates the
// to-be-freed pointer, and we can't guarantee that the pointer
// actually comes from GC_MALLOC.
}
On Fri, Jan 24, 2020 at 5:54 PM David Kastrup wrote:
>
> David Kastrup writes:
>
> > Han-Wen Nienhuys writes:
> >
> >> On Fri, Jan 2
this would be a problem.)
I am actually quite attracted to moving to GUILE 2 and using BGC.
Debugging GC problems (eg. a constructor triggering GC, which then
deletes the smob under construction) were one of most hairy things to
get right.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Why do we insist in associating each review with a http://sf.net
> issue,
> > even if there is no related bug?
>
> I think there's no initial message for a new patch here, so there needs
> to be a place where new patches go and others can see them.
Git-CL gets a token, so presumably, it could also post a request to
press the 'm' button
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
43/
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ng is clumsy. Having a gerrit or GH/GL based workflow would let
us review and exchange diffs as native Git commits, which simplifies a
lot of things.
I'm happy to push my stuff to some git branch somewhere, if that helps you.
BTW, Why do we insist in associating each review with a sf.net issue,
even if there is no related bug?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
t; mark hooks and just let the whole heap be marked and sweeped.
>
what is the documented way of disabling the hooks? And are we supposed to
include the BGC headers ourselves and issue GC_blah commands directly?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
es.
There are a bunch of others (eg. in Slur_engraver), that mark into STL
structures, but they retain pointers to events (which are kept alive
through the Music structures) and grobs (which are only unprotected
when they are put into the System).
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
d James
> implements more of a janitorial process and the decision which comments
> may be showstoppers really rests with the patch submitter.
Thanks, that's greatly appreciated.
BTW, Do issues get closed on Rietveld automatically too? I still have
many open reviews from many years ago.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Jan 24, 2020 at 11:28 AM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > Thanks for keeping track of this.
> >
> > Can you confirm my countdown patches will get pushed without any of my
> > involvement (assuming nobody else objects)?
>
> F
ark hooks and just let the whole heap be marked and sweeped.
>
Did we ever try this and publish results?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
version warnings - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5670
> http://codereview.appspot.com/557190043
>
>
> New:
>
> 5678 l -> lilne - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5678
> http://codereview.appspot.com/581470047
>
>
> ***
>
>
> Regards,
>
> James
>
>
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
401 - 500 of 3768 matches
Mail list logo
