Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld:
Thanks for testing! I assume this is also enabling Guile optimizations
during LilyPond runtime? It would be interesting to see if there's a
gain from just compiling the bytecode with optimizations. That would be
a one-time cost that may be worth p
Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld:
[snip]
Thanks for testing! I assume this is also enabling Guile optimizations
during LilyPond runtime? It would be interesting to see if there's a
gain from just compiling the bytecode with optimizations. That would be
a one-time cost that may be
On Tue, 2024-04-02 at 16:40 +0200, Michael Käppler wrote:
> Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond
> development:
> > As pointed out by Han-Wen in November, this is actually fairly little
> > code that gets dropped; we need to keep some related to optimizations
>
Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on
LilyPond development:
This is now up for review in the following merge request:
https://gitlab.com/lilypond/lilypond/-/merge_requests/2293
As pointed out by Han-Wen in November, this is actually fairly little
code that gets drop
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
> Step 4: Remove compatibility code for Guile 2.2
> This can happen after we made one or two releases with only Guile 3.0.
This is now up for review in the following merge request:
https://gitlab.com/lilypond/lilypond/-/merge_request
On Mon, 2023-12-04 at 21:55 +0100, Jonas Hahnfeld wrote:
> On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
>
> > then remove automatic detection of Guile 2.2 from configure.
>
> I did not yet upload a merge request to make Guile 3.0 the default for
> all builds:
>> then remove automatic detection of Guile 2.2 from configure.
>
> I did not yet upload a merge request to make Guile 3.0 the default
> for all builds: After more thought, I believe it's better to do this
> together with the removal of automatic configure support for Gu
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
> Step 3: Switch to Guile 3.0
> Afterwards, we can merge
> https://gitlab.com/lilypond/lilypond/-/merge_requests/2163
I put the merge request back on Patch::review, along with
https://gitlab.com/lilypond/lilypond/-/merge_requests
s 11 21H2, Intel Core i5-1135G7.
>
> "
> > lilypond.exe scheme-sandbox
> GNU LilyPond 2.25.10 (running Guile 3.0)
> Processing
> `C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly'
> P
lyPond 2.25.10 (running Guile 3.0)
Processing
`C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly'
Parsing...
GNU Guile 3.0.9
"
When I run convert-ly, it makes version statements "2.25.9". I can't
> “_” needs to be replaced with “G_”. Already in Guile 2, but Guile 3 checks for
> it more eagerly.
Fixed in LSR.
signature.asc
Description: This is a digitally signed message part
> Le 12 nov. 2023 à 19:14, Robin Bannister a écrit :
>
> If I take the code of LSR1098 [1] , without the demo part,
> Guile3 errors the input-warning call:
>
> GNU LilyPond 2.25.10 (running Guile 3.0)
> Processing `1.ly'
> Parsing...
> 1.ly:38:2: error:
Jonas Hahnfeld wrote:
On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote:
We are happy to announce the release of LilyPond 2.25.10.
And here are the binaries with Guile 3.0, built using
https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and
https://gitlab.com/lilypond/lilypond
On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote:
> We are happy to announce the release of LilyPond 2.25.10.
And here are the binaries with Guile 3.0, built using
https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and
https://gitlab.com/lilypond/lilypond/-/merge_requests/2
h the current
> > situation, let me propose to move to Guile 3.0. Below is a plan for
> > that switch, with a transition period to test the official binaries.
> > Last time, when going from Guile 1.8 to version 2.2, the switch had to
> > coincide with moving away from GUB. Betw
On Sun, Nov 5, 2023 at 10:36 PM Jonas Hahnfeld via Discussions on LilyPond
development wrote:
> Hi all,
>
> I hear LilyPond hasn't changed its Guile version since some time (more
> than 18 months). So before we get too comfortable with the current
> situation, let me propose
>> Step 1: Officially support Guile 3.0 and add optional CI testing I
>> opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162
>> to add some compatibility with earlier versions of Guile 3.0 and
>> then implement detection support in configure. It also crea
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
> Step 1: Officially support Guile 3.0 and add optional CI testing
> I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to
> add some compatibility with earlier versions of Guile 3.0 and then
> implement detectio
>> Please let me know of your comments!
>
> I'm very happy that you got Guile 3.0 working on Windows. Kudos for
> that (and I guess we need to send big thanks to Mike Gran too).
+1
> What I don't really understand is why you want to add compatibility
> with Gui
ble branch. The branch "main" receives all development
and 3.0.x releases are simply cut from it.
That's even worse for stability than the setup you describe.
signature.asc
Description: This is a digitally signed message part
Jean Abou Samra writes:
> What I don't really understand is why you want to add compatibility
> with Guile 3.0.x for small x. Upstream completely breaks the normal
> expectation from what you would find in a point release, by putting
> features and even severely backwards inc
On Sun, 2023-11-05 at 22:48 +0100, Jean Abou Samra wrote:
> What I don't really understand is why you want to add compatibility
> with Guile 3.0.x for small x. Upstream completely breaks the normal
> expectation from what you would find in a point release, by putting
> features
Le dimanche 05 novembre 2023 à 22:36 +0100, Jonas Hahnfeld via Discussions on
LilyPond development a écrit :
> Please let me know of your comments!
I'm very happy that you got Guile 3.0 working on Windows. Kudos for
that (and I guess we need to send big thanks to Mike Gran too).
What
Hi all,
I hear LilyPond hasn't changed its Guile version since some time (more
than 18 months). So before we get too comfortable with the current
situation, let me propose to move to Guile 3.0. Below is a plan for
that switch, with a transition period to test the official binaries.
Last
Le 23/05/2022 à 23:00, Wol a écrit :
On 23/05/2022 20:19, Han-Wen Nienhuys wrote:
Vendoring Guile seems totally impractical. The Guile compilation does
some sort of bootstrapping, which makes building it from scratch
glacially slow (like: O(1 hour)), so it would be impossible for day to
day deve
Wol writes:
> On 23/05/2022 20:19, Han-Wen Nienhuys wrote:
>> Vendoring Guile seems totally impractical. The Guile compilation does
>> some sort of bootstrapping, which makes building it from scratch
>> glacially slow (like: O(1 hour)), so it would be impossible for day to
>> day development work
On 23/05/2022 20:19, Han-Wen Nienhuys wrote:
Vendoring Guile seems totally impractical. The Guile compilation does
some sort of bootstrapping, which makes building it from scratch
glacially slow (like: O(1 hour)), so it would be impossible for day to
day development work.
Just an idea, if "curr
On Mon, May 23, 2022 at 9:19 PM Han-Wen Nienhuys wrote:
> I'm missing the context for this proposal.
>
Something in the original thread from Jonas made me think some distros were
wrangling keeping up distributing
guile only for lilypond's benefit. It's possible I misunderstood and he
actually me
On Sun, May 22, 2022 at 7:48 PM Luca Fascione wrote:
> I would like to bring up an option that I'd expect fair few of you will
> _really_ not like.
> I'm doing this not because I necessarily believe it to be a
> particularly good way forward,
> rather because I feel it is sometimes useful to artic
This also makes a lot of sense to me, yes.
L
On Mon, 23 May 2022, 13:12 Jean Abou Samra, wrote:
>
>
> Le 22/05/2022 à 21:52, Luca Fascione a écrit :
> >
> > On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote:
> >
> > On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> > > So at
Le 22/05/2022 à 21:52, Luca Fascione a écrit :
On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote:
On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> So at the cost of rocking the cage a bit hard, I came asking the
> uncomfortable question:
> what would happen if (f
On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote:
> On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> > So at the cost of rocking the cage a bit hard, I came asking the
> > uncomfortable question:
> > what would happen if (for this unique circumstance) we'd do what one
> > would norma
On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> So at the cost of rocking the cage a bit hard, I came asking the
> uncomfortable question:
> what would happen if (for this unique circumstance) we'd do what one
> would normally consider poor practice?
Let's call your proposal by its true,
On Sun, May 22, 2022 at 8:02 PM David Kastrup wrote:
> What do you mean with "shipped"?
I mean that when you clone the lilypond repo you'd find one more directory,
say
guile-2.2.7+/
or
guile-3.0.8+/
or something like that.
In fact we'd likely end up compiling a slightly different version thereo
Luca Fascione writes:
> I would like to bring up an option that I'd expect fair few of you will
> _really_ not like.
> I'm doing this not because I necessarily believe it to be a
> particularly good way forward,
> rather because I feel it is sometimes useful to articulate in words why an
> "obvio
heir own initiative and
> >> end up with one version of Guile they are going to ship for their whole
> >> distro, it would be good if that does not end up in making LilyPond
> >> disappear. That's all.
> >>
> >> What we _recommend_ and use ourselves
t;> disappear. That's all.
>>
>> What we _recommend_ and use ourselves is an entirely different matter.
>
>
> OK, but in that case, what is your request concretely?
> Current LilyPond master works with Guile 3.0.
That's essentially all. I wasn't sure of that
atter.
OK, but in that case, what is your request concretely?
Current LilyPond master works with Guile 3.0. Do you
want to add it to the CI?
Jean
Thomas Morley writes:
> Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>>
>>
>> #(ly:set-option 'warning-as-error #t)
>> %% not sure why these warnings appear twice [dfe]
>> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
>> -#(ly:expect-warning (_ "can
Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > some remarks:
> >
> > Guile-3.0
> > First I compiled successfully guile-master from their repo, giving GNU
> > Guile 3.0.0.6-f3298
> > Tr
Thomas Morley writes:
> Hi,
>
> some remarks:
>
> Guile-3.0
> First I compiled successfully guile-master from their repo, giving GNU
> Guile 3.0.0.6-f3298
> Trying to compile LilyPond with that guile (ofcourse adding a bunch of
> patches) I had some problems pointi
Am Mi., 22. Jan. 2020 um 00:41 Uhr schrieb Karlin High :
>
> On 1/21/2020 5:10 PM, Thomas Morley wrote:
> > Afterwards I've got a successful ´make´ with current LilyPond-master.
>
> So it's a functional LilyPond with guile-3.0? How does it perform if fed
> something
On 1/21/2020 5:10 PM, Thomas Morley wrote:
Afterwards I've got a successful ´make´ with current LilyPond-master.
So it's a functional LilyPond with guile-3.0? How does it perform if fed
something big? I'm thinking of the thread on benchmarking that used
Vaughan McAlley's
Hi,
some remarks:
Guile-3.0
First I compiled successfully guile-master from their repo, giving GNU
Guile 3.0.0.6-f3298
Trying to compile LilyPond with that guile (ofcourse adding a bunch of
patches) I had some problems pointing configure to the correct guile
and guile-config to the correct
Paul Morris wrote
> Hi all, On mac osx 10.10.2 I get the following when trying to install
> LilyDev 3:
Nevermind... I was doing it wrong. Seems to be working fine now.
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/lilydev-3-0-iso-not-mounting-on-mac-osx-tp1725
Hi all, On mac osx 10.10.2 I get the following when trying to install LilyDev
3:
___
Warning
The following disk images couldn’t be opened
Image
lilydev-3.0.iso
Reason
no mountable file systems
___
…after downloading from here:
http://www.et.byu.edu
"Janek Warchoł" schrieb:
>2014/1/12 Carl Peterson :
>> What I would *ultimately* like is the ability for someone to visually
>write
>> each part on separate staves (or using two staves with two voices
>each),
>> then those parts are translated into the template without any direct
>code
>> manipu
Janek Warchoł writes:
> 2014/1/12 Carl Peterson :
>> What I would *ultimately* like is the ability for someone to visually
>> write each part on separate staves (or using two staves with two
>> voices each), then those parts are translated into the template
>> without any direct code manipulation
2014/1/12 Carl Peterson :
> What I would *ultimately* like is the ability for someone to visually write
> each part on separate staves (or using two staves with two voices each),
> then those parts are translated into the template without any direct code
> manipulation. The visual interface would b
On Sat, Jan 11, 2014 at 11:50 PM, Paul Morris wrote:
> Carl Sorensen-3 wrote
> > I can't speak for Carl P's work. For me, effective LP input files
> require
> > structure (variables, contexts) that MusicXML knows nothing of. And it's
> > generally easier to create them than to fix them on import
Carl Sorensen-3 wrote
> I can't speak for Carl P's work. For me, effective LP input files require
> structure (variables, contexts) that MusicXML knows nothing of. And it's
> generally easier to create them than to fix them on import.
I see what you mean. Unfortunately it makes it harder to use
Am Donnerstag, den 09.01.2014, 10:13 -0500 schrieb Carl Peterson:
> On Thu, Jan 9, 2014 at 6:20 AM, David Kastrup wrote:
> > Another problem is that LilyPond has a usage philosophy and workflow
> > that strongly penalizes manual tweaks. Graphically/manually oriented
> > workflows detract from the
Janek Warchoł writes:
> 2014/1/11 David Kastrup :
>> One very nice integrated experience is offered by preview-latex
>> http://www.gnu.org/software/auctex/preview-latex>.
>
>
> Indeed, this is very nice. Although i haven't used it, i know i would
> enjoy it :)
Well, actually it's a lot better t
2014/1/11 David Kastrup :
> One very nice integrated experience is offered by preview-latex
> http://www.gnu.org/software/auctex/preview-latex>.
Indeed, this is very nice. Although i haven't used it, i know i would
enjoy it :)
j
___
lilypond-devel ma
On Jan 10, 2014, at 11:41 PM, "Paul Morris" wrote:
> Seems like getting just the notes (not layout) out of an
> imported musicXML file should be an easy and straightforward thing, but I
> guess not?
>
I can't speak for Carl P's work. For me, effective LP input files require
structure (vari
Janek Warchoł writes:
> 2014/1/10 Urs Liska :
>>
>> Well,
>> compiling a few measures of a single staff feels nearly instantaneous, and
>> when you're editing an orchestral score this makes a huge difference.
>>
>> Generally I'd think it would be a good idea to have such an interface in
>> Fresco
2014/1/10 Urs Liska :
>
> Well,
> compiling a few measures of a single staff feels nearly instantaneous, and
> when you're editing an orchestral score this makes a huge difference.
>
> Generally I'd think it would be a good idea to have such an interface in
> Frescobaldi.
I know that this is not
Carl Peterson wrote
> Retyping by far. I pretty much write exclusively a cappella SATB, and I
> have developed a very specific template/workflow for the part combining
> and
> layout. I've tried a few different ways of getting the music from these
> formats into LP, and in each case, I found myself
Am 10.01.2014 23:37, schrieb Carl Peterson:
> On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska wrote:
>
>>
>> Well,
>> compiling a few measures of a single staff feels nearly instantaneous, and
>> when you're editing an orchestral score this makes a huge difference.
>>
>> Generally I'd think it would be
On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska wrote:
>
> Well,
> compiling a few measures of a single staff feels nearly instantaneous, and
> when you're editing an orchestral score this makes a huge difference.
>
> Generally I'd think it would be a good idea to have such an interface in
> Frescobal
On 1/9/14 9:43 PM, "SoundsFromSound" wrote:
>dak wrote
>> Joseph Rushton Wakeling >Word document features the
>> consistent use of document styles for arriving at typographically
>> superior results.
>>
>> --
>> David Kastrup
>>
>> __
Carl Peterson:
...
> Retyping by far. I pretty much write exclusively a cappella SATB, and I
> have developed a very specific template/workflow for the part combining and
> layout. I've tried a few different ways of getting the music from these
> formats into LP, and in each case, I found myself sp
Urs Liska:
> Am 10.01.2014 22:23, schrieb k...@aspodata.se:
> > Carl Peterson:
...
> >> There's a visual component and a matter of input error reduction, because I
> >> have been known to enter incorrect octaves or durations and not realize it
> >> until I've finished typing and have compiled the e
Am 10.01.2014 22:23, schrieb k...@aspodata.se:
Carl Peterson:
...
I know someone suggested just turning off the PDF conversion to speed
things up, but it's not just a matter of instantaneous aural feedback.
Ok.
There's a visual component and a matter of input error reduction, because I
have
Carl Peterson:
...
> I know someone suggested just turning off the PDF conversion to speed
> things up, but it's not just a matter of instantaneous aural feedback.
Ok.
> There's a visual component and a matter of input error reduction, because I
> have been known to enter incorrect octaves or dur
On Fri, Jan 10, 2014 at 12:46 AM, Paul Morris wrote:
> Carl Peterson wrote
> > I use MuseScore,
> > Scorio, and Finale Notepad (depending on where I am and how I feel)
> > for compositional work because they provide ease of note entry in the
> > composing process and the ability to have instant a
Carl Peterson wrote
> I use MuseScore,
> Scorio, and Finale Notepad (depending on where I am and how I feel)
> for compositional work because they provide ease of note entry in the
> composing process and the ability to have instant aural feedback on
> what I've written (particularly if I'm not at
dak wrote
> Joseph Rushton Wakeling <
> joseph.wakeling@
> > writes:
>
>> On 09/01/14 12:20, David Kastrup wrote:
>>> Another problem is that LilyPond has a usage philosophy and workflow
>>> that strongly penalizes manual tweaks. Graphically/manually oriented
>>> workflows detract from the impo
On 09/01/14 21:05, David Kastrup wrote:
That must be the reason why the typical Word document features the
consistent use of document styles for arriving at typographically
superior results.
I'm not sure that I feel happy about your benchmark for comparison. I think
Lilypond's user base is a
David Kastrup schrieb:
>Joseph Rushton Wakeling writes:
>
>> On 09/01/14 12:20, David Kastrup wrote:
>>> Another problem is that LilyPond has a usage philosophy and workflow
>>> that strongly penalizes manual tweaks. Graphically/manually
>oriented
>>> workflows detract from the importance of g
Joseph Rushton Wakeling writes:
> On 09/01/14 12:20, David Kastrup wrote:
>> Another problem is that LilyPond has a usage philosophy and workflow
>> that strongly penalizes manual tweaks. Graphically/manually oriented
>> workflows detract from the importance of getting good default
>> typesettin
On 09/01/14 12:20, David Kastrup wrote:
Another problem is that LilyPond has a usage philosophy and workflow
that strongly penalizes manual tweaks. Graphically/manually oriented
workflows detract from the importance of getting good default
typesetting.
I'm not sure that's necessarily the case.
Carl Peterson:
...
> Now, consider an IDE/GUI setup
> (perhaps an extension of Frescobaldi) that would allow me to define a
> variable for a voice, then pop up a musical staff to enter and play
> back the notes for that variable without dealing with the whole
> compilation process. No manual tweaki
On Thu, Jan 9, 2014 at 6:20 AM, David Kastrup wrote:
> Another problem is that LilyPond has a usage philosophy and workflow
> that strongly penalizes manual tweaks. Graphically/manually oriented
> workflows detract from the importance of getting good default
> typesetting.
I don't know that I ag
Urs Liska writes:
> Please don't beat me up, but that's something I wondered about for
> quite some time:
> Is there _any_ notion what a LilyPond 3.0 may be?
> I mean 2.0 followed on 1.8, and now we're already towards .20
>
> Is there any general idea about what
Urs Liska writes:
> Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen:
>> Urs Liska writes:
>>
>>> Is there _any_ notion what a LilyPond 3.0 may be?
>>
>> I could imagine that if LilyPond were made into an engraving library,
>> and/or heavy rewiring to ma
On Thu, Jan 09, 2014 at 12:07:07PM +0100, Urs Liska wrote:
> But it would probably make it more attractive for the consumer
> market if it had a nice default GUI. I personally would be pleased
> to see Frescobaldi become such a default GUI (of course not cutting
> out other options). Particularly g
On Jan 9, 2014, at 1:07 PM, Urs Liska wrote:
> Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen:
>> Urs Liska writes:
>>
>>> Is there _any_ notion what a LilyPond 3.0 may be?
>>
>> I could imagine that if LilyPond were made into an engraving library,
>&g
Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen:
Urs Liska writes:
Is there _any_ notion what a LilyPond 3.0 may be?
I could imagine that if LilyPond were made into an engraving library,
and/or heavy rewiring to make it deeply integrated with a gui,
Hm, this is something I was also thinking
- Original Message -
From: "Urs Liska"
To: "LilyPond Development Team"
Sent: Thursday, January 09, 2014 10:53 AM
Subject: 3.0?
Please don't beat me up, but that's something I wondered about for quite
some time:
Is there _any_ notion what a LilyPond 3
Urs Liska writes:
> Is there _any_ notion what a LilyPond 3.0 may be?
I could imagine that if LilyPond were made into an engraving library,
and/or heavy rewiring to make it deeply integrated with a gui, or accept
another native input language like the lilypond-driven fixed fresh
release
Please don't beat me up, but that's something I wondered about for quite
some time:
Is there _any_ notion what a LilyPond 3.0 may be?
I mean 2.0 followed on 1.8, and now we're already towards .20
Is there any general idea about what would make the next major program
version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Samstag, 1. August 2009 09:52:59 schrieb Trevor Daniels:
> > CRESCENDO
> >
> > Reinhold and Frederick: as you may have guessed, I'm proposing
> > that your patch waits until 3.0. Anything requiring such manual
> >
On Sun, Aug 02, 2009 at 08:48:01PM +0200, John Mandereau wrote:
> Le lundi 27 juillet 2009 à 03:22 -0700, Graham Percival a écrit :
> > One of the biggest complaints people have with lilypond -- other
> > than that silly "there's no gui" -- is the changing syntax. Now,
>
> IMHO this project shoul
Le lundi 27 juillet 2009 à 03:22 -0700, Graham Percival a écrit :
> One of the biggest complaints people have with lilypond -- other
> than that silly "there's no gui" -- is the changing syntax. Now,
> inventing a language or standards is difficult. If you set it in
> stone too soon, you risk bei
@lilynet.net mailist.
- I could be convinced to use the lilynet wiki for this project,
although we'd need account-locked pages, and it would increase
my workload.
No, stick to a simple maillist.
CRESCENDO
Reinhold and Frederick: as you may have guessed, I'm proposing
that your pa
> Reinhold and Frederick: as you may have guessed, I'm proposing
> that your patch waits until 3.0. Anything requiring such manual
> tweaks will make some people very unhappy, such as mutopia.
>
> I think we should make *all* manual changes at once, but reassure
> people t
> > Reinhold and Frederick: as you may have guessed, I'm proposing
> > that your patch waits until 3.0. Anything requiring such manual
> > tweaks will make some people very unhappy, such as mutopia.
>
> Another possibility would be to have a "3.0 release meister&q
kOn can still be altered at a whim, as long as we
update ly/property-init.ly.
> > Reinhold and Frederick: as you may have guessed, I'm proposing
> > that your patch waits until 3.0. Anything requiring such manual
> > tweaks will make some people very unhappy, such as mut
In message <87tz0y5pm0@lola.goethe.zz>, David Kastrup
writes
If one has something like a flex/bison syntax and/or a parser library
and/on definite rules for what can, can't be done, then one has a lot of
flexibility.
I think we already have an Antlr syntax, don't we?
Although iirc it's no
Am Montag, 27. Juli 2009 12:22:33 schrieb Graham Percival:
> CRESCENDO
>
> Reinhold and Frederick: as you may have guessed, I'm proposing
> that your patch waits until 3.0.
How about splitting up the patch into backend (i.e. supporting the spanner-
type and -text property of th
format will be
> rejected. (subject to the limitations, below)
> Once this is finished, we will release lilypond 3.0.
> LIMITATIONS and SCOPE
>
> - we need standards for the location of commands. Ligature
> brackets, I'm looking at you. (non-postfix notation must die!
gt;
>
> SUMMARY
>
> Start: Sep 2009.
>
> Length: 6-9 months. We're not going to rush this.
>
> Goal: define an input format which we commit to being
> machine-updateable for the forseeable future. Any future patches
> which change the syntax in a non-convert-ly
On Mon, Jul 27, 2009 at 01:31:35PM +0200, David Kastrup wrote:
>
> Graham Percival writes:
>
> > - We're going to have lots and lots of emails flying around. They
> > don't really fit into either -devel or -user, so we'll use a
> > mailist on lilynet.net. Maybe the already-created proposal
A few comments from a consumer...
Graham Percival writes:
> SUMMARY
>
> Start: Sep 2009.
>
> Length: 6-9 months. We're not going to rush this.
>
> Goal: define an input format which we commit to being
> machine-updateable for the forseeable future. Any future patches
> which change the syntax
We're not going to rush this.
Goal: define an input format which we commit to being
machine-updateable for the forseeable future. Any future patches
which change the syntax in a non-convert-ly-able format will be
rejected. (subject to the limitations, below)
Once this is finished, we
(built against tetex-2.0) - OK
4. install tetex-3.0.0-1
FAIL1
Solution:
purge texmf/web2c/*.{base,fmt,emft} during tetex-2.0 uninstall
Although that would be the right solution, I'll purge them at the
start of the tetex-3.0 script. I'd rather not build and distribute
another
Jan Nieuwenhuizen writes:
>> - release lilypond packaged for tetex-2.0
>> - release tetex-3
>> - release ec-fonts for tetex-3, with dependency on tetex
>> - release lilypond packaged for tetex-3.0
>
> Yes, this is cleaner than the lilypond updmap hack.
So are we
elease lilypond packaged for tetex-3.0
Yes, this is cleaner than the lilypond updmap hack.
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
_
I have misunderstood something.
So here what do you think the correct order will be for releasing the
packages?
- release lilypond packaged for tetex-2.0
- release tetex-3
- release ec-fonts for tetex-3, with dependency on tetex
- release lilypond packaged for tetex-3.0
Bert
Jan Nieuwenhuizen
1 - 100 of 189 matches
Mail list logo
