Bennett Helm wrote:
Bennett,
if you define in words just what you want, I can whip up the script
for you.
I thought I did! But let me try to be clearer
Sorry, I thought that Ronald was suggesting an alternative strategy.
The object is first to find where .lyxpipe.in is located. The p
When the check is unsuccessful the line becomes invalid and therefore the while
loop breaks.
The problem of this is line 77 in chkconfig.ltx (command definition of
\TestItem) :
I did not like chkconfig.ltx but was not able to replace it.
chkconfig.ltx uses latex to check latex packages and gen
> Attached the fix for 1.4. The same for 1.5 I guess.
Many thanks Jürgen for the quick fix!
The patch works also perfectly in LyX 1.5; please apply it to trunk and branch.
regards Uwe
>> Another user has this problem too. I made a lot of tests the last days
>> together with this user but I'm still not able to reproduce it.
> It's maybe a manifest problem again.
Hmm, but why does it then work on many machines and one some not?
I notices tha there is the file
"Microsoft.VC80.C
+checking for package geometry [geometry]... yes
+checking for package jurabib [jurabib]...
creating packages.lst
creating doc/LaTeXConfig.lyx
LyX: Fertig!
lyx: Disabling LyX socket.
And this is the problem: In the example above configure.py checks for
the LaTeX-package jurabib and MiKTeX tries
On Jan 12, 2007, at 4:10 PM, Angus Leeming wrote:
Ronald Florence <[EMAIL PROTECTED]> writes:
I've been away from this too long to be of much help, but I think the
Mac way of doing this would be to put the users current LyX home
directory in ~/Library/Preferences/LyX.plist...
An alternative
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Abdelrazak Younes wrote:
> > Could someone please test this under Linux?
> >
> > Enrico, if you could test it under Cygwin as well, that would be great.
>
> Take this patch if you want to see some debug outputs. It's working
> perfectly here and it
Andre Poenitz wrote:
Does this actually help?
I would have expected that moving the method definition to the header
would have been needed, too (possiby causing additional header pulled
in)
Year, that's what I ended up doing in a following commit.
Abdel.
Abdelrazak Younes wrote:
Could someone please test this under Linux?
Enrico, if you could test it under Cygwin as well, that would be great.
Take this patch if you want to see some debug outputs. It's working
perfectly here and it's really a _huge_ performance boost under Windows!
Abdel.
I
Could someone please test this under Linux?
Enrico, if you could test it under Cygwin as well, that would be great.
Thanks in advance,
Abdel.
Index: messages.C
===
--- messages.C (revision 16645)
+++ messages.C (working copy)
@@
On Fri, 12 Jan 2007, Angus Leeming wrote:
I'm really tempted to try it anyway... Or at least partition the
harddrive and boot using a LiveCD or something. As long as I dont mess
with the MBR I shouldn't be able to screw up the Windoze installation.
That depends. If you have Norton Ghost insta
Ronald Florence <[EMAIL PROTECTED]> writes:
> I've been away from this too long to be of much help, but I think the
> Mac way of doing this would be to put the users current LyX home
> directory in ~/Library/Preferences/LyX.plist...
> An alternative that you might consider is to link ~/Library
On Fri, Jan 12, 2007 at 05:50:10PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > Believe me, external_path could be completely ditched.
>
> Please stop talking of external_path. Yesterday you wrote that you don't
> want to discuss that anymore, and I don't want that either. I gave up
On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > as a parameter introducer. To tell you the truth, the cygwin version
> > of lyx that I make available for download is patched such that through
> > an env variable it is possible to use either posix or win
[EMAIL PROTECTED] wrote:
> On Fri, 12 Jan 2007, [EMAIL PROTECTED] wrote:
>
>> On Sat, 13 Jan 2007, Bo Peng wrote:
>>
>>> > > - MSVC2005 (either Scons or CMake), that's what Bo, Michael,
>>> Edwin,
>>> > > Peter and me are using.
>>>
>>> Scons still works but there is an unconfirmed 64bit wi
Bennett,
I've been away from this too long to be of much help, but I think the
Mac way of doing this would be to put the users current LyX home
directory in ~/Library/Preferences/LyX.plist. The lyxeditor script
could then easily parse for it in the .plist -- I think there are
ready made
Peter Kümmel wrote:
> Is this still valid?
>
> * open Tutorial; click on TOC: TOC dialog has no contents
> (only with --enable-stdlib-debug, has been seen on qt 4.2.2, gcc 4.1.2,
> openSuse 10.1/x32 and 10.2/x64, but is probably not OS/qt specific, but
> dependant on the compiler)
Yes.
On Jan 12, 2007, at 11:18 AM, Ronald Florence wrote:
Bennett (& Jean-Marc),
If it hasn't already been done, a modification to the lyxeditor
script already included in MacOSX LyX based on this script
http://www.macosxhints.com/article.php?story=20070111095701823
could work nicely with LyX a
Uwe Stöhr wrote:
> Since 1.4 LyX doesn't understand decimal points in the bounding box sizes
> of graphics: Inserting a decimal point isn't possible and existing graphics
> that already have decimal points (inserted with LyX 1.3) can't be modified.
Attached the fix for 1.4. The same for 1.5 I gues
Bo Peng wrote:
>> > - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin,
>> > Peter and me are using.
>
> Scons still works but there is an unconfirmed 64bit win bug for scons;
> and debugging in cmake is easier.
>
>> > - msys/mingw with autotools: I think this is not supported a
Abdelrazak Younes wrote:
Hum, maybe gcc needs the 'virtual' keyword. Could you try it please:
inline virtual bool inMathed() const;
inline virtual bool inTexted() const;
I think virtual methods cannot be inlined because the decision which
method to call is done at runtime but for inlin
On Mon, Jan 08, 2007 at 10:50:17AM -, [EMAIL PROTECTED] wrote:
> Author: younes
> Date: Mon Jan 8 11:50:15 2007
> New Revision: 16597
>
> URL: http://www.lyx.org/trac/changeset/16597
> Log:
> performance fix.
>
> Modified:
> lyx-devel/trunk/src/dociterator.h
>
> Modified: lyx-devel/trun
<[EMAIL PROTECTED]> writes:
>
> On Fri, 12 Jan 2007, Abdelrazak Younes wrote:
>
> > [EMAIL PROTECTED] wrote:
> >> I've been meaning to get into the development (source wise) of LyX for a
> >> long time, and maybe now is the time.
> >>
> >> As compilation takes quite a while, I need a fast ma
Abdelrazak Younes wrote:
> OK, thanks for the explanation. I am not pretending that I will solve
> everything, don't be afraid ;-). We do have an internal in source
> gettext. Couldn't we just support that and live all other version aside?
I'd rather like to get rid of that instead of completely
Enrico Forestieri wrote:
> as a parameter introducer. To tell you the truth, the cygwin version
> of lyx that I make available for download is patched such that through
> an env variable it is possible to use either posix or windows style
> paths.
Making a binary created from patched sources avai
Enrico Forestieri wrote:
> Believe me, external_path could be completely ditched.
Please stop talking of external_path. Yesterday you wrote that you don't
want to discuss that anymore, and I don't want that either. I gave up
trying to understand how it behaves now a long time ago, and I don't car
On Fri, 12 Jan 2007, [EMAIL PROTECTED] wrote:
On Sat, 13 Jan 2007, Bo Peng wrote:
> > - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin,
> > Peter and me are using.
Scons still works but there is an unconfirmed 64bit win bug for scons;
and debugging in cmake is easier
On Fri, 12 Jan 2007, Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
They are not different than the translatable ones. The only problem I can
imagine is that the cache could get out of date if somebody changes the
layout file.
Do you mean in the Document settings? If yes, then
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will
use,
and we don't know what other message
On Sat, 13 Jan 2007, Bo Peng wrote:
> - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin,
>Peter and me are using.
Scons still works but there is an unconfirmed 64bit win bug for scons;
and debugging in cmake is easier.
I read INSTALL.Win32 (duh...). So the Windows alter
Georg Baum wrote:
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will use,
and we don't know what other message was translated before. To
On Fri, Jan 12, 2007 at 03:55:01PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > On Thu, Jan 11, 2007 at 08:19:05PM +0100, Georg Baum wrote:
> >
> >> Many parts of the LyX code depend on the fact that we use internal paths
> >> only. Therefore we should fix the external inset to not c
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> They are not different than the translatable ones. The only problem I can
>> imagine is that the cache could get out of date if somebody changes the
>> layout file.
>
> Do you mean in the Document settings? If yes, then we just need to reset
> the c
Abdelrazak Younes wrote:
> This last line in particular looks suspicious. Why do we set environment
> variable at each translation request?
Because the environment variable determines what language gettext will use,
and we don't know what other message was translated before. To my knowledge
no li
Georg Baum wrote:
Abdelrazak Younes wrote:
My idea would be to cache the translated text instead of translating
each time updateLabels() is called. But I am not sure I can do that on
untranslatable layouts.
They are not different than the translatable ones. The only problem I can
imagine is t
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak> not
> Another user has this problem too. I made a lot of tests the last days
> together with this user but I'm still not able to reproduce it.
It's maybe a manifest problem again.
The manifest problem usually show some weird c6043 error. But I guess
it is worth trying the mingw binary as it does no
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Are you sure that C-< should not work without buffer? Why?
Bo> I am actually not sure. Bookmark 0 is not saved with session so it
Bo> does not exist when lyx starts (reason for C-< crash). If bookmark
Bo> 0 becomes valid later, it should be usab
I'll have a look at your patch but at first glance I think you missed
the mutiple-view case entirely.
I know. That is only a proof of concept patch. Thank you for you
attention, I was just irritated that I had to hang my session stuff
everywhere instead of doing it on a per-buffer basis.
Bo
> - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin,
> Peter and me are using.
Scons still works but there is an unconfirmed 64bit win bug for scons;
and debugging in cmake is easier.
> - msys/mingw with autotools: I think this is not supported anymore
> because of automak
[EMAIL PROTECTED] wrote:
On Fri, 12 Jan 2007, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
I've been meaning to get into the development (source wise) of LyX
for a
long time, and maybe now is the time.
As compilation takes quite a while, I need a fast machine for this.
This
reduce
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak> not sure I can do that on unt
Are you sure that C-< should not work without buffer? Why?
I am actually not sure. Bookmark 0 is not saved with session so it
does not exist when lyx starts (reason for C-< crash). If bookmark 0
becomes valid later, it should be usable without a valid buffer.
I am not sure because I never use b
On Fri, 12 Jan 2007, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
I've been meaning to get into the development (source wise) of LyX for a
long time, and maybe now is the time.
As compilation takes quite a while, I need a fast machine for this. This
reduces my options to a laptop with
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak> not sure I can do that on untranslatable layouts.
This
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Yes, that's what I meant. The problem is that I don't know
Abdelrazak> what's there to translate. In a koma-script or article
Abdelrazak> layout, here is what
layout-> labelstring() gives insid
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Yes, that's what I meant. The problem is that I don't know
Abdelrazak> what's there to translate. In a koma-script or article
Abdelrazak> layout, here is what
layout-> labelstring() gives inside 'expandLabel()':
Abdel
[EMAIL PROTECTED] wrote:
I've been meaning to get into the development (source wise) of LyX for a
long time, and maybe now is the time.
As compilation takes quite a while, I need a fast machine for this. This
reduces my options to a laptop with Windows. I see a few options:
* Make the machin
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak> not sure I can do that on untranslatable layouts.
This is a problem with multip
Georg Baum wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
I seem to remember from previous discussions that user-defined layout
command are not allowed any more.
Wrong. That would mean that nobody could create custom layouts in
~/.lib/layouts. There is no reason to forbid that.
Now I see
Enrico Forestieri wrote:
> On Thu, Jan 11, 2007 at 08:19:05PM +0100, Georg Baum wrote:
>
>> Many parts of the LyX code depend on the fact that we use internal paths
>> only. Therefore we should fix the external inset to not call
>> external_path when building the to_file name. It would be nice if
I've been meaning to get into the development (source wise) of LyX for a
long time, and maybe now is the time.
As compilation takes quite a while, I need a fast machine for this. This
reduces my options to a laptop with Windows. I see a few options:
* Make the machine dual boot and install Li
Georg Baum wrote:
> Abdelrazak Younes wrote:
>> I seem to remember from previous discussions that user-defined layout
>> command are not allowed any more.
>
> Wrong. That would mean that nobody could create custom layouts in
> ~/.lib/layouts. There is no reason to forbid that.
Now I see that I o
Abdelrazak Younes wrote:
> My idea would be to cache the translated text instead of translating
> each time updateLabels() is called. But I am not sure I can do that on
> untranslatable layouts.
They are not different than the translatable ones. The only problem I can
imagine is that the cache co
Hello,
I finally know what is causing the slowness in updateLabel() on Windows!
The culprit is the translation done in Buffer::translateLabel():
docstring const Buffer::translateLabel(docstring const & label) const
{
if (support::isAscii(label))
// Probably standard layo
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Your solution may be wrong because C-< should not work without
Bo> buffer, but 'bookmark-goto 1/2/3' etc should work without buffer.
Are you sure that C-< should not work without buffer? Why?
JMarc
Dov Feldstern wrote:
Abdelrazak Younes wrote:
This is not only about the bidi algorithm but also about unicode.
Right now, everything about RTL is based on the assumption that
encodings matters for the display. It does not.
I don't understand what you mean --- can you be more specific? What
Abdelrazak Younes wrote:
This is not only about the bidi algorithm but also about unicode. Right
now, everything about RTL is based on the assumption that encodings
matters for the display. It does not.
I don't understand what you mean --- can you be more specific? What in
RTL is based on th
Jean-Marc Lasgouttes wrote:
"younes" == younes <[EMAIL PROTECTED]> writes:
younes> URL: http://www.lyx.org/trac/changeset/16652
younes> Log: tiny optimisation.
younes> + InsetBase * nextinset = nextInset();
This could even be const.
Actually no, because of asInsetMath().
Abdel.
Guy Rutenberg wrote:
Hi,
Dov mentioned that LyX bidi algorithm did a good job at previous versions,
and I agree with it. If Lyx bidi algroithm is indeed spread all over the
place, I think we will be better off disabling Qt bidi algorithm (if it's
possible). I think it won't require much additiona
Jean-Marc Lasgouttes wrote:
"younes" == younes <[EMAIL PROTECTED]> writes:
younes> URL: http://www.lyx.org/trac/changeset/16652
younes> Log: tiny optimisation.
younes> + InsetBase * nextinset = nextInset();
This could even be const.
Indeed. I'll do the change.
Thanks,
Abdel.
Jean-Marc Lasgouttes wrote:
"younes" == younes <[EMAIL PROTECTED]> writes:
younes> + // Optimisation: setLabel() can be called for each for each
younes> + // paragraph of the document. So we make the string static
younes> to + // avoid the repeated instanciation. + static docstring
younes> ite
Hi,
Dov mentioned that LyX bidi algorithm did a good job at previous versions,
and I agree with it. If Lyx bidi algroithm is indeed spread all over the
place, I think we will be better off disabling Qt bidi algorithm (if it's
possible). I think it won't require much additional code as disabling th
> "younes" == younes <[EMAIL PROTECTED]> writes:
younes> URL: http://www.lyx.org/trac/changeset/16652
younes> Log: tiny optimisation.
younes> + InsetBase * nextinset = nextInset();
This could even be const.
MJarc
> "younes" == younes <[EMAIL PROTECTED]> writes:
younes> + // Optimisation: setLabel() can be called for each for each
younes> + // paragraph of the document. So we make the string static
younes> to + // avoid the repeated instanciation. + static docstring
younes> itemlabel;
Do you have num
Uwe Stöhr wrote:
> I just installed 1.50-svn-small-3-03 from Berlios; when I run lyx.bat
> under XP Pro sp2 the system tries to start lyx with the line
>
> start "LyX" "C:\ProgramFiles\LyX15\bin\lyx.exe"
>
> and reports "The system cannot execute the specified program".
Another user has th
Michael Gerz wrote:
Abdel,
be careful with these micro-optimization. Eventually, you will shoot
yourself in the foot!
Don't worry, I am proceeding with caution.
Are you sure that these optimization are really that beneficial?
Yes.
@@ -277,29 +277,32 @@
docstring Counters::labelItem
Bo Peng wrote:
I think I am no lyx-close expert, but in principle your point is correct.
Only, please make sure that it works in practice ;-)
I know, but I am not familiar with the quit logic, and there are so
many ways to quit lyx, plus some mac specialties ...
Yes. This is very hairy stuff,
Uwe Stöhr wrote:
> Using dvips shouldn't cause troubles where have you read this?
comp.text.tex or de.comp.text.tex. I can't find it now.
> dvips is
> for example also the default driver of hyperref and therefore also used
> when producing DVI and PDF files. But dvipdfm takes the ready DVI-fil
69 matches
Mail list logo
