Re: LyX/Mac Maintainer
On 04/11/2010 10:30 PM, BH wrote: Stephen Witt has been doing some great things for LyX/Mac. Given that I have not had time or expertise to really advance LyX/Mac, and given his abilities and enthusiasm, I have asked him if he would like to take over as LyX/Mac maintainer. He has agreed. For now, at least, the plan is for Stephen to take over the LyX/Mac-2.0.0 release but leave at least the 1.6.6 release to me. (We'll see what happens for 1.6.7.) I've given Stephen the XCode source for LyX-installer.app. As I've indicated before, I think we ought to do away with a separate installer in favor of a script that can get run when LyX is launched. But I'll leave the decision of what to do with it up to Stephen. (If the installer persists, though, it should go into the svn repository.) As I told Stephen, I'll still be around on the devel and users list, still compiling recent trunk and branch, still pestering people to fix Mac and other bugs, etc. And, of course, I'll still be using and benefiting from LyX itself, without which I'd now find it very hard to do any serious work. So thanks, Stephen, for your good work so far and for the contributions I'm sure you'll make in the future. And thanks, Bennett, for your work as LyX/Mac maintainer. We'll thank you for the other stuff you mentioned later. ;-) rh
RE: r34120 - lyx-devel/trunk/src
- : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), + : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), What's the rationale about initializing a docstring with 0 ? (Does it even compile ?) Vincent
Re: r34120 - lyx-devel/trunk/src
Vincent van Ravesteijn - TNW wrote: -: action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), +: argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), What's the rationale about initializing a docstring with 0 ? (Does it even compile ?) hrmpf, i only wanted to add something for the place of argument_. now this patch is buggy, maybe even the next one i'm commiting right now... ;) i want to have response from the reporter. the whole thing is strange. since crash came from destructor and the only thing really _changed_ in Richard's patch was the sequence of initialization - my guess was it could be related because of missing argument. pavel
Re: r34120 - lyx-devel/trunk/src
On 04/12/2010 11:31 AM, Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
- : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0),
+ : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0),
y_(0),
What's the rationale about initializing a docstring with 0 ? (Does it
even compile ?)
hrmpf, i only wanted to add something for the place of argument_. now this
patch is buggy,
maybe even the next one i'm commiting right now... ;)
i want to have response from the reporter.
the whole thing is strange. since crash came from destructor and the only
thing really _changed_ in Richard's patch was the sequence of initialization -
my guess was it could be related because of missing argument.
I've tried restoring the initialization order. Otherwise, yes, it is
VERY strange. Note that this comes from LyX.cpp:531:
lyx::dispatch(FuncRequest(LFUN_WINDOW_NEW, geometryArg));
So the constructor was actually this one:
FuncRequest::FuncRequest(FuncCode act, string const arg, Origin o)
: argument_(from_utf8(arg)), action_(act), origin_(o), x_(0),
y_(0),
button_(mouse_button::none)
{}
which initializes argument_ just fine.
Apparently, you guess didn't help, so I've reverted it. Now he can just
try the patch that changes back the initialization order. I've also
suggested he try a fresh checkout.
rh
Re: r34120 - lyx-devel/trunk/src
Richard Heck wrote:
I've tried restoring the initialization order. Otherwise, yes, it is VERY
strange. Note that this comes from LyX.cpp:531:
lyx::dispatch(FuncRequest(LFUN_WINDOW_NEW, geometryArg));
So the constructor was actually this one:
FuncRequest::FuncRequest(FuncCode act, string const arg, Origin o)
: argument_(from_utf8(arg)), action_(act), origin_(o), x_(0),
y_(0),
button_(mouse_button::none)
{}
which initializes argument_ just fine.
ehh, i thought from the one without argument, no?
FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION,
o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39
pavel
RE: r34120 - lyx-devel/trunk/src
ehh, i thought from the one without argument, no? FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION, o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39 Please read further: #11 0x081a00c8 in static_initialization_and_destruction_0 () at FuncRequest?.cpp:28 This is your 0 initialization hack. Vincent
Re: r34120 - lyx-devel/trunk/src
Vincent van Ravesteijn - TNW wrote: ehh, i thought from the one without argument, no? FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION, o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39 Please read further: #11 0x081a00c8 in static_initialization_and_destruction_0 () at FuncRequest?.cpp:28 This is your 0 initialization hack. no that backtrace is from the tree, which doesn't contain 0 hack anymore. anyway Richard hit the nail on the head in between - the problem was most probably due to the linking with old object files after autotools update and fresh checkout works... pavel
Re: r34120 - lyx-devel/trunk/src
On 04/12/2010 02:25 PM, Pavel Sanda wrote: Vincent van Ravesteijn - TNW wrote: ehh, i thought from the one without argument, no? FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION, o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39 Please read further: #11 0x081a00c8 in static_initialization_and_destruction_0 () at FuncRequest?.cpp:28 This is your 0 initialization hack. no that backtrace is from the tree, which doesn't contain 0 hack anymore. anyway Richard hit the nail on the head in between - the problem was most probably due to the linking with old object files after autotools update and fresh checkout works... We should perhaps add this to our bug reporting comments: If you are seeing the bug in checkouts from svn, then you might want to try a fresh checkout. Richard
Re: r34120 - lyx-devel/trunk/src
Richard Heck wrote: We should perhaps add this to our bug reporting comments: If you are seeing the bug in checkouts from svn, then you might want to try a fresh checkout. already done in FAQ :) p
Re: r34120 - lyx-devel/trunk/src
Le 12 avr. 10 à 21:16, Pavel Sanda a écrit : Richard Heck wrote: We should perhaps add this to our bug reporting comments: If you are seeing the bug in checkouts from svn, then you might want to try a fresh checkout. already done in FAQ :) But this should not happen... JMarc
Re: Lilypond+Lyx
On 12/04/2010 6:05 AM, Helge Hafting wrote:
Of course, embedding lilypond code in LyX would be even less work. But I
don't know a quick way to program that. Anything not supported directly
by latex, is kept in separate files. This is the way it is for graphics,
as well as music.
The current lilypond support in LyX takes care of running lilypond and
importing the resulting PDF automatically. So you can include music, but
you need to have each piece in a separate file.
What you want can be done though. Lilypond code could be stored in the
..lyx file, and LyX could write out a temporary .ly file and process it
with lilypond.
You may want to file an enhancement request for this at
http://www.lyx.org/trac/wiki/BugTrackerHome
so your idea is not forgotten. The idea is interesting, but I don't have
time right now.
Helge Hafting
Hi Bernardo, and others,
I just wrote a LyX module for basic Lilypond support within LyX. It
works with LyX 2.0 (the development version) only. But if you feel
adventurous, it would be a great help if you can test it out.
To developers: it is a simple idea. It is inspired by the literate
programming frameworks. LyX produces a .lytex document (which is really
just latex with some lilypond commands) and lilypond-book converts that
to latex. The usual conversion chain ensues.
At the moment the features are minimal (just a single inset is
available, and I don't know how to pass options to LaTeX environments).
But it is usable; the patch includes an example document.
Regards,
Julien
Index: layouts/lilypond.module
===
--- layouts/lilypond.module (revision 0)
+++ layouts/lilypond.module (revision 0)
@@ -0,0 +1,34 @@
+#\DeclareLyXModule[lilypond-book-latex]{LilyPond}
+#DescriptionBegin
+#This module adds an inset to enter LilyPond code directly into LyX.
+#It will be processed in the output.
+#DescriptionEnd
+#Category: literate
+
+# Author: Julien Rioux jri...@physics.utoronto.ca
+
+Format 26
+OutputType literate
+OutputFormat lilypond-book
+
+InsetLayout LilyPond
+ LabelString LilyPond
+ LatexType Environment
+ LaTexName lilypond
+ LyXType Custom
+ DecorationClassic
+ Font
+ Color latex
+ Family typewriter
+ EndFont
+ LabelFont
+ Color latex
+ SizeSmall
+ EndFont
+ MultiPar true
+ CustomParsfalse
+ ForcePlaintrue
+ FreeSpacing true
+ PassThru true
+ ForceLTR true
+End
Property changes on: layouts/lilypond.module
___
Added: svn:mime-type
+ text/plain
Added: svn:eol-style
+ native
Index: configure.py
===
--- configure.py(revision 34124)
+++ configure.py(working copy)
@@ -506,6 +506,7 @@
\Format literate nw NoWeb N %%
document
\Format sweave RnwSweaveS %%document
\Format lilypond ly LilyPond music %%vector
+\Format lilypond-book lytex LilyPond book%%
document
\Format latex texLaTeX (plain) L %%
document
\Format pdflatex texLaTeX (pdflatex) %%
document
\Format xetex texLaTeX (XeTeX) %%
document
@@ -803,6 +804,25 @@
else:
logger.info('+ found LilyPond, but could not extract version
number.')
#
+path, lilypond_book = checkProg('a LilyPond book - LaTeX converter',
['lilypond-book'])
+if (lilypond_book != ''):
+version_string = cmdOutput(lilypond-book --version)
+match = re.match('^(\S+)$', version_string)
+if match:
+version_number = match.groups()[0]
+version = version_number.split('.')
+if int(version[0]) 2 or (len(version) 1 and int(version[0]) ==
2 and int(version[1]) = 9):
+addToRC(r'''\converter lilypond-book latexlilypond-book
--pdf $$i
+\converter lilypond-book pdflatex lilypond-book --pdf
--latex-program=pdflatex $$i ''')
+logger.info('+ found LilyPond-book version %s.' %
version_number)
+elif int(version[0]) 2 or (len(version) 1 and int(version[0])
== 2 and int(version[1]) = 1):
+addToRC(r'\converter lilypond-book latexlilypond-book
$$i')
+logger.info('+ found LilyPond-book version %s.' %
version_number)
+else:
+logger.info('+ found LilyPond-book, but version %s is too
old.' % version_number)
+else:
+logger.info('+ found
Re: LyX/Mac Maintainer
Am 12.04.2010 um 04:30 schrieb BH: Stephen Witt has been doing some great things for LyX/Mac. Given that I have not had time or expertise to really advance LyX/Mac, and given his abilities and enthusiasm, I have asked him if he would like to take over as LyX/Mac maintainer. He has agreed. Bennett, I'd like to thank you for you work as LyX/Mac Maintainer. My contributions are relative small and were not possible without the work from others before. For now, at least, the plan is for Stephen to take over the LyX/Mac-2.0.0 release but leave at least the 1.6.6 release to me. (We'll see what happens for 1.6.7.) I've given Stephen the XCode source for LyX-installer.app. As I've indicated before, I think we ought to do away with a separate installer in favor of a script that can get run when LyX is launched. But I'll leave the decision of what to do with it up to Stephen. (If the installer persists, though, it should go into the svn repository.) As I told Stephen, I'll still be around on the devel and users list, still compiling recent trunk and branch, still pestering people to fix Mac and other bugs, etc. And, of course, I'll still be using and benefiting from LyX itself, without which I'd now find it very hard to do any serious work. Thank you again for staying with the lists and your help to improve LyX. Currently I'm doing some minor improvements on the build script. On my todo list -- if possible before the 2.0.0 release -- are * Tiger support again (I believe I know what to do here) * Using the Qt-Frameworks as dynamic libraries * Review of the installer issues * Dictionaries and thesaurus for the spellchecker integration and extensibility Stephan
How to stringify a CPP macro
I'm looking for a tighter coupling of the build script and the compiled code.
There has to be a strict coherence between the strings the build script uses
and the strings for runtime lookup by LyX binary. So I want to pass a define
here. To convert it to a string I couldn't find a useable macro in LyX headers.
Is something like the following patch acceptable? Any other proposals?
(I tried something like -DSTR_ASPELL_FRAMEWORK=x.y but that did not work.)
Stephan
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp (Revision 34116)
+++ src/AspellChecker.cpp (Arbeitskopie)
@@ -27,6 +27,12 @@
#include map
#include string
+#ifdef __APPLE__ defined(ASPELL_FRAMEWORK)
+#define MYSTRINGIFY(a) _STRINGIFY(a)
+#define _STRINGIFY(a) #a
+#define STR_ASPELL_FRAMEWORK MYSTRINGIFY(ASPELL_FRAMEWORK)
+#endif
+
using namespace std;
namespace lyx {
@@ -85,17 +91,16 @@
}
}
-
AspellConfig * getConfig()
{
AspellConfig * config = new_aspell_config();
-#ifdef __APPLE__
+#ifdef __APPLE__ defined(ASPELL_FRAMEWORK)
char buf[2048] ;
- if ( getPrivateFrameworkPathName(buf, sizeof(buf), Aspell.framework)
) {
+ if ( getPrivateFrameworkPathName(buf, sizeof(buf),
STR_ASPELL_FRAMEWORK) ) {
lyx::support::FileName const base(buf);
- lyx::support::FileName const data(base.absFilename() +
/lib/aspell-0.60);
- lyx::support::FileName const dict(base.absFilename() +
/share/aspell);
+ lyx::support::FileName const data(base.absFilename() +
/Resources);
+ lyx::support::FileName const dict(base.absFilename() +
/Resources);
LYXERR(Debug::FILES, aspell bundle path: buf);
if (dict.isDirectory() data.isDirectory()) {
aspell_config_replace(config, dict-dir,
dict.absFilename().c_str());
Re: LyX/Mac Maintainer
On 04/11/2010 10:30 PM, BH wrote: Stephen Witt has been doing some great things for LyX/Mac. Given that I have not had time or expertise to really advance LyX/Mac, and given his abilities and enthusiasm, I have asked him if he would like to take over as LyX/Mac maintainer. He has agreed. For now, at least, the plan is for Stephen to take over the LyX/Mac-2.0.0 release but leave at least the 1.6.6 release to me. (We'll see what happens for 1.6.7.) I've given Stephen the XCode source for LyX-installer.app. As I've indicated before, I think we ought to do away with a separate installer in favor of a script that can get run when LyX is launched. But I'll leave the decision of what to do with it up to Stephen. (If the installer persists, though, it should go into the svn repository.) As I told Stephen, I'll still be around on the devel and users list, still compiling recent trunk and branch, still pestering people to fix Mac and other bugs, etc. And, of course, I'll still be using and benefiting from LyX itself, without which I'd now find it very hard to do any serious work. So thanks, Stephen, for your good work so far and for the contributions I'm sure you'll make in the future. And thanks, Bennett, for your work as LyX/Mac maintainer. We'll thank you for the other stuff you mentioned later. ;-) rh
RE: r34120 - lyx-devel/trunk/src
>- : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), >+ : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), > What's the rationale about initializing a docstring with 0 ? (Does it even compile ?) Vincent
Re: r34120 - lyx-devel/trunk/src
Vincent van Ravesteijn - TNW wrote: > >-: action_(LFUN_NOACTION), origin_(o), x_(0), y_(0), > >+: argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0), > y_(0), > > > > What's the rationale about initializing a docstring with 0 ? (Does it > even compile ?) hrmpf, i only wanted to add something for the place of argument_. now this patch is buggy, maybe even the next one i'm commiting right now... ;) i want to have response from the reporter. the whole thing is strange. since crash came from destructor and the only thing really _changed_ in Richard's patch was the sequence of initialization - my guess was it could be related because of missing argument. pavel
Re: r34120 - lyx-devel/trunk/src
On 04/12/2010 11:31 AM, Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
- : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0),
+ : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0),
y_(0),
What's the rationale about initializing a docstring with 0 ? (Does it
even compile ?)
hrmpf, i only wanted to add something for the place of argument_. now this
patch is buggy,
maybe even the next one i'm commiting right now... ;)
i want to have response from the reporter.
the whole thing is strange. since crash came from destructor and the only
thing really _changed_ in Richard's patch was the sequence of initialization -
my guess was it could be related because of missing argument.
I've tried restoring the initialization order. Otherwise, yes, it is
VERY strange. Note that this comes from LyX.cpp:531:
lyx::dispatch(FuncRequest(LFUN_WINDOW_NEW, geometryArg));
So the constructor was actually this one:
FuncRequest::FuncRequest(FuncCode act, string const & arg, Origin o)
: argument_(from_utf8(arg)), action_(act), origin_(o), x_(0),
y_(0),
button_(mouse_button::none)
{}
which initializes argument_ just fine.
Apparently, you guess didn't help, so I've reverted it. Now he can just
try the patch that changes back the initialization order. I've also
suggested he try a fresh checkout.
rh
Re: r34120 - lyx-devel/trunk/src
Richard Heck wrote:
> I've tried restoring the initialization order. Otherwise, yes, it is VERY
> strange. Note that this comes from LyX.cpp:531:
> lyx::dispatch(FuncRequest(LFUN_WINDOW_NEW, geometryArg));
> So the constructor was actually this one:
> FuncRequest::FuncRequest(FuncCode act, string const & arg, Origin o)
> : argument_(from_utf8(arg)), action_(act), origin_(o), x_(0),
> y_(0),
> button_(mouse_button::none)
> {}
> which initializes argument_ just fine.
ehh, i thought from the one without argument, no?
FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION,
o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39
pavel
RE: r34120 - lyx-devel/trunk/src
>ehh, i thought from the one without argument, no? > >FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION, >o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39 Please read further: #11 0x081a00c8 in static_initialization_and_destruction_0 () at FuncRequest?.cpp:28 This is your 0 initialization hack. Vincent
Re: r34120 - lyx-devel/trunk/src
Vincent van Ravesteijn - TNW wrote: > >ehh, i thought from the one without argument, no? > > > >FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION, > >o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39 > > Please read further: > > #11 0x081a00c8 in static_initialization_and_destruction_0 () > at FuncRequest?.cpp:28 > > This is your 0 initialization hack. no that backtrace is from the tree, which doesn't contain 0 hack anymore. anyway Richard hit the nail on the head in between - the problem was most probably due to the linking with old object files after autotools update and fresh checkout works... pavel
Re: r34120 - lyx-devel/trunk/src
On 04/12/2010 02:25 PM, Pavel Sanda wrote: Vincent van Ravesteijn - TNW wrote: ehh, i thought from the one without argument, no? FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION, o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39 Please read further: #11 0x081a00c8 in static_initialization_and_destruction_0 () at FuncRequest?.cpp:28 This is your 0 initialization hack. no that backtrace is from the tree, which doesn't contain 0 hack anymore. anyway Richard hit the nail on the head in between - the problem was most probably due to the linking with old object files after autotools update and fresh checkout works... We should perhaps add this to our bug reporting comments: If you are seeing the bug in checkouts from svn, then you might want to try a fresh checkout. Richard
Re: r34120 - lyx-devel/trunk/src
Richard Heck wrote: > We should perhaps add this to our bug reporting comments: If you are seeing > the bug in checkouts from svn, then you might want to try a fresh checkout. already done in FAQ :) p
Re: r34120 - lyx-devel/trunk/src
Le 12 avr. 10 à 21:16, Pavel Sanda a écrit : Richard Heck wrote: We should perhaps add this to our bug reporting comments: If you are seeing the bug in checkouts from svn, then you might want to try a fresh checkout. already done in FAQ :) But this should not happen... JMarc
Re: Lilypond+Lyx
On 12/04/2010 6:05 AM, Helge Hafting wrote:
Of course, embedding lilypond code in LyX would be even less work. But I
don't know a quick way to program that. Anything not supported directly
by latex, is kept in separate files. This is the way it is for graphics,
as well as music.
The current lilypond support in LyX takes care of running lilypond and
importing the resulting PDF automatically. So you can include music, but
you need to have each piece in a separate file.
What you want can be done though. Lilypond code could be stored in the
..lyx file, and LyX could write out a temporary .ly file and process it
with lilypond.
You may want to file an enhancement request for this at
http://www.lyx.org/trac/wiki/BugTrackerHome
so your idea is not forgotten. The idea is interesting, but I don't have
time right now.
Helge Hafting
Hi Bernardo, and others,
I just wrote a LyX module for basic Lilypond support within LyX. It
works with LyX 2.0 (the development version) only. But if you feel
adventurous, it would be a great help if you can test it out.
To developers: it is a simple idea. It is inspired by the literate
programming frameworks. LyX produces a .lytex document (which is really
just latex with some lilypond commands) and lilypond-book converts that
to latex. The usual conversion chain ensues.
At the moment the features are minimal (just a single inset is
available, and I don't know how to pass options to LaTeX environments).
But it is usable; the patch includes an example document.
Regards,
Julien
Index: layouts/lilypond.module
===
--- layouts/lilypond.module (revision 0)
+++ layouts/lilypond.module (revision 0)
@@ -0,0 +1,34 @@
+#\DeclareLyXModule[lilypond-book->latex]{LilyPond}
+#DescriptionBegin
+#This module adds an inset to enter LilyPond code directly into LyX.
+#It will be processed in the output.
+#DescriptionEnd
+#Category: literate
+
+# Author: Julien Rioux
+
+Format 26
+OutputType literate
+OutputFormat lilypond-book
+
+InsetLayout LilyPond
+ LabelString LilyPond
+ LatexType Environment
+ LaTexName lilypond
+ LyXType Custom
+ DecorationClassic
+ Font
+ Color latex
+ Family typewriter
+ EndFont
+ LabelFont
+ Color latex
+ SizeSmall
+ EndFont
+ MultiPar true
+ CustomParsfalse
+ ForcePlaintrue
+ FreeSpacing true
+ PassThru true
+ ForceLTR true
+End
Property changes on: layouts/lilypond.module
___
Added: svn:mime-type
+ text/plain
Added: svn:eol-style
+ native
Index: configure.py
===
--- configure.py(revision 34124)
+++ configure.py(working copy)
@@ -506,6 +506,7 @@
\Format literate nw NoWeb N """%%"
"document"
\Format sweave Rnw"Sweave"S "" "%%""document"
\Format lilypond ly "LilyPond music""" """%%""vector"
+\Format lilypond-book lytex "LilyPond book" "" """%%"
"document"
\Format latex tex"LaTeX (plain)" L """%%"
"document"
\Format pdflatex tex"LaTeX (pdflatex)" "" """%%"
"document"
\Format xetex tex"LaTeX (XeTeX)" "" """%%"
"document"
@@ -803,6 +804,25 @@
else:
logger.info('+ found LilyPond, but could not extract version
number.')
#
+path, lilypond_book = checkProg('a LilyPond book -> LaTeX converter',
['lilypond-book'])
+if (lilypond_book != ''):
+version_string = cmdOutput("lilypond-book --version")
+match = re.match('^(\S+)$', version_string)
+if match:
+version_number = match.groups()[0]
+version = version_number.split('.')
+if int(version[0]) > 2 or (len(version) > 1 and int(version[0]) ==
2 and int(version[1]) >= 9):
+addToRC(r'''\converter lilypond-book latex"lilypond-book
--pdf $$i" ""
+\converter lilypond-book pdflatex "lilypond-book --pdf
--latex-program=pdflatex $$i" ""''')
+logger.info('+ found LilyPond-book version %s.' %
version_number)
+elif int(version[0]) > 2 or (len(version) > 1 and int(version[0])
== 2 and int(version[1]) >= 1):
+addToRC(r'\converter lilypond-book latex"lilypond-book
$$i"""')
+logger.info('+ found LilyPond-book version %s.' %
version_number)
+else:
+logger.info('+ found LilyPond-book, but version
Re: LyX/Mac Maintainer
Am 12.04.2010 um 04:30 schrieb BH: > Stephen Witt has been doing some great things for LyX/Mac. Given that > I have not had time or expertise to really advance LyX/Mac, and given > his abilities and enthusiasm, I have asked him if he would like to > take over as LyX/Mac maintainer. He has agreed. Bennett, I'd like to thank you for you work as LyX/Mac Maintainer. My contributions are relative small and were not possible without the work from others before. > For now, at least, the plan is for Stephen to take over the > LyX/Mac-2.0.0 release but leave at least the 1.6.6 release to me. > (We'll see what happens for 1.6.7.) > > I've given Stephen the XCode source for LyX-installer.app. As I've > indicated before, I think we ought to do away with a separate > installer in favor of a script that can get run when LyX is launched. > But I'll leave the decision of what to do with it up to Stephen. (If > the installer persists, though, it should go into the svn repository.) > > As I told Stephen, I'll still be around on the devel and users list, > still compiling recent trunk and branch, still pestering people to fix > Mac and other bugs, etc. And, of course, I'll still be using and > benefiting from LyX itself, without which I'd now find it very hard to > do any serious work. Thank you again for staying with the lists and your help to improve LyX. Currently I'm doing some minor improvements on the build script. On my todo list -- if possible before the 2.0.0 release -- are * Tiger support again (I believe I know what to do here) * Using the Qt-Frameworks as dynamic libraries * Review of the installer issues * Dictionaries and thesaurus for the spellchecker integration and extensibility Stephan
How to stringify a CPP macro
I'm looking for a tighter coupling of the build script and the compiled code.
There has to be a strict coherence between the strings the build script uses
and the strings for runtime lookup by LyX binary. So I want to pass a define
here. To convert it to a string I couldn't find a useable macro in LyX headers.
Is something like the following patch acceptable? Any other proposals?
(I tried something like -DSTR_ASPELL_FRAMEWORK="x.y" but that did not work.)
Stephan
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp (Revision 34116)
+++ src/AspellChecker.cpp (Arbeitskopie)
@@ -27,6 +27,12 @@
#include
#include
+#ifdef __APPLE__ && defined(ASPELL_FRAMEWORK)
+#define MYSTRINGIFY(a) _STRINGIFY(a)
+#define _STRINGIFY(a) #a
+#define STR_ASPELL_FRAMEWORK MYSTRINGIFY(ASPELL_FRAMEWORK)
+#endif
+
using namespace std;
namespace lyx {
@@ -85,17 +91,16 @@
}
}
-
AspellConfig * getConfig()
{
AspellConfig * config = new_aspell_config();
-#ifdef __APPLE__
+#ifdef __APPLE__ && defined(ASPELL_FRAMEWORK)
char buf[2048] ;
- if ( getPrivateFrameworkPathName(buf, sizeof(buf), "Aspell.framework")
) {
+ if ( getPrivateFrameworkPathName(buf, sizeof(buf),
STR_ASPELL_FRAMEWORK) ) {
lyx::support::FileName const base(buf);
- lyx::support::FileName const data(base.absFilename() +
"/lib/aspell-0.60");
- lyx::support::FileName const dict(base.absFilename() +
"/share/aspell");
+ lyx::support::FileName const data(base.absFilename() +
"/Resources");
+ lyx::support::FileName const dict(base.absFilename() +
"/Resources");
LYXERR(Debug::FILES, "aspell bundle path: " << buf);
if (dict.isDirectory() && data.isDirectory()) {
aspell_config_replace(config, "dict-dir",
dict.absFilename().c_str());
