Re: LyX script
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 possible
locations we can anticipate are to be found specified either in the
preferences file (located in one of a number of possible LyX User
directories) or in LyX.app/Contents/Resources/lyxrc.dist.
So: I'd like to have a line in which I provide an ordered list of
possible lyx user directories (LyX-1.5, LyX-1.4, LyX, ...), and then
have the script go through these in order looking to see if a
preferences file exists in that location. If it does, it should scan
for whether \serverpipe is specified and extract the file location; if
not, it should move on to the next possible location. If it can't find
a location in any of these preferences files, it should read the
location from lyxrc.dist.
(Or, better yet, if there's a way of determining which preference file
is the one the currently running version of LyX uses )
That would indeed be better. Does something like this give you the info
you're looking for:
$ /c/Program\ Files/LyX14/bin/lyx.exe --version 2>&1 | sed -n '1{p;q;}'
LyX 1.4.2svn of Tue, Apr 11, 2006
Actually, I'd suggest that you get a friendly developer to augment the
output of "lyx --version" to output this bit of the output of "lyx -dbg init":
binary_dir c:/Program Files/LyX14/bin/
system_support c:/Program Files/LyX14/Resources/
build_support
user_support C:/Documents and Settings/Angus/Application
Data/LyX1.4.x/
locale_dir c:/Program Files/LyX14/Resources/locale/
document_dir C:/Documents and Settings/Angus/My Documents
temp_dir C:/Documents and Settings/Angus/Local Settings/Temp/
home_dir C:/Documents and Settings/Angus
Anyway, putting both the above suggestions to one side for now and
concentrating on your "multiple lyx user directories" idea...
Once .lyxpipe.in is found, the script should direct LyX to go to the
appropriate line number ($2) of the relevant file ($1).
Let's see if we can find the preferences file and parse it first ;-)
(I've copied the current state of the script below.)
The mix of perl and sed is a little inelegant, no? :-P
Bennett
---
#!/bin/sh
# [EMAIL PROTECTED], 11 Dec 2003
# With modifications by Bennett Helm, 12 Jan 2007
lyxpipe=/Users/$USER/Library/Application\ Support/LyX/.lyxpipe
So, just to be clear, the potential locations of the system-wide LyX
directory are:
APP_SUPPORT="/Users/$USER/Library/Application\ Support"
for LYXDIR in LyX-1.5 LyX-1.4 LyX
do
ABS_LYXDIR="${APP_SUPPORT}/${LYXDIR}"
test -d "${ABS_LYXDIR} || continue
echo "I've found a LyX directory at ${ABS_LYXDIR}"
done
? Or is it only the USER directory that might have multiple locations?
if [ ! -p "$lyxpipe".in ]
then
# "test -a" is a K and Bash shell-ism.
# You should probably use "test -r" --- file exists and
# is readable.
if [ -a ~/Library/Application\ Support/LyX/preferences ]
then
USER_SUPPORT="${HOME}/Library/Application Support"
test -d "${USER_SUPPORT}" || {
echo "Something horrible is going on. No user support directory
${USER_SUPPORT}" >&2
exit 1
}
for LYXDIR in LyX-1.5 LyX-1.4 LyX
do
ABS_USER_LYXDIR="${USER_SUPPORT}/${LYXDIR}"
test -d "${ABS_USER_LYXDIR}" || continue
USER_PREFERENCES="${ABS_USER_LYXDIR}/preferences"
test -r "${USER_PREFERENCES}" || continue
# preferences file exists.
# See if it contains a \\serverpipe entry
LYXPIPE=`sed -n '/^ *\\serverpipe /{
# First consider that the file path may be quoted
s/^ *\\serverpipe \{1,\}\"\([^"]\{1,\}\)\" *$/\1/
tfound
# Now, unquoted
s/^ *\\serverpipe \{1,\}\(.*\)/\1/
:found
p
q
}' "${PREFERENCES}"
echo "lyxpipe is ${LYXPIPE}"
done
lyxpipe=`perl -n -e 'print,exit if s/^.serverpipe\\s+\"(.
+)\"/$1/;' ~/Library/Application\ Support/LyX/preferences`
else
# What is this line doing?
lyxprefs=`expr "$0" : '\(.*\)MacOS/lyxeditor'`Resources/
lyxrc.dist
Ok, this (the line below) is performing the same parsing task as above but
on the $lyxprefs file. We can move the parser into a sh function to make
the code both more
readable and robust. First, however, I need to understand the "expr" line
above.
lyxpipe=`perl -n -e 'print,exit if s/^.serverpipe\\s+\"(.
+)\"/$1/;' $lyxprefs`
lyxpipe=/Users/$USER`echo "$lyxpipe" | sed 's|^~||'`
Try
lyxpipe=`echo "${lyxpipe} | sed 's|^~|'"${HOME}"'|'`
fi
fi
[ -p "$lyxpipe".in ] || exit 0
file=`echo "$1" | sed 's|^/privat
Re: Result of: Python help needed for configure.py - MiKTeX-problem
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 generate a result file. It would be slower and cleaner to test each package one by one in python, but I was not able to decipher the latex code. Bo
[patch] Re: one bug for the Qt/dialog people
> 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
Re: can't start 1.5svn under windows
>> 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.CRT.manifest" in SVN's \development\Win32\packaging folder and our Scons script don't seem to process it. Bo, do you know what this is for? >> Many users replied me that it works fine on Win2000, WinXP and I >> verified that it runs without problems on various WinXP computers and >> also under WinXP x64. > Service pack 2 has changed the memory model of XP so that might be the > reason. I tested my builds now also on two Win XP with SP2 machines and it works there so this can't be the problem. > Philip, if you want to try it out I can send you a binary privately. Philip, please report me if this build fixes the problem. >> I spend hours to find the problem, perhaps it's a Qt4 bug, because my >> builds for LyX 1.4.3 (that uses Qt3) compiled on the same system works >> fine for the user who reported the same bug as you. MSVC or mingw build? This is important as mingw doesn't care about manifest. Also a MSVC build - Joosts LyX 1.4.3-5 build, but I don't kinow what he used CMake or Scons. regards Uwe
Result of: Python help needed for configure.py - MiKTeX-problem
+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 to install it as it isn't
currently installed. As no internet connection is available this is of
course unsuccessful. But now comes the problem: configure.py doesn't
continue but jumps to the section where the list files are created - the
created are buggy because the inspection of LaTeX was incomplete.
I investigated a lot now: The reason for this is this routine in configure.py:
# we have chklayouts.tex, then process it
fout = os.popen(LATEX + ' wrap_chkconfig.ltx')
while True:
line = fout.readline()
if not line:
break;
if re.match('^\+', line):
print line,
fout.close()
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) :
\IfFileExists{\file}
{}
{\IfFileExists{\file.#4}{}{\existsfalse}}
When MiKTeX's option "Install Missing Packages on the fly" is set as "Yes" but no Internet connection is open when \ifFileExists is invoked, the
latex-script is closed by MiKTeX and you get in the console:
==
latex: No Data
I wrote an email to the MiKTeX-developer but I don't have hope that this could
easily be fixed :-(.
regards Uwe
Re: LyX script
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 that you might consider is to link ~/Library/ Application Support/lyx to the users current home directory. Then changing versions is just a matter of linking the current version to that directory. Bennett, if you define in words just what you want, I can whip up the script for you. Angus - I thought I did! But let me try to be clearer The object is first to find where .lyxpipe.in is located. The possible locations we can anticipate are to be found specified either in the preferences file (located in one of a number of possible LyX User directories) or in LyX.app/Contents/Resources/lyxrc.dist. So: I'd like to have a line in which I provide an ordered list of possible lyx user directories (LyX-1.5, LyX-1.4, LyX, ...), and then have the script go through these in order looking to see if a preferences file exists in that location. If it does, it should scan for whether \serverpipe is specified and extract the file location; if not, it should move on to the next possible location. If it can't find a location in any of these preferences files, it should read the location from lyxrc.dist. (Or, better yet, if there's a way of determining which preference file is the one the currently running version of LyX uses ) Once .lyxpipe.in is found, the script should direct LyX to go to the appropriate line number ($2) of the relevant file ($1). (I've copied the current state of the script below.) Bennett --- #!/bin/sh # [EMAIL PROTECTED], 11 Dec 2003 # With modifications by Bennett Helm, 12 Jan 2007 lyxpipe=/Users/$USER/Library/Application\ Support/LyX/.lyxpipe if [ ! -p "$lyxpipe".in ] then if [ -a ~/Library/Application\ Support/LyX/preferences ] then lyxpipe=`perl -n -e 'print,exit if s/^.serverpipe\\s+\"(. +)\"/$1/;' ~/Library/Application\ Support/LyX/preferences` else lyxprefs=`expr "$0" : '\(.*\)MacOS/lyxeditor'`Resources/ lyxrc.dist lyxpipe=`perl -n -e 'print,exit if s/^.serverpipe\\s+\"(. +)\"/$1/;' $lyxprefs` lyxpipe=/Users/$USER`echo "$lyxpipe" | sed 's|^~||'` fi fi [ -p "$lyxpipe".in ] || exit 0 file=`echo "$1" | sed 's|^/private||'` echo LYXCMD:macdvix:server-goto-file-row:"$file" $2 > "$lyxpipe".in || exit read < "$lyxpipe".out || exit
Re: [PATCH] caching translated string
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's really a _huge_ performance boost under Windows! Doesn't your cache need to take account of the language? That's what gettext is doing internally... Ie, the key shouldn't be just a string but rather pair. Angus
Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h
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.
Re: [PATCH] caching translated string
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.
Index: messages.C
===
--- messages.C (revision 16645)
+++ messages.C (working copy)
@@ -21,7 +21,10 @@
#include
#include
+#include
+using std::endl;
+using std::string;
namespace lyx {
@@ -29,10 +32,7 @@
using support::getEnv;
using support::setEnv;
-using std::string;
-using std::endl;
-
static boost::regex const reg("^([^\\[]*)\\[\\[[^\\]]*\\]\\]$");
@@ -114,11 +114,17 @@
~Pimpl() {}
- docstring const get(string const & m) const
+ docstring const & get(string const & m) const
{
+ static docstring empty_string;
if (m.empty())
- return from_ascii(m);
+ return empty_string;
+ CacheType::iterator it = cache_.find(m);
+ if (it != cache_.end()) {
+ lyxerr << "Cached translation " << to_utf8(it->second)
<< endl;
+ return it->second;
+ }
// In this order, see support/filetools.C:
string lang = getEnv("LC_ALL");
if (lang.empty()) {
@@ -206,11 +212,16 @@
setlocale(LC_MESSAGES, lang.c_str());
#endif
setlocale(LC_CTYPE, oldCTYPE.c_str());
- return translated;
+
+ lyxerr << "New translation " << to_utf8(translated) << endl;
+ it = cache_.insert(std::make_pair(m, translated)).first;
+ return it->second;
}
private:
///
string lang_;
+ typedef std::map CacheType;
+ mutable CacheType cache_;
};
#endif
@@ -250,7 +261,7 @@
{}
-docstring const Messages::get(string const & msg) const
+docstring const & Messages::get(string const & msg) const
{
return pimpl_->get(msg);
}
Index: messages.h
===
--- messages.h (revision 16645)
+++ messages.h (working copy)
@@ -29,7 +29,7 @@
///
~Messages();
///
- docstring const get(std::string const & msg) const;
+ docstring const & get(std::string const & msg) const;
private:
class Pimpl;
boost::scoped_ptr pimpl_;
[PATCH] caching translated string
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)
@@ -21,7 +21,10 @@
#include
#include
+#include
+using std::endl;
+using std::string;
namespace lyx {
@@ -29,10 +32,7 @@
using support::getEnv;
using support::setEnv;
-using std::string;
-using std::endl;
-
static boost::regex const reg("^([^\\[]*)\\[\\[[^\\]]*\\]\\]$");
@@ -114,11 +114,16 @@
~Pimpl() {}
- docstring const get(string const & m) const
+ docstring const & get(string const & m) const
{
+ static docstring empty_string;
if (m.empty())
- return from_ascii(m);
+ return empty_string;
+ CacheType::iterator it = cache_.find(m);
+ if (it != cache_.end())
+ return it->second;
+
// In this order, see support/filetools.C:
string lang = getEnv("LC_ALL");
if (lang.empty()) {
@@ -206,11 +211,15 @@
setlocale(LC_MESSAGES, lang.c_str());
#endif
setlocale(LC_CTYPE, oldCTYPE.c_str());
- return translated;
+
+ it = cache_.insert(std::make_pair(m, translated)).first;
+ return it->second;
}
private:
///
string lang_;
+ typedef std::map CacheType;
+ mutable CacheType cache_;
};
#endif
@@ -250,7 +259,7 @@
{}
-docstring const Messages::get(string const & msg) const
+docstring const & Messages::get(string const & msg) const
{
return pimpl_->get(msg);
}
Index: messages.h
===
--- messages.h (revision 16645)
+++ messages.h (working copy)
@@ -29,7 +29,7 @@
///
~Messages();
///
- docstring const get(std::string const & msg) const;
+ docstring const & get(std::string const & msg) const;
private:
class Pimpl;
boost::scoped_ptr pimpl_;
Re: What is needed to develop LyX 1.5 on Windows machine?
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 installed and in use, then *don't* dual boot the machine. You've been warned ;-) "Fortunately" I don't have Norton Ghost... nor the patience to mirror the laptop's 100GB drive to my slow USB drive. So I'll probably repartition the drive anyway, then I can boot with Knoppix and do a 'dd' on the drive. That's good thing to have either way :-) If I do have to re-install the machine, it'll just be one more re-installation of that machine. It's basically only given my trouble since I got it this September... I'll spare you the details and say that I'll never take the risk of buying another computer from "Rock Direct" in the UK. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: LyX script
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/ > Application Support/lyx to the users current home directory. Then > changing versions is just a matter of linking the current version to > that directory. Bennett, if you define in words just what you want, I can whip up the script for you. Regards, Angus
Re: [patch] move OS dependent code to proper place
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 > trying to understand how it behaves now a long time ago, and I don't care > anymore about it. The only thing I care about is that the result of an > external_path call is only used for interfacing to other programs or > display purposes (although we have makeDisplayPath for the latter that > should take care of any needed transformations), and never for further use > inside of LyX. What a Friday! -- Enrico
Re: [patch] move OS dependent code to proper place
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 windows style > > paths. > > Making a binary created from patched sources available is very bad IMO. > Either this patch is for your personal convenience, then you should not > make the binary available, or it is useful in general, then the patch > should be included in the official version. > > I don't know if the README in the package talks about the patch and where to > get it, but if it does not then you are even breaking the GPL. Oh, it's friday! -- Enrico
Re: What is needed to develop LyX 1.5 on Windows machine?
[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 win bug for scons; >>> and debugging in cmake is easier. >> >> I read INSTALL.Win32 (duh...). So the Windows alternative would then >> use these tools: >> >> * MSVC 2005 >> ** Windows platform SDK >> * Scons (or CMAKE, although INSTALL.Win32 doesn't mention CMAKE) >> * Python >> >> and of course I know that I need: >> * (Tortoise)SVN >> * Emacs >> >> What else would I need? > > Answering to my self... In order to test LyX I'll of course need lots > of other software. Could I just use the installer for e.g. LyX 1.4.3 and > use that to get the other stuff I'd need? No, 1.4 is bases on Qt 3, but there is a package from Joost for 1.5 > > /Christian > Download 'lyx-windows-deps-msvc-qt4.zip' from http://lyx.mirror.fr/index2.php?pwd=%2Fcontrib extract it, e.g to c:\lyx-windows-deps-msvc-qt4 Add the path to qmake: set PATH=c:\lyx-windows-deps-msvc-qt4\qt-4\bin;%PATH% call cmake from a build folder on the same level as trunk: cmake ..\trunk\development\cmake -DWINDEPS=1 That's it, msvc project files are generated which fully support the debugger. Peter
Re: LyX script
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 perl functions to do that, or xcode has stubs for other languages. An alternative that you might consider is to link ~/Library/ Application Support/lyx to the users current home directory. Then changing versions is just a matter of linking the current version to that directory. Cheers, - Ronald
Re: TOC bug on Linux
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. Jürgen
Re: LyX script
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 and a PDF viewer. Thanks, Ronald. I didn't know about PDFView.app, and it works nicely ... once I patch up the lyxeditor script. (PDFView.app works just the same as macdvix or dvix.) Below is the new script, but it's becoming inadequate. The trouble is the way I'm packaging LyX/Mac: I compile it so that the user's directory is ~/Library/Application\ Support/*lyx* (where *lyx* can be "LyX", "LyX-1.4", or "LyX-1.5"), so that LyX-1.3, LyX-1.4, and LyX-1.5 installations can co-exist. This seems like a good strategy to allow users to upgrade and then downgrade without losing any settings, but it is beginning to make things difficult for lyxeditor. What should be done with lyxeditor, I take it, is to search for LyX-1.5/preferences, then LyX-1.4/preferences, then LyX/preferences then LyX.app/Contents/Resources/lyxrc.dist. I take it some sort of loop would be easiest, but I don't know sh well enough to do it (and I don't have time now). But what I've got below should provide a starting point. Can someone help me fill this out? Thanks. Bennett --- #!/bin/sh # [EMAIL PROTECTED], 11 Dec 2003 # With modifications by Bennett Helm, 12 Jan 2007 lyxpipe=/Users/$USER/Library/Application\ Support/LyX/.lyxpipe if [ ! -p "$lyxpipe".in ] then if [ -a ~/Library/Application\ Support/LyX/preferences ] then lyxpipe=`perl -n -e 'print,exit if s/^.serverpipe\\s+\"(. +)\"/$1/;' ~/Library/Application\ Support/LyX/preferences` else lyxprefs=`expr "$0" : '\(.*\)MacOS/lyxeditor'`Resources/ lyxrc.dist lyxpipe=`perl -n -e 'print,exit if s/^.serverpipe\\s+\"(. +)\"/$1/;' $lyxprefs` lyxpipe=/Users/$USER`echo "$lyxpipe" | sed 's|^~||'` fi fi [ -p "$lyxpipe".in ] || exit 0 file=`echo "$1" | sed 's|^/private||'` echo LYXCMD:macdvix:server-goto-file-row:"$file" $2 > "$lyxpipe".in || exit read < "$lyxpipe".out || exit
[patch] Re: one bug for the Qt/dialog people
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 guess. Jürgen Index: src/frontends/qt2/QGraphicsDialog.C === --- src/frontends/qt2/QGraphicsDialog.C (Revision 16624) +++ src/frontends/qt2/QGraphicsDialog.C (Arbeitskopie) @@ -52,10 +52,10 @@ angle->setValidator(new QDoubleValidator(-360, 360, 2, angle)); - lbX->setValidator(new QIntValidator(lbX)); - lbY->setValidator(new QIntValidator(lbY)); - rtX->setValidator(new QIntValidator(rtX)); - rtY->setValidator(new QIntValidator(rtY)); + lbX->setValidator(new QDoubleValidator(lbX)); + lbY->setValidator(new QDoubleValidator(lbY)); + rtX->setValidator(new QDoubleValidator(rtX)); + rtY->setValidator(new QDoubleValidator(rtY)); displayscale->setValidator(new QIntValidator(displayscale)); height->setValidator(unsignedLengthValidator(height));
Re: What is needed to develop LyX 1.5 on Windows machine?
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 anymore >> > because of automake version. > > It is quite tricky to get autoconf/automake work, and no one is using > this method now. > >> > - scons/mingw: This still works AFAIK. > > It works, using just mingw gcc. You can use qt4 from trolltech directly. > >> > - CMake/mingw: This still works AFAIK. > > Never tried. I guess cmake people only use msvc. I've only used the cmake files and gcc under Linux, and there are no problems, but I don't know how it works under Windows. > >> Can I (legally) download MSVC2005 gratis? Does it include a debugger? > > Yes. > > Bo > -- Peter Kümmel
Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h
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 inlining the compiler already has to know that. bernhard
Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h
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/trunk/src/dociterator.h
> URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/dociterator.h?rev=16597
> ==
> --- lyx-devel/trunk/src/dociterator.h (original)
> +++ lyx-devel/trunk/src/dociterator.h Mon Jan 8 11:50:15 2007
> @@ -125,10 +125,14 @@
> ///
> void boundary(bool b) { boundary_ = b; }
>
> - /// are we in mathed?
> - bool inMathed() const;
> - /// are we in texted?
> - bool inTexted() const;
> + /// are we in mathed?.
> + /// inlined out because of profiling results under linux when
> + /// opening a document.
> + inline bool inMathed() const;
> + /// are we in texted?.
> + /// inlined out because of profiling results under linux when
> + /// opening a document.
> + inline bool inTexted() const;
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)
Andre'
Re: What is needed to develop LyX 1.5 on Windows machine?
<[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 machine for this. This > >> reduces my options to a laptop with Windows. I see a few options: > >> > >> * Make the machine dual boot and install Linux > >>(I'd prefer this, but it's a work laptop and I don't want to break it) > > > > I'm in the same situation otherwise I've gone the Linux route. > > 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 installed and in use, then *don't* dual boot the machine. You've been warned ;-) Having learnt that lesson the hard way, I have a dual boot machine at home and can build out LyX on both sides. On Windows, I used mingw and the autotools until Lars deliberately vandalised it (mingw comes with a less modern version of automake than the one we now require). Thereafter, I could continue by using the cygwin version of automake. Having done that for a couple of years, I can say without reservation that develpment of LyX under mingw is a royal PITA. Not least because there's no package management so all software has to be upgraded by hand. Cygwin, by contrast is a joy in this respect. On both, however, gcc crawls. If you're starting from a clean slate, I'd *definitely* recommend that you use msvc which means you have a choice of either scons or cmake. You're package management problems will remain, but the development environment is very user friendly. Regards, Angus Angus
Re: Translation madness! (was Re: Do we support user defined layout?)
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 relying on it and the need to keep it up to date. > Maybe this would simplify the code a bit, dunno. Yes, it would, but it would not make it faster unless we modify it to cache multiple languages. The latter would create even more maintenance problems than we already have (out internal gettext is almost always out of date, and I remember that some updates caused problems on some platforms). > One other thing that may be changed also is the way we load po files. It > seems that there is some caching done inside gettext but it is disabled > as soon as we change the po file. This is explained here: > > http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC152 > > Maybe there's something wrong in the way we load the po files? Just > asking to you knowledgeable people... I have no idea. I think that basicxally Jean-Marc is right that gettext was just not designed for frequent multiple language switching like we do. Georg
Re: [patch] move OS dependent code to proper place
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 available is very bad IMO. Either this patch is for your personal convenience, then you should not make the binary available, or it is useful in general, then the patch should be included in the official version. I don't know if the README in the package talks about the patch and where to get it, but if it does not then you are even breaking the GPL. Georg
Re: [patch] move OS dependent code to proper place
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 care anymore about it. The only thing I care about is that the result of an external_path call is only used for interfacing to other programs or display purposes (although we have makeDisplayPath for the latter that should take care of any needed transformations), and never for further use inside of LyX. Georg
Re: What is needed to develop LyX 1.5 on Windows machine?
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. I read INSTALL.Win32 (duh...). So the Windows alternative would then use these tools: * MSVC 2005 ** Windows platform SDK * Scons (or CMAKE, although INSTALL.Win32 doesn't mention CMAKE) * Python and of course I know that I need: * (Tortoise)SVN * Emacs What else would I need? Answering to my self... In order to test LyX I'll of course need lots of other software. Could I just use the installer for e.g. LyX 1.4.3 and use that to get the other stuff I'd need? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Do we support user defined layout?
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 we just need to reset the cache when this is changed. No, I mean if somebody changes the layout file on disk. I don't know whether we read layout files only on startup, or always if a buffer is loaded, so I don't know whether this is already a problem or not. When I messed with layouts as a user, LyX only read layout files on startup. So that's how the older versions did it and AFAIK this has not changed. However, I really hope LyX will be able to to re-read the layout files in the future so I think it'd be bad to add a constraint. cheers /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Translation madness! (was Re: Do we support user defined layout?)
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 was translated before. To my
knowledge
no library call of gettext exists that takes the language as a function
argument rather than an environment variable.
[...]
Unless you really want to spend a lot of time yo learn all aspects about
gettext I suggest that you leave this alone.
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?
Maybe this would simplify the code a bit, dunno.
One other thing that may be changed also is the way we load po files. It
seems that there is some caching done inside gettext but it is disabled
as soon as we change the po file. This is explained here:
http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC152
Maybe there's something wrong in the way we load the po files? Just
asking to you knowledgeable people...
At this link they say something interesting WRT changing language:
http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC155
I don't see any use of this '_nl_msg_cat_cntr' variable in the code.
Maybe that's a solution. Did you tried that in the past?
10.5 Being a gettext grok
To fully exploit the functionality of the GNU gettext library it is
surely helpful to read the source code. But for those who don't want to
spend that much time in reading the (sometimes complicated) code here is
a list comments:
* Changing the language at runtime
For interactive programs it might be useful to offer a selection
of the used language at runtime. To understand how to do this one need
to know how the used language is determined while executing the gettext
function. The method which is presented here only works correctly with
the GNU implementation of the gettext functions.
In the function dcgettext at every call the current setting of
the highest priority environment variable is determined and used.
Highest priority means here the following list with decreasing priority:
1. LANGUAGE
2. LC_ALL
3. LC_xxx, according to selected locale
4. LANG
Afterwards the path is constructed using the found value and the
translation file is loaded if available.
What is now when the value for, say, LANGUAGE changes. According
to the process explained above the new value of this variable is found
as soon as the dcgettext function is called. But this also means the
(perhaps) different message catalog file is loaded. In other words: the
used language is changed.
But there is one little hook. The code for gcc-2.7.0 and up provides
some optimization. This optimization normally prevents the calling of
the dcgettext function as long as no new catalog is loaded. But if
dcgettext is not called the program also cannot find the LANGUAGE
variable be changed (see section 10.2.7 Optimization of the *gettext
functions). A solution for this is very easy. Include the following code
in the language switching function.
/* Change language. */
setenv ("LANGUAGE", "fr", 1);
/* Make change known. */
{
extern int _nl_msg_cat_cntr;
++_nl_msg_cat_cntr;
}
Abdel.
Re: What is needed to develop LyX 1.5 on Windows machine?
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 alternative would then use these tools: * MSVC 2005 ** Windows platform SDK * Scons (or CMAKE, although INSTALL.Win32 doesn't mention CMAKE) * Python and of course I know that I need: * (Tortoise)SVN * Emacs What else would I need? What's the difference between Scons and CMAKE (which is faster?) /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Translation madness! (was Re: Do we support user defined layout?)
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 my knowledge no library call of gettext exists that takes the language as a function argument rather than an environment variable. [...] Unless you really want to spend a lot of time yo learn all aspects about gettext I suggest that you leave this alone. 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? Maybe this would simplify the code a bit, dunno. One other thing that may be changed also is the way we load po files. It seems that there is some caching done inside gettext but it is disabled as soon as we change the po file. This is explained here: http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC152 Maybe there's something wrong in the way we load the po files? Just asking to you knowledgeable people... Abdel.
Re: [patch] move OS dependent code to proper place
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 call > >> external_path when building the to_file name. It would be nice if you > >> could do that. > > > > I did that, and also arranged to avoid backslashes in internal paths: > > http://www.lyx.org/trac/changeset/16659 > > Thanks, that is exactly what I had in mind (but did not want to do since I > a) could not testb it and b) would not know whether to remove external_path > completely or conditionally). Believe me, external_path could be completely ditched. However, it is now mostly used for display purposes, apart from the last use of it in insetgraphics.C. But I will not touch it, because I like to wait for the next bug report it will cause (big smiley here). Indeed, the ditched external_path was not causing problems in 1.4.x (just checked). -- Enrico
Re: Do we support user defined layout?
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 cache when this is changed. No, I mean if somebody changes the layout file on disk. I don't know whether we read layout files only on startup, or always if a buffer is loaded, so I don't know whether this is already a problem or not. > Problem is that a single Buffer can presents multiple languages as > explained in the other part of the thread. Indeed. Then maybe a cache per layout but with different languages would work. Georg
Re: Translation madness! (was Re: Do we support user defined layout?)
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 library call of gettext exists that takes the language as a function argument rather than an environment variable. > This other chunk of code rings a bell in the context of the hebrew RTL > bug (related to LC_TYPE): > > // CTYPE controls what getmessage thinks what encoding the po file uses > char const * lc_ctype = setlocale(LC_CTYPE, NULL); > string oldCTYPE = lc_ctype ? lc_ctype : ""; But setting LC_TYPE is needed for gettext. > I don't know anything about gettext but this stuff looks awfully > complicated. Couldn't we simplify the thing a bit? I don't think so. This awfully complicated stuff is the result of many bug fixes and a lot of work of several people. It is so complicated because some gettext versions are broken (especially on windows). I once tried to simplify this but only made Michael Gerz angry who suddenly discovered lots of bugs. Unless you really want to spend a lot of time yo learn all aspects about gettext I suggest that you leave this alone. Georg
Re: Do we support user defined layout?
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 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 cache when this is changed. Another idea would be to translate the layout on first loading and use that later on. Then we could continue to support untranslatable layouts. That would be problematic since the translation depends on the buffer language. But if you introduce a cache at buffer level it should work. Problem is that a single Buffer can presents multiple languages as explained in the other part of the thread. I am not sure I got everything right so please explain me. I hope it is clear now. Clearer yes, thanks. Abdel.
Translation madness! (was Re: Do we support user defined layout?)
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 sure I can do that on untranslatable layouts.
This is a problem with multiple languages. I _think_ the problem is
that switching language is expensive with gettext (I am not sure
gettext is designed to change languages very often, like we do).
I think you're right.
If this is the case, then we could cache string/lang pairs.
You mean at gettext.[Ch] level?
Or rather at messages.[Ch] level. As this is set to one unique language
Apparently, this is not true and I don't understand why. The language is
set at construction of the Message class. A language change in the
document will reset the Message object to the new language. Up to that
point I understand.
But, updateLabel() is using Messages::Pimpl::get() and this can change
the language at each call! This is because of this code that checks ans
sets environment variables:
docstring const get(string const & m) const
{
if (m.empty())
return from_ascii(m);
// In this order, see support/filetools.C:
string lang = getEnv("LC_ALL");
if (lang.empty()) {
lang = getEnv("LC_MESSAGES");
if (lang.empty()) {
lang = getEnv("LANG");
if (lang.empty())
lang = "C";
}
}
#ifdef HAVE_LC_MESSAGES
char const * lc_msgs = setlocale(LC_MESSAGES, lang_.c_str());
#endif
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
This other chunk of code rings a bell in the context of the hebrew RTL
bug (related to LC_TYPE):
// CTYPE controls what getmessage thinks what encoding the po file uses
char const * lc_ctype = setlocale(LC_CTYPE, NULL);
string oldCTYPE = lc_ctype ? lc_ctype : "";
I don't know anything about gettext but this stuff looks awfully
complicated. Couldn't we simplify the thing a bit?
Abdel.
Re: can't start 1.5svn under windows
> 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 not require manifest. Bo
Re: Bug 3062 AGAIN! (Re: [PATCH] bug 3062 and getStatus cleanup)
> "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 usable without a valid buffer. That's it. It is the job of isValid to say whether a bookmark is valid. Bo> I am not sure because I never use bookmark 0 and do not know how Bo> to set it. To me, it is a consequence of some internal trick (and Bo> I almost got rid of it). Typically, it would be nice to set bookmark-0 as soon as we use one of the LFUN_GOTO_XXX functions. Think of it as the back button of a web browser. JMarc
Re: Fix bug 3092.
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
Re: What is needed to develop LyX 1.5 on Windows machine?
> - 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 automake version. It is quite tricky to get autoconf/automake work, and no one is using this method now. > - scons/mingw: This still works AFAIK. It works, using just mingw gcc. You can use qt4 from trolltech directly. > - CMake/mingw: This still works AFAIK. Never tried. I guess cmake people only use msvc. Can I (legally) download MSVC2005 gratis? Does it include a debugger? Yes. Bo
Re: What is needed to develop LyX 1.5 on Windows machine?
[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 reduces my options to a laptop with Windows. I see a few options: * Make the machine dual boot and install Linux (I'd prefer this, but it's a work laptop and I don't want to break it) I'm in the same situation otherwise I've gone the Linux route. 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. At your own risk ;-) * Use windows and ??? - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin, Peter and me are using. - msys/mingw with autotools: I think this is not supported anymore because of automake version. - scons/mingw: This still works AFAIK. - CMake/mingw: This still works AFAIK. Can I (legally) download MSVC2005 gratis? yes, search for the Express edition. Does it include a debugger? Yes and a very good one. What compiler do you use in the latter alternatives, gcc? yes. Abdel.
Re: Do we support user defined layout?
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 untranslatable layouts. This is a problem with multiple languages. I _think_ the problem is that switching language is expensive with gettext (I am not sure gettext is designed to change languages very often, like we do). I think you're right. If this is the case, then we could cache string/lang pairs. You mean at gettext.[Ch] level? Or rather at messages.[Ch] level. As this is set to one unique language we don't have to maintain the cache for lang at this level. Abdel.
Re: Bug 3062 AGAIN! (Re: [PATCH] bug 3062 and getStatus cleanup)
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 bookmark 0 and do not know how to set it. To me, it is a consequence of some internal trick (and I almost got rid of it). Cheers, Bo
Re: What is needed to develop LyX 1.5 on Windows machine?
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 Windows. I see a few options: * Make the machine dual boot and install Linux (I'd prefer this, but it's a work laptop and I don't want to break it) I'm in the same situation otherwise I've gone the Linux route. 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. * Use windows and ??? - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin, Peter and me are using. - msys/mingw with autotools: I think this is not supported anymore because of automake version. - scons/mingw: This still works AFAIK. - CMake/mingw: This still works AFAIK. Can I (legally) download MSVC2005 gratis? Does it include a debugger? What compiler do you use in the latter alternatives, gcc? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Do we support user defined layout?
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 is a problem with multiple languages. I _think_ the problem is that switching language is expensive with gettext (I am not sure gettext is designed to change languages very often, like we do). I think you're right. If this is the case, then we could cache string/lang pairs. You mean at gettext.[Ch] level? Yes, that would be a perfect solution that would work all other strings. Good idea. Abdel.
Re: Do we support user defined layout?
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 inside 'expandLabel()':
Abdelrazak> raw fmt: \arabic{chapter}.\arabic{section} raw fmt:
Abdelrazak> @[EMAIL PROTECTED]
Abdelrazak> Am I right here that there is nothing to translate?
No. Look for example at this eu.po snippet:
msgid "Chapter \\arabic{chapter}"
msgstr "\\arabic{chapter}. kapitulua"
Basque does not have the same conventions as we do. These are rare
cases, but they exist.
Oh... shit.
Abdel.
Re: Do we support user defined layout?
> "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()':
Abdelrazak> raw fmt: \arabic{chapter}.\arabic{section} raw fmt:
Abdelrazak> @[EMAIL PROTECTED]
Abdelrazak> Am I right here that there is nothing to translate?
No. Look for example at this eu.po snippet:
msgid "Chapter \\arabic{chapter}"
msgstr "\\arabic{chapter}. kapitulua"
Basque does not have the same conventions as we do. These are rare
cases, but they exist.
JMarc
Re: What is needed to develop LyX 1.5 on Windows machine?
[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 machine dual boot and install Linux (I'd prefer this, but it's a work laptop and I don't want to break it) I'm in the same situation otherwise I've gone the Linux route. * Use windows and cygwin? Enrico is doing that. * Use windows and ??? - MSVC2005 (either Scons or CMake), that's what Bo, Michael, Edwin, Peter and me are using. - msys/mingw with autotools: I think this is not supported anymore because of automake version. - scons/mingw: This still works AFAIK. - CMake/mingw: This still works AFAIK. Abdel. Abdel.
Re: Do we support user defined layout?
> "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 multiple languages. I _think_ the problem is that switching language is expensive with gettext (I am not sure gettext is designed to change languages very often, like we do). If this is the case, then we could cache string/lang pairs. JMarc
Re: Do we support user defined layout?
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 that I overread 'command'. What you mean are style names, but what
is translated here are static labels.
Yes, that's what I meant. The problem is that I don't know what's there
to translate. In a koma-script or article layout, here is what
layout->labelstring() gives inside 'expandLabel()':
raw fmt: \arabic{chapter}.\arabic{section}
raw fmt: @[EMAIL PROTECTED]
Am I right here that there is nothing to translate?
For the 'report' layout' we can have something like this:
raw fmt: Chapter \arabic{chapter}
raw fmt: \arabic{chapter}.\arabic{section}
Here, is it right that the only translatable part is the word "Chapter"?
If yes, wouldn't it be possible to translate that word once and for all
at layout loading? Then we could avoid translateLabel() altogether.
Abdel.
Re: [patch] move OS dependent code to proper place
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 you >> could do that. > > I did that, and also arranged to avoid backslashes in internal paths: > http://www.lyx.org/trac/changeset/16659 Thanks, that is exactly what I had in mind (but did not want to do since I a) could not testb it and b) would not know whether to remove external_path completely or conditionally). Georg
What is needed to develop LyX 1.5 on Windows machine?
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 Linux (I'd prefer this, but it's a work laptop and I don't want to break it) * Use windows and cygwin? * Use windows and ??? What are my options? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Do we support user defined layout?
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 overread 'command'. What you mean are style names, but what is translated here are static labels. Georg
Re: Do we support user defined layout?
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 could get out of date if somebody changes the layout file. > 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. > How is this layout business related to that translateLabel() method? Can > I just ditch the method and use _() directly? No. _() would assert if a user defined layout contained a label name with non-ascii characters. That was the very reason to introduce Buffer::translateLabel. Besides the slowness is in _(), not the additional ascii test. > Another idea would be to translate the layout on first loading and use > that later on. Then we could continue to support untranslatable layouts. That would be problematic since the translation depends on the buffer language. But if you introduce a cache at buffer level it should work. > I am not sure I got everything right so please explain me. I hope it is clear now. Georg
Do we support user defined layout?
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 layout, try to translate
return B_(to_ascii(label));
else
// This must be a user defined layout. We cannot translate
// this, since gettext accepts only ascii keys.
return label;
}
If I short-cuts this and return label (thus avoiding the gettext
translation), the paragraph breaking is very fast!
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.
I seem to remember from previous discussions that user-defined layout
command are not allowed any more.
So question to Georg, Jose, JMarc or ???:
How is this layout business related to that translateLabel() method? Can
I just ditch the method and use _() directly?
Another idea would be to translate the layout on first loading and use
that later on. Then we could continue to support untranslatable layouts.
I am not sure I got everything right so please explain me.
Abdel.
Re: Bug 3062 AGAIN! (Re: [PATCH] bug 3062 and getStatus cleanup)
> "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
Re: Bidi support in Lyx 1.5 svn
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 in RTL is based on the assumption that the encodings matter? With Unicode, encodings should not matter at the character level. In pre-unicode time, the encoding mattered to understand an 8 bits character. I think that the Bidi algorithm looks at the language (as defined in LyX) rather than the encoding of the letters themselves This is exactly the problem. The Bidi algorithm in LyX will reorder the letters inside a Word depending on the language and encoding settings. It may be OK for Hebrew because the characters set used to fit in a single byte in pre-unicode time. But this is not OK for Arabic and other asian languages AFAIK. Just another thought on this issue: this also has some GUII implications, in the sense that if we decide to use Qt for the Bidi, I said that we should Qt at letter level. We can still use our own Bidi at word level. that means that any other frontend that we may decide to use must also do the right thing with Bidi. This may or may not be a problem, but we need to be aware of this before deciding to adopt this path. Sure but most modern toolkits do bidi just fine. So, to summarize, the problems will not be solved automagically if we manage to disable Qt bidi algorithm. Actually, for Hebrew I think they will. For Arabic, you're right --- the shaping is very encoding dependent, and therefore the move to unicode will affect that a lot. But that's not a Bidi issue, per-se. I'm not sure how entangled these two issues are in the code, however. We should not implement two different algorithms for Hebrew and Arabic IMHO. See above. Abdel.
Re: Bidi support in Lyx 1.5 svn
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 the assumption that the encodings matter? I think that the Bidi algorithm looks at the language (as defined in LyX) rather than the encoding of the letters themselves --- which is the only reason, of course, that it still works. Qt does the right thing at the word level and we should leverage that. Just another thought on this issue: this also has some GUII implications, in the sense that if we decide to use Qt for the Bidi, that means that any other frontend that we may decide to use must also do the right thing with Bidi. This may or may not be a problem, but we need to be aware of this before deciding to adopt this path. So, to summarize, the problems will not be solved automagically if we manage to disable Qt bidi algorithm. Actually, for Hebrew I think they will. For Arabic, you're right --- the shaping is very encoding dependent, and therefore the move to unicode will affect that a lot. But that's not a Bidi issue, per-se. I'm not sure how entangled these two issues are in the code, however. Dov
Re: [Cvslog] r16652 - /lyx-devel/trunk/src/dociterator.C
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.
Re: Bidi support in Lyx 1.5 svn
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 additional code as disabling the Lyx Bidi algorithm. 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. Qt does the right thing at the word level and we should leverage that. So, to summarize, the problems will not be solved automagically if we manage to disable Qt bidi algorithm. There is much more to it. Fortunately, it's more about removing code than developing new code. Abdel: In previous versions of Lyx, did it handle Arabic right, or messed the directions? I guess it did. Never tried it. Abdel.
Re: [Cvslog] r16652 - /lyx-devel/trunk/src/dociterator.C
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.
Re: [Cvslog] r16648 - /lyx-devel/trunk/src/buffer_funcs.C
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> itemlabel; Do you have numbers proving this is useful, or is it "just in case"? I don't have exact numbers but the "feeling" is improving with each of these optimisations. I am talking about the time taken by LyX to break a section in the UserGuide. This is still too slow. Abdel.
Re: Bidi support in Lyx 1.5 svn
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 the Lyx Bidi algorithm. Abdel: In previous versions of Lyx, did it handle Arabic right, or messed the directions? Guy Abdelrazak Younes <[EMAIL PROTECTED]> writes: Dov Feldstern wrote: > Abdel, I know that you agree with Guy on this one, so maybe you guys are > right... And it's true that for Arabic, letting Qt deal with everything > will probably simplify things a lot... However, it sounds like a really > big job to me, and I think that the alternative would work, and would be > much much simpler, even if it is a little backwards. Perhaps we can reuse part of LyX bidi algorithm. I am thinking about keeping the reordering of words but not the reordering of letters. This must be done by Qt because it is the one who knows how to paint them on screen at the end. This won't be a big change because we already pass the strings word by word to the painter. Abdel.
Re: [Cvslog] r16652 - /lyx-devel/trunk/src/dociterator.C
> "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
Re: [Cvslog] r16648 - /lyx-devel/trunk/src/buffer_funcs.C
> "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 numbers proving this is useful, or is it "just in case"? JMarc
Re: can't start 1.5svn under windows
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 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. Many users replied me that it works fine on Win2000, WinXP and I verified that it runs without problems on various WinXP computers and also under WinXP x64. Service pack 2 has changed the memory model of XP so that might be the reason. That said, I run SP2 and have no problem with my CMake build. Philip, if you want to try it out I can send you a binary privately. I spend hours to find the problem, perhaps it's a Qt4 bug, because my builds for LyX 1.4.3 (that uses Qt3) compiled on the same system works fine for the user who reported the same bug as you. MSVC or mingw build? This is important as mingw doesn't care about manifest. Abdel. What we found out while testing is a problem of LyX's configure file but this was not the reason for the problem with starting lyx.exe - we'll try to fix this anyway. Sorry but regards Uwe
Re: [Cvslog] r16658 - /lyx-devel/trunk/src/counters.C
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(docstring const & ctr,
docstring const & numbertype)
{
-if (counterList.find(ctr) == counterList.end()) {
+CounterList::const_iterator const cit = counterList.find(ctr);
+if (cit == counterList.end()) {
lyxerr << "Counter "
<< to_utf8(ctr)
<< " does not exist." << endl;
return docstring();
}
+int val = cit->second.value();
+
if (numbertype == "hebrew")
-return docstring(1, hebrewCounter(value(ctr)));
+return docstring(1, hebrewCounter(val));
I fail to see why
value(ctr)
is the same as
val = cit->second.value()
Yes, that is because Counters::value() is doing the same map search for
nothing:
int Counters::value(docstring const & ctr) const
{
CounterList::const_iterator const cit = counterList.find(ctr);
if (cit == counterList.end()) {
lyxerr << "value: Counter does not exist: "
<< to_utf8(ctr) << endl;
return 0;
}
return cit->second.value();
}
Abdel.
Re: Fix bug 3092.
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, don't underestimate the difficulty. I'll have a look at your patch but at first glance I think you missed the mutiple-view case entirely. Abdel.
Re: [patch] fix bug 2721 now with attached patch
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-file so > it is driver independent. I don't understand. dvips is a converter from dvi to PostScript, dvipdfm is a converter from dvi to PDF. Both start from the dvi file. The point is that geometry inserts dvi specials that might confuse dvipdfm or other post-dvi tools. > All you get is this warning: > > [1 > ** WARNING ** Unparsed material at end of special ignored. > Current input buffer is -->! /landplus90 true store<-- > ] I see. > This can be ignored this has no consequences an tells that the input DVI > file is in landscape. When this message doesn't appear dvipdfm doesn't > recognize the landscape format and produces ugly PDFs. So not using dvips > is makes it more worse than using dvips because using the dvips driver > also fixes the bug when using dvipdfm! I didn't say that your solution does not improve the current situation. It does. However, I don't like hardcoding dvips instead of chosing the appropriate driver if we can do better. > I tested this with with various > larger documents. dvipdfm is not under development since 5 years now and > therefore not recommended to use. But there's dvipdfmx. And some people just prefer dvipdfm over pdflatex (for instance, because it generates smaller files). > So we should also use this when using dvipdfm. To rephrase: the correct solution is not to hardcode a driver, but to use always the correct one. That is, dvips when dvips is used, dvipdfm when dvipdfm is used and pdftex when pdflatex is used. It might turn out that this is not so easy, I didn't have a closer look at the code. Then your solution is probably better than the current solution. Jürgen
