On 03/01/2021 10:07, James wrote:
my desktop before that was from 2013 (i5 something) and I was getting
sub hour make doc times even then but using 3 CPUs.
So you having those timings while using a -j5 option ... wow!
I am obviously inhabiting some technological bubble that I wasn't aware
I
Hello
On 02/01/2021 16:58, Thomas Morley wrote:
Am Sa., 2. Jan. 2021 um 14:41 Uhr schrieb James :
On 02/01/2021 12:20, Thomas Morley wrote:
A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:
Hours?
Am Sa., 2. Jan. 2021 um 14:41 Uhr schrieb James :
>
>
> On 02/01/2021 12:20, Thomas Morley wrote:
> > A full `make doc` takes hours for me, even if invoked with `make doc
> > -j5 CPU_COUNT=5`
> > Thus I hardly do so, but use the CG-documented methods:
>
> Hours?
>
> Really?
>
> Perhaps 'an hour'
On 02/01/2021 15:38, Kieren MacMillan wrote:
I’m using an 11-year old iMac, running LilyDev in a Linux VM. =)
Oh .. OK.
Yeah. Don't make doc.
%^)
James
Hi all,
>> Perhaps 'an hour' if you were using some very, very old CPU - but even using
>> a single CPU on an 'old' i5 Intel system a full make doc for me took less
>> than 50 mins. That last time it took longer than an hour was when I had an
>> old (8+ years ago) iMac running make doc in a
Hello
On 02/01/2021 14:07, Trevor wrote:
James wrote 02/01/2021 13:41:06
On 02/01/2021 12:20, Thomas Morley wrote:
A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:
Hours?
Really?
Perhaps 'an hour'
James wrote 02/01/2021 13:41:06
On 02/01/2021 12:20, Thomas Morley wrote:
A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:
Hours?
Really?
Perhaps 'an hour' if you were using some very, very old
On 02/01/2021 12:20, Thomas Morley wrote:
A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:
Hours?
Really?
Perhaps 'an hour' if you were using some very, very old CPU - but even
using a single CPU
Am Sa., 2. Jan. 2021 um 13:20 Uhr schrieb Thomas Morley
:
>
> Hi Kieren,
>
> Am Sa., 2. Jan. 2021 um 00:00 Uhr schrieb Kieren MacMillan
> :
> >
> > Hi Michael (et al.),
> >
> > > please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
> > > instead. I adjusted some parts of this
Hi Kieren,
Am Sa., 2. Jan. 2021 um 00:00 Uhr schrieb Kieren MacMillan
:
>
> Hi Michael (et al.),
>
> > please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
> > instead. I adjusted some parts of this section last year. However, I
> > would be happy to hear if something
It shouldn't take multiple hours unless your system is very slow. A few 10s of
minutes is a more reasonable expectation.
On 01/01/2021 23:00, Kieren MacMillan wrote:
Hi Michael (et al.),
please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
instead. I adjusted some
Hi Michael (et al.),
> please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
> instead. I adjusted some parts of this section last year. However, I
> would be happy to hear if something remains still unclear.
This is great. Thanks.
I have now compiled Lilypond on my
Hi Kieren,
Hi Jonas (et al.),
I would claim that the contributor experience has been pretty stable
since the initial switch to GitLab. Enabling CI and the recent work to
also run 'make check' automatically shouldn't change much from a
contributor's point of view, I hope.
I can't promise to
Il giorno ven, gen 1 2021 at 16:37:40 -0500, Kieren MacMillan
ha scritto:
Hi Jonas (et al.),
I would claim that the contributor experience has been pretty stable
since the initial switch to GitLab. Enabling CI and the recent work
to
also run 'make check' automatically shouldn't
Hi Jonas (et al.),
> I would claim that the contributor experience has been pretty stable
> since the initial switch to GitLab. Enabling CI and the recent work to
> also run 'make check' automatically shouldn't change much from a
> contributor's point of view, I hope.
> I can't promise to give
Hi Kieren,
I would claim that the contributor experience has been pretty stable
since the initial switch to GitLab. Enabling CI and the recent work to
also run 'make check' automatically shouldn't change much from a
contributor's point of view, I hope.
I can't promise to give detailed guidance,
Hello all!
I’m just wondering if the new process / repo / workflow is in a state where an
enthusiastic but oft-discouraged[-by-the-state-of-the-tech-and-process] Frog
might finally dive in fully to the contribution process?
If so, which Jedi Master(s) might patiently guide this young Padawan
2012/4/22 James pkx1...@gmail.com:
Hello,
On 22 April 2012 00:02, Francisco Vila paconet@gmail.com wrote:
2012/4/20 Graham Percival gra...@percival-music.ca:
We do not have a long history of flawless git actions from
translations, so my preference would be not to touch anything.
Good
Francisco Vila paconet@gmail.com writes:
On the other hand, I can not omit doing things forever just for
safety. Therefore, I have to assume a certain degree of risk. I
already apologized when it went bad. After that, everything has gone
smoothly. Git history will judge us all.
The
Git history will judge us all.
Interesting. Up to now I've assumed God does this.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Werner LEMBERG w...@gnu.org writes:
Git history will judge us all.
Interesting. Up to now I've assumed God does this.
If HE weren't a fan of distributed version control systems, why create
the world in the first place?
--
David Kastrup
___
Interesting. Up to now I've assumed God does this.
If HE weren't a fan of distributed version control systems, why
create the world in the first place?
Good point :-)
This reminds me of a joke:
Two planets meet.
`How are you?'
`Well, not very well.'
`How comes?'
`I suffer from
Hello,
On 22 April 2012 11:59, David Kastrup d...@gnu.org wrote:
Werner LEMBERG w...@gnu.org writes:
Git history will judge us all.
Interesting. Up to now I've assumed God does this.
If HE weren't a fan of distributed version control systems, why create
the world in the first place?
Le 20/04/2012 23:42, Graham Percival disait :
On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote:
Le 19/04/2012 21:30, Graham Percival disait :
- nobody touches the release/unstable branch, other than
translators, who may merge with that if they want to and don't
Jean-Charles Malahieude lily...@orange.fr writes:
Le 20/04/2012 23:42, Graham Percival disait :
On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote:
Le 19/04/2012 21:30, Graham Percival disait :
- nobody touches the release/unstable branch, other than
translators, who
On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote:
[1] why oh why does the main GNU editor not use the official
extension language for the GNU operating system??
Same reason why its keyboard shortcuts are only so-so compatible with
CUA and/or GNOME: its development was
Bernard Hurley bern...@marcade.biz writes:
On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote:
[1] why oh why does the main GNU editor not use the official
extension language for the GNU operating system??
Same reason why its keyboard shortcuts are only so-so compatible
On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote:
Bernard Hurley bern...@marcade.biz writes:
On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote:
[1] why oh why does the main GNU editor not use the official
extension language for the GNU operating system??
Bernard Hurley bern...@marcade.biz writes:
On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote:
Bernard Hurley bern...@marcade.biz writes:
That sounds interesting. Personally I would rather see Emacs
re-implemented using Common Lisp instead of Emacs Lisp.
2012/4/20 Graham Percival gra...@percival-music.ca:
We do not have a long history of flawless git actions from
translations, so my preference would be not to touch anything.
Good idea! The definitive recipe for eternal flawless development is
not to touch anything, ever. Better safe than sorry.
Hello,
On 22 April 2012 00:02, Francisco Vila paconet@gmail.com wrote:
2012/4/20 Graham Percival gra...@percival-music.ca:
We do not have a long history of flawless git actions from
translations, so my preference would be not to touch anything.
Good idea! The definitive recipe for
On Apr 19, 2012, at 9:30 PM, Graham Percival wrote:
We have a new release candidate, slower development, highlights on
development problems, and a vacation.
SLOWER DEVELOPMENT
Development has slowed to a trickle. I'm not certain if this is
just because it's late spring (i.e. busy
On Thu, Apr 19, 2012 at 12:30 PM, Graham Percival
gra...@percival-music.ca wrote:
Trying to anticipate future problems, I recalled guile
indentation:
http://codereview.appspot.com/4896043/
My impression is that it would only take an hour or two to fix
this, and then we could standardize all
Le 19/04/2012 21:30, Graham Percival disait :
We have a new release candidate, slower development, highlights on
development problems, and a vacation.
RELEASE CANDIDATE
As always, this means:
- activity on master goes on as normal.
- nobody touches the release/unstable branch, other than
On Fri, Apr 20, 2012 at 08:27:20AM -0700, Adam Spiers wrote:
On Thu, Apr 19, 2012 at 12:30 PM, Graham Percival
gra...@percival-music.ca wrote:
Trying to anticipate future problems, I recalled guile
indentation:
http://codereview.appspot.com/4896043/
I would be happy to tackle this and
On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote:
Le 19/04/2012 21:30, Graham Percival disait :
- nobody touches the release/unstable branch, other than
translators, who may merge with that if they want to and don't
break anything.
The question of whether
On Fri, Apr 20, 2012 at 3:23 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Apr 19, 2012, at 9:30 PM, Graham Percival wrote:
Development has slowed to a trickle. I'm not certain if this is
just because it's late spring (i.e. busy academic time), or if
people are holding their
Graham Percival gra...@percival-music.ca writes:
[1] why oh why does the main GNU editor not use the official
extension language for the GNU operating system??
Same reason why its keyboard shortcuts are only so-so compatible with
CUA and/or GNOME: its development was started more than 30 years
We have a new release candidate, slower development, highlights on
development problems, and a vacation.
RELEASE CANDIDATE
As always, this means:
- activity on master goes on as normal.
- nobody touches the release/unstable branch, other than
translators, who may merge with that if they
Graham Percival gra...@percival-music.ca writes:
SLOWER DEVELOPMENT
Development has slowed to a trickle. I'm not certain if this is
just because it's late spring (i.e. busy academic time), or if
people are holding their breaths waiting for the stable release
(i.e. not putting forward any
On Thu, Apr 19, 2012 at 09:52:55PM +0200, David Kastrup wrote:
Graham Percival gra...@percival-music.ca writes:
SLOWER DEVELOPMENT
Development has slowed to a trickle. I'm not certain if this is
I am partly responsible.
A power-law function for development work is certainly predicted
Hello,
On 19 April 2012 20:52, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
SLOWER DEVELOPMENT
Development has slowed to a trickle. I'm not certain if this is
just because it's late spring (i.e. busy academic time), or if
people are holding their
42 matches
Mail list logo
