On vacation
I'll be on vacation this week; probably away from the internet for the entire week. I'll respond as soon as possible to any issues when I return. If there are any issues with the autobeaming code that breaks compiling, please revert the patch if it can't be fixed. I'll check email once more tomorrow morning before I leave (about 8 hours from now). Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
On Sun, Jul 18, 2010 at 6:25 PM, Carl Sorensen wrote: > On 7/18/10 3:11 PM, "Jan Nieuwenhuizen" wrote: >>Op zondag 18-07-2010 om 13:35 uur [tijdzone -0700], schreef Patrick >> McCarty: >>> I think if we "roll our own" LilyPad, and borrow a lot of ideas from >>> gummi or other similar projects, we'll be on the right track. >> >> Yeah, probably maybe. I'm not too comfortable with this tex-ness, >> otoh, sharing efforts would be nice. > > I'm not trying to rain on anybody's parade, and I think I might know the > answer, but ... > > Why do we want to "roll our own" when we already have LilyPondTool/Jedit, > and Frescobaldi? > > I think the answers are 1) Jedit is not very lightweight, and we want > something lightweight; and 2) Frescobaldi is specific to KDE and we want to > develop something that is cross-platform. Yeah, the heaviness is the main problem. I think Frescobaldi is pretty lightweight, though it carries a massive dependency (KDE). Also, the JRE (or OpenJDK) for Jedit is pretty heavy. > Is it possible to separate the KDE4 stuff from Frescobaldi, and use pygtk > instead? Perhaps we could use the same core functionality. We could try porting some of the code to pygtk, though I haven't looked into it to see how difficult it would be. > It seems better to not reinvent the wheel if we can avoid it. I agree. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming code pushed -- need to run make bin-clean for future builds
Carl, just wanted to echo Trevor's appreciation for your work. Thanks. :) Jon On Sun, Jul 18, 2010 at 8:07 PM, Carl Sorensen wrote: > On 7/18/10 12:33 PM, "Trevor Daniels" wrote: > >> Carl, >> >> Just to congratulate you on finally succeeding with this. >> This will be a great improvement in the next release. > > Thanks, Trevor. It's been fun, but I'm ready to be done with it. > > Next step, Issue # 11. > > Carl > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
On 7/18/10 3:11 PM, "Jan Nieuwenhuizen" wrote: > Op zondag 18-07-2010 om 13:35 uur [tijdzone -0700], schreef Patrick > McCarty: > Hi Patrick, > >> Yeah, I'm getting a little carried away. :) > > Been there, see below :-) > >>>http://gummi.midnightcoding.org/ >> >> Cool! >> >> I got it running on my Linux box, and it looks promising. > > Talking about carried away, I got it built in GUB and running in > wine ;-) > >> I think if we "roll our own" LilyPad, and borrow a lot of ideas from >> gummi or other similar projects, we'll be on the right track. > > Yeah, probably maybe. I'm not too comfortable with this tex-ness, > otoh, sharing efforts would be nice. I'm not trying to rain on anybody's parade, and I think I might know the answer, but ... Why do we want to "roll our own" when we already have LilyPondTool/Jedit, and Frescobaldi? I think the answers are 1) Jedit is not very lightweight, and we want something lightweight; and 2) Frescobaldi is specific to KDE and we want to develop something that is cross-platform. Is it possible to separate the KDE4 stuff from Frescobaldi, and use pygtk instead? Perhaps we could use the same core functionality. It seems better to not reinvent the wheel if we can avoid it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming code pushed -- need to run make bin-clean for future builds
On 7/18/10 12:33 PM, "Trevor Daniels" wrote: > Carl, > > Just to congratulate you on finally succeeding with this. > This will be a great improvement in the next release. Thanks, Trevor. It's been fun, but I'm ready to be done with it. Next step, Issue # 11. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
Op zondag 18-07-2010 om 13:35 uur [tijdzone -0700], schreef Patrick McCarty: Hi Patrick, > Yeah, I'm getting a little carried away. :) Been there, see below :-) > >http://gummi.midnightcoding.org/ > > Cool! > > I got it running on my Linux box, and it looks promising. Talking about carried away, I got it built in GUB and running in wine ;-) > I think if we "roll our own" LilyPad, and borrow a lot of ideas from > gummi or other similar projects, we'll be on the right track. Yeah, probably maybe. I'm not too comfortable with this tex-ness, otoh, sharing efforts would be nice. Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyOfSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
On Sun, Jul 18, 2010 at 6:20 AM, Carl Sorensen wrote: > On 7/18/10 2:56 AM, "Jan Nieuwenhuizen" wrote: > >> It could be smart to work together with gummi, >> possibly there are better programs than gummi, >> possibly we're better off stealing their technology >> (poppler pdf display) and rolling our own. >> >> What do you think? > > One good thing about doing this is that we could have the application for > both Windows and OSX. > > One bad thing about this is that it will add a new dependency > (python-poppler). > > On the whole, if somebody wants to pursue this, I think it would be a good > feature to add (but I guess it's not available for 2.14 because of > dependency freezing). Well, I'm not sure if we would want to develop the editor in the same source tree as LilyPond... I think, at least for now, it would be best to work in a separate repo, add the editor to GUB eventually, and see where things go from there. So, in order words, if we keep it in a separate code base, we don't need to worry about the 2.14 dependency freeze. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
Hi Jan, On Sun, Jul 18, 2010 at 1:56 AM, Jan Nieuwenhuizen wrote: > > While I appreciate your working on lilypad, I doubt > whether this is an efficient way of spending our efforts. Yeah, I'm getting a little carried away. :) I'm starting to think it would be difficult expanding on the current LilyPad, since it really lacks features, and I'm starting to not enjoy working with the win32 API... Also, many people want to see syntax highlighting, etc., and the current solution isn't going to cut it. While it's "interesting", I agree that working on a cross-platform editor would be a much wiser use of time. > Why not write a simple editor in pygtk? Indeed, I wanted > to write a simple editor to get you going and found gummi: > > http://gummi.midnightcoding.org/ Cool! I got it running on my Linux box, and it looks promising. > It could be smart to work together with gummi, > possibly there are better programs than gummi, > possibly we're better off stealing their technology > (poppler pdf display) and rolling our own. > > What do you think? I think if we "roll our own" LilyPad, and borrow a lot of ideas from gummi or other similar projects, we'll be on the right track. Thanks a lot for posting about this. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming code pushed -- need to run make bin-clean for future builds
Carl, Just to congratulate you on finally succeeding with this. This will be a great improvement in the next release. Trevor - Original Message - From: "Carl Sorensen" To: "Lily devel" Sent: Sunday, July 18, 2010 5:39 AM Subject: Autobeaming code pushed -- need to run make bin-clean for future builds I have pushed the new autobeaming code to master. The build will fail due to old .o files that have been removed. You will need to do make bin-clean or rm lily/out/* before compiling. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
the big difference came out of the notes.clean() (???) line!
yours, Arno
On Thu, 15 Jul 2010 01:02:07 +0200, Joe Neeman wrote:
On Wed, Jul 14, 2010 at 3:34 PM, Arno Waschk wrote:
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman
wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk wrote:
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version "2.13.28"
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work
much
better now.
Wow! First impression is huge running time reduction. Rough guess 80%
for
my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
Is this with git master or with my patch for extra caching?
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
This is also a memory problem, since grob-smob.cc:50 is run as part of
guile's garbage collections.
I have uploaded my patch for comments here:
http://codereview.appspot.com/1817045
Cheers,
Joe
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
On 7/18/10 2:56 AM, "Jan Nieuwenhuizen" wrote: > It could be smart to work together with gummi, > possibly there are better programs than gummi, > possibly we're better off stealing their technology > (poppler pdf display) and rolling our own. > > What do you think? One good thing about doing this is that we could have the application for both Windows and OSX. One bad thing about this is that it will add a new dependency (python-poppler). On the whole, if somebody wants to pursue this, I think it would be a good feature to add (but I guess it's not available for 2.14 because of dependency freezing). Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming code pushed -- need to run make bin-clean for future builds
On 7/18/10 1:17 AM, "David Kastrup" wrote: > Writing `/usr/local/tmp/lilypond/Documentation/out/pitches.texi'... > Processing include: rhythms.itely > Reading /usr/local/tmp/lilypond/Documentation/out/rhythms.itely... > Dissecting...lilypond-book.py: error: file not found: subdividing-beams.ly > > make[1]: *** [out/snippets.texi] Error 1 > rm out/weblinks.itexi > make[1]: Leaving directory `/usr/local/tmp/lilypond/Documentation' > make: *** [all] Error 2 Thanks for finding that. I had not added the renamed file to git, so although it compiled well on my machine, it didn't push the change. Fixed in git. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fix ly:parser-parse-file in an ly file (issue1345041)
On 2010/07/18 09:08:19, Valentin Villenave wrote: if you don't mind me asking, where are we wrt this patch? If it only comes down to a coding style problem, I'm pretty sure I've already seen worse in existing source code :) I've prepared a patch which I'll push later. Cheers, Neil http://codereview.appspot.com/1345041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fix ly:parser-parse-file in an ly file (issue1345041)
On 2010/07/11 04:08:30, Carl wrote: If we get these cleared up, then I'll push. Hello guys, if you don't mind me asking, where are we wrt this patch? If it only comes down to a coding style problem, I'm pretty sure I've already seen worse in existing source code :) Cheers, Valentin http://codereview.appspot.com/1345041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypad for windows
Hi Patrick,
While I appreciate your working on lilypad, I doubt
whether this is an efficient way of spending our efforts.
Why not write a simple editor in pygtk? Indeed, I wanted
to write a simple editor to get you going and found gummi:
http://gummi.midnightcoding.org/
it took me about 15 minutes to write this crude hack
(yes, should use .endswith () and os.path.split () etc)
to make it run and show lilypond preview.
It could be smart to work together with gummi,
possibly there are better programs than gummi,
possibly we're better off stealing their technology
(poppler pdf display) and rolling our own.
What do you think?
Oh, to run gummi, just install the necessary python-*
bindings (probably apt-get install python-poppler
will pull in everything), apply the patch and do
python gummi/Core.py
Greetings,
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyOfSource.com | Avatar® http://AvatarAcademy.nl
diff -purN --exclude='*~' --exclude='*pyc' gummi-0.4.8/gummi/GummiGUI.py gummi-0.4.8-lily/gummi/GummiGUI.py
--- gummi-0.4.8/gummi/GummiGUI.py 2010-05-16 22:14:53.0 +0200
+++ gummi-0.4.8-lily/gummi/GummiGUI.py 2010-07-18 10:30:54.807484687 +0200
@@ -397,8 +397,8 @@ class MainGUI:
self.exitinterrupt = True
if response == gtk.RESPONSE_OK:
filename = chooser.get_filename()
- if not ".tex" in filename[-4:]:
-filename = filename + ".tex"
+ if not ".ly" in filename[-3:]:
+filename = filename + ".ly"
self.iofunc.make_environment(filename)
chooser.destroy()
return filename
diff -purN --exclude='*~' --exclude='*pyc' gummi-0.4.8/gummi/IOFunctions.py gummi-0.4.8-lily/gummi/IOFunctions.py
--- gummi-0.4.8/gummi/IOFunctions.py 2010-05-16 22:14:53.0 +0200
+++ gummi-0.4.8-lily/gummi/IOFunctions.py 2010-07-18 10:39:32.975484454 +0200
@@ -60,12 +60,12 @@ class IOFunctions:
if filename is not None:
self.filename = filename
self.texpath = os.path.dirname(self.filename) + "/"
- if ".tex" in self.filename:
-self.texname = os.path.basename(self.filename)[:-4]
+ if ".ly" in self.filename:
+self.texname = os.path.basename(self.filename)[:-3]
else:
self.texname = os.path.basename(self.filename)
- (self.workfd, self.workfile) = tempfile.mkstemp(".tex")
- self.pdffile = self.workfile[:-4] + ".pdf"
+ (self.workfd, self.workfile) = tempfile.mkstemp(".ly")
+ self.pdffile = self.workfile[:-3] + ".pdf"
print ("\nEnvironment created for: \n" + \
"TEX: " + str(self.filename) + "\n" \
"TMP: " + self.workfile + "\n" + \
diff -purN --exclude='*~' --exclude='*pyc' gummi-0.4.8/gummi/Motion.py gummi-0.4.8-lily/gummi/Motion.py
--- gummi-0.4.8/gummi/Motion.py 2010-05-16 22:14:53.0 +0200
+++ gummi-0.4.8-lily/gummi/Motion.py 2010-07-18 10:40:13.080486763 +0200
@@ -150,12 +150,10 @@ class Motion:
def update_pdffile(self):
try:
- pdfmaker = subprocess.Popen(self.texcmd + \
- ' -interaction=nonstopmode \
- -file-line-error \
- -halt-on-error \
- --output-directory="%s" "%s"' \
- % (self.tempdir, self.workfile),
+ self.lyname = self.workfile[:-3]
+ command = ' %(texcmd)s --output="%(lyname)s" "%(workfile)s"' % self.__dict__
+ print 'running:', command
+ pdfmaker = subprocess.Popen(command,
shell=True, cwd=self.texpath, close_fds=True, \
stdin=None, stdout = subprocess.PIPE, stderr=None )
self.output = pdfmaker.communicate()[0]
diff -purN --exclude='*~' --exclude='*pyc' gummi-0.4.8/gummi/Preferences.py gummi-0.4.8-lily/gummi/Preferences.py
--- gummi-0.4.8/gummi/Preferences.py 2010-05-16 22:15:12.0 +0200
+++ gummi-0.4.8-lily/gummi/Preferences.py 2010-07-18 10:44:20.811484288 +0200
@@ -42,24 +42,13 @@ CFGDEFAULTS = {
'font': 'Monospace 10',
'autosaving': False,
'autosave_timer': 600,
-'typesetter': 'pdflatex',
+'typesetter': 'lilypond',
'compile_timer': 1,
'compile_status': True,
'recent1': '',
'recent2': '',
'recent3': '',
-'welcome': '''\documentclass{article}
-\\begin{document}
-
-\\begin{center}
-\Huge{Welcome to Gummi} \\
-
-\\LARGE{You are using the ''' + VERSION + ''' version.
-I welcome your suggestions at
-http://gummi.midnightcoding.org}
-\\end{center}
-
-\\end{document}
+'welcome': r'''\relative c' { a b c }
'''
}
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming code pushed -- need to run make bin-clean for future builds
Carl Sorensen writes: > I have pushed the new autobeaming code to master. > > The build will fail due to old .o files that have been removed. > > You will need to do > > make bin-clean > > or > > rm lily/out/* > > before compiling. Processing include: pitches.itely Reading /usr/local/tmp/lilypond/Documentation/out/pitches.itely... Dissecting... Writing snippets... Processing... Invoking `true -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=texidoc --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I "/usr/local/tmp/lilypond/out/lybook-db" -I "/usr/local/tmp/lilypond/Documentation" -I "/usr/local/tmp/lilypond/Documentation" -I "/usr/local/tmp/lilypond/Documentation/out" -I "/usr/local/tmp/lilypond/input" -I "/usr/local/tmp/lilypond/Documentation" -I "/usr/local/tmp/lilypond/Documentation/snippets" -I "/usr/local/tmp/lilypond/input/regression" -I "/usr/local/tmp/lilypond/Documentation/included" -I "/usr/local/tmp/lilypond/mf/out" -I "/usr/local/tmp/lilypond/mf/out" -I "/usr/local/tmp/lilypond/Documentation/pictures" -I "/usr/local/tmp/lilypond/Documentation/pictures/out" --formats=eps --verbose -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/usr/local/tmp/lilypond/out/lybook-db/snippet-names-895894955.ly"' Compiling /usr/local/tmp/lilypond/Documentation/out/pitches.texi... Writing `/usr/local/tmp/lilypond/Documentation/out/pitches.texi'... Processing include: rhythms.itely Reading /usr/local/tmp/lilypond/Documentation/out/rhythms.itely... Dissecting...lilypond-book.py: error: file not found: subdividing-beams.ly make[1]: *** [out/snippets.texi] Error 1 rm out/weblinks.itexi make[1]: Leaving directory `/usr/local/tmp/lilypond/Documentation' make: *** [all] Error 2 -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
