2008/5/19 Graham Percival <[EMAIL PROTECTED]>:
> Valentin offered a bounty a year ago; I don't know if that's still
> valid. A certain developer with the initial HWN even said that
> it was a "good idea" half a year ago. :)
It certainly is. I was hesitating to bring this up here, but thanks
for
On Mon, 19 May 2008 12:54:02 -0300
"Han-Wen Nienhuys" <[EMAIL PROTECTED]> wrote:
> 2008/5/19 Hans Aberg <[EMAIL PROTECTED]>:
> > In Lilypond, I thought that perhaps it was such file setup problems
> > that causes problems for users.
>
> While the include mechanism is clumsy, last time I looked th
2008/5/19 Hans Aberg <[EMAIL PROTECTED]>:
>> I would propose to move the remainder of this discussion off the mailing
>> list.
Indeed, please discuss C++ vs Haskell somewhere else.
> My hope was to get to the discussion of using in Lilypond Haskell like a
> "import" construct, which I think might
Hans Aberg wrote
My hope was to get to the discussion of using in Lilypond Haskell like a
"import" construct, which I think might help LilyPond users, as opposed
to the current "\include", which I think is more like the C preprocessor
"#include", and is trickier to use.
Is this an offe
> The "man" page of 'gcc' has 62 occurrences of this word, the first
> one being:
>Some options control the preprocessor and others the compiler
> itself.
Once again answering a different question. You made a direct quote from
Stroustrups book. Could you tell me which page it is on instead
On 19 May 2008, at 15:59, Mats Bengtsson wrote:
I would propose to move the remainder of this discussion off the
mailing list.
Regards
/Mats
My hope was to get to the discussion of using in Lilypond Haskell
like a "import" construct, which I think might help LilyPond users,
as oppos
On 19 May 2008, at 14:02, immanuel litzroth wrote:
I could not even find preprocessor in the index, just preprocessing
directive. Care to give a page reference with this quote?
The "man" page of 'gcc' has 62 occurrences of this word, the first
one being:
Some options control the preproce
I would propose to move the remainder of this discussion off the mailing
list.
Regards
/Mats
Hans Aberg wrote:
On 19 May 2008, at 14:02, immanuel litzroth wrote:
It is of a formal grammar, since it does not define a sentence
symbol, nor does it specify context dependencies. For the forma
On 19 May 2008, at 14:02, immanuel litzroth wrote:
It is of a formal grammar, since it does not define a sentence
symbol, nor does it specify context dependencies. For the formal
definition of a grammar, see books on compiler construction, for
example Waite & Goose, "Compiler Construction".
Pl
Quoting Hans Aberg <[EMAIL PROTECTED]>:
> It is of a formal grammar, since it odes not define a sentence
> symbol, nor does it specify context dependencies. For the formal
> definition of a grammar, see books on compiler construction, for
> example Waite & Goose, "Compiler Construction".
P
On 19 May 2008, at 11:27, immanuel litzroth wrote:
You can check the whole formal grammar of C++ processing on page
307 of the standard.
It is of a formal grammar, since it odes not define a sentence
symbol, nor does it specify context dependencies. For the formal
definition of a grammar
> C++ has the same preprocessor as C, and the same
> grammar sentence symbol,
> and a language subset. GCC has options for invoking the
> preprocessor and language proper separate
You can check the whole formal grammar of C++ processing on page 307 of the
standard. The "language proper" is a
On 18 May 2008, at 22:47, immanuel litzroth wrote:
I am talking about C. That was what my argument was about. Now you
bring C++ -- Has somebody pointed out to you that that is a
different standard? -- into the argument saying out that it does
not have a "formal grammar". Are you making this
On 18 May 2008, at 19:55, immanuel litzroth wrote:
So the C language itself does not
have any #include directive.
The C language standard is available at:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
You'll see all the preprocessing directives explained there and no
mention of a
Quoting Hans Aberg <[EMAIL PROTECTED]>:
> On 18 May 2008, at 15:16, immanuel litzroth wrote:
>
> >> So the C language itself does not
> >> have any #include directive.
The C language standard is available at:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
You'll see all the preproces
On 18 May 2008, at 14:56, fiëé visuëlle wrote:
I used the existence of a PDF as indicator if LilyPond was
successful - it says "file failed" very often even if the output is
ok.
OK. Perhaps Lilypond has the problem and not always produces the
expected exit code.
Also, you might put in
On 18 May 2008, at 15:16, immanuel litzroth wrote:
So the C language itself does not
have any #include directive.
Implementation issue. There is no requirement for a separate
preprocessor, ...
In the C and C++ standards there are.
...and the fact that compilation happens in stages is a fe
Nicolas:
> Le 18 mai 08 à 00:24, Karl Hammar a écrit :
>
> > Actually what I would like is some way to tell on the command line
> > that
> > this run should have /ancient fonts/c-clefs/modern clefs/... so I
> > could
> > easily switch style without having to write a new file.
>
> You can alre
Quoting Hans Aberg <[EMAIL PROTECTED]>:
> C is composed of two languages: the preprocessor, to which #include
>
> belongs, and merely composes the files into one compile unit, and
> the
> C compiler, which processes that. So the C language itself does not
>
> have any #include directive.
Am 2008-05-18 um 13:57 schrieb Hans Aberg:
This is my lily.sh script for OSX:
- deletes previous myname.pdf
- runs lilypond myname.ly
- deletes old mylily.mid and renames myname.midi to myname.mid
- deletes myname.ps
- opens MIDI and PDF
You don't have to remove older files, as they are over
On 18 May 2008, at 12:55, fiëé visuëlle wrote:
This is my lily.sh script for OSX:
- deletes previous myname.pdf
- runs lilypond myname.ly
- deletes old mylily.mid and renames myname.midi to myname.mid
- deletes myname.ps
- opens MIDI and PDF
You don't have to remove older files, as they are
Am 2008-05-18 um 12:16 schrieb Hans Aberg:
On UNIX, like OS X, one can run the command
lilypond foo.ly && mv foo.midi foo.mid
Easy to repeat - on OS X, use the up arrow key. Or write a script
or alias.
This is my lily.sh script for OSX:
"""
#!/bin/bash
if [ -e $1.pdf ]; then
rm $1.
On 18 May 2008, at 10:34, Valentin Villenave wrote:
and if you are using makefiles, lilypond don't have to solve that
problem, you could just as easily add an mv-line in the makefile.
If we all were using makefiles (including the newbies on Win32), then
we wouldn't be having this discussion at
2008/5/18 Karl Hammar <[EMAIL PROTECTED]>:
> and if you are using makefiles, lilypond don't have to solve that
> problem, you could just as easily add an mv-line in the makefile.
If we all were using makefiles (including the newbies on Win32), then
we wouldn't be having this discussion at all :-)
On 18 May 2008, at 00:35, Karl Hammar wrote:
If one has more that one file, .lilypond could be made into a
directory instead. Various programs use this setup.
The problem with this is if you want to share your lilypond files,
then
you migth have to include all your .lilypond directory, and s
On 18 May 2008, at 00:24, Karl Hammar wrote:
This would walk down the path of C-like compilers.
Is that a bad thing?
It means only that it might be a good idea to think very carefully
before walking down that path :-). C is a very old language, with a
simple setup, leaving much to the us
Le 18 mai 08 à 00:24, Karl Hammar a écrit :
Actually what I would like is some way to tell on the command line
that
this run should have /ancient fonts/c-clefs/modern clefs/... so I
could
easily switch style without having to write a new file.
You can already do this, using -d options in t
Valentin:
> 2008/5/17 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
>
> > we can have a -dmidi-extension=mid, and change the default for the
> > Windows binary.
>
> Another feature that would be greatly appreciated (once again, this is
> an idea from the French list) would be the ability to define separa
se this setup.
The problem with this is if you want to share your lilypond files, then
you migth have to include all your .lilypond directory, and some things
in there might conflict with other users .lilypond/*. It migth be
better to be restrictive in what you implicitly include, and restric
Hans:
> On 17 May 2008, at 22:15, Karl Hammar wrote:
...
> > I would be nice to be able to do like
> >
> > lilypond a.ly .. o.ly z.ly
> >
> > i.e. treat a.ly .. o.ly as if they where included in z.ly, without
> > having to say so in z.ly.
>
> This would walk down the path of C-like compilers.
I
On 17 May 2008, at 23:00, Bertalan Fodor wrote:
Also .lilypond is a good idea, it should work as init.ly but from
the user's home dir.
If one has more that one file, .lilypond could be made into a
directory instead. Various programs use this setup.
Hans
On 17 May 2008, at 22:52, immanuel litzroth wrote:
Haskell does not "deduce" what to include. You have to explicitly
import each module or no magic happens. Can't really see the big
difference with #include "stdio.h" and import Unix.
C is composed of two languages: the preprocessor, to whic
2008/5/17 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> we can have a -dmidi-extension=mid, and change the default for the
> Windows binary.
Another feature that would be greatly appreciated (once again, this is
an idea from the French list) would be the ability to define separate
output paths for midi
There is ly:option or something that makes command line options settable
from the LilyPond file.
Also .lilypond is a good idea, it should work as init.ly but from the
user's home dir.
Hans Aberg írta:
On 17 May 2008, at 16:48, Han-Wen Nienhuys wrote:
I think the proper solution is to softc
Haskell does not "deduce" what to include. You have to explicitly import each
module or no magic happens. Can't really see the big difference with #include
"stdio.h" and import Unix. The point is I believe that you are guaranteed that
what is linked is is is compatible with your declarations, th
On 17 May 2008, at 22:15, Karl Hammar wrote:
A startup file would be about the same as an initial \include.
Perhaps it is not needed in a compiler.
I would be nice to be able to do like
lilypond a.ly .. o.ly z.ly
i.e. treat a.ly .. o.ly as if they where included in z.ly, without
having t
Hans:
> On 17 May 2008, at 16:48, Han-Wen Nienhuys wrote:
>
> > I think the proper solution is to softcode this, so
> > we can have a -dmidi-extension=mid, ...
...
> On UNIX system, one might have a startup file $HOME/.lilypond
> defining such options. Then the startup arguments (and .ly files)
Han-Wen:
> 2008/5/16 Bertalan Fodor (LilyPondTool) <[EMAIL PROTECTED]>:
> > Why always speaking about broken OS-es and softwares? We want to make
...
> I actually prefer being able to understand file names, and .midi makes
> more sense to me. I think the proper solution is to softcode this, so
> w
On 17 May 2008, at 16:48, Han-Wen Nienhuys wrote:
I think the proper solution is to softcode this, so
we can have a -dmidi-extension=mid, ...
Any takers for this?
In addition, one might be able to put it into the .ly file. If both
options (startup and within file) are invoked, it is safest
2008/5/16 Bertalan Fodor (LilyPondTool) <[EMAIL PROTECTED]>:
> Why always speaking about broken OS-es and softwares? We want to make
> LilyPond better, don't we?
> LilyPond generates .midi files, which are not usable for many applications.
> If LilyPond generated .mid files, it would work on every
On 16 May 2008, at 08:23, Graham Percival wrote:
OSX *isn't* stupid, but it pretends to
be. I have no clue what the Aqua people were up to. :(
The underlying UNIX does not care about file extensions: it is the
Finder program that does. On UFS (UNIX file system), the meta-data is
stored i
Why always speaking about broken OS-es and softwares? We want to make
LilyPond better, don't we?
LilyPond generates .midi files, which are not usable for many
applications. If LilyPond generated .mid files, it would work on every
application (except LilyPondTool :-), which I think unfortunately
On Thu, 15 May 2008 22:55:50 -0700
Michael David Crawford <[EMAIL PROTECTED]> wrote:
> But when Apple bought NeXT from Steve Jobs, the Cocoa framework that
> became Mac OS X knew nothing of types and creator codes. Now the Mac
> is borked in the same way windows is.
Yes and no. The underlying
Karl Hammar wrote:
I consider it a bug that programs are picky about file extensions.
There was a time when the Mac OS didn't care about file extensions. The
filesystem had a type and a "creator code" in the filesystem metadata,
hidden from the user. The user had complete control over the
> Tell me one application that allows midi and doesn't allow mid.
I consider it a bug that programs are picky about file extensions.
> I think this decision of choosing .midi was the result of an unpractical
> idealistic approach.
>
> I consider this a bug.
>
> Bert
Regards,
/Karl
___
Tell me one application that allows midi and doesn't allow mid.
I think this decision of choosing .midi was the result of an unpractical
idealistic approach.
I consider this a bug.
Bert
Valentin Villenave wrote:
2008/5/15 Karl Hammar <[EMAIL PROTECTED]>:
Perhaps you have better luck if
message in context:
http://www.nabble.com/*.mid-vs-*.midi-tp17235029p17253856.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 15. Mai 2008 schrieb Valentin Villenave:
> I tried to have a look at the MIDI 1.0 specs to see if there was any
> "official" extension, but couldn't find one. Windows users seem to
> believe that .mid is more legitimate than .midi, but
2008/5/15 Karl Hammar <[EMAIL PROTECTED]>:
> Perhaps you have better luck if you change the "midi" to "mid"
> and recompile.
The question that was asked on the French list about also implied that
these files should be typed as .mid by default...
I tried to have a look at the MIDI 1.0 specs to see
CDon:
> Karl Hammar wrote:
> >
> > change the .midi to .mid, and you should get what you want (though I
> > have not tested it).
> >
>
> Thanks Karl, this looks promising but does not work. There is a TODO at the
> top of the file stating:
>
> ";; this is broken: we should not ever export vari
from Scheme."
It is not clear what this is referring to, but the implication is that the
whole file is broken. I then assume that setting the .midi extension must
be done some other place (?).
Don
--
View this message in context:
http://www.nabble.com/*.mid-vs-*.midi-tp17235029p17241827.
2008/5/14 Karl Hammar <[EMAIL PROTECTED]>:
> From version 2.8 (I think) and up, find the file:
>
> midi.scm
Is it not performance.cc?
(in this case it would require a recompilation)
We recently had the same question on the French mailing list.
Cheers,
Valentin
___
Don:
> Is there a way to direct LilyPond to use the .mid extension as opposed
> to .midi? I see in the archives that the choice of extensions has been
> discussed, but I can find no way to change it.
>From version 2.8 (I think) and up, find the file:
midi.scm
Edit that file, go to the end of
Is there a way to direct LilyPond to use the .mid extension as opposed to
.midi? I see in the archives that the choice of extensions has been discussed,
but I can find no way to change it.
CDon___
lilypond-user mailing list
lilypond-user@gnu.org
http:
54 matches
Mail list logo
