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 w
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?
Re
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' if
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 lin
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' i
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 CP
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 o
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 remains
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 part
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 machine!
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 gi
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 change
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 det
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, th
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 th
Hello,
On 22 April 2012 11:59, David Kastrup wrote:
> Werner LEMBERG 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?
>
God Loves Git
>> 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 f
Werner LEMBERG 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
___
lilypond-deve
> 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
Francisco Vila 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 thing to remember is
2012/4/22 James :
> Hello,
>
> On 22 April 2012 00:02, Francisco Vila wrote:
>> 2012/4/20 Graham Percival :
>>> 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
Hello,
On 22 April 2012 00:02, Francisco Vila wrote:
> 2012/4/20 Graham Percival :
>> 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 touc
2012/4/20 Graham Percival :
> 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.
--
Francisco Vila. Ba
Bernard Hurley writes:
> On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote:
>> Bernard Hurley writes:
>>
>> > That sounds interesting. Personally I would rather see Emacs
>> > re-implemented using Common Lisp instead of Emacs Lisp.
>>
>> http://common-lisp.net/project/climacs/> is
On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote:
> Bernard Hurley 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 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 wit
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 deve
>> [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 ago,
> when nobody had ever heard of
Jean-Charles Malahieude 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 may
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
brea
Graham Percival 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 ago,
when nobody had
On Fri, Apr 20, 2012 at 3:23 PM, 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 breaths waiting f
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 wheth
On Fri, Apr 20, 2012 at 08:27:20AM -0700, Adam Spiers wrote:
> On Thu, Apr 19, 2012 at 12:30 PM, Graham Percival
> wrote:
> > Trying to anticipate future problems, I recalled guile
> > indentation:
> > http://codereview.appspot.com/4896043/
>
> I would be happy to tackle this and *hope* to have a
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 Thu, Apr 19, 2012 at 12:30 PM, Graham Percival
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 the scheme indentatio
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. bu
Hello,
On 19 April 2012 20:52, David Kastrup wrote:
> Graham Percival 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 stabl
On Thu, Apr 19, 2012 at 09:52:55PM +0200, David Kastrup wrote:
> Graham Percival 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
by numerous st
Graham Percival 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 major patches), or j
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 want
43 matches
Mail list logo
