On Jun 18, 2020, at 03:05, Jonas Hahnfeld wrote:
>
> Am Mittwoch, den 17.06.2020, 18:11 -0400 schrieb Dan Eble:
>> On Jun 14, 2020, at 07:04, Han-Wen Nienhuys wrote:
>>> Hey Dan,
>>>
>>> does your CI runner have limitations on sending data back to G
On Jun 17, 2020, at 17:18, Han-Wen Nienhuys wrote:
>
> My proposal is to use -Werror only in CI, so we can keep code free of
> warnings.
>
I'd go along with that if I could have a single switch or environment variable
to configure my local build with all the options that will be enabled in
On Jun 14, 2020, at 07:04, Han-Wen Nienhuys wrote:
>
> Hey Dan,
>
> does your CI runner have limitations on sending data back to Gitlab by any
> chance? It looks like this hung while uploading the failure logs
>
> -- Forwarded message -
> From: GitLab
Han-Wen proposed building with -Werror in a merge request. What do you think?
I like -Werror, but I've only ever used it where there were very few (or one)
supported build environments, all of which were covered in CI. A dimension of
the CI coverage was optimization level, which can change
I haven't put any limits on it. (I don't know if that's possible.) There have
been a couple of times in the last few months when something happened with my
cable connection and rebooting my modem fixed it, but apart from your build,
everything looks fine today.
—
Dan
> On Jun 14, 2020, at
On Jun 6, 2020, at 16:03, Jonas Hahnfeld wrote:
> Am Samstag, den 06.06.2020, 15:47 -0400 schrieb Dan Eble:
>> On Jun 6, 2020, at 15:26, Dan Eble wrote:
>>> split the doc stage of the build into multiple stages that can be run in
>>> parallel on different runners
&g
On Jun 6, 2020, at 15:26, Dan Eble wrote:
>
> split the doc stage of the build into multiple stages that can be run in
> parallel on different runners
For example, assigning each runner one or more languages to build.
—
Dan
Would we still be validating LilyPond properly if we split the doc stage of the
build into multiple stages that can be run in parallel on different runners, or
is it fundamentally important that we test "make doc"?
—
Dan
On May 24, 2020, at 06:51, Jonas Hahnfeld wrote:
>
> I'm currently researching how GitLab schedules jobs. Unfortunately it
> seems to be first-come-first-serve, so no priority for currently online
> specific runners. But every runner, if intermittent or not, has a
> chance of getting a job
On May 27, 2020, at 21:03, David Kastrup wrote:
>
> Dan Eble writes:
>> I wonder how the rest of you feel about having another developer click
>> the buttons to rebase and merge your MRs?
>
> If you refer to me doing that on Han-Wen's merge request, he actually
I had
On May 27, 2020, at 07:16, David Kastrup wrote:
>
> Now that we have the first "please get in line" merge that isn't
> actually to any degree unusual, I get the suspicion that my previous
> alternative proposal of pushing to a CI-less staging branch that then
> uses CI to get to master will
On May 23, 2020, at 13:59, Jonas Hahnfeld wrote:
>
> Hi all,
>
> I've now made the necessary settings, merged the changes in
> https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
> existing merge requests to target 'master', and deleted 'staging'.
This helped me update the
> On May 20, 2020, at 03:17, Valentin Villenave wrote:
>
> On 5/20/20, Arthur Reutenauer wrote:
>> “How often would you like me to make contact?” :-)
>> https://www.lexico.com/definition/touch_base
>
> I urge you not to look up that phrase on Urban Dictionary… ;-)
s/that
On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
>
> before merging. As we only allow fast-forward merges, this means each
> MR has received testing in the form it hits master. This would
> effectively replace the current setup of pushing to staging.
I'm for this.
—
Dan
On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> if we want to get faster builds, we can always add our own machines.
> That is a matter of installing Docker and the runner (packages provided
> by GitLab). Configuration is as simple as running one command and
> pasting the URL as well as a
On May 13, 2020, at 17:13, David Kastrup wrote:
>>> At the current point of time, our pipeline does not tend to be all that
>>> full I think. We are not at Linux kernel levels of participation...
>>
>> No, you're probably right. It's only a bit more bothersome if you have
>> multiple changes to
Rietveld used to send email to lilypond-devel for all comments by default,
though one could disable that when commenting. Are we satisfied with GitLab's
not doing that?
—
Dan
On May 11, 2020, at 19:42, Caio Barros wrote:
>
> Then I noticed that on the "old" repo there was GNUmakefile.in
> and GNUmakefile. The second one is not present on the "new" repo, so i did
...
>
> Am I missing something?
Run autogen.sh and/or configure?
—
Dan
On May 10, 2020, at 18:51, Joram Noeck wrote:
>
> as far as I understand (from experience with other projects), you can
> clone anonymously (and fetch without authentication then).
> If you want to be able to push, you need to authenticate and then you
> also need to authenticate for fetch or
On May 10, 2020, at 15:36, Jonas Hahnfeld wrote:
>
> All right, I populated the repository
When I try to fetch from gitlab with https, it prompts me to authenticate.
It's inconvenient. Is it expected?
—
Dan
I'm trying to upgrade the LilyDev Dockerfile to use Ubuntu 20.04 and I get this
error when I try to build. It's coming from here:
# realpath doesn't exist on OSX
realpath() {
python -c "import os; print(os.path.realpath('$1'))"
}
Is there a Right Way to resolve this? Should
On May 10, 2020, at 08:11, lilyp...@de-wolff.org wrote:
>
> I did replace all implicit casts to an int by a inline function, checking if
> the value is valid, and then casting to int.
>
> Together with my previous patch now all but one compiler warnings are
> solved.
Jaap,
I love the fact
On May 9, 2020, at 15:13, David Kastrup wrote:
> Carl Sorensen writes:
>
>> ->CS At any rate, I think that we should have appropriate CG
>> instructions at the time we make the switch. They don't have to be
>> perfect (the CG has a much lower editing bar than the NR), but they
>> need to be in
On May 7, 2020, at 11:12, v.villen...@gmail.com wrote:
> No, I actually want oneline to be true . I did consider changing the
> variable name to no_multiple_lines, because that’s what it’s really
> about. I also considered adding a comment such as:
> // If there is no StaffSymbol, print MMrests on
On May 5, 2020, at 18:03, David Kastrup wrote:
>
> If everything can be represented/mapped in similar manner, the Scheme
> garbage collector does not need any interaction with user-written code
> for doing its job.
I would not like to see the STL go, but if the getting rid of all the explicit
On May 5, 2020, at 17:48, David Kastrup wrote:
>
> One thing here is that being under control of a wrapper, one can use
> unchecked unsmobs.
This is a good idea. I considered this briefly, but I wanted to focus first on
making it natural to deal robustly with potentially improper or
On May 5, 2020, at 13:37, David Kastrup wrote:
>
> What I have ready-to-use is something that stores like an SCM value but
> behaves like a Smob pointer with regard to -> and * usage.
Oh. I believe I have some of that too. Excerpt:
// specialization for pointers
template
class ly_scm_t
{
On May 5, 2020, at 11:09, David Kastrup wrote:
> I'd like to come up with an allocator/container programming model
> comparatively similar to the STL one so that one could mostly steal the
> implementations and "just" add the required Scheme awareness while
> removing of destruction/deallocation
On May 3, 2020, at 07:00, Jonas Hahnfeld wrote:
>
> As the last two points involve some (short) scripts and I already have
> two more for the migration, I'd like to put them into a new repository;
> maybe https://gitlab.com/lilypond/infrastructure ? (I think they're
> sufficiently orthogonal to
RFC on Case 3 below. Thanks.
—
Dan
\version "2.20.0"
upper = f''1
lower = e'1
%% CASE 1: When the music in each simultaneous element begins with a
%% note, the upper staff is created first.
\score {
<<
\upper
\lower
>>
}
%% CASE 2: When there are sets preceding the notes in both
On Apr 23, 2020, at 16:24, Jonas Hahnfeld wrote:
>> I'd prefer file-names and thumbnails, unfolded by clicking.
>>
>> Is this behaviour adjustable?
>
> No, I'm merely linking the uploaded file (GitLab decides to display the
> image inline) and AFAICS there are no options to influence this
>
On Apr 23, 2020, at 19:25, Dan Eble wrote:
>
>(let ((masked-music (ly:music-property m 'void)))
> (if (and (ly:music? masked-music) (tags-keep-predicate tags))
^^
Oops. This is bogus and the output of the score i
Is this \mask function worth developing as a feature of LilyPond? Is there
already something that can achieve this that I am overlooking?
The use case will probably be clearer if you start by running this example
through LilyPond than if you start by reading the code.
Regards,
—
Dan
\version
On Apr 18, 2020, at 14:38, nine.fierce.ball...@gmail.com wrote:
>
> On 2020/04/18 18:14:33, thomasmorley651 wrote:
>
> I ran make check and didn't see any differences. Without test coverage,
> someone could easily break this again without knowing it.
Oops. *I* wrote that; I just neglected to
On Apr 15, 2020, at 19:41, Dan Eble wrote:
>
> What I have seen while testing this is that the header returned by
> (ly:performance-header performance) contains only the items from the score
> headers.
https://sourceforge.net/p/testlilyissues/issues/5917/
—
Dan
On Apr 16, 2020, at 01:16, Werner LEMBERG wrote:
>
> Have you ever tried valgrind's `callgrind` tool for profiling (and
> using `kcachegrind` for displaying the results)? While very slow it
> would avoid temperature issues and the like – no need to call it
> multiple times to get reliable
You're not going to be able to run this because you don't have the
after-writing callback that it requires, but I hope that it is unnecessary to
run this to answer my question.
What I have seen while testing this is that the header returned by
(ly:performance-header performance) contains only
On Apr 15, 2020, at 15:44, David Kastrup wrote:
>
> Jonas Hahnfeld writes:
>
>> To conclude, I believe we should choose one of Gerrit and GitLab and
>> have a trial to see if the processes can be carried over. (If not, we
>> can still give the other platform a try.)
>
> IIRC, Gerrit was not
On Apr 13, 2020, at 16:31, hanw...@gmail.com wrote:
>
>> Does const serve a purpose here? The iterator doesn't carry through
> with any
>> kind of enforcement. The same question applies to try_retrieve() and
>> to_alist().
>
> It allows one to iterate over properties in a const method.
>
>
On Apr 9, 2020, at 14:42, Valentin Villenave wrote:
>
> Here’s to hoping we can get back on track with our once bi-monthly
> development release cycle!
Oh, you don't like software development on Biblical timescales?
At the end of every seven years thou shalt make a release
(Deuteronomy
Knut,
Regarding [1], I thought I would check whether you have anything more recent or
less intrusive before I try it.
Thanks,
--
Dan
[1] "Video generation on linux systems: Note and rests change color"
https://lists.gnu.org/archive/html/lilypond-user/2017-07/msg00234.html
On Mar 30, 2020, at 17:34, Han-Wen Nienhuys wrote:
>
> On Sun, Mar 29, 2020 at 11:45 PM Dan Eble wrote:
>>
>> On Mar 29, 2020, at 17:39, Han-Wen Nienhuys wrote:
>>>> test-output-distance was removed on the grounds that the self-test
>>>> serves the
On Mar 29, 2020, at 17:39, Han-Wen Nienhuys wrote:
>> test-output-distance was removed on the grounds that the self-test
>> serves the same purpose, but I don't see how it does.
>
> Could you elaborate? What failure scenario are you worried about?
My question is, how does the self-test "verify
On Mar 29, 2020, at 15:31, David Kastrup wrote:
> I was actually only planning to touch convertrules.py . Sigh.
Sure, don't let it bother you.
—
Dan
On Mar 29, 2020, at 14:46, David Kastrup wrote:
>
> Dan Eble writes:
>
>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>>
>>> Anybody can think of a holdup?
>>
>> convert-ly is broken:
...
> Oh wow, how did that happen?
>
> Oh, and
On Mar 29, 2020, at 11:54, David Kastrup wrote:
>
> Anybody can think of a holdup?
convert-ly is broken:
find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
Traceback (most recent call last):
File "/home/user/lilypond-build/out/bin/convert-ly", line 236, in do_conversion
newstr
On Mar 23, 2020, at 18:41, David Kastrup wrote:
>
> Dan Eble writes:
>
>> I'll submit that for review along with some tweaks to the clang-format
>> configuration. I still have some testing to do.
>
> Thanks, and sorry for causing that workload out of not reall
On Mar 23, 2020, at 17:10, David Kastrup wrote:
>
> Dan Eble writes:
>> As far as I'm concerned, we could just declare 3.1 to be the new
>> preferred version. I'm not sure whether that would inconvenience
>> anyone else, though.
>
> It's the current versio
On Mar 23, 2020, at 10:06, Jean-Charles Malahieude wrote:
>
> Le 21/03/2020 à 18:11, Malte Meyn a écrit :
>> Hi list,
>> first of all, I’d like thank those who made the make output less verbose,
>> this makes errors much easier to find.
>
> It is, unfortunately, sometimes too little verbose:
On Mar 22, 2020, at 17:04, David Kastrup wrote:
>
> Dan Eble writes:
>
>> Did you use astyle 2.04 or another version? I built 2.04 from source
...
> 3.1. I am afraid that I may have updated my system since the review,
...
> So where should we go from here?
As far as I'
On Mar 21, 2020, at 11:26, David Kastrup wrote:
> it got a bit lost in other things, but I think I would want to run
> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
> conventions for template arguments but there are comparatively few of
> those).
Did you use astyle
On Mar 21, 2020, at 11:26, David Kastrup wrote:
> it got a bit lost in other things, but I think I would want to run
> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
> conventions for template arguments but there are comparatively few of
> those).
OK here. Also, thanks
On Mar 21, 2020, at 08:25, hanw...@gmail.com wrote:
>
> For context: many projects that I contribute to keep harping about
> trailing whitespace
I recently started using the ws-butler package to limit whitespace changes to
lines that also have substantive changes. It has helped me.
On Mar 15, 2020, at 12:21, David Kastrup wrote:
>
> Han-Wen Nienhuys writes:
>> suggests that OSX actually uses bash.
>
> Paywalled site.
The current macOS (10.15.3, "Catalina") sets zsh as the default shell for new
users. bash is still provided.
$ zsh --version
zsh 5.7.1
On Mar 15, 2020, at 10:26, Han-Wen Nienhuys wrote:
>
> On Sun, Mar 15, 2020 at 2:33 AM Dan Eble wrote:
>>
>> On Mar 14, 2020, at 19:39, Han-Wen Nienhuys wrote:
>>>
>>> On Sat, Mar 14, 2020 at 9:16 PM Dan Eble wrote:
>>>> I assume the warni
On Mar 14, 2020, at 19:39, Han-Wen Nienhuys wrote:
>
> On Sat, Mar 14, 2020 at 9:16 PM Dan Eble wrote:
>> I assume the warnings are incorrect, otherwise you would be asking for help
>> to fix them rather than asking whether checking the HTML is valuable. Is
>>
On Mar 14, 2020, at 15:26, Han-Wen Nienhuys wrote:
>
> In my docker install of Ubuntu Xenial, I see the following failure,
> apparently coming from tidy.
>
> creating
> /lilypond/out/test-results/input/regression/out-test-baseline/test-output-distance.png
> creating
>
On Mar 13, 2020, at 09:03, pkx1...@posteo.net wrote:
>
> 5703 Run scripts/auxiliar/fixcc.py - David Kastrup
> https://sourceforge.net/p/testlilyissues/issues/5703
> http://codereview.appspot.com/549480043
What is the plan for this?
—
Dan
On Mar 13, 2020, at 04:43, Kevin Barry wrote:
>
> The direction of this statement is correct, but the magnitude is not. The
> kernel is still provided by the host. Getting a crash report can be
> frustrating when the guest's behavior hinges on /proc features that the host
> OS has
On Mar 12, 2020, at 08:36, Kevin Barry wrote:
>
>> Would docker give us this 'proverbial canary' or would it turn into
>> 'worksforme' when someone tried to build their own version of LP on a
>> vanilla base of Linux?
>>
> Docker would eliminate 'worksforme' type issues yes.
The direction of
On Mar 10, 2020, at 04:13, Han-Wen Nienhuys wrote:
> I never said that blue is a kind of red.
True. What you said was this:
> Wouldn't this be much simpler if you'd implement
> the transition as a layout tweak to a hyphen? You'd get something like:
>
> vowelTransition = \once \override
On Mar 9, 2020, at 04:42, Han-Wen Nienhuys wrote:
>
> On Mon, Mar 9, 2020 at 12:44 AM Dan Eble wrote:
>> I agree that lots of duplication is something that should be avoided, but so
>> is the conflation of style and meaning. A lyric hyphen separates syllables;
>>
On Mar 8, 2020, at 11:21, hanw...@gmail.com wrote:
>
> I think it would be better to do this as something that doesn't require
> special syntax at first, ie. some identifier.
>
> We can always add special syntax later, if this becomes a very popular
> feature.
+1. In the meantime, the
On Mar 5, 2020, at 01:38, pkx1...@posteo.net wrote:
>
> Push:
...
> 5809 output-distance: avoid calling strip() on None - Han-Wen Nienhuys
> https://sourceforge.net/p/testlilyissues/issues/5809
> http://codereview.appspot.com/549640043
...
> Countdown:
...
> 5803 output-distance: treat
On Feb 25, 2020, at 05:29, Werner LEMBERG wrote:
>
> What do you think about converting all tabs in the .mf files to
> spaces? If you agree, I would apply this to the staging.
I don't usually work in that domain, so SGTM.
—
Dan
On Feb 23, 2020, at 09:11, David Kastrup wrote:
>
>> "Sharing Job Slots with GNU make"
>> https://www.gnu.org/software/make/manual/html_node/Job-Slots.html
>
> But that still doesn't solve the problem that the database approach of
> lilypond-book does not work for running multiple
On Feb 23, 2020, at 09:04, Han-Wen Nienhuys wrote:
>
>> What would you recommend to a developer who doesn't want to run more than J
>> = M + N - 1 concurrent jobs due to lilypond development? What values of M
>> and N would serve best?
>
> Normally M=N= #cpus should be OK. A bit of extra
On Feb 23, 2020, at 06:08, Han-Wen Nienhuys wrote:
> I think we should do both: the lilypond runs in lp-book should be
> protected by some sort of lock, and we should use both CPU_COUNT=M and
> -jN.
>
> then worst case, you have M lilypond processes and N-1 other jobs.
What would you recommend
On Feb 10, 2020, at 20:48, David Kastrup wrote:
>
> Templating on a string constant is, unfortunately, not a thing at least
> in C++11 (don't know whether they managed since then). Or one could go
> that route rather than GCC-specific in-expression use of a static
> initializer.
Well,
On Feb 10, 2020, at 21:35, David Kastrup wrote:
> property_set (grob, "stencil", SCM_BOOL_F);
>
> and
>
> property_get (grob, "color")
These are fine.
—
Dan
On Feb 10, 2020, at 17:47, David Kastrup wrote:
> It will look a bit redundant either way with
>
> grob->Get (Grob, "color");
> or
> grob->grob_set ("stencil", SCM_BOOL_F);
"Yuck" either way. Removing "property" to shorten the name is not a good
course of action.
My brainstorming without
On Feb 9, 2020, at 04:25, jonas.hahnf...@gmail.com wrote:
>
> Anyway I think adding a comment here and in smobs.cc how this is
> initialized (refer to static lifetime in C/C++) would likely clarify the
> intent.
Initialization is an area where the legacy of the language is complicated (more
On Feb 7, 2020, at 16:23, Han-Wen Nienhuys wrote:
>
> More work , and I'm lazy :)
No problem! Jonas is probably bored now that there's nothing left to port to
Python 3.
—
Dan
I aim to communicate with empathy. Have I failed? ¯\_(ツ)_/¯
On Feb 7, 2020, at 15:22, Kevin Barry wrote:
> P.S. I think I have seen a dockerfile for creating a build environment
> for LilyPond somewhere.
https://github.com/fedelibre/LilyDev/tree/master/docker
I'm using it. I'm not sure who else is.
—
Dan
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 attach the difference images directly?
>
> Those are potentially 1372 images to attach if you made a change with
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?
> On success, the driver uploads the image snapshot to code review.
>
> On failure, the
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 think it is incorrect. (If "make test-baseline" doesn't work on
its own, it should be fixed.)
If this says
On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
>
> contains a copy of ccache
ccache is interesting. It speeds up recompiling files after a make clean,
which is great if you often have to make clean because your makefile is broken,
or if you often reconfigure your build options (e.g. debug
On Feb 7, 2020, at 13:26, Han-Wen Nienhuys wrote:
>
> To do https://codereview.appspot.com/561390043/ properly, I have to expand
> the heap when GC notifies us that a collection took place. Unfortunately,
> libgc notifications are done with the garbage collector lock held. So I'll
> need
Dear LilyPond developers,
I'm facing the bittersweet experience of becoming an employee again on Monday.
I'm not sure what the ramp-up will require or what the new cadence of my life
will be, but I will certainly have less time to devote to LilyPond. Hopefully,
it will be a reversion to the
On Feb 7, 2020, at 10:39, Han-Wen Nienhuys wrote:
>
> There are a couple of downsides to this format:
> * The number takes up space in the
>git log --format=short
upside: the number appears in git log —format=short
> * The number is meaningless without the site that hosts the tracker
On Feb 6, 2020, at 18:35, Paolo Prete wrote:
>
> (I re-post this here, because it's a bug and maybe you have an easy fix for
> it)
Paolo,
I'm not sure where you're re-posting from, but the expected forum for bug
reports is https://lists.gnu.org/mailman/listinfo/bug-lilypond . The audience
On Feb 6, 2020, at 09:32, Kieren MacMillan
wrote:
>
>> So what I want to work on is some sort of ”Splittable Staff“.
This terminology looks at the use case from a point of view that might not be
very consistent with LilyPond. Let's think carefully about what we want to
call this, because
On Feb 5, 2020, at 20:26, Thomas Morley wrote:
> So to repeat myself, everyone should take his post literal, not offending!
>
> I'd love to see a community bearing different personalities, even
> personalities with problematic conversation skills.
> For me it's like strange english from a
On Feb 5, 2020, at 10:09, Jonas Hahnfeld wrote:
>
> required to synchronize the review and the associated issue. I propose
> to start using GitLab hosted on gitlab.com [4] for all of this:
> Repository, Issues, and Merge Requests (MR) for reviews. It was
> evaluated 'C' in 2015 [5] and should be
On Feb 5, 2020, at 05:45, Han-Wen Nienhuys wrote:
>
> Having a CoC gives us a set of guidelines, a process and a set of
> corrective actions to take to help keep things nice.
I prefer the implicit good-neighbour agreement we have now.
—
Dan
On Feb 5, 2020, at 07:59, jonas.hahnf...@gmail.com wrote:
>
> and it seems stable, but I have yet to build a theory why OS thread
> migration actually improves performance…
Educated guess: The core gets too hot. The OS is not allowed to move the
thread to a cooler core, so it throttles the
On Feb 5, 2020, at 06:57, David Kastrup wrote:
>
> Our current process is awkward technically, not because of the roles its
> human players assume.
+1(000)
For a long time, the LilyPond project has needed these:
1. more and better automation to reduce the load on the (amazingly
> On Feb 4, 2020, at 16:14, Dan Eble wrote:
>
> Begin forwarded message:
>>
>> Subject: [testlilyissues:issues] #5719 Tie formatting maintenance
> ...
>> commit 937e413c0f399b2ec44785b7ca29d61cf7b24cff
>> Author: Dan Eble nine.fierce.ball...@gmail.com
Begin forwarded message:
>
> Subject: [testlilyissues:issues] #5719 Tie formatting maintenance
...
> commit 937e413c0f399b2ec44785b7ca29d61cf7b24cff
> Author: Dan Eble nine.fierce.ball...@gmail.com
> Date: Fri Jan 31 13:48:35 2020 -0500
The changes for Issue 5719 remove a heade
On Feb 4, 2020, at 11:02, Jonas Hahnfeld wrote:
>> That would be my impulse as well. It is not like this code appears to
>> have notable drawbacks for the unafflicted platforms.
>
> Except for very funny overflows and negative signs if the value is too
> large to fit into I64 ;-P
>
> unsigned
> On Feb 4, 2020, at 10:32, Jonas Hahnfeld wrote:
>
> Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
$ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2
-mfpmath=sse -I include -I .. rational.cc
>>
$
On Feb 4, 2020, at 09:44, Masamichi Hosoda wrote:
>
> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
> +// it seems that static cast from `unsigned long long` to `double`
> +// by x86 SSE2 raises an internal compile error.
> +// However, static cast from `signed long long` to `double`
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
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
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
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?
On Feb 2, 2020, at 09:15, hanw...@gmail.com wrote:
>
>> I don't like this methodology, what's the difference over disabling
>> -Wconversion
>
> My selfish is reason is that it gets the warnings out of the way of
> whomever is not interested in fixing casts, including myself.
About 1/3 of the
On Feb 1, 2020, at 11:26, Jonas Hahnfeld wrote:
>
> +# disable Python's hash randomization until 'make check' is fixed
> +PYTHONHASHSEED=0
> +export PYTHONHASHSEED
Looks good, works fine.
—
Dan
On Feb 1, 2020, at 10:15, Jonas Hahnfeld wrote:
> How distracting are the profiling differences for your work? I'm
> obviously not a big fan of reverting bc8a3fa7e4, but I also don't want
> to block anybody else from making progress.
The log differences are more annoying than the profile
301 - 400 of 822 matches
Mail list logo
