Han-Wen Nienhuys writes:
> On Wed, Jan 22, 2020 at 11:43 PM David Kastrup wrote:
>
>> > Actually, the I was comparing the -O2 build with the -O0 build.
>> >
>> > When recompiling, the Scheme init (reading .scm files) takes 0.31s in 1.8
>> > vs. 2.7s in 2.0, a 9x slowdown.
>>
>> The Guile-2 compi
Hi,
I once pushed the /dev/guile-v2-work-branch to our repo.
Would it be of help to have a /dev/guile-v3-work as well?
If so, I'd need to do some clean up, currently my lily-guile3-build is
a bit messy.
Cheers,
Harm
Thomas Morley writes:
> Hi,
>
> I once pushed the /dev/guile-v2-work-branch to our repo.
> Would it be of help to have a /dev/guile-v3-work as well?
> If so, I'd need to do some clean up, currently my lily-guile3-build is
> a bit messy.
Can you summarize the differences? If there are extensive
Am Do., 23. Jan. 2020 um 10:35 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > I once pushed the /dev/guile-v2-work-branch to our repo.
> > Would it be of help to have a /dev/guile-v3-work as well?
> > If so, I'd need to do some clean up, currently my lily-guile3-build is
>
Am Do., 23. Jan. 2020 um 10:48 Uhr schrieb Thomas Morley
:
>
> Am Do., 23. Jan. 2020 um 10:35 Uhr schrieb David Kastrup :
> >
> > Thomas Morley writes:
> >
> > > Hi,
> > >
> > > I once pushed the /dev/guile-v2-work-branch to our repo.
> > > Would it be of help to have a /dev/guile-v3-work as well?
Wednesday, January 22, 2020, 10:35:45 PM, Michael Käppler wrote:
Am 22.01.2020 um 14:03 schrieb Peter Toye:
> Yes, I would suggest that you start from scratch again.
That's because the keyboard-layout package is not installed in LilyDev v1 by
default. In LilyDev v2, it will be there.
I hadn't
Il giorno gio 23 gen 2020 alle 10:45, Peter Toye
ha scritto:
Wednesday, January 22, 2020, 10:35:45 PM, Michael Käppler wrote:
Am 22.01.2020 um 14:03 schrieb Peter Toye:
Yes, I would suggest that you start from scratch again.
That's because the keyboard-layout package is not installed
I'm quite sure that you have more experience with C++ than me, however,
I'm not really happy with this change since it makes the code
substantially uglier. Isn't there another solution for the problem?
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh
File flowe
Urs Liska writes:
> Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska:
>>
>> You mean that a package has to export every function or variable
>> separately? I think that would be good wrt self-documentation.
>>
>
> This gave me another idea: How would it be if elements (functions,
> va
Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska:
> Am Mittwoch, den 22.01.2020, 11:06 +0100 schrieb David Kastrup:
> > Urs Liska writes:
> >
> > > Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska:
> > > > > Ok. One thing to think about is that we want package files
> > > > >
On 2020/01/23 11:33:11, lemzwerg wrote:
> I'm quite sure that you have more experience with C++ than me,
however, I'm not
> really happy with this change since it makes the code substantially
uglier.
> Isn't there another solution for the problem?
>
>
https://codereview.appspot.com/579240043/diff
> Why is this ugly? std::string is really the name of the class.
No question, but I would prefer
struct xxx {
using std:string;
string foo;
string bar;
string baz;
}
}
to
struct xxx {
std::string foo;
std::string bar;
std::string baz;
}
for example, to incr
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh
File flower/include/file-name.hh (right):
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47
flower/include/file-name.hh:47: std::string root_;
On 2020/01/23 11:33:11, l
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh
File flower/include/file-name.hh (right):
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47
flower/include/file-name.hh:47: std::string root_;
On 2020/01/23 11:33:11, l
On 2020/01/23 12:43:34, lemzwerg wrote:
> > Why is this ugly? std::string is really the name of the class.
>
> No question, but I would prefer
>
> struct xxx {
> using std:string;
>
> string foo;
> string bar;
> string baz;
> }
> }
>
> to
>
> struct xxx {
> std::strin
On 2020/01/23 14:36:26, dak wrote:
> On 2020/01/23 12:43:34, lemzwerg wrote:
> > > Why is this ugly? std::string is really the name of the class.
> >
> > No question, but I would prefer
> >
> > struct xxx {
> > using std:string;
> >
> > string foo;
> > string bar;
> > string ba
Hello,
Here is the current patch countdown list. The next countdown will be on
January 25th
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
Push:
5665 Remove broken and undocumented tracing features - Jonas
Am 23.01.2020 um 12:11 schrieb Federico Bruni:
If it helps, I can release v2 tomorrow.
Michael, let me know if you have other PRs to send.
Yes, I have some, but did not have the time to test them thoroughly.
But they are completely unrelated to Peter's recent problems.
I'd like to to test Dan's
> On 23 Jan 2020, at 13:43, lemzwerg--- via Discussions on LilyPond development
> wrote:
>
>> Why is this ugly? std::string is really the name of the class.
>
> No question, but I would prefer
>
> struct xxx {
>using std:string;
>
>string foo;
>string bar;
>string baz;
> }
On 2020/01/22 10:18:48, hanwenn wrote:
> alternately, we could just do -Wno-conversion in the makefile, and we
wouldn't
> have to do any work here at all.
These warnings weren't implemented just to irritate us. They were
implemented because C is the basement of C++ and there are bugs hiding
in it
OK, point taken. Thanks for all the responses.
Well, then the ugly way :-)
https://codereview.appspot.com/579240043/
On 2020/01/23 20:02:58, Dan Eble wrote:
> On 2020/01/22 10:18:48, hanwenn wrote:
> > alternately, we could just do -Wno-conversion in the makefile, and
we wouldn't
> > have to do any work here at all.
>
> These warnings weren't implemented just to irritate us. They were
implemented
> because C is
Am Do., 23. Jan. 2020 um 10:48 Uhr schrieb Thomas Morley
:
>
> Am Do., 23. Jan. 2020 um 10:35 Uhr schrieb David Kastrup :
> >
> > Thomas Morley writes:
> >
> > > Hi,
> > >
> > > I once pushed the /dev/guile-v2-work-branch to our repo.
> > > Would it be of help to have a /dev/guile-v3-work as well?
hanw...@gmail.com writes:
> In LilyPond, the bulk of the warnings come from unsigned 64 bit sizes,
> ie. vector and list sizes.
>
> In order to cause an error, you would have to create vector or list of
> over 2G of
> elements (on 32 bit architecture), so the unsigned size would be
> converted to
Il giorno gio 23 gen 2020 alle 18:30, Michael Käppler
ha scritto:
We figured out, that the clipboard service /usr/bin/VBoxClient
--clipboard is not running
on Peter's LilyDev instance. I could not reproduce this on my v1
image.
What we both noticed was that startup occassionally fails with
On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote:
> The GUILE 2.0 release
>
> https://lwn.net/Articles/428288/
>
> has one big red flag for me.
>
> * Switch to the Boehm-Demers-Weiser garbage collector
>
We can easily measure this, by adding the following to
#(display (version))
#(di
Han-Wen Nienhuys writes:
> On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote:
>
>> The GUILE 2.0 release
>>
>> https://lwn.net/Articles/428288/
>>
>> has one big red flag for me.
>>
>> * Switch to the Boehm-Demers-Weiser garbage collector
>>
>
> We can easily measure this, by adding th
On 2020/01/23 20:49:01, hanwenn wrote:
> I mean, if we were writing a new SSL library, I surely would want
scrutiny on
> every cast, but we aren't.
The question is, do you want scrutiny of any cast? If you do, then
keeping the warnings enabled and keeping the signal-to-noise ratio high
by casting
Am 23.01.2020 um 11:45 schrieb Peter Toye:
Re: Looking for help in configuring LilyDev in VirtualBox Wednesday,
January 22, 2020, 10:35:45 PM, Michael Käppler wrote:
Am 22.01.2020 um 14:03 schrieb Peter Toye:
> Yes, I would suggest that you start from scratch again.
That's be
29 matches
Mail list logo
