Re: [PATCH] Move Converter Cache to /tmp/lyx_tmpdir

[Helge Hafting]

rgheck wrote:

On 03/26/2010 06:40 PM, Enrico Forestieri wrote:

On Fri, Mar 26, 2010 at 11:16:10PM +0100, Enrico Forestieri wrote:
  

On Fri, Mar 26, 2010 at 06:08:58PM -0400, Richard Heck wrote:

Any other ideas, then? This does seem to be a real problem for some 
people.
   

Several:
1. Disable cache.
2. Softlink the cache dir somewhere else.
3. Use the -userdir flag when launching lyx.
4. Set the LYX_USERDIR_16x to a place with plenty of room.
 

Was forgetting this one:

   5. Change the user dir in the preferences.

   
This doesn't help. The user's problem is that he has a small quota on 
disk space. Files written to the temp dir don't count towards the quota. 
So unless you're proposing changing the user directory to /tmp/lyx/, ...


Is this something LyX should work around at all?

The above case is special, after all. Make a fix for that, then a 
different case comes along, where there _is_ quota on temp dirs too.


Seems to me that the better solution is an upper size limit on the 
converter cache. It may default to infinity, but the user could set

something lower to cope with his disk quotas. LyX could then delete
the least recently used cache files as the cache fills up.

Helge Hafting

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Le 02/04/2010 01:21, Pavel Sanda a écrit :
 Support for xz and lzma have been added at the same time in automake.

 are you sure? my 1.10.3 generated makefile knows dist-lzma, but not 
 dist-xz
 target. after hard fight i forced gentoo automake wrapper to choose 1.11.1 
 and
 dist-xz appeared.

 This is what the NEWS file says. Gentoo may have added the patch to its 
 1.10 version.


no i see in unpatched sources :
New in 1.10.1:
 - make dist can now create lzma-compressed tarballs.

so my proposal is lo use lzma from dependency and compression ratio
reasons.

pavel

Re: Compile Time

[Guenter Milde]

On 2010-04-06, Jack Desert wrote:
 Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
 MB RAM Compaq Presario, and it takes about 45 minutes. How long should
 it take?

Well, on my Duron 700 with 512 MB, it took several hours (and finally
crashed).

You can save memory/time if you compile without debugging info::

   Ohne debug-symbole, mit suffix (lyx - lyx-svn)::
   
./configure --with-version-suffix=-svn --enable-build-type=release 

and then

 * make, make install

Günter

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Stephan Witt]

Am 06.04.2010 um 04:12 schrieb BH:

 On Mon, Apr 5, 2010 at 8:48 PM, Stephan Witt st.w...@gmx.net wrote:
 Finally I learned how to build aspell myself as universal static library.
 So I'm able to provide a universal binary with aspell support.
 
 It is required to install aspell + dictionaries from macports to make it 
 work.
 The cocoAspell dictionaries aren't usable with stock aspell code.
 
 Another option is the conversion of the self made dynamic library to a 
 framework to place it inside the LyX app bundle.
 But this would be more work and may become superfluous with working 
 enchant+mac spell service support.
 
 What do others think?
 
 We've gotten many complaints over the years about spelling support,
 and spelling work without the user needing to install anything else
 would be great.

Yes, I realized this and that's why I want to try it.

 One question: if you include aspell as a framework, would you also
 include dictionaries, or how would users be able to add their own?

That are good questions. In principle I think dictionaries should be included. 
Additions by users should be possible and as easy as possible.

But I don't know if there is any GPL to care for. We have to check this before.

Another thing: perhaps I have to change the aspell code to make it work as a 
framework.
 
 On the other hand, how likely is enchant+mac spell support in the near future?

Don't know. This one perhaps JMarc can answer...

And then - if I'm not misinformed - there are not so many languages available.

Anyway, I propose to investigate the framework idea with aspell as an example 
and see if it works. (This I'll do)
Later the question is which spell checker is the right one, there are plenty 
alternatives, unfortunately.

Stephan

RE: Compile Time

[Vincent van Ravesteijn - TNW]

 
Well, on my Duron 700 with 512 MB, it took several
hours (and finally crashed).

I guess the memory is the big problem here. I upgraded my machine from
512 MB to 2 GB and compilation times were severely reduced.

Vincent

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Pavel Sanda]

Stephan Witt wrote:
 What do others think?

 Pavel, should I provide a 2nd alpha with aspell support?

i can not comment on the technical part - whether apell is best choice
on Mac or not. but sure we want to have spelling checker working, so
if aspell is the right choice, then lets build it with the support.

secondly, its important to keep your building procedure to be documented
somewhere in our tree.

feel free to create new dirs/files in development directory
for anything needed.

pavel

Re: r33993 - lyx-devel/trunk/lib/ui

[Pavel Sanda]

Peter Kümmel wrote:
 Could we reuse one form repo.or.cz? Or should
 we start over?

i had the feeling that tags were not correct on repo.or.cz.

  Is there a way to automatically synchronize?

dont know. some comments about non-automatical updating
were on the old git archive above.

for the fetch part be prepared for a day(s).

pavel

Re: edit ERT insets with external editor?

[Guenter Milde]

On 2010-04-01, rgheck wrote:
 On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:
 On 03/31/2010 05:53 PM, Liviu Andronic wrote:
 Dear LyX developers
 Would it be a good idea to allow users to edit ERT insets with an
 external editor? [snip]

 It is a good idea but it sounds a bit complicated to implement for the 
 communication of the child process; but it doable.

 Couldn't we do this internally, fairly easily? We already have LaTeX 
 highlighting in the preamble.

Most users that use complex ERT 

* will be familiar with LaTeX,
* will have a favourite LaTeX editor.

Reproducing the favourite LaTeX editors in LyX will never reach near the
original.

Günter

Re: Enhancement bugs for 2.0

[Guenter Milde]

On 2010-04-01, Jean-Marc Lasgouttes wrote:
 Le 31/03/2010 13:07, Guenter Milde a écrit :

 I wonder if we could use utf-8 as default latex source encoding for most
 (all) languages if the locale is UTF-8.

 AFAIK, UTF8 support is too weak in LaTeX right now. 

While it is weak in LaTeX, LyX's own UTF8 support is fine and also kicks
in if the latex-source is in UTF-8.

In a modern system, it really does not make sense to write the source in
iso8859-15, say, if the locale is UTF-8.

 And people should be able to chose the encoding they want.

Of course they should. However, this is not prevented by using a
different *default*.

Günter

Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes

[Pavel Sanda]

Uwe Stöhr wrote:
 The problem is that LyX does not store the colors buffer-dependent. If you 
 have 2 documents opened and switch between them, the colors need to be 
 updated. (Another manifestation of this bug is 
 http://www.lyx.org/trac/ticket/6626).

 Does anybody have an idea how to fix this properly?

use something like colorname_identificator_path_filename as color indetificator
internally inside gui?

pavel

Re: LyX 2.0: Mac widgets

[Pavel Sanda]

Rob Oakes wrote:
 One last thought.  I think LyX should strive for excellent UI design, 
 regardless of platform. There are certain aspects to Mac OS X, for example 
 that are pointless (like the worthless green maximize button).  I think it 
 makes sense to avoid propagating UI anachronisms, simply because they are 
 more Mac like.

the point was not to propagate mac-like things regardless the platform
but to make it more mac-like for mac people. unless it costs too much
coding effort, i dont see reason why lyx shouldn't look mac-style on mac.

pavel

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Jean-Marc Lasgouttes]

BH bewih...@gmail.com writes:
 On the other hand, how likely is enchant+mac spell support in the near future?

I have not contacted enchant/applespell author yet, but I will. However,
seeing how enchant brings in glib dependency, it might be better to do
our own applespell backend...

JMarc

Re: Compile Time

[Jean-Marc Lasgouttes]

Jack Desert jackdesert...@gmail.com writes:

 Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
 MB RAM Compaq Presario, and it takes about 45 minutes. How long should
 it take?

Final linking is probably the problem. Try to compile without debug
information (unless you are debugging). That would be --disable-debug.

JMarc

[f.j.frank...@newcastle.ac.uk] Re: Using AppleSpell with enchant

[Jean-Marc Lasgouttes]

Here is the answer I got. I think we have to implement it by ourselves...

JMarc


---BeginMessage---
Hi,

It's five years since I did this so I'm very rusty. I'm guessing you're
looking at AppleSpell in the enchant package?

http://www.abisource.com/viewvc/enchant/trunk/src/applespell/

This basically forces Apple's spell checker system:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/SpellCheck/SpellCheck.html

into the enchant framework - which means combining C++ and Objective-C,
which is always fun and semi-redundant.

If LyX is working with a native Cocoa interface (it's a long while since I
used LyX, so I don't know what you're doing these days) then there are
probably better ways to implement spelling on Mac OS X; whereas enchant
has the nice feature of being cross-platform.

Anyway, let me know a bit more about what you actually want to do and I'll
see if I can help...

Kind regards,
Frank

 Hello,

 We have added support for enchant in LyX (www.lyx.org) recently, qnd
 I had a look at AppleSpell support. Unfortunately, I do not understand
 how it is supposed to work. Dominic Lachowicz told me that you are the
 man
 who knows about this.

 Could you give me hints about the way to proceed?

 Sincerely
 Jean-Larc Lasgouttes



---End Message---

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Pavel Sanda sa...@lyx.org writes:
 no i see in unpatched sources :
 New in 1.10.1:
  - make dist can now create lzma-compressed tarballs.

 so my proposal is lo use lzma from dependency and compression ratio
 reasons.

OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate
releases. So you should require 1.10.1.

JMarc

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Jean-Marc Lasgouttes]

Jean-Marc Lasgouttes lasgout...@lyx.org writes:
 I have not contacted enchant/applespell author yet, but I will. However,
 seeing how enchant brings in glib dependency, it might be better to do
 our own applespell backend...

Actually I had :)

JMArc

Re: Compile Time

[Jack Desert]

El Tue, 06 Apr 2010 15:15:12 +0200
Jean-Marc Lasgouttes lasgout...@lyx.org escribió:
 Jack Desert jackdesert...@gmail.com writes:
 
  Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
  MB RAM Compaq Presario, and it takes about 45 minutes. How long should
  it take?
 
 Final linking is probably the problem. Try to compile without debug
 information (unless you are debugging). That would be --disable-debug.
 
 JMarc

Sounds good. I'll try that next. 

Actually, I downloaded a fresh copy of trunk last night, and it's not finding 
the makefile, so can't even get to that part.

  $ ./configure
  [snipped a bunch of lines]
  config.status: error: cannot find input file: `Makefile.in'

It worked fine a week ago. Has anything changed?

-Jack


-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: [f.j.frank...@newcastle.ac.uk] Re: Using AppleSpell with enchant

[Abdelrazak Younes]

On 04/06/2010 03:24 PM, Jean-Marc Lasgouttes wrote:

Here is the answer I got. I think we have to implement it by ourselves...
   


Maybe we can send our spellchecker header and see if he can help us? :-)

Abdel.

Re: Compile Time

[BH]

On Tue, Apr 6, 2010 at 10:04 AM, Jack Desert jackdesert...@gmail.com wrote:
 El Tue, 06 Apr 2010 15:15:12 +0200
 Jean-Marc Lasgouttes lasgout...@lyx.org escribió:
 Jack Desert jackdesert...@gmail.com writes:

  Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
  MB RAM Compaq Presario, and it takes about 45 minutes. How long should
  it take?

 Final linking is probably the problem. Try to compile without debug
 information (unless you are debugging). That would be --disable-debug.

 JMarc

 Sounds good. I'll try that next.

 Actually, I downloaded a fresh copy of trunk last night, and it's not finding 
 the makefile, so can't even get to that part.

  $ ./configure
  [snipped a bunch of lines]
  config.status: error: cannot find input file: `Makefile.in'

 It worked fine a week ago. Has anything changed?

Did you run autogen.sh first?

BH

Re: edit ERT insets with external editor?

[Liviu Andronic]

Hello

On Tue, Apr 6, 2010 at 12:16 PM, Guenter Milde mi...@users.berlios.de wrote:
 * will have a favourite LaTeX editor.

 Reproducing the favourite LaTeX editors in LyX will never reach near the
 original.

Abdel's idea to use QScintilla looks very appealing to me. This has
the advantage of providing neat editing features for a good deal of
languages *within* a LyX document, eliminating the overhead of using
an external editor (to read or edit the code). Having both options
would be a perfect solution, but having any of the two would be just
great.

Regards
Liviu

Math Question

[Richard Heck]

So I'm working on giving LyX the ability to output images instead of 
MathML/HTML for math constructs that it doesn't understand, and I've run 
into a problem. Basically, what I want to do is, in 
InsetMathHull::xhtml(), to be able to generate a preview image. I've 
been able to make necessary additions to the preview classes so I can 
wait for that to happen and get the filename back. But it doesn't work 
quite right, because I don't have a DocIterator to pass to addPreview(), 
which it needs to figure out what macros are defined at this point in 
the file. Any ideas how I could get such a thing? The only idea I've had 
is to cache one during updateBuffer(), but that seems both fragile and 
ugly. I'm also not sure I know precisely what the DocIterator needs to 
point to.


rh

Buffer Cloning Issue

[Richard Heck]

In working on the XHTML stuff, in particular on graphics and math 
output, I have started to wonder whether it is a good idea for the 
cloned buffer to share a temporary directory with the original buffer. 
E.g., in the graphics output routines (and this is true for LaTeX 
output, too), we copy lots of things into the temporary directory and 
may manipulate them. Is there a possibility of some kind of conflict 
here with what the original buffer is doing? Or even some weird race 
condition?


The downside to creating a new tempdir for the cloned buffer is that you 
would then have to copy things into it, etc, and then do it all again 
the next time. Though perhaps we could create a directory like 
/tmp/lyx_tmpdir.M1402/lyx_tmpbuf0/clone/, and let that always be the 
temporary directory for clones.


rh

RE: r34002 - lyx-devel/trunk

[Vincent van Ravesteijn - TNW]

 
 no i see in unpatched sources :
 New in 1.10.1:
  - make dist can now create lzma-compressed tarballs.

 so my proposal is lo use lzma from dependency and compression ratio 
 reasons.

OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate
releases. So you should require 1.10.1.


Maybe, I don't understand this well enough, but anyway, why do we
require automake 1.10.1 for everyone ? Even for people not using make
dist or the tarball at all.

Who does use make dist by the way ? Is it only Pavel, or do other
people do this as well ?

For me, requiring this means that I can no longer compile on Linux as I
don't have the appropriate rights there to update automake.

Vincent

Re: Compile Time

[Jack Desert]

 
  Sounds good. I'll try that next.
 
  Actually, I downloaded a fresh copy of trunk last night, and it's not 
  finding the makefile, so can't even get to that part.
 
   $ ./configure
   [snipped a bunch of lines]
   config.status: error: cannot find input file: `Makefile.in'
 
  It worked fine a week ago. Has anything changed?
 
 Did you run autogen.sh first?
 
 BH

Yes, I did run autogen first.

-Jack

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: r34068 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

sa...@lyx.org writes:

 Author: sanda
 Date: Tue Apr  6 17:25:12 2010
 New Revision: 34068
 URL: http://www.lyx.org/trac/changeset/34068

 Log:
 Bump automake deps.

You have therefore to bump autoconf to 2.60.

JMarc

Re: [f.j.frank...@newcastle.ac.uk] Re: Using AppleSpell with enchant

[Jean-Marc Lasgouttes]

Abdelrazak Younes you...@lyx.org writes:

 On 04/06/2010 03:24 PM, Jean-Marc Lasgouttes wrote:
 Here is the answer I got. I think we have to implement it by ourselves...


 Maybe we can send our spellchecker header and see if he can help us? :-)

I doubt it :) But if we begin to implement it and it does not work, I
guess we can ask.

JMarc

Re: LyX 1.6.6: please prepare for landing

[Jean-Pierre Chrétien]

Jürgen Spitzmüller a écrit :
We are only a few bugfixes away from the next release. Please prepare for a 
release in about three weeks.


What about bug #6608 ? Could the patch I suggested be applied ?

I the same line, I submitted an example file for crossrefs
http://article.gmane.org/gmane.editors.lyx.devel/126589
and I got no comments about it. Should it have been posted to lyx-docs ?

--
Jean-Pierre

Re: Compile Time

[Jack Desert]

El Tue, 6 Apr 2010 10:11:19 -0400
BH bewih...@gmail.com escribió:
 On Tue, Apr 6, 2010 at 10:04 AM, Jack Desert jackdesert...@gmail.com wrote:
  El Tue, 06 Apr 2010 15:15:12 +0200
  Jean-Marc Lasgouttes lasgout...@lyx.org escribió:
  Jack Desert jackdesert...@gmail.com writes:
 
   Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
   MB RAM Compaq Presario, and it takes about 45 minutes. How long should
   it take?
 
  Final linking is probably the problem. Try to compile without debug
  information (unless you are debugging). That would be --disable-debug.
 
  JMarc
 
  Sounds good. I'll try that next.
 
  Actually, I downloaded a fresh copy of trunk last night, and it's not 
  finding the makefile, so can't even get to that part.
 
   $ ./configure
   [snipped a bunch of lines]
   config.status: error: cannot find input file: `Makefile.in'
 
  It worked fine a week ago. Has anything changed?
 
 Did you run autogen.sh first?
 
 BH

Actually, autogen is throwing an error/warning:

Using automake (GNU automake) 1.9
Using autoconf (GNU Autoconf) 2.64
Building macros...
Building config header template...
Building Makefile templates...
configure.ac:29: option `dist-lzma' not recognized
Building configure...
Building po/POTFILES.in...

-Jack

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

RE: Compile Time

[Vincent van Ravesteijn - TNW]

 Did you run autogen.sh first?
 
 BH

Actually, autogen is throwing an error/warning:

Using automake (GNU automake) 1.9
Using autoconf (GNU Autoconf) 2.64
Building macros...
Building config header template...
Building Makefile templates...
configure.ac:29: option `dist-lzma' not recognized Building
configure...
Building po/POTFILES.in...


Since of today 17:25 GMC+1, we require automake 1.10.1 at least.

Vincent

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl writes:
 Maybe, I don't understand this well enough, but anyway, why do we
 require automake 1.10.1 for everyone ? Even for people not using make
 dist or the tarball at all.

Because there is no way (that I know of) to test for automake version
and require lzma target only when automake version is 1.10 or better.
I guess we can hack around it by testing for some macro which is known
to exist only in automake =1.10.

 Who does use make dist by the way ? Is it only Pavel, or do other
 people do this as well ?

That would be Pavel and Juergen.

 For me, requiring this means that I can no longer compile on Linux as I
 don't have the appropriate rights there to update automake.

I will have to update my automake too. Note that you can do a local
installation of automake.

JMarc

Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes

[Uwe Stöhr]

 use something like colorname_identificator_path_filename as color
 indetificator internally inside gui?

This doesn't work because in stdinsets we define the color for e.g. the 
greyed-out box as gereyedouttext. If we would use another color name 
for every buffer the inset won't find the color.
I therefore think that the easiest solution is to update all colors 
whenever a file is loaded or the file view is changed (when you switch 
between opened files using the tabbar).


Btw. do you have a starting point which routines are called by LyX when 
switching documents via the tabbar?


thanks and regards
Uwe

Re: LyX 1.6.6: please prepare for landing

[Jürgen Spitzmüller]

Jean-Pierre Chrétien wrote:
 What about bug #6608 ? Could the patch I suggested be applied ?

trac is down, but if I remember correctly, this was the French/prettyref 
issue, right? I think this is too late for 1.6.6, we have to look into that 
more deeply first.

IIRC you propose to load an extra package. I'm not sure about that. For me, 
the following preamble code fixes the problem as well:

\let\oldlabel\label
\renewcommand*{\label}{\catcode`\:=12 \oldlabel}
\let\oldpref\prettyref
\renewcommand*{\prettyref}{\catcode`\:=12 \oldpref}

But it's tedious to change catcodes like that. OTOH I don't know what the 
package you propose does.

 I the same line, I submitted an example file for crossrefs
 http://article.gmane.org/gmane.editors.lyx.devel/126589
 and I got no comments about it. Should it have been posted to lyx-docs ?

This is for trunk only. I guess Richard has an eye on it.

Jürgen

Re: LyX 1.6.6: please prepare for landing

[rgheck]

On 04/06/2010 01:09 PM, Jürgen Spitzmüller wrote:

Jean-Pierre Chrétien wrote:
   


I the same line, I submitted an example file for crossrefs
http://article.gmane.org/gmane.editors.lyx.devel/126589
and I got no comments about it. Should it have been posted to lyx-docs ?
 

This is for trunk only. I guess Richard has an eye on it.

   
Yes. We were talking about it, and I thought I should pause and think 
about your concerns. I believe that these can be met, though I haven't 
had time to work on this. I was thinking we can parse the preface (in 
lyx2lyx and also in layout2layout) and look for things like:

\newrefformat{For}{(\ref{#1}}
and transform them to:
\newref{For}{refcmd = {(\ref{#1})}}
Or just insert:
\newcommand\newrefformat[2]{\newref{#1}{refcmd = {#2}}}
at some relevant point. Untested as yet, but something like this should 
work.


rh

Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes

[Pavel Sanda]

Uwe Stöhr wrote:
 This doesn't work because in stdinsets we define the color for e.g. the 
 greyed-out box as gereyedouttext. If we would use another color name for 
 every buffer the inset won't find the color.

i was proposing to have it coded _internally_ which means that nothing changes
from the point of the stdinstes files or gui names. only the functions for
reading and writing would need more code to add/strip the filename part.

 Btw. do you have a starting point which routines are called by LyX when 
 switching documents via the tabbar?

this wont help, because you can have multiple windows.
pavel

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 Maybe, I don't understand this well enough, but anyway, why do we
 require automake 1.10.1 for everyone ? Even for people not using make
 dist or the tarball at all.

automake  1.10.1 will fail with the current tree because it wont
understand dist-lzma target.

 For me, requiring this means that I can no longer compile on Linux as I
 don't have the appropriate rights there to update automake.

:( i was bit afraid of those problems. you still have the possibility,
because you can compile and install automake locally on your own account,
but i understand thats not comfortable.

i'm open to revert all this lzma business if you or others think
it brings too much problems.

pavel

Re: Compile Time

[Jack Desert]

El Tue, 6 Apr 2010 18:46:54 +0200
Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl escribió:
 
  Did you run autogen.sh first?
  
  BH
 
 Actually, autogen is throwing an error/warning:
 
 Using automake (GNU automake) 1.9
 Using autoconf (GNU Autoconf) 2.64
 Building macros...
 Building config header template...
 Building Makefile templates...
 configure.ac:29: option `dist-lzma' not recognized Building
 configure...
 Building po/POTFILES.in...
 
 
 Since of today 17:25 GMC+1, we require automake 1.10.1 at least.
 
 Vincent

Ah, it seems I downloaded 1.9 thinking it was newer than 1.10. (As a decimal 
number it looks bigger.) Is it conventional for 1.9 to be lesser than 1.10? If 
so, I guess I'll have to get used to it.

We'll try this again.

-Jack

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: r34002 - lyx-devel/trunk

[Sven Hoexter]

On Tue, Apr 06, 2010 at 10:04:50PM +0200, Pavel Sanda wrote:
 Vincent van Ravesteijn - TNW wrote:
  Maybe, I don't understand this well enough, but anyway, why do we
  require automake 1.10.1 for everyone ? Even for people not using make
  dist or the tarball at all.
 
 automake  1.10.1 will fail with the current tree because it wont
 understand dist-lzma target.

Hm automake 1.10.1 is even in the current Debian/stable release so it's
a bit away from bleeding edge. So I'd expect that at least the other big
Linux distributions ship it aswell.

The current FreeBSD 7 and 8 stable series provide 1.10.1 aswell (at least
it's in the ports system).


  For me, requiring this means that I can no longer compile on Linux as I
  don't have the appropriate rights there to update automake.

Sounds rather odd (and old).
 
 :( i was bit afraid of those problems. you still have the possibility,
 because you can compile and install automake locally on your own account,
 but i understand thats not comfortable.
 
 i'm open to revert all this lzma business if you or others think
 it brings too much problems.

It's hard to tell which distributions in which version people use to work on.
After all it's hard to make right for everyone.

off-topic
While some people nowdays start to scream that Debian releases too often
someone from the Su^Oracles MySQL team recently wrote a blog post that he
couldn't believe people running CentOS (the RHEL rebuild) are still at
some 5.0.xx release and use that in production.
/off-topic


Beside that: Pavel, I had a look at #2820 and afterwards started to read
about the auto tools but wihout any helpful result so far. :( 

Sven
-- 
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in peace
   [The Cardigans - 03:45: No sleep]

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 For me, requiring this means that I can no longer compile on Linux as I
 don't have the appropriate rights there to update automake.

btw what distro you use? isn't possible there is more automake-xx versions
installed on your system?

pavel

Re: Compile Time

[Jack Desert]

El Tue, 06 Apr 2010 15:15:12 +0200
Jean-Marc Lasgouttes lasgout...@lyx.org escribió:
 Jack Desert jackdesert...@gmail.com writes:
 
  Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
  MB RAM Compaq Presario, and it takes about 45 minutes. How long should
  it take?
 
 Final linking is probably the problem. Try to compile without debug
 information (unless you are debugging). That would be --disable-debug.
 
 JMarc

I built it with --enable-build-type=release, and the time is down to 25 minutes 
from 45. 

-Jack



-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

[PATCH] Mac OS Aspell-Framework baby

[Stephan Witt]

Hi,

I made a case study to provide the aspell library as an framework.
(For the non-mac people: basically it's some formalized directory structure 
inside 
 the LyX.app directory - which is called the bundle)

1. We have to provide our own shared library of aspell inside the application 
bundle. 
This can be done with the help of apples install_name_tool.
2. We have to tell aspell the location of the data files inside the private 
framework in bundle.
This can be done with some Core Foundation magic.
3. We have to copy some files to the appropriate places.
I did this manually for the experiment. Later it has to be scripted.

I'll present a patch to make the way to go more transparent.
I was lazy and didn't add any files and therefore I modified the existing ones.

Maybe finally the getPrivateFrameworkPathName() function belongs to support 
somewhere...

The output of the compiled lyx looks like that:

.../src/AspellChecker.cpp(99): aspell bundle path: 
.../LyX-2.0.0svn.app/Contents/Frameworks
.../src/AspellChecker.cpp(103): aspell dict: 
.../LyX-2.0.0svn.app/Contents/Frameworks/share/aspell


Stephan

PS: I'll provide the patch inline to make comments easy. Please, send some 
comments.


Index: src/support/linkback/LinkBackProxy.h
===
--- src/support/linkback/LinkBackProxy.h(Revision 34068)
+++ src/support/linkback/LinkBackProxy.h(Arbeitskopie)
@@ -23,6 +23,8 @@
 ///
 void getLinkBackData(void const ** buf, unsigned * len);
 ///
+int getPrivateFrameworkPathName(char * buf, unsigned len);
+///
 void closeAllLinkBackLinks();
 
 #ifdef __cplusplus
Index: src/support/linkback/LinkBackProxy.m
===
--- src/support/linkback/LinkBackProxy.m(Revision 34068)
+++ src/support/linkback/LinkBackProxy.m(Arbeitskopie)
@@ -1,5 +1,5 @@
 /**
- * \file LinkBackProxy.mm
+ * \file LinkBackProxy.m
  * This file is part of LyX, the document processor.
  * Licence details can be found in the file COPYING.
  *
@@ -195,7 +195,6 @@
}
 }
 
-   
 void getLinkBackData(void const * * buf, unsigned * len)
 {
checkAutoReleasePool() ;
@@ -229,7 +228,17 @@
return [linkBackClient edit:nsDocName] == YES;
 }
 
+int getPrivateFrameworkPathName(char * buf, unsigned len)
+{
+   CFBundleRef myAppsBundle = NULL;
+   CFURLRefbaseURL  = NULL;
 
+   myAppsBundle = CFBundleGetMainBundle(); //  Get our application's main 
bundle from Core Foundation
+   baseURL = CFBundleCopyPrivateFrameworksURL( myAppsBundle );
+
+   return CFURLGetFileSystemRepresentation(baseURL, TRUE, buf, len) == YES;
+}
+
 void closeAllLinkBackLinks()
 {
[linkBackClient release];
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp   (Revision 34068)
+++ src/AspellChecker.cpp   (Arbeitskopie)
@@ -18,6 +18,9 @@
 #include support/lassert.h
 #include support/debug.h
 #include support/docstring_list.h
+#include support/filetools.h
+#include support/FileName.h
+#include support/linkback/LinkBackProxy.h
 
 #include aspell.h
 
@@ -83,10 +86,32 @@
 }
 
 
+AspellConfig * getConfig()
+{
+   AspellConfig * config = new_aspell_config();
+#ifdef __APPLE__
+   char buf[2048] ;
+
+   if ( getPrivateFrameworkPathName(buf, sizeof(buf)) ) {
+   lyx::support::FileName const base(buf);
+   lyx::support::FileName const dict(base.absFilename() + 
/share/aspell);
+   lyx::support::FileName const data(base.absFilename() + 
/lib/aspell-0.60);
+   LYXERR(Debug::FILES, aspell bundle path:   buf);
+   if (dict.isDirectory()  data.isDirectory()) {
+   aspell_config_replace(config, dict-dir, 
dict.absFilename().c_str());
+   aspell_config_replace(config, data-dir, 
data.absFilename().c_str());
+   LYXERR(Debug::FILES, aspell dict:   dict);
+   }
+   }
+#endif
+   return config ;
+}
+
+
 AspellSpeller * AspellChecker::Private::addSpeller(string const  lang,
   string const  variety)
 {
-   AspellConfig * config = new_aspell_config();
+   AspellConfig * config = getConfig();
// Aspell supports both languages and varieties (such as German
// old vs. new spelling). The respective naming convention is
// lang_REGION-variety (e.g. de_DE-alt).
@@ -107,6 +132,7 @@
else
// Report run-together words as errors
aspell_config_replace(config, run-together, false);
+
AspellCanHaveError * err = new_aspell_speller(config);
if (spell_error_object)
delete_aspell_can_have_error(spell_error_object);
@@ -116,6 +142,7 @@
// FIXME: We should we indicate somehow that this language is 
not
// supported.
   

Re: r34002 - lyx-devel/trunk

[Vincent van Ravesteijn]

Pavel Sanda schreef:

Vincent van Ravesteijn - TNW wrote:
  

For me, requiring this means that I can no longer compile on Linux as I
don't have the appropriate rights there to update automake.



btw what distro you use? isn't possible there is more automake-xx versions
installed on your system?

pavel
  


I probably can manage to get it back up running. However, it's annoying 
to update things, find workarounds, while I absolutely don't see any 
advantage at all.


I remember from when I wanted to start to participate in LyX that I was 
turned down because it seemed that you could only compile LyX on Windows 
with mingw back then, and this didn't work. Then I tried one linux 
machine, but I didn't have the right version of autotools, then another 
one, which didn't have the right gcc and so forth. Then a year later I 
wanted to try again, but suddenly Qt4 was required. Then, locally 
installing qt an compiling it, it still didn't work because LyX forgot 
to bump the gcc requirement which gave me errors I couldn't understand. 
Luckily, in the end, it was possible to compile on Windows without the 
hassle of cygwin/mingw.


Anyway, I'd prefer not to bump the requirements without a necessity or 
clear reason. It only might turn off users/possible developers and so 
forth. As I'm not a Linux guy at all, I really don't care how the 
tarballs are compressed, and if it's only needed for Pavel and Juergen, 
I prefer not to bump it.


However, It's up to you. I can work around it personally..

Vincent

Re: compilation error

[BH]

On Mon, Apr 5, 2010 at 8:46 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 06.04.2010 02:23, schrieb Richard Heck:

 since r34059 I cannot compile LyX:

 ..\..\src\Buffer.cpp(1571) : error C2065: 'PACKAGE_STRING' :
 undeclared identifier

 I'm guessing this is some Windows, or possibly cmake, thing. This is a
 macro defined in config.h, and it should be available.

 Indeed: SCons compiles while CMake doesn't.

It's not just Windows -- I have the same problem with cmake on Mac.

BH

Cmake compilation error

[rgheck]

On 04/06/2010 08:02 PM, BH wrote:

On Mon, Apr 5, 2010 at 8:46 PM, Uwe Stöhruwesto...@web.de  wrote:
   

Am 06.04.2010 02:23, schrieb Richard Heck:

 

since r34059 I cannot compile LyX:

..\..\src\Buffer.cpp(1571) : error C2065: 'PACKAGE_STRING' :
undeclared identifier

 

I'm guessing this is some Windows, or possibly cmake, thing. This is a
macro defined in config.h, and it should be available.
   

Indeed: SCons compiles while CMake doesn't.
 

It's not just Windows -- I have the same problem with cmake on Mac.

   

OK, so it's some cmake issue. Can someone help us with this?

rh

Re: [PATCH] Move Converter Cache to /tmp/lyx_tmpdir

[Helge Hafting]

rgheck wrote:

On 03/26/2010 06:40 PM, Enrico Forestieri wrote:

On Fri, Mar 26, 2010 at 11:16:10PM +0100, Enrico Forestieri wrote:
  

On Fri, Mar 26, 2010 at 06:08:58PM -0400, Richard Heck wrote:

Any other ideas, then? This does seem to be a real problem for some 
people.
   

Several:
1. Disable cache.
2. Softlink the cache dir somewhere else.
3. Use the -userdir flag when launching lyx.
4. Set the LYX_USERDIR_16x to a place with plenty of room.
 

Was forgetting this one:

   5. Change the user dir in the preferences.

   
This doesn't help. The user's problem is that he has a small quota on 
disk space. Files written to the temp dir don't count towards the quota. 
So unless you're proposing changing the user directory to /tmp/lyx/, ...


Is this something LyX should "work around" at all?

The above case is special, after all. Make a fix for that, then a 
different case comes along, where there _is_ quota on temp dirs too.


Seems to me that the better solution is an "upper size limit" on the 
converter cache. It may default to "infinity", but the user could set

something lower to cope with his disk quotas. LyX could then delete
the least recently used cache files as the cache fills up.

Helge Hafting

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 02/04/2010 01:21, Pavel Sanda a écrit :
>>> Support for xz and lzma have been added at the same time in automake.
>>
>> are you sure? my 1.10.3 generated makefile knows dist-lzma, but not 
>> dist-xz
>> target. after hard fight i forced gentoo automake wrapper to choose 1.11.1 
>> and
>> dist-xz appeared.
>
> This is what the NEWS file says. Gentoo may have added the patch to its 
> 1.10 version.


no i see in unpatched sources :
New in 1.10.1:
 - "make dist" can now create lzma-compressed tarballs.

so my proposal is lo use lzma from dependency and compression ratio
reasons.

pavel

Re: Compile Time

[Guenter Milde]

On 2010-04-06, Jack Desert wrote:
> Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> it take?

Well, on my Duron 700 with 512 MB, it took several hours (and finally
crashed).

You can save memory/time if you compile without debugging info::

   Ohne debug-symbole, mit suffix (lyx -> lyx-svn)::
   
./configure --with-version-suffix=-svn --enable-build-type=release 

and then

 * make, make install

Günter

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Stephan Witt]

Am 06.04.2010 um 04:12 schrieb BH:

> On Mon, Apr 5, 2010 at 8:48 PM, Stephan Witt  wrote:
>> Finally I learned how to build aspell myself as universal static library.
>> So I'm able to provide a universal binary with aspell support.
>> 
>> It is required to install aspell + dictionaries from macports to make it 
>> work.
>> The cocoAspell dictionaries aren't usable with stock aspell code.
>> 
>> Another option is the conversion of the self made dynamic library to a 
>> framework to place it inside the LyX app bundle.
>> But this would be more work and may become superfluous with working 
>> enchant+mac spell service support.
>> 
>> What do others think?
> 
> We've gotten many complaints over the years about spelling support,
> and spelling work without the user needing to install anything else
> would be great.

Yes, I realized this and that's why I want to try it.

> One question: if you include aspell as a framework, would you also
> include dictionaries, or how would users be able to add their own?

That are good questions. In principle I think dictionaries should be included. 
Additions by users should be possible and as easy as possible.

But I don't know if there is any GPL to care for. We have to check this before.

Another thing: perhaps I have to change the aspell code to make it work as a 
framework.
 
> On the other hand, how likely is enchant+mac spell support in the near future?

Don't know. This one perhaps JMarc can answer...

And then - if I'm not misinformed - there are not so many languages available.

Anyway, I propose to investigate the framework idea with aspell as an example 
and see if it works. (This I'll do)
Later the question is which spell checker is the right one, there are plenty 
alternatives, unfortunately.

Stephan

RE: Compile Time

[Vincent van Ravesteijn - TNW]

 
>Well, on my Duron 700 with 512 MB, it took several
>hours (and finally crashed).

I guess the memory is the big problem here. I upgraded my machine from
512 MB to 2 GB and compilation times were severely reduced.

Vincent

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Pavel Sanda]

Stephan Witt wrote:
> What do others think?
>
> Pavel, should I provide a 2nd alpha with aspell support?

i can not comment on the technical part - whether apell is best choice
on Mac or not. but sure we want to have spelling checker working, so
if aspell is the right choice, then lets build it with the support.

secondly, its important to keep your building procedure to be documented
somewhere in our tree.

feel free to create new dirs/files in development directory
for anything needed.

pavel

Re: r33993 - lyx-devel/trunk/lib/ui

[Pavel Sanda]

Peter Kümmel wrote:
> Could we reuse one form repo.or.cz? Or should
> we start over?

i had the feeling that tags were not correct on repo.or.cz.

> > Is there a way to automatically synchronize?

dont know. some comments about non-automatical updating
were on the old git archive above.

for the fetch part be prepared for a day(s).

pavel

Re: edit ERT insets with external editor?

[Guenter Milde]

On 2010-04-01, rgheck wrote:
> On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:
>> On 03/31/2010 05:53 PM, Liviu Andronic wrote:
>>> Dear LyX developers
>>> Would it be a good idea to allow users to edit ERT insets with an
>>> external editor? [snip]

>> It is a good idea but it sounds a bit complicated to implement for the 
>> communication of the child process; but it doable.

> Couldn't we do this internally, fairly easily? We already have LaTeX 
> highlighting in the preamble.

Most users that use complex ERT 

* will be familiar with LaTeX,
* will have a favourite LaTeX editor.

Reproducing the favourite LaTeX editors in LyX will never reach near the
original.

Günter

Re: Enhancement bugs for 2.0

[Guenter Milde]

On 2010-04-01, Jean-Marc Lasgouttes wrote:
> Le 31/03/2010 13:07, Guenter Milde a écrit :

>> I wonder if we could use utf-8 as default latex source encoding for most
>> (all) languages if the locale is UTF-8.

> AFAIK, UTF8 support is too weak in LaTeX right now. 

While it is weak in LaTeX, LyX's own UTF8 support is fine and also kicks
in if the latex-source is in UTF-8.

In a modern system, it really does not make sense to write the source in
iso8859-15, say, if the locale is UTF-8.

> And people should be able to chose the encoding they want.

Of course they should. However, this is not prevented by using a
different *default*.

Günter

Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes

[Pavel Sanda]

Uwe Stöhr wrote:
> The problem is that LyX does not store the colors buffer-dependent. If you 
> have 2 documents opened and switch between them, the colors need to be 
> updated. (Another manifestation of this bug is 
> http://www.lyx.org/trac/ticket/6626).
>
> Does anybody have an idea how to fix this properly?

use something like colorname_identificator_path_filename as color indetificator
internally inside gui?

pavel

Re: LyX 2.0: Mac widgets

[Pavel Sanda]

Rob Oakes wrote:
> One last thought.  I think LyX should strive for excellent UI design, 
> regardless of platform. There are certain aspects to Mac OS X, for example 
> that are pointless (like the worthless green maximize button).  I think it 
> makes sense to avoid propagating UI anachronisms, simply because they are 
> more "Mac like".

the point was not to propagate mac-like things regardless the platform
but to make it more mac-like for mac people. unless it costs too much
coding effort, i dont see reason why lyx shouldn't look mac-style on mac.

pavel

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Jean-Marc Lasgouttes]

BH  writes:
> On the other hand, how likely is enchant+mac spell support in the near future?

I have not contacted enchant/applespell author yet, but I will. However,
seeing how enchant brings in glib dependency, it might be better to do
our own applespell backend...

JMarc

Re: Compile Time

[Jean-Marc Lasgouttes]

Jack Desert  writes:

> Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> it take?

Final linking is probably the problem. Try to compile without debug
information (unless you are debugging). That would be --disable-debug.

JMarc

[f.j.frank...@newcastle.ac.uk] Re: Using AppleSpell with enchant

[Jean-Marc Lasgouttes]

Here is the answer I got. I think we have to implement it by ourselves...

JMarc


--- Begin Message ---
Hi,

It's five years since I did this so I'm very rusty. I'm guessing you're
looking at AppleSpell in the enchant package?

http://www.abisource.com/viewvc/enchant/trunk/src/applespell/

This basically forces Apple's spell checker system:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/SpellCheck/SpellCheck.html

into the enchant framework - which means combining C++ and Objective-C,
which is always fun and semi-redundant.

If LyX is working with a native Cocoa interface (it's a long while since I
used LyX, so I don't know what you're doing these days) then there are
probably better ways to implement spelling on Mac OS X; whereas enchant
has the nice feature of being cross-platform.

Anyway, let me know a bit more about what you actually want to do and I'll
see if I can help...

Kind regards,
Frank

> Hello,
>
> We have added support for enchant in LyX (www.lyx.org) recently, qnd
> I had a look at AppleSpell support. Unfortunately, I do not understand
> how it is supposed to work. Dominic Lachowicz told me that you are the
> man
> who knows about this.
>
> Could you give me hints about the way to proceed?
>
> Sincerely
> Jean-Larc Lasgouttes
>


--- End Message ---

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Pavel Sanda  writes:
> no i see in unpatched sources :
> New in 1.10.1:
>  - "make dist" can now create lzma-compressed tarballs.
>
> so my proposal is lo use lzma from dependency and compression ratio
> reasons.

OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate
releases. So you should require 1.10.1.

JMarc

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Jean-Marc Lasgouttes]

Jean-Marc Lasgouttes  writes:
> I have not contacted enchant/applespell author yet, but I will. However,
> seeing how enchant brings in glib dependency, it might be better to do
> our own applespell backend...

Actually I had :)

JMArc

Re: Compile Time

[Jack Desert]

El Tue, 06 Apr 2010 15:15:12 +0200
Jean-Marc Lasgouttes  escribió:
> Jack Desert  writes:
> 
> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> > MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> > it take?
> 
> Final linking is probably the problem. Try to compile without debug
> information (unless you are debugging). That would be --disable-debug.
> 
> JMarc

Sounds good. I'll try that next. 

Actually, I downloaded a fresh copy of trunk last night, and it's not finding 
the makefile, so can't even get to that part.

  $ ./configure
  [snipped a bunch of lines]
  config.status: error: cannot find input file: `Makefile.in'

It worked fine a week ago. Has anything changed?

-Jack


-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: [f.j.frank...@newcastle.ac.uk] Re: Using AppleSpell with enchant

[Abdelrazak Younes]

On 04/06/2010 03:24 PM, Jean-Marc Lasgouttes wrote:

Here is the answer I got. I think we have to implement it by ourselves...
   


Maybe we can send our spellchecker header and see if he can help us? :-)

Abdel.

Re: Compile Time

[BH]

On Tue, Apr 6, 2010 at 10:04 AM, Jack Desert  wrote:
> El Tue, 06 Apr 2010 15:15:12 +0200
> Jean-Marc Lasgouttes  escribió:
>> Jack Desert  writes:
>>
>> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
>> > MB RAM Compaq Presario, and it takes about 45 minutes. How long should
>> > it take?
>>
>> Final linking is probably the problem. Try to compile without debug
>> information (unless you are debugging). That would be --disable-debug.
>>
>> JMarc
>
> Sounds good. I'll try that next.
>
> Actually, I downloaded a fresh copy of trunk last night, and it's not finding 
> the makefile, so can't even get to that part.
>
>  $ ./configure
>  [snipped a bunch of lines]
>  config.status: error: cannot find input file: `Makefile.in'
>
> It worked fine a week ago. Has anything changed?

Did you run autogen.sh first?

BH

Re: edit ERT insets with external editor?

[Liviu Andronic]

Hello

On Tue, Apr 6, 2010 at 12:16 PM, Guenter Milde  wrote:
> * will have a favourite LaTeX editor.
>
> Reproducing the favourite LaTeX editors in LyX will never reach near the
> original.
>
Abdel's idea to use QScintilla looks very appealing to me. This has
the advantage of providing neat editing features for a good deal of
languages *within* a LyX document, eliminating the overhead of using
an external editor (to read or edit the code). Having both options
would be a "perfect" solution, but having any of the two would be just
great.

Regards
Liviu

Math Question

[Richard Heck]

So I'm working on giving LyX the ability to output images instead of 
MathML/HTML for math constructs that it doesn't understand, and I've run 
into a problem. Basically, what I want to do is, in 
InsetMathHull::xhtml(), to be able to generate a preview image. I've 
been able to make necessary additions to the preview classes so I can 
wait for that to happen and get the filename back. But it doesn't work 
quite right, because I don't have a DocIterator to pass to addPreview(), 
which it needs to figure out what macros are defined at this point in 
the file. Any ideas how I could get such a thing? The only idea I've had 
is to cache one during updateBuffer(), but that seems both fragile and 
ugly. I'm also not sure I know precisely what the DocIterator needs to 
point to.


rh

Buffer Cloning Issue

[Richard Heck]

In working on the XHTML stuff, in particular on graphics and math 
output, I have started to wonder whether it is a good idea for the 
cloned buffer to share a temporary directory with the original buffer. 
E.g., in the graphics output routines (and this is true for LaTeX 
output, too), we copy lots of things into the temporary directory and 
may manipulate them. Is there a possibility of some kind of conflict 
here with what the original buffer is doing? Or even some weird race 
condition?


The downside to creating a new tempdir for the cloned buffer is that you 
would then have to copy things into it, etc, and then do it all again 
the next time. Though perhaps we could create a directory like 
/tmp/lyx_tmpdir.M1402/lyx_tmpbuf0/clone/, and let that always be the 
temporary directory for clones.


rh

RE: r34002 - lyx-devel/trunk

[Vincent van Ravesteijn - TNW]

 
>> no i see in unpatched sources :
>> New in 1.10.1:
>>  - "make dist" can now create lzma-compressed tarballs.
>>
>> so my proposal is lo use lzma from dependency and compression ratio 
>> reasons.
>
>OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate
>releases. So you should require 1.10.1.
>

Maybe, I don't understand this well enough, but anyway, why do we
require automake 1.10.1 for everyone ? Even for people not using make
dist or the tarball at all.

Who does use "make dist" by the way ? Is it only Pavel, or do other
people do this as well ?

For me, requiring this means that I can no longer compile on Linux as I
don't have the appropriate rights there to update automake.

Vincent

Re: Compile Time

[Jack Desert]

> >
> > Sounds good. I'll try that next.
> >
> > Actually, I downloaded a fresh copy of trunk last night, and it's not 
> > finding the makefile, so can't even get to that part.
> >
> >  $ ./configure
> >  [snipped a bunch of lines]
> >  config.status: error: cannot find input file: `Makefile.in'
> >
> > It worked fine a week ago. Has anything changed?
> 
> Did you run autogen.sh first?
> 
> BH

Yes, I did run autogen first.

-Jack

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: r34068 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

sa...@lyx.org writes:

> Author: sanda
> Date: Tue Apr  6 17:25:12 2010
> New Revision: 34068
> URL: http://www.lyx.org/trac/changeset/34068
>
> Log:
> Bump automake deps.

You have therefore to bump autoconf to 2.60.

JMarc

Re: [f.j.frank...@newcastle.ac.uk] Re: Using AppleSpell with enchant

[Jean-Marc Lasgouttes]

Abdelrazak Younes  writes:

> On 04/06/2010 03:24 PM, Jean-Marc Lasgouttes wrote:
>> Here is the answer I got. I think we have to implement it by ourselves...
>>
>
> Maybe we can send our spellchecker header and see if he can help us? :-)

I doubt it :) But if we begin to implement it and it does not work, I
guess we can ask.

JMarc

Re: LyX 1.6.6: please prepare for landing

[Jean-Pierre Chrétien]

Jürgen Spitzmüller a écrit :
We are only a few bugfixes away from the next release. Please prepare for a 
release in about three weeks.


What about bug #6608 ? Could the patch I suggested be applied ?

I the same line, I submitted an example file for crossrefs
http://article.gmane.org/gmane.editors.lyx.devel/126589
and I got no comments about it. Should it have been posted to lyx-docs ?

--
Jean-Pierre

Re: Compile Time

[Jack Desert]

El Tue, 6 Apr 2010 10:11:19 -0400
BH  escribió:
> On Tue, Apr 6, 2010 at 10:04 AM, Jack Desert  wrote:
> > El Tue, 06 Apr 2010 15:15:12 +0200
> > Jean-Marc Lasgouttes  escribió:
> >> Jack Desert  writes:
> >>
> >> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> >> > MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> >> > it take?
> >>
> >> Final linking is probably the problem. Try to compile without debug
> >> information (unless you are debugging). That would be --disable-debug.
> >>
> >> JMarc
> >
> > Sounds good. I'll try that next.
> >
> > Actually, I downloaded a fresh copy of trunk last night, and it's not 
> > finding the makefile, so can't even get to that part.
> >
> >  $ ./configure
> >  [snipped a bunch of lines]
> >  config.status: error: cannot find input file: `Makefile.in'
> >
> > It worked fine a week ago. Has anything changed?
> 
> Did you run autogen.sh first?
> 
> BH

Actually, autogen is throwing an error/warning:

Using automake (GNU automake) 1.9
Using autoconf (GNU Autoconf) 2.64
Building macros...
Building config header template...
Building Makefile templates...
configure.ac:29: option `dist-lzma' not recognized
Building configure...
Building po/POTFILES.in...

-Jack

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

RE: Compile Time

[Vincent van Ravesteijn - TNW]

>> Did you run autogen.sh first?
>> 
>> BH
>
>Actually, autogen is throwing an error/warning:
>
>Using automake (GNU automake) 1.9
>Using autoconf (GNU Autoconf) 2.64
>Building macros...
>Building config header template...
>Building Makefile templates...
>configure.ac:29: option `dist-lzma' not recognized Building
configure...
>Building po/POTFILES.in...
>

Since of today 17:25 GMC+1, we require automake 1.10.1 at least.

Vincent

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

"Vincent van Ravesteijn - TNW"  writes:
> Maybe, I don't understand this well enough, but anyway, why do we
> require automake 1.10.1 for everyone ? Even for people not using make
> dist or the tarball at all.

Because there is no way (that I know of) to test for automake version
and require lzma target only when automake version is 1.10 or better.
I guess we can hack around it by testing for some macro which is known
to exist only in automake >=1.10.

> Who does use "make dist" by the way ? Is it only Pavel, or do other
> people do this as well ?

That would be Pavel and Juergen.

> For me, requiring this means that I can no longer compile on Linux as I
> don't have the appropriate rights there to update automake.

I will have to update my automake too. Note that you can do a local
installation of automake.

JMarc

Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes

[Uwe Stöhr]

> use something like colorname_identificator_path_filename as color
> indetificator internally inside gui?

This doesn't work because in stdinsets we define the color for e.g. the 
greyed-out box as "gereyedouttext". If we would use another color name 
for every buffer the inset won't find the color.
I therefore think that the easiest solution is to update all colors 
whenever a file is loaded or the file view is changed (when you switch 
between opened files using the tabbar).


Btw. do you have a starting point which routines are called by LyX when 
switching documents via the tabbar?


thanks and regards
Uwe

Re: LyX 1.6.6: please prepare for landing

[Jürgen Spitzmüller]

Jean-Pierre Chrétien wrote:
> What about bug #6608 ? Could the patch I suggested be applied ?

trac is down, but if I remember correctly, this was the French/prettyref 
issue, right? I think this is too late for 1.6.6, we have to look into that 
more deeply first.

IIRC you propose to load an extra package. I'm not sure about that. For me, 
the following preamble code fixes the problem as well:

\let\oldlabel\label
\renewcommand*{\label}{\catcode`\:=12 \oldlabel}
\let\oldpref\prettyref
\renewcommand*{\prettyref}{\catcode`\:=12 \oldpref}

But it's tedious to change catcodes like that. OTOH I don't know what the 
package you propose does.

> I the same line, I submitted an example file for crossrefs
> http://article.gmane.org/gmane.editors.lyx.devel/126589
> and I got no comments about it. Should it have been posted to lyx-docs ?

This is for trunk only. I guess Richard has an eye on it.

Jürgen

Re: LyX 1.6.6: please prepare for landing

[rgheck]

On 04/06/2010 01:09 PM, Jürgen Spitzmüller wrote:

Jean-Pierre Chrétien wrote:
   


I the same line, I submitted an example file for crossrefs
http://article.gmane.org/gmane.editors.lyx.devel/126589
and I got no comments about it. Should it have been posted to lyx-docs ?
 

This is for trunk only. I guess Richard has an eye on it.

   
Yes. We were talking about it, and I thought I should pause and think 
about your concerns. I believe that these can be met, though I haven't 
had time to work on this. I was thinking we can parse the preface (in 
lyx2lyx and also in layout2layout) and look for things like:

\newrefformat{For}{(\ref{#1}}
and transform them to:
\newref{For}{refcmd = {(\ref{#1})}}
Or just insert:
\newcommand\newrefformat[2]{\newref{#1}{refcmd = {#2}}}
at some relevant point. Untested as yet, but something like this should 
work.


rh

Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes

[Pavel Sanda]

Uwe Stöhr wrote:
> This doesn't work because in stdinsets we define the color for e.g. the 
> greyed-out box as "gereyedouttext". If we would use another color name for 
> every buffer the inset won't find the color.

i was proposing to have it coded _internally_ which means that nothing changes
from the point of the stdinstes files or gui names. only the functions for
reading and writing would need more code to add/strip the filename part.

> Btw. do you have a starting point which routines are called by LyX when 
> switching documents via the tabbar?

this wont help, because you can have multiple windows.
pavel

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
> Maybe, I don't understand this well enough, but anyway, why do we
> require automake 1.10.1 for everyone ? Even for people not using make
> dist or the tarball at all.

automake < 1.10.1 will fail with the current tree because it wont
understand dist-lzma target.

> For me, requiring this means that I can no longer compile on Linux as I
> don't have the appropriate rights there to update automake.

:( i was bit afraid of those problems. you still have the possibility,
because you can compile and install automake locally on your own account,
but i understand thats not comfortable.

i'm open to revert all this lzma business if you or others think
it brings too much problems.

pavel

Re: Compile Time

[Jack Desert]

El Tue, 6 Apr 2010 18:46:54 +0200
"Vincent van Ravesteijn - TNW"  escribió:
> 
> >> Did you run autogen.sh first?
> >> 
> >> BH
> >
> >Actually, autogen is throwing an error/warning:
> >
> >Using automake (GNU automake) 1.9
> >Using autoconf (GNU Autoconf) 2.64
> >Building macros...
> >Building config header template...
> >Building Makefile templates...
> >configure.ac:29: option `dist-lzma' not recognized Building
> configure...
> >Building po/POTFILES.in...
> >
> 
> Since of today 17:25 GMC+1, we require automake 1.10.1 at least.
> 
> Vincent

Ah, it seems I downloaded 1.9 thinking it was newer than 1.10. (As a decimal 
number it looks bigger.) Is it conventional for 1.9 to be lesser than 1.10? If 
so, I guess I'll have to get used to it.

We'll try this again.

-Jack

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: r34002 - lyx-devel/trunk

[Sven Hoexter]

On Tue, Apr 06, 2010 at 10:04:50PM +0200, Pavel Sanda wrote:
> Vincent van Ravesteijn - TNW wrote:
> > Maybe, I don't understand this well enough, but anyway, why do we
> > require automake 1.10.1 for everyone ? Even for people not using make
> > dist or the tarball at all.
> 
> automake < 1.10.1 will fail with the current tree because it wont
> understand dist-lzma target.

Hm automake 1.10.1 is even in the current Debian/stable release so it's
a bit away from bleeding edge. So I'd expect that at least the other big
Linux distributions ship it aswell.

The current FreeBSD 7 and 8 stable series provide 1.10.1 aswell (at least
it's in the ports system).


> > For me, requiring this means that I can no longer compile on Linux as I
> > don't have the appropriate rights there to update automake.

Sounds rather odd (and old).
 
> :( i was bit afraid of those problems. you still have the possibility,
> because you can compile and install automake locally on your own account,
> but i understand thats not comfortable.
> 
> i'm open to revert all this lzma business if you or others think
> it brings too much problems.

It's hard to tell which distributions in which version people use to work on.
After all it's hard to make right for everyone.


While some people nowdays start to scream that Debian releases too often
someone from the Su^Oracles MySQL team recently wrote a blog post that he
couldn't believe people running CentOS (the RHEL rebuild) are still at
some 5.0.xx release and use that in production.



Beside that: Pavel, I had a look at #2820 and afterwards started to read
about the auto tools but wihout any helpful result so far. :( 

Sven
-- 
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in peace
   [The Cardigans - 03:45: No sleep]

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
> For me, requiring this means that I can no longer compile on Linux as I
> don't have the appropriate rights there to update automake.

btw what distro you use? isn't possible there is more automake-xx versions
installed on your system?

pavel

Re: Compile Time

[Jack Desert]

El Tue, 06 Apr 2010 15:15:12 +0200
Jean-Marc Lasgouttes  escribió:
> Jack Desert  writes:
> 
> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> > MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> > it take?
> 
> Final linking is probably the problem. Try to compile without debug
> information (unless you are debugging). That would be --disable-debug.
> 
> JMarc

I built it with --enable-build-type=release, and the time is down to 25 minutes 
from 45. 

-Jack



-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

[PATCH] Mac OS Aspell-Framework baby

[Stephan Witt]

Hi,

I made a case study to provide the aspell library as an framework.
(For the non-mac people: basically it's some formalized directory structure 
inside 
 the LyX.app directory - which is called the bundle)

1. We have to provide our own shared library of aspell inside the application 
bundle. 
This can be done with the help of apples install_name_tool.
2. We have to tell aspell the location of the data files inside the private 
framework in bundle.
This can be done with some Core Foundation magic.
3. We have to copy some files to the appropriate places.
I did this manually for the experiment. Later it has to be scripted.

I'll present a patch to make the way to go more transparent.
I was lazy and didn't add any files and therefore I modified the existing ones.

Maybe finally the getPrivateFrameworkPathName() function belongs to support 
somewhere...

The output of the compiled lyx looks like that:

.../src/AspellChecker.cpp(99): aspell bundle path: 
.../LyX-2.0.0svn.app/Contents/Frameworks
.../src/AspellChecker.cpp(103): aspell dict: 
.../LyX-2.0.0svn.app/Contents/Frameworks/share/aspell


Stephan

PS: I'll provide the patch inline to make comments easy. Please, send some 
comments.


Index: src/support/linkback/LinkBackProxy.h
===
--- src/support/linkback/LinkBackProxy.h(Revision 34068)
+++ src/support/linkback/LinkBackProxy.h(Arbeitskopie)
@@ -23,6 +23,8 @@
 ///
 void getLinkBackData(void const ** buf, unsigned * len);
 ///
+int getPrivateFrameworkPathName(char * buf, unsigned len);
+///
 void closeAllLinkBackLinks();
 
 #ifdef __cplusplus
Index: src/support/linkback/LinkBackProxy.m
===
--- src/support/linkback/LinkBackProxy.m(Revision 34068)
+++ src/support/linkback/LinkBackProxy.m(Arbeitskopie)
@@ -1,5 +1,5 @@
 /**
- * \file LinkBackProxy.mm
+ * \file LinkBackProxy.m
  * This file is part of LyX, the document processor.
  * Licence details can be found in the file COPYING.
  *
@@ -195,7 +195,6 @@
}
 }
 
-   
 void getLinkBackData(void const * * buf, unsigned * len)
 {
checkAutoReleasePool() ;
@@ -229,7 +228,17 @@
return [linkBackClient edit:nsDocName] == YES;
 }
 
+int getPrivateFrameworkPathName(char * buf, unsigned len)
+{
+   CFBundleRef myAppsBundle = NULL;
+   CFURLRefbaseURL  = NULL;
 
+   myAppsBundle = CFBundleGetMainBundle(); //  Get our application's main 
bundle from Core Foundation
+   baseURL = CFBundleCopyPrivateFrameworksURL( myAppsBundle );
+
+   return CFURLGetFileSystemRepresentation(baseURL, TRUE, buf, len) == YES;
+}
+
 void closeAllLinkBackLinks()
 {
[linkBackClient release];
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp   (Revision 34068)
+++ src/AspellChecker.cpp   (Arbeitskopie)
@@ -18,6 +18,9 @@
 #include "support/lassert.h"
 #include "support/debug.h"
 #include "support/docstring_list.h"
+#include "support/filetools.h"
+#include "support/FileName.h"
+#include "support/linkback/LinkBackProxy.h"
 
 #include 
 
@@ -83,10 +86,32 @@
 }
 
 
+AspellConfig * getConfig()
+{
+   AspellConfig * config = new_aspell_config();
+#ifdef __APPLE__
+   char buf[2048] ;
+
+   if ( getPrivateFrameworkPathName(buf, sizeof(buf)) ) {
+   lyx::support::FileName const base(buf);
+   lyx::support::FileName const dict(base.absFilename() + 
"/share/aspell");
+   lyx::support::FileName const data(base.absFilename() + 
"/lib/aspell-0.60");
+   LYXERR(Debug::FILES, "aspell bundle path: " << buf);
+   if (dict.isDirectory() && data.isDirectory()) {
+   aspell_config_replace(config, "dict-dir", 
dict.absFilename().c_str());
+   aspell_config_replace(config, "data-dir", 
data.absFilename().c_str());
+   LYXERR(Debug::FILES, "aspell dict: " << dict);
+   }
+   }
+#endif
+   return config ;
+}
+
+
 AspellSpeller * AspellChecker::Private::addSpeller(string const & lang,
   string const & variety)
 {
-   AspellConfig * config = new_aspell_config();
+   AspellConfig * config = getConfig();
// Aspell supports both languages and varieties (such as German
// old vs. new spelling). The respective naming convention is
// lang_REGION-variety (e.g. de_DE-alt).
@@ -107,6 +132,7 @@
else
// Report run-together words as errors
aspell_config_replace(config, "run-together", "false");
+
AspellCanHaveError * err = new_aspell_speller(config);
if (spell_error_object)
delete_aspell_can_have_error(spell_error_object);
@@ -116,6 +142,7 @@
// FIXME: We should we indicate somehow that this language is 
not
 

Re: r34002 - lyx-devel/trunk

[Vincent van Ravesteijn]

Pavel Sanda schreef:

Vincent van Ravesteijn - TNW wrote:
  

For me, requiring this means that I can no longer compile on Linux as I
don't have the appropriate rights there to update automake.



btw what distro you use? isn't possible there is more automake-xx versions
installed on your system?

pavel
  


I probably can manage to get it back up running. However, it's annoying 
to update things, find workarounds, while I absolutely don't see any 
advantage at all.


I remember from when I wanted to start to participate in LyX that I was 
turned down because it seemed that you could only compile LyX on Windows 
with mingw back then, and this didn't work. Then I tried one linux 
machine, but I didn't have the right version of autotools, then another 
one, which didn't have the right gcc and so forth. Then a year later I 
wanted to try again, but suddenly Qt4 was required. Then, locally 
installing qt an compiling it, it still didn't work because LyX forgot 
to bump the gcc requirement which gave me errors I couldn't understand. 
Luckily, in the end, it was possible to compile on Windows without the 
hassle of cygwin/mingw.


Anyway, I'd prefer not to bump the requirements without a necessity or 
clear reason. It only might turn off users/possible developers and so 
forth. As I'm not a Linux guy at all, I really don't care how the 
tarballs are compressed, and if it's only needed for Pavel and Juergen, 
I prefer not to bump it.


However, It's up to you. I can work around it personally..

Vincent

Re: compilation error

[BH]

On Mon, Apr 5, 2010 at 8:46 PM, Uwe Stöhr  wrote:
> Am 06.04.2010 02:23, schrieb Richard Heck:
>
>>> since r34059 I cannot compile LyX:
>>>
>>> ..\..\src\Buffer.cpp(1571) : error C2065: 'PACKAGE_STRING' :
>>> undeclared identifier
>>>
>> I'm guessing this is some Windows, or possibly cmake, thing. This is a
>> macro defined in config.h, and it should be available.
>
> Indeed: SCons compiles while CMake doesn't.

It's not just Windows -- I have the same problem with cmake on Mac.

BH

Cmake compilation error

[rgheck]

On 04/06/2010 08:02 PM, BH wrote:

On Mon, Apr 5, 2010 at 8:46 PM, Uwe Stöhr  wrote:
   

Am 06.04.2010 02:23, schrieb Richard Heck:

 

since r34059 I cannot compile LyX:

..\..\src\Buffer.cpp(1571) : error C2065: 'PACKAGE_STRING' :
undeclared identifier

 

I'm guessing this is some Windows, or possibly cmake, thing. This is a
macro defined in config.h, and it should be available.
   

Indeed: SCons compiles while CMake doesn't.
 

It's not just Windows -- I have the same problem with cmake on Mac.

   

OK, so it's some cmake issue. Can someone help us with this?

rh