Re: [patch] fix bugs 2234 and 2236
Georg Baum [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes wrote: The 2236 part looks OK. This is in. For 2234, are you sure that \tag* works? I thought so, but obviously it does not work. Actually, is there a need to consider it separately? Yes, otherwise the * will be parsed as argument of \tag. The attached patch fixes also \tag*. Please test. Georg, I was so happy that with your patch I could import my test latex file with ams constructs that I did not noticed that it had no starred version of \tag. Sorry. I tested your revised patch and now it also works with \tag*. Thank you. -- Enrico
Re: [patch] fix bugs 2234 and 2236
Enrico Forestieri [EMAIL PROTECTED] writes: I tested your revised patch and now it also works with \tag*. Just noticed a small problem. It works when importing a latex file, but I am not able to insert \tag* by using the keyboard. I obtain a \tag cell plus the *, but not a \tag* cell. -- Enrico
Uploaded LyX 1.4.0 for Cygwin
I have uploaded a Cygwin package for LyX 1.4.0 to ftp.devel.lyx.org/pub/incoming/ The package is named lyx-1.4.0-cygwin2.tar.gz and I hope it can be moved to ftp.lyx.org/pub/lyx/bin/1.4.0/ and renamed lyx-1.4.0-cygwin.tar.gz Notice that in pub/incoming there also should be an incomplete lyx-1.4.0-cygwin.tar.gz due to a failed previous upload attempt. I was neither able to overwrite the file nor to delete it. -- Enrico
Re: Uploaded LyX 1.4.0 for Cygwin
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico I have uploaded a Cygwin package for LyX 1.4.0 to Enrico ftp.devel.lyx.org/pub/incoming/ Enrico The package is named lyx-1.4.0-cygwin2.tar.gz and I hope it Enrico can be moved to ftp.lyx.org/pub/lyx/bin/1.4.0/ and renamed Enrico lyx-1.4.0-cygwin.tar.gz I did that. Thank you, Jean-Marc. -- Enrico . . .
Mysterious crash with a cygwin build
When trying to preview a beamer document I get a crash with a cygwin build. I attach a bt at the bottom. Am I right that the crash is occurring inside cygwin1.dll? Just ignore the first two false SEGFAULTS, it's a known problem with gdb in cygwin, solved by a couple of cont. I am quite sure it is a cygwin1.dll fault, but want to be really sure before I report the problem to their really picky mailing list ;-) -- Enrico $ gdb src/lyx-qt.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin...(no debugging symbols found) (gdb) run Starting program: /usr/local/src/lyx-1.4.0/build/src/lyx-qt.exe ---Type return to continue, or q return to quit--- Program received signal SIGSEGV, Segmentation fault. 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll (gdb) cont Continuing. New counter already exists: section Locale en_US could not be set beamericonbook.pdf beamericonbook.20.pdf beamericonarticle.pdf beamericonarticle.20.pdf Program received signal SIGSEGV, Segmentation fault. 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll (gdb) bt #0 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll #1 0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll #2 0x0022ca90 in ?? () #3 0x00b02e64 in use_thread_key () #4 0x0022cb88 in ?? () #5 0x10146890 in ?? () #6 0x0022ca90 in ?? () #7 0x610af6b7 in pthread::once () from /usr/bin/cygwin1.dll #8 0x610af6b7 in pthread::once () from /usr/bin/cygwin1.dll #9 0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll #10 0x0050 in ?? () #11 0x in ?? () #12 0x10146b0c in ?? () #13 0x00c57530 in globals_key () #14 0x0022cb24 in ?? () #15 0x0001 in ?? () #16 0x10146890 in ?? () #17 0x10146890 in ?? () #18 0x0022cb24 in ?? () #19 0x0001 in ?? () #20 0x009dd6b0 in check_exception_spec () #21 0x009de467 in __cxa_throw () #22 0x009d5eee in std::__throw_ios_failure () ---Type return to continue, or q return to quit--- #23 0x00a9333d in std::basic_filebufchar, std::char_traitschar ::underflow () #24 0x00af49b9 in std::for_eachstd::istreambuf_iteratorchar, std::char_traitschar , boost::crc_optimal32u, 79764919u, 4294967295u, 4294967295u, true, true () #25 0x009b5557 in lyx::support::sum () #26 0x00412364 in DepTable::insert () #27 0x004184bb in (anonymous namespace)::handleFoundFile () #28 0x00418b7c in LaTeX::deplog () #29 0x00419695 in LaTeX::run () #30 0x0044aedc in Converters::runLaTeX () #31 0x0044c6e3 in Converters::convert () #32 0x004593d3 in Exporter::Export () #33 0x00459f68 in Exporter::Preview () #34 0x0048091b in LyXFunc::dispatch () #35 0x005f31cf in lyx::frontend::QLPopupMenu::fire () #36 0x0066ae7f in lyx::frontend::QLPopupMenu::qt_invoke () #37 0x006b3f6a in QObject::activate_signal () #38 0x006b44fd in QObject::activate_signal () #39 0x007c9904 in QPopupMenu::activated () #40 0x0079a821 in QPopupMenu::actSig () #41 0x0079adb1 in QPopupMenu::mouseReleaseEvent () #42 0x006d3f18 in QWidget::event () ---Type return to continue, or q return to quit---q Quit (gdb) q The program is running. Exit anyway? (y or n) n Not confirmed. (gdb) cont Continuing. Program exited with code 0103000. (gdb) q
Re: Mysterious crash with a cygwin build
Angus Leeming [EMAIL PROTECTED] writes: If memory serves me right, this function is pretty self contained. You should be able to add a main() that just calls it with the offending file. gcc -E the file to create the full source listing and you'll be able to give 'em the code that triggers the fault. Thank you for the tip, Angus. I'll elaborate on that. What is strange is that the crash seems to occur only when trying to preview a beamer document. -- Enrico
Re: Mysterious crash with a cygwin build
Angus Leeming [EMAIL PROTECTED] writes: If memory serves me right, this function is pretty self contained. You should be able to add a main() that just calls it with the offending file. gcc -E the file to create the full source listing and you'll be able to give 'em the code that triggers the fault. I made a self-contained executable from lyxsum.C and tried it on every file in the texmf tree but did not succeed in crashing it. So I added some debugging statements to src/support/lyxsum.C to see what file was triggering the crash and to my suprise it was not a file but a directory... $ src/lyx-qt.exe New counter already exists: section Locale en_US could not be set beamericonbook.pdf beamericonbook.20.pdf beamericonarticle.pdf beamericonarticle.20.pdf Computing crc of /tmp/lyx_tmpdir1456cHRIK5/lyx_tmpbuf0/beamer-crash.tex Computing crc of /c/texmf/tex/latex/beamer/beamer.cls Computing crc of /c/texmf/tex/latex/beamer/beamerbasemodes.sty Computing crc of /c/texmf/tex/latex/beamer/beamerbasedecode.sty Computing crc of /c/texmf/tex/latex/beamer/beamerbaseoptions.sty Computing crc of /c/texmf/tex/latex/graphics/keyval.sty Computing crc of /c/texmf/tex/latex/pgf/basiclayer/pgfcore.sty Computing crc of /c/texmf/tex/latex/graphics/ Abort (core dumped) I tried the same with a mingw build and got that it also tried computing the crc of the same directory, but in this case no crash was occurring. As it seems really strange that the crc of a directory is needed I tought that it is better if I still stick with this mailing list before going to bug the cygwin people ;-) -- Enrico
Re: Mysterious crash with a cygwin build
Enrico Forestieri [EMAIL PROTECTED] writes: I made a self-contained executable from lyxsum.C and tried it on every file in the texmf tree but did not succeed in crashing it. So I added some debugging statements to src/support/lyxsum.C to see what file was triggering the crash and to my suprise it was not a file but a directory... $ src/lyx-qt.exe New counter already exists: section Locale en_US could not be set beamericonbook.pdf beamericonbook.20.pdf beamericonarticle.pdf beamericonarticle.20.pdf Computing crc of /tmp/lyx_tmpdir1456cHRIK5/lyx_tmpbuf0/beamer-crash.tex Computing crc of /c/texmf/tex/latex/beamer/beamer.cls Computing crc of /c/texmf/tex/latex/beamer/beamerbasemodes.sty Computing crc of /c/texmf/tex/latex/beamer/beamerbasedecode.sty Computing crc of /c/texmf/tex/latex/beamer/beamerbaseoptions.sty Computing crc of /c/texmf/tex/latex/graphics/keyval.sty Computing crc of /c/texmf/tex/latex/pgf/basiclayer/pgfcore.sty Computing crc of /c/texmf/tex/latex/graphics/ Abort (core dumped) I tried the same with a mingw build and got that it also tried computing the crc of the same directory, but in this case no crash was occurring. As it seems really strange that the crc of a directory is needed I tought that it is better if I still stick with this mailing list before going to bug the cygwin people I think I found the source of the problem. LyX reads the log file generated by running latex to build a list of files used as dependency. The files are extracted from the log by using a bunch of regular expressions. These regexps sometime fail to correctly extract a file name if it is truncated between lines. For example, the following is an excerpt from the log file /tmp/lyx_tmpdir1456cHRIK5/lyx_tmpbuf0/beamer-crash.log generated by MikTeX and leading to the last files above, just before the crash: ... (C:\texmf\tex\latex\beamer\beamerbaseoptions.sty Package: beamerbaseoptions 2004/11/15 (rcs-revision 1.7) (C:\texmf\tex\latex\graphics\keyval.sty Package: keyval 1999/03/16 v1.13 key=value parser (DPC) [EMAIL PROTECTED]@=\toks14 )) (C:\texmf\tex\latex\pgf\basiclayer\pgfcore.sty (C:\texmf\tex\latex\graphics\ graphicx.sty Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) ... Notice that the line ending in (C:\texmf\tex\latex\graphics\ really ends with a linebreak, such that graphicx.sty is not wrapped but it is on the next line (I checked it editing with vim the file). So, instead of C:\texmf\tex\latex\graphics\graphicx.sty the regexps extract simply C:\texmf\tex\latex\graphics\, upon which the crc computation is tried, leading to a crash in cygwin. I'll try to come up with a patch to the LaTeX::deplog() function in src/LaTeX.C. -- Enrico
Re: Mysterious crash with a cygwin build
Angus Leeming [EMAIL PROTECTED] writes: Enrico Forestieri forenr at ... writes: Computing crc of /c/texmf/tex/latex/graphics/ Abort (core dumped) I tried the same with a mingw build and got that it also tried computing the crc of the same directory, but in this case no crash was occurring. As it seems really strange that the crc of a directory is needed I tought that it is better if I still stick with this mailing list before going to bug the cygwin people General screw up! Now you just have to find out why and how :) Uhm, I think I found why and how, only I am not sure that I will be able to cleanly fix it... -- Enrico
Re: Mysterious crash with a cygwin build
Angus Leeming [EMAIL PROTECTED] writes:
I'll try to come up with a patch to the LaTeX::deplog() function in
src/LaTeX.C.
Way to go!
;-)
Here is the patch. Please test, it works for me. The only drawback which
I can foresee is that a file *may* be passed two times to handleFoundFile()
but I think it is better than before, when a file could be missed.
--
Enrico
--- src/LaTeX.C.orig2006-03-14 05:04:34.0 +0100
+++ src/LaTeX.C 2006-03-16 19:29:24.0 +0100
@@ -688,7 +688,7 @@
// On initial insert we want to do the update at once
// since this file can not be a file generated by
// the latex run.
- if (fs::exists(foundfile))
+ if (fs::exists(foundfile) !fs::is_directory(foundfile))
head.insert(foundfile, true);
return;
@@ -750,20 +750,30 @@
static regex reg5(Writing index file ([^ ]+).*);
ifstream ifs(logfile.c_str());
+ string line1, line2 = ;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by File: xxx only
// So I think we should use some regexps to find files instead.
// (\([^ ]+\) should match the (file variant, note
// that we can have several of these on one line.
- // File: \([^ ]+\) should match the File: file variant
-
- string token;
- getline(ifs, token);
- token = rtrim(token, \r);
- if (token.empty())
+ // File: \([^ ]+\) should match the File: file variant.
+ // As a path name may be split across lines, we use a sliding
+ // window comprising two lines at a time while scanning files.
+
+ line1 = line2;
+ getline(ifs, line2);
+ line2 = rtrim(line2, \r);
+ const int len = line2.length();
+ const char endchar = len ? line2[len - 1] : 0;
+ if (line1.empty()
+ || line2.substr(0,8) == Package:
+ || line2.substr(0,5) == File:
+ || line2.substr(0,9) == Language:
+ || endchar == '\\' || endchar == '/' || endchar == ')')
continue;
+ string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Re: Mysterious crash with a cygwin build
Angus Leeming [EMAIL PROTECTED] writes:
I think that this version is more robust, but I haven't tried it out...
It works ;-)
Angus
at at -750,20 +750,30 at at
static regex reg5(Writing index file ([^ ]+).*);
ifstream ifs(logfile.c_str());
- string line1, line2 = ;
+ string line2;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by File: xxx only
// So I think we should use some regexps to find files
instead.
// (\([^ ]+\) should match the (file variant, note
// that we can have several of these on one line.
// File: \([^ ]+\) should match the File: file variant.
// As a path name may be split across lines, we use a sliding
// window comprising two lines at a time while scanning files.
- line1 = line2;
+ string const line1 = line2;
getline(ifs, line2);
+ if (!ifs)
+ break;
+ // Is this rtrim needed? Doesn't getline() do it for you?
Angus, I am a C++ newbie and don't even know if getline() is some sort
of standard function or a LyX support function ...
The rtrim was already there and I didn't dare to get rid of it ;-)
line2 = rtrim(line2, \r);
+ // I believe that the coding style is int const len...
Ok, changed.
const int len = line2.length();
const char endchar = len ? line2[len - 1] : 0;
+ // Isn't line1 empty on the first iteration of this loop?
Yes, it is.
+ // Also, move the line1.empty() test to the place
+ // where you assign line1.
Really not, if I want to avoid an endless loop ;-)
I think that it logically belongs here because these are all checks to
see if we can move further down our sliding window.
if (line1.empty()
|| line2.substr(0,8) == Package:
|| line2.substr(0,5) == File:
|| line2.substr(0,9) == Language:
|| endchar == '\\' || endchar == '/' || endchar == ')')
continue;
string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Attached the revised patch.
--
Enrico
--- src/LaTeX.C.orig2006-03-14 05:04:34.0 +0100
+++ src/LaTeX.C 2006-03-16 21:04:04.0 +0100
@@ -688,7 +688,7 @@
// On initial insert we want to do the update at once
// since this file can not be a file generated by
// the latex run.
- if (fs::exists(foundfile))
+ if (fs::exists(foundfile) !fs::is_directory(foundfile))
head.insert(foundfile, true);
return;
@@ -750,20 +750,34 @@
static regex reg5(Writing index file ([^ ]+).*);
ifstream ifs(logfile.c_str());
+ string line2;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by File: xxx only
// So I think we should use some regexps to find files instead.
// (\([^ ]+\) should match the (file variant, note
// that we can have several of these on one line.
- // File: \([^ ]+\) should match the File: file variant
-
- string token;
- getline(ifs, token);
- token = rtrim(token, \r);
- if (token.empty())
+ // File: \([^ ]+\) should match the File: file variant.
+ // As a path name may be split across lines, we use a sliding
+ // window comprising two lines at a time while scanning files.
+
+ string const line1 = line2;
+ getline(ifs, line2);
+ if (!ifs)
+ break;
+ line2 = rtrim(line2, \r);
+ int const len = line2.length();
+ char const endchar = len ? line2[len - 1] : 0;
+ // Check whether we can slide further down our 2-line window
+ if (line1.empty()
+ || line2.substr(0,5) == File:
+ || line2.substr(0,6) == (Font)
+ || line2.substr(0,8) == Package:
+ || line2.substr(0,9) == Language:
+ || endchar == '\\' || endchar == '/' || endchar == ')')
continue;
+ string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Re: Mysterious crash with a cygwin build
Angus Leeming [EMAIL PROTECTED] writes:
Enrico Forestieri forenr at ... writes:
Angus, I am a C++ newbie
No! Really? Wow! You don't come across as one!
Well, I am quite proficient in C, if that counts something ;-)
and don't even know if getline() is some sort
of standard function
namespace std {
templateclass Elem, class Tr, class Alloc
basic_istreamElem, Tr
getline(basic_istreamElem, Tr istr,
basic_stringElem, Tr, Alloc str);
}
;-)
At the time, I only had a glance at a 1993 edition of the Stroustroup
book (I still have it somewhere), and I think the word template doesn't
even appeared there ;-)
This is arabic as far as I am concerned (but I can guess at it ;-)).
However, my C++ semi-ignorance doesn't stop me from hacking C++ sources.
I only do what I know works for sure...
I am not a programmer but I know quite a slew of languages, even some
assembly. Recently I learned python, that enough for setting up a web
site to support a workshop I organized. I offered the possibility to
submit papers in LyX, using a custom layout, and even got 4 submissions
out of 31 (9 were in word and the remaining in LaTeX).
or a LyX support function ...
+ // Also, move the line1.empty() test to the place
+ // where you assign line1.
Really not, if I want to avoid an endless loop
:)
Attached the revised patch.
Looks good to me. Since it fixes a crash, I'd get JMarc to shove it in the
1.4.x
tree. That means you'll need to enlist the help of someone thorough to test
it :)
Well, it is a so simple patch... Simply catenate two lines before
applying the already devised regexps to account for splitted file names...
Anyway, any volunteers?
--
Enrico
Re: Mysterious crash with a cygwin build
Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
substr(0, x) == foo
we have lstring functions for that
prefixIs(Index:, foo)
Thanks Lars.
Latest patch (using prefixIs) attached.
--
Enrico
--- src/LaTeX.C.orig2006-03-14 05:04:34.0 +0100
+++ src/LaTeX.C 2006-03-16 23:37:34.0 +0100
@@ -688,7 +688,7 @@
// On initial insert we want to do the update at once
// since this file can not be a file generated by
// the latex run.
- if (fs::exists(foundfile))
+ if (fs::exists(foundfile) !fs::is_directory(foundfile))
head.insert(foundfile, true);
return;
@@ -750,20 +750,34 @@
static regex reg5(Writing index file ([^ ]+).*);
ifstream ifs(logfile.c_str());
+ string line2;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by File: xxx only
// So I think we should use some regexps to find files instead.
// (\([^ ]+\) should match the (file variant, note
// that we can have several of these on one line.
- // File: \([^ ]+\) should match the File: file variant
-
- string token;
- getline(ifs, token);
- token = rtrim(token, \r);
- if (token.empty())
+ // File: \([^ ]+\) should match the File: file variant.
+ // As a path name may be split across lines, we use a sliding
+ // window comprising two lines at a time while scanning files.
+
+ string const line1 = line2;
+ getline(ifs, line2);
+ if (!ifs)
+ break;
+ line2 = rtrim(line2, \r);
+ int const len = line2.length();
+ char const endchar = len ? line2[len - 1] : 0;
+ // Check whether we can slide further down our 2-line window
+ if (line1.empty()
+ || prefixIs(line2, File:)
+ || prefixIs(line2, (Font))
+ || prefixIs(line2, Package:)
+ || prefixIs(line2, Language:)
+ || endchar == '\\' || endchar == '/' || endchar == ')')
continue;
+ string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Re: win32 installer for LyX 1.4?
Angus Leeming [EMAIL PROTECTED] writes: In fact, if I think about it, the only manual step in the whole process is the installation of the LyX icons into the lyx.exe executable. If someone takes it upon themselves to integrate that step into the build process then everything else can be merged into a Makefile fairly easily. Angus, it should simply be a matter of windres -i lyxicons.rc -o lyxicons.o where: $ cat lyxicons.rc 1 ICON lyx_32x32.ico 2 ICON lyx_doc_32x32.ico and then including lyxicons.o in the final link step. But windres is a cygwin program... I see that a free resource compiler is available from here: http://www.jorgon.freeserve.co.uk/ but I have not tried it. -- Enrico
Re: Mysterious crash with a cygwin build
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Latest patch (using prefixIs) attached. At least the part that skips directories can go in now. It is the part that avoids the crash. Concerning the rest, I think it matches a bugzilla entry. Could you look for it? You are right. I found http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say that this patch fixes precisely that bug ;-) Jean-Marc, what about the patch attached at bug 2344? http://bugzilla.lyx.org/show_bug.cgi?id=2344 It is really simple and fixes a real bug in cygwin builds. I think that the PATH prefix handling needs to be polished with cygwin. As it is now the Use Cygwin-style paths button has no effect and one should always enter the PATH prefix in posix style format. Then, the Use Cygwin-style paths is a bit misleading, because when it is checked LyX presents you Windows mixed style paths (\ replaced by /) and when not, posix paths (seems to be a reversed logic). Time permitting, I'll try to polish it and submit patches. -- Enrico
Re: Mysterious crash with a cygwin build
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico You are right. I found
Enrico http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say
Enrico that this patch fixes precisely that bug
Probably, yes.
Enrico Jean-Marc, what about the patch attached at bug 2344?
Enrico http://bugzilla.lyx.org/show_bug.cgi?id=2344
Enrico It is really simple and fixes a real bug in cygwin builds.
Yes, it should work with cygwin. We could apply it now, but see below.
Enrico I think that the PATH prefix handling needs to be polished
Enrico with cygwin. As it is now the Use Cygwin-style paths button
Enrico has no effect and one should always enter the PATH prefix in
Enrico posix style format.
Enrico Then, the Use Cygwin-style paths is a bit misleading,
Enrico because when it is checked LyX presents you Windows mixed
Enrico style paths (\ replaced by /) and when not, posix paths (seems
Enrico to be a reversed logic).
It would be nice to understand better this Use Cygwin-style paths
thing. I did not understand it very well when Kayvan introduced it,
and I'd appreciate other views on it.
If we can get rid of this, it may be that the bug above needs a
different solution.
No, it is needed anyway. I'll try to explain why in the following.
The idea of the Use Cygwin-style paths button is indeed nice, because
as a cygwin application LyX should be considered as posix-compliant and
should really be viewed as if it was a unix/linux program.
But Windows users are not familiar with posix paths and would be confused,
perhaps. So, you show them a Windows-like path and they are happy.
As they stand now, things work, but some polishment is needed. For example,
here is the external_path() function in src/support/os_cygwin.C
string external_path(string const p)
{
string dos_path;
// Translate from cygwin path syntax to dos path syntax
if (cygwin_path_fix_ is_absolute_path(p)) {
char dp[PATH_MAX];
cygwin_conv_to_full_win32_path(p.c_str(), dp);
dos_path = !dp ? : dp;
}
else return p;
//No backslashes in LaTeX files
dos_path = subst(dos_path,'\\','/');
lyxerr[Debug::LATEX]
Cygwin path correction [
p ]-[
dos_path ']' endl;
return dos_path;
}
You can see that the returned path is a Windows-like path only if
cygwin_path_fix_ is true and the original is an absolute path. This is
fine and poses no problems. Depending on cygwin_path_fix_, external_path()
may be equivalent to internal_path(), as it is in os_unix.C.
However, being able to generate Windows-style paths using external_path()
is useful if you use native Windows apps, which are posix-unaware.
Also, this poses little problems if you use cygwin apps, as they
(trough cygwin1.dll) indifferently understand both Windows and posix
notations. The only problem which could arise is if the application
tries to be smart and wants to establish if a path is absolute or not.
But to what is set cygwin_path_fix_? In os_cygwin.C you'll find:
void cygwin_path_fix(bool use_cygwin_paths)
{
cygwin_path_fix_ = use_cygwin_paths;
}
where use_cygwin_paths corresponds to the state of the Use Cygwin-style
paths button! Now, for me cygwin-style == posix-style and I see an
inverted logic problem here.
As regards PATH prefix, as the PATH is set using setenv(), a cygwin
function, it always should be in posix format. So, the patch to bug 2344
should be applied in any case.
The polishment to be done in this case would be to let the user enter
a Windows-style PATH list in PATH prefix when Use Cygwin-style paths
is checked (sic!) and convert it to a posix-style PATH list behind the
scenes.
So, I think that what should be done is:
1) Rename the Use Cygwin-style paths button to Use Windows-style paths
2) Add the PATH list conversion above to the PATH prefix handling code,
such that a Windows or posix style PATH list is showed and accepted
depending on the Use Windows-style paths button state.
So, in conclusion, whatever is done, the patch attached to bug 2344 is
needed.
--
Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes:
Dear Enrico,
I have problems with the -mms-bitfields option passed to gcc for cygwin
and Mingw ports. Is it something related to structure in memory
apparently. Do you know if it is still necessary? I would like to remove
that from cygwin.m4 or create a mingw.m4 but I am not really proficient
in m4.
Abdel,
I always had that option automatically inserted but never cared because
it doesn't seem to hurt. For example, I compile Qt without that option
and LyX with it and never noticed a problem.
I remember that once it was documented in the gcc man page on cygwin
but now I don't see it anymore. This is what configure spits out:
checking how to get MSVC-compatible struct packing... -mms-bitfields
so it is something related to MSVC. A wild guess is that it may be needed
because LyX is then linked to several Windows libraries (kernel32, user32...)
but I really don't know, sorry.
This guess is supported by the following excerpt from configure:
cygwin* | mingw* | pw32* )
if test $GCC = yes; then
# Ensure MSVC-compatible struct packing convention.
# Depends on GCC version. gcc2 uses -fnative-struct while
# gcc3 uses -mms-bitfields.
#
[...]
if test x$msnative_struct = x; then
echo $as_me:$LINENO: result: no way 5
echo ${ECHO_T}no way 6
{ echo $as_me:$LINENO: WARNING: produced libraries might be
incompatible with MSVC libs 5
echo $as_me: WARNING: produced libraries might be incompatible with MSVC libs
2;}
else
CXXFLAGS=$CXXFLAGS $msnative_struct
echo $as_me:$LINENO: result: ${msnative_struct} 5
echo ${ECHO_T}${msnative_struct} 6
fi
The keywords there are might be, so someone at a time found some problem.
As regards me, I have built gnuplot and gsview32 without using it and all
went always well.
Next time I will try to get rid of it and tell you. I can't right now,
because building from scratch takes 1.5 hours for me.
--
Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: Next time I will try to get rid of it and tell you. I can't right now, because building from scratch takes 1.5 hours for me. OK, if you confirm that you don't have any problem without the option, I would suggest to just eliminate it in cygwin.m4. It seems that -mms-bitfields is necessary in some circumstances. However, it is a gcc issue, not cygwin. See for example: http://www.mail-archive.com/cygwin@cygwin.com/msg21724.html http://www.mail-archive.com/cygwin@cygwin.com/msg39400.html -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum [EMAIL PROTECTED] writes: That means it is necessary if you want to link against libraries compiled by a MS compiler, and it will hurt if you link against libraries compiled by gcc without this switch. Further investigation shows that this setting was added by Kayvan on 2003-03-12 (see config/ChangeLog). The reference mentioned in the ChangeLog added this option only for mingw, and I think that is correct. In the meantime I recompiled from scratch LyX on cygwin. No problem when linking, no problem in usage (I played only a bit with it). This was with Qt/Win, I'll later test Qt/X11 but I don't think it will make a difference. So, at least with cygwin, I would say that -mms-bitfield is not needed. Moreover, if it is a gcc issue, why should it be needed with mingw? -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: Georg Baum a écrit : Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan: On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote: Kayvan, are you listening? Why did you introduce this option also for cygwin? I think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: Configuration Host type: i686-pc-cygwin Special build flags:compression use-aspell C Compiler: gcc -mno-cygwin C Compiler LyX flags: C Compiler flags: -I/c/MinGW/include -O2 C++ Compiler: g++ -mno-cygwin (3.4.4) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -I/c/MinGW/include -O2 Linker flags: Linker user flags: -L/usr/local/qt-win32/lib -lqt -lkernel32 -luser32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -limm32 -lwinmm -lwsock32 -lwinspool -L/c/MinGW/lib Qt Frontend: Qt version: 3.3.5 Packaging: windows LyX binary dir: C:/Programmi/LyX-1.4.0/bin LyX files dir: C:/Programmi/LyX-1.4.0/Resources Configuration of LyX was successful. Type 'make' to compile the program, and then 'make install' to install it. This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing ;-) -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing I have tried that in the past but did not succeed (compiling from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz [EMAIL PROTECTED] writes: It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. -- Enrico
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Concerning LyX/Mac, we have several reports that make me believe that the whole document gets rebroken/displayed at times. This is very weird. Jean-Marc, LyX 1.4 has serious speed problems not only on the Mac. I tried to use 1.4.0pre4 for working on a big document (~60 pages) with lots of figures and equations, and went back to 1.3.7 in desperation. I see that you consider the userguide as a good speed test. Well, I can tell you that LyX 1.4 is blazingly fast editing the userguide with respect to my document... Things seems better with the official release. We are still far from the usability of 1.3.7, but I think that eventually you will get there ;-) -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum [EMAIL PROTECTED] writes: Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz: Abdelrazak Younes wrote: I was maybe not clear... Please do the change for mingw also. Oh, I thought you were using cygwin. How did you compile qt? It should work if you compile it with -mms-bitfields. It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Sorry to be so pedantic here, but I really want to understand this issue before doing any change. Georg, I compile LyX with mingw as a target using cygwin. Cygwin has a minimal support for mingw as they use it only for compiling their setup.exe installation tool. Indeed, the only supported library is libz. I had to compile every library I needed for building LyX, and it turned out that I only needed Qt, aspell, and libiconv. Nothing more. So, given that those libraries don't use -mms-bitfields, I think it is safe avoiding it. Moreover, if those libraries don't use -mms-bitfields and you enforce it, problems arise (see Abdel case). I think it is easier to add -mms-bitfields to CPPFLAGS (if needed) than hacking some m4 file or editing Makefiles to remove it. Anyway, that's my 2 cents... -- Enrico
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Jean-Marc, LyX 1.4 has serious speed problems not only on the Enrico Mac. I tried to use 1.4.0pre4 for working on a big document Enrico (~60 pages) with lots of figures and equations, and went back Enrico to 1.3.7 in desperation. Is that in particular when adding/deleting paragraphs? No, I experience sluggishness when trying to move around the document. Sometimes I find myself rolling the wheel without seeing any movement at all. This is not related to Windows as I see it on Debian and Solaris, too. If I load the userguide and press the page down key, the window scrolls almost uniformly until the end. But if I load my document and hold down the PgDn key, the scrolling is rather not uniform. At certain points it even stops and I can count from 1 to 5 before it starts scrolling again. In part it is due to the fact that some figures must be rendered, but if I wait until all figures are rendered and repeat the experiment I see no great improvement (this time when it stops scrolling I can count from 1 to 3 before it restarts). The only difference with the userguide is that I have a lot of figures and equations. This doesn't happen in 1.3.7 where scrolling is still not uniform but never stops. It is really irritating when you roll the wheel or click on the arrows on the sidebar and nothing happens for some seconds... I repeat, this is with with my big document (about 60 pages) full of figures and equations, otherwise with other documents it is bearable. I also see that recently it is a little better than with the prelease versions. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz [EMAIL PROTECTED] writes: Enrico Forestieri wrote: Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. Then why not keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes:
Success! I managed to compile everything (qt4) without MSYS. There two
small problem though:
1) I have to use -sysdir option because the generated executable look
for an inexistant directory:
$ ./lyx-qt4
Unable to determine the system directory having searched
d:/msys/home/yns/lyx/trunk/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment variable
LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to ...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
2) I had to hack the source code in order to replace '/tmp' with
'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
Except for that I am happy to report that I cannot see any difference
with the lyx I generated within MSYS. Except that the executable is
smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
int
main ()
{
QApplication a(0,0);
a.unlock();
;
return 0;
}
fails compilation and a multi-threaded Qt would be not recognized
as such. I had to modify that program in the following way:
int
main ()
{
int argc;
char **argv = NULL;
QApplication a(argc,argv);
a.unlock();
;
return 0;
}
for the test to be successful in the case Qt is multi-threaded.
I think that's all. The native LyX I compile using cygwin is fully
functional and until now I have seen no side effects.
--
Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Angus Leeming [EMAIL PROTECTED] writes: Enrico, Using MSYS, I have built the libiconv package suggested by Michael and then gone on to build LyX using --with-included-gettext. configure finds libiconv and the build proceeds happily, but I find that the resulting .exe is unable to change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Angus, I suspect that this is an hardcoded path problem. The configure script sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale and then this directory is hardcoded into the executable. So, if LyX is installed in a different place than the $prefix dir, it will be unable to find the files. I don't know how this can be cleanly solved. I can think of two solutions. The first one is rather dirty: hack the configure script such that LYX_ABS_INSTALLED_LOCALEDIR is set to a PATH_MAX long string and then at installation time overwrite the string in the LyX executable with the proper path (other than dirty, this may also be fragile). The second one is the following. You already have an hardcoded path C:/Aspell, so you could change that to C:/LyXsupport and put there both aspell and locale files. A third possibility is investigating wheter libiconv/gettext support dynamic relocation. A fourth possibility is switching to cygwin and forget all those problems, but I suspect that this is not an option ;-) But, wait a moment... what about hacking configure such that LYX_ABS_INSTALLED_LOCALEDIR is a relative path? Uhm... perhaps that is not possible to do, I mean that perhaps it has to be an absolute path. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Angus Leeming [EMAIL PROTECTED] writes: I seem to remember you stating that this dynamic conversion worked for you using a Cygwin-built LyX. I was trying to find out a little bit more about your setup. Do you use the libiconv and gettext compiled by Cygwin, did you compile your own? Etc, etc... I think you are referring to this post: http://article.gmane.org/gmane.editors.lyx.devel/53929 There I was trying to say that I get exactly your results as shown in http://thread.gmane.org/gmane.editors.lyx.devel/53873 when I use Polish, but I am able to get cyrillic menus instead of garbage when setting a Russian locale. I obtain similar results with a cygwin LyX (using the cygwin provided libiconv) and a native LyX (using my own compiled libiconv). I think that the circular process in building libiconv/gettext has an impact only on their own localization. Indeed, I solved the thing simply compiling with --disable-nls and thus always using english messages. So, the results I obtain with Polish are essentially as correct (wrong?) as yours, but I seem to obtain correct results with Russian. I am sorry I can't be of much help here... -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: Yep I used 'c:/' like syntax. But the --with-extra-prefix never worked for me, with either c:/ or /c/ style. configure just stops telling that it cannot find 'c' directory even though it was there. Unlike MSYS, when using Cygwin the /c thing should be activated by $ mount -f C: /c otherwise you have to use the /cygdrive/c style syntax. You have to issue the mount command only once as it will be stored in a mount table and used again next time. Another problem can arise when a path is autogenerated by configure. There is some code in the configure script that turns 'C:/Programs/LyX' into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your settings), so I had to add the following to the sed command I use for modifying configure: # Set locale and data dir in mixed rather than posix format /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/ otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the executable instead of 'C:/Programs/LyX/Resources/locale', and the net effect would be that setting LANG to some locale doesn't work. Thinking about it, perhaps this is the reason (hardcoded path) why Angus reports that setting LANG seems not working in mingw builds. Wouldn't it make sense to fix it in svn instead of doing manually the change? I am sure they would accept your patch. No, this is only needed when you want to build a native LyX but using the cygwin compiler. This is not supported and I don't ask that it is as I agree that it would make things more complicated than they are now. Anyway, I have my lyxconfig script that appropriately hacks 'configure' as needed, so this is not a problem for me. However, this is the only problem that I spotted. To be honest there was another one, but it was about the recognition of a multi-threaded Qt. For some reason the default test program used in configure: I have heard about this one from Michael Gerz IIRC. I am using Qt4 so oviously I don't have this problem Likely, as when using -mno-cygwin the cygwin compiler really turns into the mingw one. I think that's all. The native LyX I compile using cygwin is fully functional and until now I have seen no side effects. IMHO cygwin is a much better environment than MSYS and we should switch to that if we manage to fix those problems. I disagree, even if I do that ;-) You should have a good knowledge of the way cygwin works and be prepared to surprises. However, I may be wrong on this one. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: What are the preprocessor macros that say we are in cygwin -mnocygwin mode? This is what we have to test for. Please, find below the results obtained with and without -mno-cygwin. Essentially, I think that in the first case the WIN32 thing (in all its variants _WIN32, __WIN32, ...) gets defined, whereas in the second case unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). -- Enrico $ touch nonexistent.C $ g++ -dM -E -mno-cygwin nonexistent.C #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 65535U #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 2 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 4 #define _stdcall __attribute__((__stdcall__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MAX_EXP__ 16384 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ _ #define __STDC_HOSTED__ 1 #define __WIN32 1 #define __LDBL_HAS_INFINITY__ 1 #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __GXX_WEAK__ 1 #define __tune_i686__ 1 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 3 #define _cdecl __attribute__((__cdecl__)) #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define _fastcall __attribute__((__fastcall__)) #define __cplusplus 1 #define __USING_SJLJ_EXCEPTIONS__ 1 #define __DEPRECATED 1 #define __DBL_MAX_EXP__ 1024 #define __WIN32__ 1 #define __GNUG__ 3 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __DBL_MIN__ 2.2250738585072014e-308 #define __FLT_MIN_10_EXP__ (-37) #define __DBL_HAS_QUIET_NAN__ 1 #define __REGISTER_PREFIX__ #define __cdecl __attribute__((__cdecl__)) #define __NO_INLINE__ 1 #define __i386 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) #define _WIN32 1 #define _X86_ 1 #define i386 1 #define __i386__ 1 #define __SIZE_TYPE__ unsigned int #define __FLT_RADIX__ 2 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L #define __MSVCRT__ 1 #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MAX_10_EXP__ 38 #define __LONG_MAX__ 2147483647L #define __FLT_HAS_INFINITY__ 1 #define __stdcall __attribute__((__stdcall__)) #define __EXCEPTIONS 1 #define __LDBL_MANT_DIG__ 64 #define __WCHAR_TYPE__ short unsigned int #define __FLT_DIG__ 6 #define __INT_MAX__ 2147483647 #define WIN32 1 #define __MINGW32__ 1 #define __FLT_MAX_EXP__ 128 #define __DBL_MANT_DIG__ 53 #define __WINT_TYPE__ unsigned int #define __LDBL_MIN_EXP__ (-16381) #define __WCHAR_UNSIGNED__ 1 #define __LDBL_MAX_10_EXP__ 4932 #define __DBL_EPSILON__ 2.2204460492503131e-16 #define __tune_pentiumpro__ 1 #define __fastcall __attribute__((__fastcall__)) #define WINNT 1 #define __FLT_DENORM_MIN__ 1.40129846e-45F #define __FLT_MAX__ 3.40282347e+38F #define __GNUC_MINOR__ 4 #define __DBL_MAX_10_EXP__ 308 #define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L #define __PTRDIFF_TYPE__ int #define __LDBL_MIN_10_EXP__ (-4931) #define __LDBL_DIG__ 18 #define __declspec(x) __attribute__((x)) -- $ g++ -dM -E nonexistent.C #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 65535U #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 2 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 4 #define _stdcall __attribute__((__stdcall__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __unix 1 #define __LDBL_MAX_EXP__ 16384 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ _ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __GXX_WEAK__ 1 #define __tune_i686__ 1 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __unix__ 1 #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 3 #define _cdecl __attribute__((__cdecl__)) #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define _fastcall __attribute__((__fastcall__)) #define __cplusplus 1 #define __USING_SJLJ_EXCEPTIONS__ 1 #define __DEPRECATED 1 #define __DBL_MAX_EXP__ 1024 #define __GNUG__ 3 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __DBL_MIN__ 2.2250738585072014e-308 #define __FLT_MIN_10_EXP__ (-37) #define __DBL_HAS_QUIET_NAN__ 1 #define __REGISTER_PREFIX__ #define __cdecl __attribute__((__cdecl__)) #define __NO_INLINE__ 1 #define __i386 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) #define _X86_ 1
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum [EMAIL PROTECTED] writes: Am Montag, 20. März 2006 16:45 schrieb Enrico Forestieri: Jean-Marc Lasgouttes Jean-Marc.Lasgouttes at ... writes: What are the preprocessor macros that say we are in cygwin -mnocygwin mode? This is what we have to test for. Please, find below the results obtained with and without -mno-cygwin. Essentially, I think that in the first case the WIN32 thing (in all its variants _WIN32, __WIN32, ...) gets defined, whereas in the second case unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). The problem is that we would need to set the USE_WINDOWS_PACKAGING macro in configure. I believe that for now you ned to do that manually with the --with-packaging=windows switch if you use -mnocygwin. Enrico, does that work? If yes, it should probably be documented. Yes, I have to specify --with-packaging=windows, otherwise I would get posix. The packaging test in configure is quite simple. I don't know if it can be changed in the following way (using some sort of pseudo-code): ... case $host in *-apple-darwin*) lyx_use_packaging=macosx ;; *-pc-mingw32*) lyx_use_packaging=windows;; *-pc-cygwin*) lyx_use_packaging=cygwin;; *) lyx_use_packaging=posix;; esac if [ $lyx_use_packaging = cygwin ]; then IF compiler defines WIN32 THEN lyx_use_packaging=windows ELSE lyx_use_packaging=posix ENDIF fi ... -- Enrico
Re: Aspell 0.60.4 does not work with gettext 0.14.5
Michael Gerz [EMAIL PROTECTED] writes: 2. class OStream has a method called printf. Unfortunately, gettext 0.14.5 redefines printf which results in a lot of errors (IIRC printf is replaced by intl_printf). Michael, I solved that problem by the following patch: --- common/config.cpp.orig 2005-06-22 07:32:30.0 +0200 +++ common/config.cpp 2005-12-31 04:20:50.0 +0100 @@ -42,6 +42,7 @@ #include iostream.hpp +#undef printf #define DEFAULT_LANG en_US // NOTE: All filter options are now stored with he f- prefix. However HTH -- Enrico
Re: LyX 1.4.0 on Windows
Angus Leeming [EMAIL PROTECTED] writes: Ok, I've read 'em. I can see that the thing compiles, but my reading of the libiconv/gettext installation notes is that you need a third compilation: * make, make install gettext * make, make install libiconv * make, make install gettext There's a circular dependency which must be resolved to make gettext libiconv-aware (and vice versa). Angus, if you are referring to this excerpt from the libiconv README: ... On systems other than GNU/Linux, the iconv program will be internationalized only if GNU gettext has been built and installed before GNU libiconv. This means that the first time GNU libiconv is installed, we have a circular dependency between the GNU libiconv and GNU gettext packages, which can be resolved by building and installing either - first libiconv, then gettext, then libiconv again, or (on systems supporting shared libraries, excluding AIX) - first gettext, then libiconv, then gettext again. ... my reading of it is that you need the three compilations only if you want an internationalized iconv program, i.e., if you want translated messages from iconv. I personally think that building libiconv with --disable-nls and then LyX with --with-included-gettext is sufficient. But I may be wrong ;-) -- Enrico
Re: LyX 1.4.0 on Windows
Angus Leeming [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes Jean-Marc.Lasgouttes at ... writes: Enrico my reading of it is that you need the three compilations only Enrico if you want an internationalized iconv program, i.e., if you Enrico want translated messages from iconv. I personally think that Enrico building libiconv with --disable-nls and then LyX with Enrico --with-included-gettext is sufficient. But I may be wrong That seems very reasonable indeed. It may seem reasonable, but that's what I did (apart from the --disable-nls bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is the explicit --disable-nls important? Presumably not, since libiconv's configure will work out that it can't see a gettext. Angus, this is what I do: $ cd libiconv-1.10 $ ./configure CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' CFLAGS='-O2' \ CXXFLAGS='-O2' --enable-static --disable-shared --disable-nls \ --prefix=C:/MinGW $ make $ make install and then I configure LyX with --with-included-gettext. Works for me and I don't get garbage. Please double check the other post where I was talking about LYX_ABS_INSTALLED_LOCALEDIR, this one maybe the culprit. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Yes, I have to specify --with-packaging=windows, otherwise I Enrico would get posix. The packaging test in configure is quite Enrico simple. I don't know if it can be changed in the following way Enrico (using some sort of pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. It is good for building a native LyX (not dependent on cygwin) by using cygwin tools only. Jean-Marc, I am not asking to add anything. I thought I was answering a question by Georg. I am fine with the official way of building a native version of LyX. But, as I already have cygwin, I tried and succeeded in building a native LyX with cygwin tools. It can be done, but I do not endorse it because it is much more complicated. I am fine with whatever thing you will do (or not do). -- Enrico
A Cygwin related patch
The attached patch fixes the bug reported here:
http://thread.gmane.org/gmane.editors.lyx.general/29227
In my intention this is the first of a series of patches aimed at polishing
the Cygwin target, which I think is lagging behind. Please, tell me if this
ok with you. I have no problem in maintaining the Cygwin target but my time
is limited so I cannot guarantee a continuous commitment. I will do it time
permitting. There should be no big problems, as I think the Cygwin users
will not be more than those I can count with only one of my hands ;-)
Do you prefer that I file this one on bugzilla?
--
Enrico
Index: src/support/os_unix.C
===
--- src/support/os_unix.C (revision 13450)
+++ src/support/os_unix.C (working copy)
@@ -97,6 +97,12 @@ char path_separator()
void cygwin_path_fix(bool)
{}
+
+bool cygwin_path_fix()
+{
+ return false;
+}
+
} // namespace os
} // namespace support
} // namespace lyx
Index: src/support/os.h
===
--- src/support/os.h(revision 13450)
+++ src/support/os.h(working copy)
@@ -65,6 +65,7 @@ char path_separator();
* under Cygwin.
*/
void cygwin_path_fix(bool use_cygwin_paths);
+bool cygwin_path_fix();
} // namespace os
} // namespace support
Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,13 @@ string const latex_path(string const o
latex_path_extension extension,
latex_path_dots dots)
{
- string path = subst(original_path, \\, /);
+ string path;
+
+ if (suffixIs(original_path, '/') os::cygwin_path_fix())
+ path = os::external_path(original_path) + /;
+ else
+ path = subst(original_path, \\, /);
+
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because is sometimes active (e.g. if
Index: src/support/os_win32.C
===
--- src/support/os_win32.C (revision 13450)
+++ src/support/os_win32.C (working copy)
@@ -265,6 +265,12 @@ void cygwin_path_fix(bool)
{}
+bool cygwin_path_fix()
+{
+ return false;
+}
+
+
namespace {
void bail_out()
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C (revision 13450)
+++ src/support/os_cygwin.C (working copy)
@@ -146,6 +146,12 @@ void cygwin_path_fix(bool use_cygwin_pat
cygwin_path_fix_ = use_cygwin_paths;
}
+
+bool cygwin_path_fix()
+{
+ return cygwin_path_fix_;
+}
+
} // namespace os
} // namespace support
} // namespace lyx
Index: src/support/os_os2.C
===
--- src/support/os_os2.C(revision 13450)
+++ src/support/os_os2.C(working copy)
@@ -212,6 +212,12 @@ char path_separator()
void cygwin_path_fix(bool)
{}
+
+bool cygwin_path_fix()
+{
+ return false;
+}
+
} // namespace os
} // namespace support
} // namespace lyx
Re: A Cygwin related patch
Enrico Forestieri [EMAIL PROTECTED] writes:
The attached patch fixes the bug reported here:
http://thread.gmane.org/gmane.editors.lyx.general/29227
In my intention this is the first of a series of patches aimed at polishing
the Cygwin target, which I think is lagging behind. Please, tell me if this
ok with you. I have no problem in maintaining the Cygwin target but my time
is limited so I cannot guarantee a continuous commitment. I will do it time
permitting. There should be no big problems, as I think the Cygwin users
will not be more than those I can count with only one of my hands
Do you prefer that I file this one on bugzilla?
Here is a perhaps less obtrusive patch.
--
Enrico
Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,16 @@ string const latex_path(string const o
latex_path_extension extension,
latex_path_dots dots)
{
- string path = subst(original_path, \\, /);
+ string path;
+
+ if (suffixIs(original_path, '/')) {
+ // The call to os::external_path is needed for Cygwin.
+ path = subst(os::external_path(original_path), \\, /);
+ if (!suffixIs(path, '/'))
+ path += /;
+ } else
+ path = subst(original_path, \\, /);
+
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because is sometimes active (e.g. if
Re: A Cygwin related patch
Martin Vermeer [EMAIL PROTECTED] writes: On Wed, Mar 22, 2006 at 09:29:35PM +, Enrico Forestieri wrote: The attached patch fixes the bug reported here: http://thread.gmane.org/gmane.editors.lyx.general/29227 In my intention this is the first of a series of patches aimed at polishing the Cygwin target, which I think is lagging behind. Please, tell me if this ok with you. I have no problem in maintaining the Cygwin target but my time is limited so I cannot guarantee a continuous commitment. I will do it time permitting. There should be no big problems, as I think the Cygwin users will not be more than those I can count with only one of my hands You would be amazed by the true number of LyX/Windows users... I have no doubt, but somehow I have the idea that LyX/Cygwin users are a niche. However, I maybe wrong. Unfortunately I am unable / cannot be bothered to work on that, but I am really happy somebody does. LyX adoption benefits greatly by having the option of cross-platform collaborative authoring. And some people are stuck on Windows. BTW some of us are hit by symptoms like compulsive hand washing after touching Windows. Another reason for admiring you I am not any different... I can bear Windows only because of cygwin. With it, my working environment is not any different from some *nix flavor ;-) -- Enrico
Re: A Cygwin related patch
Georg Baum [EMAIL PROTECTED] writes: Enrico Forestieri wrote: The attached patch fixes the bug reported here: http://thread.gmane.org/gmane.editors.lyx.general/29227 In my intention this is the first of a series of patches aimed at polishing the Cygwin target, which I think is lagging behind. Please, tell me if this ok with you. I have no problem in maintaining the Cygwin target but my time is limited so I cannot guarantee a continuous commitment. I will do it time permitting. There should be no big problems, as I think the Cygwin users will not be more than those I can count with only one of my hands This patch looks good. I don't like the other one, because the code in filetools.C is more complicated, and in this one it is more clear because of cygwin_path_fix(). Really? I had thought the second one was more cleaner. Actually I had to figure out that when latex_path() is called for generating the argument of [EMAIL PROTECTED] it is assumed that a trailing / is present, and the second patch makes this clear not only for cygwin. On the other hand, external_path() is almost a no-op for the other OSes, so I don't it is such an overhead. So, what shall I use? Do you prefer that I file this one on bugzilla? I think it is there already: http://bugzilla.lyx.org/show_bug.cgi?id=2409 Or do you fix something else? Funny, it was not there when I started working on the bug ;-) -- Enrico
Re: A Cygwin related patch
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Really? I had thought the second one was more cleaner. Enrico Actually I had to figure out that when latex_path() is called Enrico for generating the argument of \input at path it is assumed that Enrico a trailing / is present, and the second patch makes this clear Enrico not only for cygwin. Why shall we assume that? I do not really understand this explicit check for a trailing slash. I think it should be elsewhere. I saw that the [EMAIL PROTECTED] argument always has a double / appended. In my eyes this was not wrong because I remember that in kpathsea a double / signals to also search for subdirectories. Your post rang an alarm bell for me and I checked the [EMAIL PROTECTED] syntax and indeed it is not the same as for kpathsea. A single / should be appended to the path, but it seems that two do not hurt. Now, as a / was later added to the path, in my mind a / should have already been in the path. And indeed this is the case: whenever latex_path() is called to generate the argument of [EMAIL PROTECTED] the path which is passed always has a / appended. As I think that one should not fix what is not broken, in my patch I used that to distinguish when latex_path should generate the argument of [EMAIL PROTECTED] such that to act on this case only. Not only, as in cygwin external_path() can remove the trailing slash, I also paid attention to readd it... So I now know that the trailing slash is not there on purpose. However, it is a good flag for signaling latex_path() that a path for [EMAIL PROTECTED] is to be generated. Now I think I have two choices: 1) Find in the sources where latex_path() is called for [EMAIL PROTECTED], in order to enforce the trailing slash as a flag for this case, and then modify the patch such as to later remove it in latex_path(). 2) Check if the path passed to latex_path() is a directory. If it is, assume that this is the [EMAIL PROTECTED] case and act accordingly. What do you think is the better choice? -- Enrico
Re: A Cygwin related patch
Georg Baum [EMAIL PROTECTED] writes: Enrico Forestieri wrote: Really? I had thought the second one was more cleaner. Actually I had to figure out that when latex_path() is called for generating the argument of \input at path it is assumed that a trailing / is present, and the second patch makes this clear not only for cygwin. \input at path must always be an absolute path (otherwise it would not work TeX-wise), but why should that matter in LyX? Trailing, not heading /. But it seems I was misunderstanding the code. See my other post. On the other hand, external_path() is almost a no-op for the other OSes, so I don't it is such an overhead. So, what shall I use? The overhead does not matter at all here. We have had a lot of path problems on the different windows flavors. Angus worked hard to resolve these, and implemented the external/internal path distiction. If we want to avoid more problems we must keep this distinction and be always explicit whether a path is external or intrnal. In the long run we should not juggle with paths as strings, but always use a path class with external() and internal() methods. This will make the distinction more clear. Ok I am not really sure how things work on cygwin. Can we always assume that all external paths are either windows or posix style? Or do we need posix paths in some cases and windows paths in others? The latter. On cygwin, depending on a checkbox status, external_path() generates posix or windows style paths. This is because if you use MikTeX you need win-style paths. The configure script checks what kind of paths are needed and then sets the boolean \cygwin_path_fix_needed in lyxrc.defaults. But then you can override it by a checkbox (which, btw, is misnamed as it does the contrary of what its name implies). -- Enrico
Re: A Cygwin related patch
Georg Baum [EMAIL PROTECTED] writes: What I meant was: Do we need for one setting of cygwin_path_fix_needed both windos/posix styles, or does cygwin_path_fix_needed simply switch external_path() between the windows and posix version? As it is now, cygwin_path_fix_needed simply switch external_path() between the windows and posix version. However, if regarded as an OS, cygwin is really posix, so in some cases one must always use internal_path(). This is a singular case with respect to the other supported OSes. It may seem complicated, but apart the need for some polish, it does work. -- Enrico
Re: A Cygwin related patch
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg Now I don't like either anymore. The problem of both fixes is
Georg that they use a trailing '/' as flag whether external_path() is
Georg needed or not. This will strike back sooner or later.
Sure, this is not good. Is the problem that latex_path() needs
different syntax depending on whether the file name is used inside a
.tex file or as command argument?
What is the problem exactly?
The problem is that I have not a full grasp of the overall code and don't
want introduce changes without fully knowing the consequences. I repeat,
my idea is of only fixing what is broken, making changes that I fully
understand. As a problem arised with [EMAIL PROTECTED], I tried to fix only
that case.
As regards the trailing '/', I think this is not a problem, as there is
only one place in the code where latex_path() is called for generating
the argument of [EMAIL PROTECTED] It is in src/buffer.C, so a patch in which
I am confident is along these lines:
--- src/buffer.C(revision 13450)
+++ src/buffer.C(working copy)
@@ -875,7 +876,9 @@ void Buffer::makeLaTeXFile(ostream os,
texrow().newline();
}
if (!original_path.empty()) {
- string const inputpath = latex_path(original_path);
+ // A trailing slash is used as a flag for latex_path
+ // which will return an unslashed path.
+ string const inputpath = latex_path(original_path + /)
;
os \\makeatletter\n
[EMAIL PROTECTED]
inputpath /}}\n
and then in latex_path(), either:
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -87,6 +87,11 @@ string const latex_path(string const o
latex_path_dots dots)
{
string path = subst(original_path, \\, /);
+ if (suffixIs(path, '/')) {
+ path = rtrim(path, /);
+ if (os::cygwin_path_fix())
+ path = os::external_path(path);
+ }
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because is sometimes active (e.g. if
alongthe lines of the first patch, or:
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,15 @@ string const latex_path(string const o
latex_path_extension extension,
latex_path_dots dots)
{
- string path = subst(original_path, \\, /);
+ string path;
+
+ if (suffixIs(original_path, '/')) {
+ path = rtrim(path, /);
+ // The call to os::external_path is needed for Cygwin.
+ path = subst(os::external_path(original_path), \\, /);
+ } else
+ path = subst(original_path, \\, /);
+
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because is sometimes active (e.g. if
along the lines of the second patch. Both approaches work and are robust
because the trailing '/' is anyway added. Please, tell me what to do.
I do not feel confortable in unconditionally call external_path (I don't
want to fix what is not broken).
--
Enrico
Re: A Cygwin related patch
Georg Baum [EMAIL PROTECTED] writes:
I think that you can safely call it unconditionally. I looked it up, and
latex_path() is only called on filenames that are written to .tex files. I
would be very surprised if a TeX compiler exists on windows that needs win
style paths in \inputa at path but posix style paths in \includegraphics or
\input.
To be sure you could make a simple test: Call external_path()
unconditionally, and try to view a document that contains a graphics inset,
and two include insets, one with \input and one with \include. All files
should be entered with absolute names.
If my theory is right then running latex on the exported .tex file will work
with the unconditional fix and fail with the conditional one.
The absolute names are necessary to get slashes in the name, and running
latex on the exported .tex file is necessary because LyX uses always
relative paths for running latex internally.
Your theory is right and I wasn't fearless enough, not having the time
to study the code. So, the attached is apparently the right fix. While
testing this patch I run up against another bug.
1) File-New
2) Insert-File-Child Document (say we input ~/test.tex)
3) File-Export-LaTeX
LyX pops up a dialog telling me that ~/test.tex already exists and
asking for overwriting it. I say yes, overwrite it, but newfile1.lyx
is normally created and ~/test.tex is not overwritten. This is
independent from the fact that the buffer has been given a name or not.
This also happens on Solaris and I could not find a similar bug
reported in bugzilla.
PS: You might want to have a look at the cygwin version of external_path().
It contains unreachable code.
Uhm, I don't think so. The code after else return p; gets executed when
the previous if() clause is satisfied.
Many thanks for your helpful and appreciated comments.
--
Enrico
Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13463)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,9 @@ string const latex_path(string const o
latex_path_extension extension,
latex_path_dots dots)
{
- string path = subst(original_path, \\, /);
+ // The call to os::external_path is only needed for Cygwin.
+ string path = subst(os::external_path(original_path), \\, /);
+ path = rtrim(path, /);
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because is sometimes active (e.g. if
Re: A Cygwin related patch
Georg Baum [EMAIL PROTECTED] writes: Many thanks for your helpful and appreciated comments. I hope they are not too disappointing Oh, not at all... Here you basically revert external_path on non-cygwin windows. This is a bit ugly, so I moved this into a new function lyx::support::os::latex_path(). This is a noop except on cygwin, where it is identical to external_path(). Shall I put this in? It's very elegant. Please do. -- Enrico
Re: Bug in most recent svn -stable branch
Lodewijk Bonebakker [EMAIL PROTECTED] writes: When compiling lyx on Solaris 10, using an up-to-date gnu setup (updated autoconf, automake, etc). Compilation of the recent svn stable branch completes without problems. At startup however, lyx displays the main window, reports a SIGSEGV, displays the 'please report a bug message' and core dumps. I have no problems compiling LyX 1.4.x on Solaris 10 (sparc). The debugger reports: #0 0xd09f1015 in _lwp_kill () from /usr/lib/libc.so.1 The following parameters were used for configure: export LDFLAGS=-L/usr/lib export CPPFLAGS=-I/usr/include ./configure --prefix=/opt/lyx/latest --with-x --with-frontend=xforms \ --with-packaging=posix --with-pic --x-includes=/opt/sfw/include \ --x-libraries=/opt/sfw/lib --with-pspell=no --disable-static \ --enable-shared Your --x-includes and --x-libraries look suspicious, drop them. However, you may need --with-extra-lib=/usr/X11/lib RESULT=$? if [ $RESULT -eq 0 ]; then gmake fi I am now in the process of making a debug build. Any suggestions? I think that your configure options are wrong. -- Enrico
Re: A Cygwin related patch
On Fri, Mar 24, 2006 at 11:09:00AM +0100, Georg Baum wrote: Jean-Marc Lasgouttes wrote: I thought the idea of cygwin_path_fix was that it is only needed for latex. I am not so sure anymore. Why do you say so? The lines //No backslashes in LaTeX files dos_path = subst(dos_path,'\\','/'); would support the argument that external_path() is intended for latex on cygwin. Indeed. This might also explain the need for patching qt on cygwin, since external_path() is used for paths in file dialogs, for example. I really faced the opposite problem, as Qt was being passed posix paths, which is right, but when using the native graphics version, calls to the Windows API were being made and a conversion to win-style paths was needed. If I remember correctly, I patched the Qt sources such that both win-style and posix-style paths were ok. I also remember that I had to do something for UNC paths (//machine/xxx), which otherwise would have not worked. That is because I was so wary about the unconditional call to external_path. I am sure that my Qt port can cope with whatever path-style it is presented, but I cannot be sure for other ports. Maybe Kayvan can shed some light? I think that the current Qt version distributed with cygwin cannot be used for compiling LyX as it is multi-threaded and there are problems with the cygwin1.dll, as explained here: http://www.mail-archive.com/cygwin@cygwin.com/msg65681.html Anyway, the patch is somewehat orthogonal to the question whether cygwin_path_fix should be used in external_path or not. We would need to change the implementation of latex_path() if that should be true, but the external usage would stay the same. Well, I have been compiling by myself LyX and Qt/X11 since LyX 1.3.4 and until 1.3.5 (then I have been using the Angus port) and never noticed a problem. Even this latex_path issue was escaping me. But I am not sure if this was because until a certain time I have been using the cygwin tetex before switching to miktex. So what do you think about the patch? Should it go in, or should we first research the use cygwin_path_fix in external_path or not issue? In my experience, if a cygwin application does not try to manipulate a path by itself, i.e., if it simply use the pathname for loading, or saving, or whatever, it can even be passed a true win-style path with '\'. A notable exception is latex, which for some reason needs posix-style paths in .tex files. So, given that things work as they stand now, why changing? Anyway, I have no problem in maintaining my own patches to the official sources. To tell you the truth, there is almost no free software I use that I do not patch for some reason or another. Sometimes it is because the patches are really peculiar to me, but sometimes it is because I am scared by the time you have to invest to have them accepted (I don't mean you in this case, really). -- Enrico
Re: A Cygwin related patch
On Fri, Mar 24, 2006 at 12:51:17PM +0100, Georg Baum wrote: Jean-Marc Lasgouttes wrote: I think I agree with it. Could you repost it please? I am lost in the thread :) Sure, here it is. I have a comment on this patch. I see that you get rid of the rtrim call in latex_path. This has the following effect: in all cases the argument of [EMAIL PROTECTED] will have two '/' appended, except on cygwin when cygwin_path_fix_ is true, in which case only one '/' is appended. This is because external_path() will trim the trailing '/' when cygwin_path_fix_ is true. -- Enrico
Re: A Cygwin related patch
On Fri, Mar 24, 2006 at 01:43:55PM +0100, Georg Baum wrote: Enrico Forestieri wrote: I have a comment on this patch. I see that you get rid of the rtrim call in latex_path. This has the following effect: in all cases the argument of [EMAIL PROTECTED] will have two '/' appended, except on cygwin when cygwin_path_fix_ is true, in which case only one '/' is appended. This is because external_path() will trim the trailing '/' when cygwin_path_fix_ is true. Why does it do that? It does not make any sense to me. This is the way the cygwin call which convert paths works... I'll commit the patch as-is rught now. It is a monotonic improvement over the current situation, we can fix this issue when we know why it happens. I was only being pedantic. I put a lot of attention on those small things because you never know to what a small difference can lead. Anyway, the argument of [EMAIL PROTECTED] should have a single shash appended and the rtrim would guarantee that. -- Enrico PS: Sorry that I cannot reply promptly, but I have also to do some work.
Re: A Cygwin related patch
On Fri, Mar 24, 2006 at 02:04:53PM +0100, Georg Baum wrote:
No, it does not need posix style paths: It simply cannot cope with
backslashes for obvious reasons. AFAIK miktex can handle paths like
C:/temp/test.tex. Not a big difference, but not exactly posix either.
This path style is called mixed style in the cygwin documentation.
The test performed by the configure script about use_cygwin_path_fix is
exactly based on that. It consists in creating a latex file containing
something like \input{C:/temp/test.tex}, launching latex on the file,
and then looking for an error. The cygwin tetex gives an error, indeed,
whereas miktex does not.
If everything works: Fine, but from reading the code I suspect that there
might be problems when calling external programs or handling paths to the
filedialog. Of course we should not fix anything when we are not sure where
the problem lies.
As I said, cygwin can cope with both win and posix style paths, so a
problem is unlikely to occur but not impossible (see bug 2344). However,
I am getting more and more convinced that the way the Use Cygwin-style
paths checkbox is currently used is wrong. The configure script already
takes care of appropriately setting the use_cygwin_path_fix switch, and
the fact that such setting can be subverted through that checkbox, can
only be harmful to the casual user which has not clear what its
implications are.
I don't know if the idea of who introduced such checkbox was to let
the user decide what kind of path style LyX would use/show in its GUI,
but I think that its purpose should be exactly this one. Therefore it
should be made orthogonal to the use_cygwin_path_fix switch.
Building upon your clever intuition about the need of an os::latex_path
function, I devised the attached patch and I am currently testing it.
Until now everything works and the behavior seems more consistent to me.
Essentially, my idea is that when Use Cygwin-style paths is unchecked,
LyX/Cygwin should look and feel as a native windows application and the
files it produces should be completely interoperable with the native
LyX/Win version, as I think this is a good thing.
I still have to reach that goal. For the moment only the paths in
preferences are converted to the desired format.
Anyway, I am posting the patch as it is now, in order to get some
feedback.
--
Enrico
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 13496)
+++ src/lyxfunc.C (working copy)
@@ -1977,6 +1977,11 @@ void actOnUpdatedPrefs(LyXRC const lyx
namespace os = lyx::support::os;
os::cygwin_path_fix(lyxrc_new.cygwin_path_fix);
}
+ case LyXRC::RC_CYGWIN_STYLE_PATHS:
+ if (lyxrc_orig.cygwin_style_paths !=
lyxrc_new.cygwin_style_paths) {
+ namespace os = lyx::support::os;
+ os::cygwin_style_paths(lyxrc_new.cygwin_style_paths);
+ }
case LyXRC::RC_DATE_INSERT_FORMAT:
case LyXRC::RC_DEFAULT_LANGUAGE:
case LyXRC::RC_DEFAULT_PAPERSIZE:
Index: src/frontends/qt2/QPrefs.C
===
--- src/frontends/qt2/QPrefs.C (revision 13496)
+++ src/frontends/qt2/QPrefs.C (working copy)
@@ -148,6 +148,11 @@ string const internal_path(QString const
return lyx::support::os::internal_path(fromqstr(input));
}
+string const internal_path_list(QString const input)
+{
+ return lyx::support::os::internal_path_list(fromqstr(input));
+}
+
}
@@ -199,7 +204,7 @@ void QPrefs::apply()
#if defined(__CYGWIN__) || defined(__CYGWIN32__)
QPrefCygwinPathModule * cygwinmod(dialog_-cygwinpathModule);
- rc.cygwin_path_fix = cygwinmod-pathCB-isChecked();
+ rc.cygwin_style_paths = cygwinmod-pathCB-isChecked();
#endif
QPrefLatexModule * latexmod(dialog_-latexModule);
@@ -253,7 +258,7 @@ void QPrefs::apply()
rc.template_path = internal_path(pathsmod-templateDirED-text());
rc.backupdir_path = internal_path(pathsmod-backupDirED-text());
rc.tempdir_path = internal_path(pathsmod-tempDirED-text());
- rc.path_prefix = fromqstr(pathsmod-pathPrefixED-text());
+ rc.path_prefix = internal_path_list(pathsmod-pathPrefixED-text());
// FIXME: should be a checkbox only
rc.lyxpipes = internal_path(pathsmod-lyxserverDirED-text());
@@ -467,6 +472,11 @@ QString const external_path(string const
return toqstr(lyx::support::os::external_path(input));
}
+QString const external_path_list(string const input)
+{
+ return toqstr(lyx::support::os::external_path_list(input));
+}
+
}
@@ -536,7 +546,7 @@ void QPrefs::update_contents()
#if defined(__CYGWIN__) || defined(__CYGWIN32__)
QPrefCygwinPathModule * cygwinmod(dialog_-cygwinpathModule);
- cygwinmod-pathCB-setChecked(rc.cygwin_path_fix);
+
Re: [patch] check for the preview-package
On Sun, Mar 26, 2006 at 10:28:15AM +0200, Georg Baum wrote: Am Sonntag, 26. März 2006 05:10 schrieb Uwe Stöhr: Btw. for what is the file LyXConfig.lyx.in needed? I knew once, but forgot. I think this file was obsoleted by LaTeXConfig.lyx.in. Perhaps chkconfig.ltx should be updated to reflect it. -- Enrico
Re: LyX 1.4.0 on Windows
Angus Leeming [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes Jean-Marc.Lasgouttes at ... writes: Enrico my reading of it is that you need the three compilations only Enrico if you want an internationalized iconv program, i.e., if you Enrico want translated messages from iconv. I personally think that Enrico building libiconv with --disable-nls and then LyX with Enrico --with-included-gettext is sufficient. But I may be wrong That seems very reasonable indeed. It may seem reasonable, but that's what I did (apart from the --disable-nls bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is the explicit --disable-nls important? Presumably not, since libiconv's configure will work out that it can't see a gettext. Angus, I don't know if you solved this problem, but I just got aware of a gettext env var (OUTPUT_CHARSET) which may be related to it. I have the correct output when I start a native LyX (compiled with -mno-cygwin) as $ LANG=ru_RU /c/Programmi/LyX-1.4.0/bin/lyx-1.4.0win32 but I get garbage when I do $ OUTPUT_CHARSET=UTF-8 LANG=ru_RU /c/Programmi/LyX-1.4.0/bin/lyx-1.4.0win32 Anyway, OUTPUT_CHARSET=iso-8859-1 seems to work fine for me. Here are a couple of links which may be useful: http://www.mail-archive.com/cygwin@cygwin.com/msg37340.html http://www.linuxdocs.org/HOWTOs/Unicode-HOWTO-3.html HTH -- Enrico
Re: [Fwd: What is the qt functions to get/set position of the main window?]
On Mon, Mar 27, 2006 at 04:25:58PM +0200, Joost Verburg wrote: Charles de Miramon wrote: Why not make things simple. I'm in favour of Bo Peng's approach. Power users can always use the -geometry option from the command line. Or if they use, KWin use the advanced options for windows placement where you can tweak parameters forever. The -geometry option only works for xforms, maybe it would be a good idea to make it work for Qt as well. Uh? It works even on Windows. -- Enrico
Re: LyX/Win 1.4.1 svn
On Tue, Mar 28, 2006 at 08:49:50AM +0200, Ekkehart Schlicht wrote: 2. If I write a+b=c in a math insert and switch on instant preview, the insert sometimes disappears, and at other times it appears as a b c (with missing operators). If you have dvipng installed, this may be due to the fact that when a font is missing it is created on the fly by mktexpk (or alike) and its output gets mixed to that of dvipng. This output confuses the lyxpreview2bitmap.py script, which thinks the font is not available. If this theory is correct, you should simply close and then reopen your document to see the previews. -- Enrico
Re: Mysterious crash with a cygwin build
On Tue, Mar 28, 2006 at 03:13:17PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Latest patch (using prefixIs) attached. At least the part that skips directories can go in now. It is the part that avoids the crash. Concerning the rest, I think it matches a bugzilla entry. Could you look for it? Enrico You are right. I found Enrico http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say Enrico that this patch fixes precisely that bug ;-) Enrico, I plan to apply this patch for now. Is it enoughto fix the cygwin crash? Yes, it is. Thanks Jean-Marc. -- Enrico
Re: [Cvslog] r13434 - in /lyx-devel/trunk/src: bufferlist.C client/cli...
On Tue, Mar 28, 2006 at 09:05:03PM +0200, Georg Baum wrote: Am Dienstag, 28. März 2006 15:03 schrieb Jean-Marc Lasgouttes: I put it there, except dor the part in client.C. I am not sure this one is right/useful. It is currently a noop because the client does not work on windows. But it should help if that changes some day. The client works with the cygwin/X11 version of LyX. It doesn't work with the cygwin/native-graphics version, but I suspect that this is because the Qt sources are crippled when using the cygwin-g++-win32 target (as opposed to cygwin-g++, which uses X11). I am confident that I can solve this problem. -- Enrico
Re: Thoughts on future features for LyX
On Wed, Mar 29, 2006 at 05:18:04PM +0200, Helge Hafting wrote: Well, lyx supports the latex programming/typesetting language. You can define a \cis in the document preamble, then you'd be able to type \cis in math. It won't look exactly the same as sin and cos on screen, but it will look right in print and pdf. You can achieve this goal by copying the symbols file in systemdir to your userdir and adding at its bottom the line cis lyxblacktext 0 0 func x You still have to define \cis in the document preamble. -- Enrico
[patch] Cygwin polishing
I have reviewed all (I think) possible problems related to paths in cygwin. The attached is the patch I come up with. I hope that it can be applied for 1.4.1 as it doesn't harm the other targets and is really needed for cygwin. I have reorganized things in this way: 1) The kind of path style to be written into .tex files is only decided by the configure script which checks what the correct style is (miktex vs cygwin tetex). 2) The Use Cygwin-style paths checkbox is now unrelated to the check performed by the configure script. When unchecked, all paths written to .lyx files, returned by the dialogs, and shown in preferences are in pseudo win-style, including the PATH prefix. When using win-style paths, the .lyx files written by the cygwin version can also be read by the native LyX version (when they contain absolute paths). I have tested it quite extensively and I am confident that it works as it should. Now, in dialogs and source files, a filename may be input in any style (windows, posix, mixed style) and it always works. The patch is against 1.4.x, please tell me if you need one against 1.5. -- Enrico Index: insets/insetgraphics.C === --- insets/insetgraphics.C (revision 13529) +++ insets/insetgraphics.C (working copy) @@ -597,7 +597,7 @@ string const InsetGraphics::prepareFile( copyToDirIfNeeded(orig_file, temp_path, zipped); if (status == FAILURE) - return orig_file; + return os::latex_path(orig_file); // a relative filename should be relative to the master // buffer. @@ -629,7 +629,7 @@ string const InsetGraphics::prepareFile( boost::tie(status, bb_file) = copyFileIfNeeded(bb_orig_file, bb_file); if (status == FAILURE) - return orig_file; + return os::latex_path(orig_file); runparams.exportdata-addExternalFile(latex, bb_file); } Index: insets/ChangeLog === --- insets/ChangeLog(revision 13529) +++ insets/ChangeLog(working copy) @@ -1,3 +1,7 @@ +2006-03-29 Enrico Forestieri [EMAIL PROTECTED] + * insetgraphics.C (prepareFile): Fix the returned path such + that it is in the proper style for inclusion in a .tex file. + 2006-03-11 Jürgen Spitzmüller [EMAIL PROTECTED] *insettabular (doDispatch, insertAsciiString): Index: bufferlist.C === --- bufferlist.C(revision 13529) +++ bufferlist.C(working copy) @@ -28,6 +28,7 @@ #include support/filetools.h #include support/package.h +#include support/os.h #include boost/bind.hpp @@ -43,6 +44,8 @@ using lyx::support::removeAutosaveFile; using lyx::support::package; using lyx::support::prefixIs; +using lyx::support::os::external_path; + using boost::bind; using std::auto_ptr; @@ -379,7 +382,7 @@ Buffer * BufferList::getBufferFromTmp(st BufferStorage::iterator it = bstore.begin(); BufferStorage::iterator end = bstore.end(); for (; it end; ++it) - if (prefixIs(s, (*it)-temppath())) + if (prefixIs(external_path(s), external_path((*it)-temppath( return *it; return 0; } Index: ChangeLog === --- ChangeLog (revision 13529) +++ ChangeLog (working copy) @@ -1,3 +1,12 @@ +2006-03-29 Enrico Forestieri [EMAIL PROTECTED] + * lyxrc.h: Added boolean cygwin_style_paths. + * lyxrc.C: + * lyxfunc.C: + * lyx_main.C: Handle cygwin_style_paths. + * bufferlist.C (getBufferFromTmp): + * exporter.C (copyFile): Fix problem with paths as on + cygwin they can be of different type (posix vs windows). + 2006-03-29 Jean-Marc Lasgouttes [EMAIL PROTECTED] * LaTeX.C (handleFoundFile): do not add directories to the Index: exporter.C === --- exporter.C (revision 13529) +++ exporter.C (working copy) @@ -33,6 +33,7 @@ #include support/filetools.h #include support/lyxlib.h #include support/package.h +#include support/os.h #include boost/filesystem/operations.hpp @@ -46,6 +47,7 @@ using lyx::support::OnlyFilename; using lyx::support::OnlyPath; using lyx::support::package; using lyx::support::prefixIs; +using lyx::support::os::external_path; using std::find; using std::string; @@ -107,7 +109,8 @@ CopyStatus copyFile(string const forma // overwrite themselves. This check could be changed to // boost::filesystem::equivalent(sourceFile, destFile
Re: [Cvslog] r13434 - in /lyx-devel/trunk/src: bufferlist.C client/cli...
On Wed, Mar 29, 2006 at 08:53:37PM +0200, Georg Baum wrote: Am Mittwoch, 29. März 2006 03:11 schrieb Enrico Forestieri: The client works with the cygwin/X11 version of LyX. Sorry, I meant windows without cygwin. It doesn't work with the cygwin/native-graphics version, but I suspect that this is because the Qt sources are crippled when using the cygwin-g++-win32 target (as opposed to cygwin-g++, which uses X11). I am confident that I can solve this problem. Qt should not have anything to do with the client. It should just work if socket support is available in the OS. AFAIK this is the case on cygwin, but not on plain win32. Indeed, when configuring for X11 everything works, because in this case all *_unix.cpp files are pulled in. But, when configuring for cygwin without X11, a mix of *_win.cpp and *_unix.cpp files are compiled. I think the reason is that using the cygwin-g++-win32 target, qeventloop_win.cpp is compiled instead of qeventloop_unix.cpp. The socket code here apparently doesn't work with cygwin. My idea is to substitute the socket code in qeventloop_win.cpp with the one in qeventloop_unix.cpp (when/if I'll have the time...). Notice that qsocketdevice_unix.cpp is always compiled instead of its *_win.cpp counterpart. If it is not so, I can't explain why it works when linking with libqt for X11 and it does not work when linking with libqt without X11. I had not a closer look at the LyX sources, but it seems to me that some sort of callback function gets registered with Qt. -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 11:01:29AM +0200, Abdelrazak Younes wrote: Enrico Forestieri a écrit : I have reviewed all (I think) possible problems related to paths in cygwin. The attached is the patch I come up with. I hope that it can be applied for 1.4.1 as it doesn't harm the other targets and is really needed for cygwin. Hello Enrico, Having had a (quick) look at your patch, it seems that some (most?) of your patch would be of benefit to non-cygwin windows user. At least they wouldn't hurt. I am in favor of getting rid of the #ifdef __CYGWIN__ in code and creates a universal Windows binary that will work equally good (via a setting) within a Cygwin environment or not. What do you think? That indeed would be great, but I think that the cygwin target has some peculiarities not easily mimicked by a native build. For example, the Use Cygwin-style paths checkbox could also be provided for the plain win32 build, but, apart from the fact that the routines converting between path styles should be someway designed (they are provided by cygwin), there's a problem here. Indeed, if in a native build you use cygwin style paths, you are obliged to use only cygwin apps, as the native ones will not understand posix syntax. On the contary, with a cygwin build you can use both path styles, as cygwin apps also understand plain win32 style (it is more likely that if you use cygwin, you also have all cygwin apps). However, IMO, the cygwin_path_fix switch should also be used in os_win32.C to decide what kind of paths are to be output to .tex files, as a user should not be forced to use miktex. This is easy to do, as it simply involves changing C:/xxx to /cygdrive/c/xxx in os:latex_path and in os:internal_path when it is passed os::LATEX_FILE. The problem here would be that the /cygdrive prefix could be changed to anything else by the user in cygwin (unlikely but not impossible). Another problem is converting from posix to win32 style the absolute paths found in a .lyx file (perhaps produced by a cygwin LyX using cygwin-style paths), if such paths are relative to the cygwin root. For example, /home/user/xxx should be converted to cygwin_root/home/user/xxx and you should know what cygwin_root is (this info is stored in the registry, however). So, I agree with you that a part of the fix can also be applied to the plain win32 target, but I do not think that we can avoid all the #ifdef __CYGWIN__ switches. I think I can also tweak os_win32.C, but I do not dare to do that without permission. I dared to modify the cygwin target because it was my impression that it was being left behind and I didn't want it going down the sink like the OS2 target... -- Enrico
Re: [PATCH] Clean up configure.py
On Wed, Mar 29, 2006 at 10:55:19PM -0600, Bo Peng wrote: Dear list, configure.py was first written as a direct translation of the configure.m4 file. It is not structured, and use all global variables. Attached is a more pythonic version. It is the first step towards my goal of automatic partial re-configuration. The diff will be difficult to read so I attach configure.py as well. Please apply and test it. I tested it on cygwin. Here are the results. 1) After launching, the script was hanging in checkCygwinPath(). I had to kill the latex.exe process to let it continue (I use MikTeX, so latex.exe is a native win32 program, whereas python is a cygwin application). Doing so, the check for cygwin_path_fix was wrong, of course. 2) lyxrc.defaults had CRLF terminators. 3) All other files (packages.lst, textclass.lst, and doc/LaTeXconfig.lyx) were ok and a diff with the ones produced by the sh configure script showed no significant differences. So, apart from 1) and 2) above, it works. Good work! I think that the configure script should also provide for a default \path_prefix in lyxrc.default, probably based on platform. When sys.platform == 'cygwin', it would be: \path_prefix /usr/local/bin:/usr/bin:/usr/X11R6/bin -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 01:16:56PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri a écrit :
That indeed would be great, but I think that the cygwin target has
some peculiarities not easily mimicked by a native build.
IMHO, no need to mimic anything, he who want a cygwin functionality
should use the cygwin mode... I am not sure I am not saying something
stupid her :-0
I don't think it's stupid. That would mean detecting at runtime if
we are a cygwin app or not. See below.
So, I agree with you that a part of the fix can also be applied
to the plain win32 target, but I do not think that we can avoid
all the #ifdef __CYGWIN__ switches.
Maybe not all but any which can be deleted is good. Is there a simple
way to check at runtime if we are running in a cygwin environment?
If yes, this check could be used as a replacement for the #ifdef,
couldn't it? (I hate #ifdef ;-))
The following C program prints I am a cygwin app when compiled with
the cygwin gcc, and I am a native win32 app when compiled with mingw
(-mno-cygwin, in my case).
#include stdio.h
#include unistd.h
int main(void)
{
if (access(/cygdrive, F_OK) == 0)
puts(I am a cygwin app);
else
puts(I am a native win32 app);
return 0;
}
I think I can also tweak os_win32.C, but I do not dare to do that
without permission. I dared to modify the cygwin target because it
was my impression that it was being left behind and I didn't want
it going down the sink like the OS2 target...
Well, Angus is retired, at least that's what he says ;-)... I am sure
that Michael Gerz would be happy and _I_ would happy that you take the
leadership for the windows platform :-). That makes the count for
potential windows developers, or did I forget somebody? Also I am very
short of time these days and you seem to have a lot knowledge in all
that stuff. Once your cygwin patch is accepted for 1.4.x, I would
suggest that you base your work against trunk.
What do you think?
I think I should be considered in the same position as Angus ;-)
I cannot assure neither a continuous commitment nor a prompt reply
to the list, due to my workload. Anyway, it is fun for me and I find
that I am spending some night hours on the LyX sources. It seems
that LyX has some addictive effect ;-)
Then you should consider that, even if I am very proficient in C, I
should be regarded as a real C++ newbie. I also think that Michael
or you are good candidates to that leadership ;-)
Thanks for all the good explanations,
You're welcome
--
Enrico
Re: [PATCH] Clean up configure.py
On Thu, Mar 30, 2006 at 10:09:07AM -0600, Bo Peng wrote:
I tested it on cygwin. Here are the results.
1) After launching, the script was hanging in checkCygwinPath().
I had to kill the latex.exe process to let it continue (I use
MikTeX, so latex.exe is a native win32 program, whereas python
is a cygwin application). Doing so, the check for cygwin_path_fix
was wrong, of course.
Was the old configure.py working under this configuration? What will
happen if you run latex.exe directly from a cygwin environment?
I don't know because this is the first time that I test it.
Anyway, I think I know why latex hangs. In the script you use mkstemp()
to generate a temp file. As python is a cygwin app, it is returning a
name of the form /tmp/xxx. Now, the MikTeX latex.exe doesn't understand
this path and stops, asking you to input another filename. But, as it is
not run interactively, it hangs (it would be better to call latex
redirecting its stdin to /dev/null).
Also note that when you run latex /some/path/file.tex, file.log and
file.aux will be left in the current directory.
Please, attached find a patch correcting this problems. I have
substituted cmdOutput('cygpath -w ' + ...).replace('\\', '/')
with cmdOutput('cygpath -m ' + ...), as the -m flag to cygpath
already does what you do with the replace().
I also have corrected the logic: path correction is not needed when
the output from latex contains Error.
A last thing: I don't know why the script is not removing chklatex.ltx
and chklatex.log, even if it should, as removeFiles() is called for them.
I think that the configure script should also provide for a default
\path_prefix in lyxrc.default, probably based on platform. When
sys.platform == 'cygwin', it would be:
\path_prefix /usr/local/bin:/usr/bin:/usr/X11R6/bin
Where will it be used?
It is used by LyX to set the PATH prefix. In *nix it should be omitted,
as everything needed should already be in the PATH. In the native win32
LyX it will be set by the installer, so also in this case it is probably
not needed. This leaves cygwin (I don't know for Mac) where the above
is to be taken as the default (it can be later override by the user).
--
Enrico
Re: [PATCH] Clean up configure.py
On Thu, Mar 30, 2006 at 09:46:57PM +0200, Enrico Forestieri wrote:
Please, attached find a patch correcting this problems.
I forgot to attach the patch.
--
Enrico
--- configure.py.orig Thu Mar 30 12:58:18 2006
+++ configure.pyThu Mar 30 21:27:14 2006
@@ -33,7 +33,7 @@
def removeFiles(filenames):
'''utility function: 'rm -f'
-ignore erroes when file does not exist, or is a directory.
+ignore errors when file does not exist, or is a directory.
'''
for file in filenames:
try:
@@ -78,7 +78,7 @@
sys.exit(1)
-def checkCygwinPath():
+def checkCygwinPath(srcdir):
''' Adjust PATH for Win32 (Cygwin) '''
if sys.platform == 'cygwin':
from tempfile import mkstemp
@@ -88,19 +88,23 @@
\begin{document}\end{document}
''')
os.close(fd)
-inpname = cmdOutput('cygpath -w ' + tmpfname).replace('\\', '/')
+inpname = cmdOutput('cygpath -m ' + tmpfname)
# a wrapper file
wfd, wtmpfname = mkstemp(suffix='.ltx')
+wtmpfname = cmdOutput('cygpath -m ' + wtmpfname)
os.write(wfd, r'\input{' + inpname + '}' )
os.close(wfd)
if cmdOutput('latex ' + wtmpfname).find('Error') != -1:
+ print configure: cygwin detected; path correction is not needed
+else:
print configure: cygwin detected; path correction
- srcdir = cmdOutput('cygpath -w ' + srcdir).replace(r'\\', '')
+ srcdir = cmdOutput('cygpath -m ' + srcdir)
print srcdir = , srcdir
addToRC(r'\cygwin_path_fix_needed true')
-else:
- print configure: cygwin detected; path correction is not needed
-removeFiles( [ tmpfname, wtmpfname ])
+tmpbname,ext = os.path.splitext(os.path.basename(tmpfname))
+wtmpbname,ext = os.path.splitext(os.path.basename(wtmpfname))
+removeFiles( [ tmpfname, wtmpfname, tmpbname + '.log', \
+ tmpbname + '.aux', wtmpbname + '.log', wtmpbname + '.aux' ] )
## Searching some useful programs
@@ -672,7 +676,7 @@
sys.exit(1)
setEnviron()
createDirectories()
- checkCygwinPath()
+ checkCygwinPath(srcdir)
## Write the first part of outfile
writeToFile(outfile, '''# This file has been automatically generated by LyX'
lib/configure.py
# script. It contains default settings that have been determined by
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 03:56:02PM +0200, Abdelrazak Younes wrote: Just for confirmation, is /cygdrive is present on any cygwin installation? But in the special case where a user has a c:\cygdrive and lyx is installed on the same drive, this test doesn't work (I just made the test). Is there any other way? I really don't know... Message to the main lyx developers: IMHO, if you want to encourage new contributions, you should relax a bit the implicit process of reviewing for trunk. I think that external developers are feeling very scared (I am for non-qt4) and this fact can stop them from further contribution. So instead of discussing during a month or two some patches, why not commit the patches (if they don't make lyx crash) and work from that point? It's easy enough to revert a change with SVN if a patch is obviously wrong. IMHO, from the new developer point of view, it is much easier to work this way. And _I_ think that the SVN history is much better than the mailing archive in order to know why this or that patch has evolved. Abdel, I think that a review is necessary. You cannot be sure that you did no mistakes. As regards myself, I understand that cygwin related problems are not a priority. I simply hope to pinpoint the problems, suggest a solution and wait that someone more knowleadgeable than me tells if it is ok or suggests something better. For example, while testing I just got this assertion from boost: assertion src.size() == std::strlen( src.c_str() ) failed: file ../../../../../boost/libs/filesystem/src/path_posix_windows.cpp, line 235 I don't get it without my patch, so, something is going wrong. Back to thinking... -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 05:33:31PM +0200, Georg Baum wrote: I did not yet have time to comment on Enricos patch, I just had a quick look and the cygwin ifdefs he introduced in frontends/qt2/FileDialog.C don't seem right. If they are really needed (which I doubt currently, but that may change after reading the whole patch) we should introduce just another patch function. That way, we get nice clean code and the ugly stuff is banned to few files in src/support. I try to explain again why I did that. In Windows one could use miktex or tetex (by cygwin). But, as things stand now, tetex cannot be used because, for reasons not known to me, it gives an error when a path like C:/xxx is output to a .tex file. I think that it is related to the fact that a check for a posix-style absolute path is being made, but I have not read the tetex sources and cannot be sure. I think that in Windows all files output to a .tex file should be obtained by os::latex_file() which, according to the cygwin_path_fix switch, should return either C:/xxx or /cygdrive/c/xxx. So, three functions are needed: 1) os::internal_path for paths used internally by LyX 2) os::external_path for paths intended to be used by external programs 3) os::latex_pathfor paths going to .tex files In *nix all of them are noops. In native win32 1) and 2) simply differ in the path separator, whereas 3) should give either pseudo-win paths or posix paths according to wheter miktex or tetex is used (this is what cygwin_path_fix tells you). In cygwin, things could be exactly as in *nix, but if you want to allow for miktex, than 3) above should be exactly as for native win32 (as it should be, I mean, not as it is now). However, you could also use other native apps apart from miktex, so it is useful that both 1) and 2) return either posix- or win-style paths. This is to be independent from the cygwin_path_fix switch and in my patch it is done through the Use Cygwin-style paths checkbox. As a cygwin app can deal with both posix or win-style paths, we could simply ditch the Use Cygwin-style paths checkbox and make 1) and 2) always return pseudo win-style paths (I mean with forward slashes because it seems that most windows programs understand that, even notepad and word have no problems with forward slahes). But chances are high that if you have cygwin, you also use all-cygwin apps, and if one of them tries to be smart about deciding that a path is absolute or not, you are in trouble, because you suddenly find that the current dir path is prepended to your already absolute path. For this reason I think that the checkbox should stay. One input source from which a path is entered is the file dialog, so I simply pass its output to os::internal_path which returns a path in the style dictated by the Use Cygwin-style paths checkbox. This is the logic driving my patch and I am sure that it can be implemented in a better way than I did, but I don't want to be one which simply asks for something and I think it is helpful to start from an almost working implementation rather than from scratch. If you do not agree with this vision, I am fine anyway. I do not want to make a pressure on you as I have the sources and can build my own version of LyX. However, the cygwin version that I made available is the one I am using, so if my copy is different from the official sources and this is not acceptable for you, I will not provide other versions if you ask so, as I don't want that you get blamed for it. Anyway, I would like to thank you for LyX which I am using from version 0.10 (I think I still have the COLD program lying on the hard disk). -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 06:39:39PM +0200, Jean-Marc Lasgouttes wrote: I think this cygwin-without-cygwin stuff is becoming stranger and stranger. cygwin-without-cygwin? what's that? ;-) -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 05:01:52PM +0200, Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Message to the main lyx developers: Abdelrazak IMHO, if you want to encourage new contributions, you Abdelrazak should relax a bit the implicit process of reviewing for Abdelrazak trunk. I think that external developers are feeling very Abdelrazak scared (I am for non-qt4) and this fact can stop them from Abdelrazak further contribution. So instead of discussing during a Abdelrazak month or two some patches, why not commit the patches (if Abdelrazak they don't make lyx crash) and work from that point? I think reviewing publicly a patch is easier when it is complete. The main problem is that we do not have enough time to work on LyX. I know this is a problem for me; already focusing on 1.4 is difficult, so reviewing patches lags. I hope I will be more available after 1.4 settles. No problem with me. I am not going to push you. OTOH, we have tried adding patches 'that work' without asking much. And now we have a lot of code that nobody really understands or special hacks. It is not that new contributors are not good. It is just that often you need several people to find the right solution. I do want to have new blood in the team. We definitely need that. But at the same time we need to keep the code in a consistent shape. FWIW, I agree with you. -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 05:44:17PM +0200, Abdelrazak Younes wrote: I am using TortoiseSVN which has a very good GUI that can show visual comparison between revisions or even 3-way comparisons. With this GUI you can reject a change, revert to an older version, etc. I definitely prefer this method of reviewing instead of having to apply the patch first (which does not always work fine). For me reading a diff is not practical for new functionality, only for bug fixing. I find that another good tool is meld. -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 10:21:53PM +0200, Georg Baum wrote: Am Mittwoch, 29. März 2006 20:49 schrieb Enrico Forestieri: I have reorganized things in this way: 1) The kind of path style to be written into .tex files is only decided by the configure script which checks what the correct style is (miktex vs cygwin tetex). 2) The Use Cygwin-style paths checkbox is now unrelated to the check performed by the configure script. I am not sure that this good. This checkbox was introduced because the user should be able to override the result of the configure script (if you want to know more, read the thread Latest LyX on Latest Cygwin from jan 2005). I read it. IMHO the checkbox should go completely if it is never necessary to correct the decision of the configure script, or it should stay and override that decision as it has been originally. Currently, the checkbox also decides that all external paths should be in windows style. That may be fine, but there is a problem. When checked you get win-style paths instead of posix, i.e., the contrary of what the checkbox is labeled (Use Cygwin-style paths). When unchecked, all paths written to .lyx files, returned by the dialogs, and shown in preferences are in pseudo win-style, including the PATH prefix. What has the path prefix to do with that? Currently, you have win-style paths in all preferences except PATH prefix which should always be entered in posix style. When using win-style paths, the .lyx files written by the cygwin version can also be read by the native LyX version (when they contain absolute paths). In 1.3 it was possible to use the same files with relative filenames on linux and native win, does this still work? Yes, it does. IMHO the paths in LyX files should always be with forward slashes. This should not be configurable. That gives maximum compatibility between platforms. It is already so. Note that the Use Cygwin-style paths was originally implemented only for LaTeX paths. IMO it should retain that meaning. The problem that other programs (converters) may need different paths was not dealt with at all, but the thread mentioned above has solutions. Yes, I read it and I agree with you. But currently it is not so. Index: insets/insetgraphics.C === --- insets/insetgraphics.C (revision 13529) +++ insets/insetgraphics.C (working copy) @@ -597,7 +597,7 @@ string const InsetGraphics::prepareFile( copyToDirIfNeeded(orig_file, temp_path, zipped); if (status == FAILURE) - return orig_file; + return os::latex_path(orig_file); // a relative filename should be relative to the master // buffer. @@ -629,7 +629,7 @@ string const InsetGraphics::prepareFile( boost::tie(status, bb_file) = copyFileIfNeeded(bb_orig_file, bb_file); if (status == FAILURE) - return orig_file; + return os::latex_path(orig_file); runparams.exportdata-addExternalFile(latex, bb_file); } These changes are not necessary, but don't hurt either. These return statements are only executed if something failed already, so the .tex file cannot be compiled anyway. Understood. I was being thorough. Index: bufferlist.C === --- bufferlist.C(revision 13529) +++ bufferlist.C(working copy) @@ -28,6 +28,7 @@ #include support/filetools.h #include support/package.h +#include support/os.h #include boost/bind.hpp @@ -43,6 +44,8 @@ using lyx::support::removeAutosaveFile; using lyx::support::package; using lyx::support::prefixIs; +using lyx::support::os::external_path; + using boost::bind; using std::auto_ptr; @@ -379,7 +382,7 @@ Buffer * BufferList::getBufferFromTmp(st BufferStorage::iterator it = bstore.begin(); BufferStorage::iterator end = bstore.end(); for (; it end; ++it) - if (prefixIs(s, (*it)-temppath())) + if (prefixIs(external_path(s), external_path((*it)-temppath( return *it; return 0; } This looks strange. Why is it needed? Please add an explaining comment. Oh, this must be a left over. I think this is not necessary after the patch to package.C.in. Here (*it)-temppath() is in posix format while s can be in win-style format, so prefixIs would fail. This is because s can come from internal_path() which would turn posix paths into win-paths when cygwin_path_fix is true
Re: [PATCH] Clean up configure.py
On Thu, Mar 30, 2006 at 08:59:37PM +, Angus Leeming wrote: Enrico Forestieri [EMAIL PROTECTED] writes: It is used by LyX to set the PATH prefix. In *nix it should be omitted, as everything needed should already be in the PATH. In the native win32 LyX it will be set by the installer, so also in this case it is probably not needed. This leaves cygwin (I don't know for Mac) where the above is to be taken as the default (it can be later override by the user). Setting it in the installer is a kludge. The correct place to set this thing is in the configure script so that it can be updated as you install software. We couldn't do that before now because shell scripts have limited support for interogation of the registry ;-) If you had chosen cygwin instead of MSYS, you could have enjoyed the regtool utility ;-) Another favorite of mine is /proc/registry by which you can browse the registry settings as if it was a filesystem. And LyX itself can remain registry-ignorant. I really hate the registry thing :( -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 10:59:18AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Thu, Mar 30, 2006 at 06:39:39PM +0200, Jean-Marc Lasgouttes Enrico wrote: I think this cygwin-without-cygwin stuff is becoming stranger and stranger. Enrico cygwin-without-cygwin? what's that? ;-) Isn't the point of this thread to support compiling with cygwin -mnocygwin and (perhaps separately, I am not sure anymore) to have a binary that can either be cygwin-based or not depending on the phase of the moon? It may be that I missed the point, but I think we should keep things simple. No, you got it wrong. This for the real cygwin target. The interesting part, of course, is proper support for real cygwin, which you address in your other message. I always had addressed real cygwin. I have never spoken of problems related to build a native LyX with cygwin (cygwin-without-cygwin). In some other thread I mentioned it only to say that building it that way I see no problems related with gettext/libiconv as opposed to what seems to happen using mingw. -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 12:10:14PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico cygwin-without-cygwin? what's that? ;-) Isn't the point of this thread to support compiling with cygwin -mnocygwin and (perhaps separately, I am not sure anymore) to have a binary that can either be cygwin-based or not depending on the phase of the moon? It may be that I missed the point, but I think we should keep things simple. Enrico No, you got it wrong. This for the real cygwin target. Well, I was answering to abdel originally, and he did say he wanted an universal binary that would decide at runtime whether it is cygwin-based or not. You're right. I got it wrong ;-) The interesting part, of course, is proper support for real cygwin, which you address in your other message. Enrico I always had addressed real cygwin. I have never spoken of Enrico problems related to build a native LyX with cygwin Enrico (cygwin-without-cygwin). Did I say you did? I beg your pardon, next time I'll check more closely quotations. -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 12:34:36PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico I beg your pardon, next time I'll check more closely Enrico quotations. No problem, I would be more useful if I actually manage to understand how cygwin stuff should work. I already tried to tell how I think it should work. I am going to summarize here my thoughts from a cygwin pov only. In Windows either a native or cygwin-based TeX engine can be used. This means that paths written in .tex files should have either a win- or posix-style depending on the TeX engine used (note that this is also true for the native version of LyX, which is otherwise unusable with the cygwin-tetex). The configure script already has the ability to detect the TeX engine and it sets the boolean \cygwin_path_fix_needed accordingly. When it is true, we are using a native TeX engine. So, a os::latex_path function is needed (other than os::internal_path and os::external_path) to convert paths going to .tex files in the right format. As cygwin is posix conformant, os:internal_path and os::external_path could be noop functions as it is for *nix. BUT: if one uses miktex, most probably also has other native apps which would be unusable because they don't understand posix. Now, given that cygwin apps have no problems with either win- or posix-style formats, it is reasonable that both os::internal_path and os::external_path return pseudo win-style paths (I mean paths with forward slashes, but with a prefixing drive letter and a colon). However, if one uses tetex, most probably has all cygwin-apps and it is better that both os::insternal_path and os::external_path return posix-style formats. My patch does exactly this. The user cannot customize os::latex_path because that is the configure script job. However, he can decide if is version of LyX/Cygwin behaves as if it was a native win32 app or not as regards the paths used elsewhere. How things currently work: - The configure script makes its guess about \cygwin_path_fix_needed. - Every path used externally to LyX has the format dictated by the configure guess, irrespectively of whether it goes written into a .tex file or not. - The user can subvert the configure guess by a checkbox. So, currently LyX behaves as a native or posix app based on the checkbox. My patch tries to polish things, separating the case of path for latex by that of path for external use. -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 01:59:09PM +0200, Georg Baum wrote: Enrico Forestieri wrote: However, you could also use other native apps apart from miktex, so it is useful that both 1) and 2) return either posix- or win-style paths. This is to be independent from the cygwin_path_fix switch and in my patch it is done through the Use Cygwin-style paths checkbox. Not agreed. os::internal_path should always create posix-style paths. Why would we want other paths internally? If you think about presentation of paths to the user, then I would rather invent a new function display_path(), otherwise we mixup things. One could argue what os::external_path should do. In fact I am not really sure how to handle this on cygwin. I do not understand why os::internal_path can return paths like C:/xxx in the win32 version and cannot for the cygwin version. Note that the test for an absolute path already takes that into account. As regards os::external_path, it should be equivalent to os::internal_path, as it is on *nix. As a cygwin app can deal with both posix or win-style paths, we could simply ditch the Use Cygwin-style paths checkbox and make 1) and 2) always return pseudo win-style paths (I mean with forward slashes because it seems that most windows programs understand that, even notepad and word have no problems with forward slahes). But chances are high that if you have cygwin, you also use all-cygwin apps, and if one of them tries to be smart about deciding that a path is absolute or not, you are in trouble, because you suddenly find that the current dir path is prepended to your already absolute path. For this reason I think that the checkbox should stay. The checkbox does not really solve the fundamental problem: On cygwin, we don't know which of the external programs needs a cygwin style path, and which one needs a native windows path. rather than the checkbox I would like to have a more general mechanism, for example a wrapper script that is invoked instead of an external program and that can translate the paths. The configure script could then write the corresponding entries in lyxrc.default. This way you simply add complexity. As it is now, os::external_path already returns C:/xxx style paths depending on the checkbox status. I want simply make that independent of \cygwin_path_fix_needed. Notice that it works. I use it daily without problems with a mix of cygwin and native apps. I use MikTeX and the native ImageMagick, all other programs are cygwin's. Never noticed a problem. Only recently the [EMAIL PROTECTED] bug has arised, and there is another one that still has gone unnoticed and that I spotted browsing the sources. Small things, easily fixed. However, the cygwin version that I made available is the one I am using, so if my copy is different from the official sources and this is not acceptable for you, I will not provide other versions if you ask so, as I don't want that you get blamed for it. I personally am fine as long as it is clearly labelld as a modified version. Ok. -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 02:11:25PM +0200, Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: However, you could also use other native apps apart from miktex, so it is useful that both 1) and 2) return either posix- or win-style paths. This is to be independent from the cygwin_path_fix switch and in my patch it is done through the Use Cygwin-style paths checkbox. Georg Not agreed. os::internal_path should always create posix-style Georg paths. Why would we want other paths internally? Definitely. Note that for the win32 target os::internal_path returns pseudo-win style paths. Why it cannot be so also for cygwin? Georg If you think about presentation of paths to the user, then I Georg would rather invent a new function display_path(), otherwise we Georg mixup things. One could argue what os::external_path should do. external_path could have a second, optional, argument that would be an enum describing what we want to do with the name (LATEX, DEFAULT, whatever). No, sorry. external_path should not be related to latex. Hmmm, I am not sure it is a good idea actually. Georg The checkbox does not really solve the fundamental problem: On Georg cygwin, we don't know which of the external programs needs a Georg cygwin style path, and which one needs a native windows path. Georg rather than the checkbox I would like to have a more general Georg mechanism, for example a wrapper script that is invoked instead Georg of an external program and that can translate the paths. The Georg configure script could then write the corresponding entries in Georg lyxrc.default. For converters, we could use a flag to tell what kind of paths are needed. Of course, if we use convert we do not know whether it is a native or a cygwin version (do both exist?). Both exist, and the cygwin version has no problems with C:/xxx style paths, even if it is presented with eps:C:/xxx. We could also have special forms of $i $o and friends asking for an internal path. This is a cool idea, but I think that it is orthogonal to the question of what kind of paths internal_path and external_path should return. -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 02:33:08PM +0200, Georg Baum wrote: Enrico Forestieri wrote: I think that it is better to proceed step by step. Is it okay with you if I start from scratch and do the minimum necessary to fix real bugs? You don't need to start from scratch, since you solved a lot of probelsm already. I like the step by step approach, and would really appreciate if you could start with the latex_path fixes and fix the current cygwin_fix setting. Then you could look at input_path(), and then at the problems below: Currently these are: 1) Bug 2344. 2) If in a graphics inset an absolute path is inserted by the file dialog, it will be exported in the .tex file in posix format, such that miktex fails to find the file. This has not been reported by anyone, I discovered it browsing the sources. If you think that the order should be different: that would also be fine with me. Ok, let's take a more pragmatic approach. I am going to post a patch #1 which simply solves the two problems above. I would like them fixed in 1.4.1 such that the binary I'll made available will not be different from that which can be built from the official sources. Notice that I have already incorporated the fix to bug 2344 in 1.4.0, which otherwise would be unusable. Then I am going to separate the checkbox from the cygwin_fix setting. This is going to be patch #2. Then we will see. Is this acceptable for you? -- Enrico
Re: [PATCH] Clean up configure.py
On Fri, Mar 31, 2006 at 07:25:48AM -0600, Bo Peng wrote: * configure.py: Major clean up. I could have written that one myself. I was thinking about something more detailed, but I'll use that now. I do not think there are more details. :-) This is only a clean up with things are grouped together and packed into functions, No new feature is introduced, but this will allow new features to be added in easily. Bo, have you incorporated my patch about the cygwin test? Without it the setting of \cygwin_path_fix_needed is completely wrong. -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 10:23:38PM +0200, Enrico Forestieri wrote: For example, while testing I just got this assertion from boost: assertion src.size() == std::strlen( src.c_str() ) failed: file ../../../../../boost/libs/filesystem/src/path_posix_windows.cpp, line 235 I don't get it without my patch, so, something is going wrong. Back to thinking... Actually it turns out that my patch uncovered an already present problem. I added some debug statements and got this output: === '25.34679pt too wide' === 'C:/OML/ztmcm/m/it/12 t[]/OT1/ztmcm/m/n/12' assertion src.size() == std::strlen( src.c_str() ) failed: file ../../../../../boost/libs/filesystem/src/path_posix_windows.cpp, line 238 That strange file name comes from LaTeX::deplog and is extracted from the latex logfile. The pertinent excerpt is the following: ... Overfull \hbox (25.34679pt too wide) in paragraph at lines 1414--1417 \T1/ptm/m/n/12 where $\OML/ztmcm/m/it/12 [] \OT1/ztmcm/m/n/12 = \OML/ztmcm/m/i t/12 s[]\OT1/ztmcm/m/n/12 (\OML/ztmcm/m/it/12 t[]\OT1/ztmcm/m/n/12 )$\T1/ptm/m/ n/12 , and $\OML/ztmcm/m/it/12 \OT1/ztmcm/m/n/12 = \OML/ztmcm/m/it/12 R\OT1/z tmcm/m/n/12 (\OML/ztmcm/m/it/12 t[] \OMS/ztmcm/m/n/12 \OML/ztmcm/m/it/12 t[]\ OT1/ztmcm/m/n/12 )\OML/ztmcm/m/it/12 =R\OT1/ztmcm/m/n/12 (0)$ \T1/ptm/m/n/12 is their cor-re-la-tion co-ef-fi-cient, be-ing $\OML/ztmcm/m/it/12 R\OT1/ztmcm/m/ n/12 (\OML/ztmcm/m/it/12 \OT1/ztmcm/m/n/12 ) = \OMS/ztmcm/m/n/12 F[] []$\T1/pt m/m/n/12 . ... Here, (\OML/ztmcm/m/it/12 t[] \OMS/ztmcm/m/n/12 \OML... is taken as a filename because it is after a (. Notice that a null is in there. I don't know if it will survive the email transfer, but I see it as ^@ in vim, and as soh in nedit, just before \OML The fact that the path above has a C: prepended and '\' turned into '/' is due to the cygwin api functions converting filepaths. So, I think that my patch is innocent here, or at least it is not the direct cause of the assert. Why miktex is outputting non-text characters is beyond me, though. -- Enrico
Re: Windows build automake version problem.
On Fri, Mar 31, 2006 at 03:55:02PM +0200, Abdelrazak Younes wrote: Bo Peng a écrit : Dear list, [...] So I run autogen.sh myself: sh-2.04$ ./autogen.sh Using automake (GNU automake) 1.8.2 This automake version is not supported by LyX. LyX only supports automake 1.9. I checked mingw website (and the instruction), 1.8.2 is the current release, and was used by others. Hello Bo, You have to switch to cygwin (which should have automake-1.9) and run autogen.sh from there. Then you can switch back to msys for the configure.sh step. Or you can try to do everything from cygwin by giving the -mno-cygwin option to gcc so that the mingw version of gcc is used. No, please, don't do that if you don't know what you are doing! Dragons are there! -- Enrico
Re: Windows build automake version problem.
On Fri, Mar 31, 2006 at 08:17:42AM -0600, Bo Peng wrote: You have to switch to cygwin (which should have automake-1.9) and run autogen.sh from there. Then you can switch back to msys for the Thanks. Lyx is compiling. However, aspell still does not work. The latest error message is ... Any idea? Please, attached find the patch I apply to fix aspell compilation. It works for me. -- Enrico --- common/file_util.cpp.orig 2004-11-15 13:29:54.0 +0100 +++ common/file_util.cpp2005-12-30 23:26:42.0 +0100 @@ -26,6 +26,7 @@ #ifdef WIN32 +# include asc_ctype.hpp # include io.h # define ACCESS _access # include windows.h --- common/config.cpp.orig 2005-06-22 07:32:30.0 +0200 +++ common/config.cpp 2005-12-31 04:20:50.0 +0100 @@ -42,6 +42,7 @@ #include iostream.hpp +#undef printf #define DEFAULT_LANG en_US // NOTE: All filter options are now stored with he f- prefix. However
[patch] fix bug 2344 and paths issues on cygwin
Here is a minimal patch for cygwin. It fixes bug 2344 and the following
two bugs:
- Export to latex fails when cygwin_path_fix is true, because
prefixIs(p1,p2) in copyFile() fails to recognize that p2 is prefix of
p1 when they are in different styles.
- When a file is exported to latex and the extension is to be omitted,
the file gets written in the .tex file in posix syntax, such that
miktex will not be able to find it.
These bugs are a result of the mess caused by letting cygwin_path_fix
control both the style of the paths to be written in .tex files and
to be used externally.
Note that this is a dirty patch, in the sense that it do not solve
the problem that the paths used internally by LyX are still partly in
posix style and partly in pseudo-win32 style when cygwin_path_fix is
true.
The correct fix to this problem is my other patch in the thread
Cygwin polishing, which however, I admit tries to solve too much
things in a single shot.
--
Enrico
Index: src/bufferlist.C
===
--- src/bufferlist.C(revision 13538)
+++ src/bufferlist.C(working copy)
@@ -28,6 +28,7 @@
#include support/filetools.h
#include support/package.h
+#include support/os.h
#include boost/bind.hpp
@@ -43,6 +44,8 @@ using lyx::support::removeAutosaveFile;
using lyx::support::package;
using lyx::support::prefixIs;
+using lyx::support::os::internal_path;
+
using boost::bind;
using std::auto_ptr;
@@ -380,8 +383,11 @@ Buffer * BufferList::getBufferFromTmp(st
{
BufferStorage::iterator it = bstore.begin();
BufferStorage::iterator end = bstore.end();
+ // On cygwin it is currently a mess: when cygwin_path_fix_ is true,
+ // some paths are in pseudo-win32 style, some other in posix style.
+ // So, we must make sure that both paths are in the same style.
for (; it end; ++it)
- if (prefixIs(s, (*it)-temppath()))
+ if (prefixIs(internal_path(s), (*it)-temppath()))
return *it;
return 0;
}
Index: src/ChangeLog
===
--- src/ChangeLog (revision 13538)
+++ src/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2006-03-31 Enrico Forestieri [EMAIL PROTECTED]
+ * bufferlist.C (getBufferFromTmp):
+ * exporter.C (copyFile): Fix problem with paths as on cygwin they
+ maybe of different type (posix vs pseudo-windows).
+
2006-03-16 Jürgen Spitzmüller [EMAIL PROTECTED]
* text.C (delete): adjust cursor after backspace in change tracking
Index: src/exporter.C
===
--- src/exporter.C (revision 13538)
+++ src/exporter.C (working copy)
@@ -33,6 +33,7 @@
#include support/filetools.h
#include support/lyxlib.h
#include support/package.h
+#include support/os.h
#include boost/filesystem/operations.hpp
@@ -47,6 +48,8 @@ using lyx::support::OnlyPath;
using lyx::support::package;
using lyx::support::prefixIs;
+using lyx::support::os::internal_path;
+
using std::find;
using std::string;
using std::vector;
@@ -111,7 +114,10 @@ CopyStatus copyFile(string const forma
// overwrite themselves. This check could be changed to
// boost::filesystem::equivalent(sourceFile, destFile) if export to
// other directories than the document directory is desired.
- if (!prefixIs(OnlyPath(sourceFile), package().temp_dir()))
+ // On cygwin it is currently a mess: when cygwin_path_fix_ is true,
+ // some paths are in pseudo-win32 style, some other in posix style.
+ // So, we must make sure that both paths are in the same style.
+ if (!prefixIs(OnlyPath(internal_path(sourceFile)),
package().temp_dir()))
return ret;
if (!force) {
Index: src/support/os_unix.C
===
--- src/support/os_unix.C (revision 13538)
+++ src/support/os_unix.C (working copy)
@@ -57,7 +57,7 @@ string external_path(string const p)
}
-string internal_path(string const p)
+string internal_path(string const p, path_target)
{
return p;
}
Index: src/support/os.h
===
--- src/support/os.h(revision 13538)
+++ src/support/os.h(working copy)
@@ -26,6 +26,11 @@ enum shell_type {
CMD_EXE
};
+enum path_target {
+ DEFAULT,
+ LATEX
+};
+
/// Do some work just once.
void init(int argc, char * argv[]);
@@ -45,7 +50,7 @@ std::string::size_type common_path(std::
std::string external_path(std::string const p);
/// Converts a host OS style path to unix style.
-std::string internal_path(std::string const p);
+std::string internal_path(std::string const p, path_target target = DEFAULT);
/**
* Converts a unix style path into a form suitable for inclusion in a LaTeX
Index: src/support
Re: 'Re: [patch] Cygwin polishing' - MARC
On Fri, Mar 31, 2006 at 09:53:45AM -0800, Stephen Harris wrote: http://marc.theaimsgroup.com/?l=lyx-develm=114381524012218w=2 Enrico wrote: Why miktex is outputting non-text characters is beyond me, though. --- http://groups.google.com/group/comp.editors/browse_thread/thread/1b8a2d71bce3eb33 /99fc8b9a55bf799f?lnk=stq=%22%5EM%22++EOLrnum=1hl=en#99fc8b9a55bf799f I have seen ^M at the end of some words (or lines) which has to do with Dos/CRLF getting confused with *nix/LF EOL's. The DOS EOL (end of line) is seen as Crtl-M by the Unix editor. Yes, this is common. Even a non-ascii character with code 127 would not be a surprise. But a null (zero value) in the middle of a string is quite unusual. I wondered if the type of editor used to generate the LyX files used could cause a conflict? This is a tentative suggestion. No, LyX has no problems in dealing with both line termination styles. -- Enrico
Re: [patch] fix bug 2344 and paths issues on cygwin
On Fri, Mar 31, 2006 at 09:56:41PM +0200, Enrico Forestieri wrote: The correct fix to this problem is my other patch in the thread Cygwin polishing, which however, I admit tries to solve too much things in a single shot. This is to reaffirm what I said. I just discovered another bug related to the actual mess. MakeRelPath(abspath,basepath) fails because its arguments are in different style, so the paths entered by the dialogs are always absolute. I am not going to fix this bug, though. The correct fix to it and to all other bugs is the other big patch ;-) -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 08:05:10PM +0200, Michael Gerz wrote: Just my two cents: I agree with Jean-Marc that we should keep things simple. We don't have to support each and every conceivable configuration. If we manage to provide the Windows world with a working LyX - no matter how - our job is done! Michael, the point is that I think a cygwin version of LyX is potentially better than a native version. This is my opinion and I do not want to convince anybody of it. You should understand that there may be someone who doesn't like what you like and viceversa ;-) I compile it for myself and I think I am not leaking any resource from the native version. I also hope to not be a stumbling stone. I also don't understand why a user may want to change path conventions at run-time (is there anybody out there who actually understands the implications?) It is not like that. You simply decide that you like the win-style for paths and check a button in preferences, so it is as if you have the native version. Or you could prefer a posix appearance. But you do this once, not every minute. There is no implication, as the LyX sources already deal with both pseudo-win style and posix style. It is like having a chameleon. The way I designed things, the conversions are always consistent and till now I neither noticed problems, nor can I foresee them. If I have a problem using win-style paths, the same problem will show up in the native version. If I have a problem with posix style, the same problem will show up in the *nix version. However, as cygwin runs on Windows, the win-style is more advantageous, because you can use both native and cygwin apps. Using the native version you are somewhat more limited. I use cygwin and have many cygwin applications, so I do not want to have duplicates for using LyX. Heck, I was even using cygwin for compiling a native version! I was able to use cygwin and native LyX together, but it seems that many people have trouble. So, I think that a cygwin version is good for them. This said, I am happy with any patches that fix cygwin problems. However, we should make sure that MinGW and MikTeX continue to work without special hacks. Agreed. -- Enrico
Re: [patch] Cygwin polishing
On Sat, Apr 01, 2006 at 01:24:00PM +0200, Georg Baum wrote: Am Freitag, 31. März 2006 15:21 schrieb Enrico Forestieri: I do not understand why os::internal_path can return paths like C:/xxx in the win32 version and cannot for the cygwin version. Note that the test for an absolute path already takes that into account. It could as well return paths like C:/xxx under cygwin. I am actually not sure what is better. My point is that it should always do the same for a given OS environment. If we make this configurable we only create confusion and gain nothing. This is exactly what my patch does. I do not agree about the confusion. The checkbox in preferences is to be considered as a one-time switch. Check it and LyX always uses posix paths, uncheck it and LyX always uses C:/xxx like paths. The rationale is that who has cygwin and has all cygwin-apps, gain nothing from the win-style paths and actually he maybe *wants* to see posix paths. Then he can check the box and is done. Note that who uses cygwin for its posix features, may like to use miktex instead of tetex, or the native Imagemagick instead of the cygwin port. I took into account these cases also and in the cygwin installation I provide two scripts (convert and epstopdf) which deal with them. In this way, who accidentally checks or unchecks the checkbox is not going to have any surprise. IMO, the checkbox is added functionality and no confusion at all. As regards os::external_path, it should be equivalent to os::internal_path, as it is on *nix. Do you mean with equivalent that it should perform the opposite conversion? No, I mean external_path == internal_path when output is not going to .tex files (and always using forward slashes). The problem with the checkbox is that normal users will probably not understand what it is for. The advantage fo the more general mechanism would be that all the complexity can be in the configure script, and users are only faced with it when defining a new converter. Not agreed. When they check or uncheck it, they immediately understand what it does as the paths they see in preferences (even the PATH prefix) and those they get from the file dialogs are of the requested type. They don't need to know that the configure script has already instructed LyX to output the correct path styles in .tex files. Moreover, nuking the checkbox maybe be seen as a regression... As it is now, os::external_path already returns C:/xxx style paths depending on the checkbox status. I want simply make that independent of \cygwin_path_fix_needed. I think we all agree that this is right. I take you mean the independence point, because actually the behavior of external_path is fundamentally wrong. Notice that it works. I use it daily without problems with a mix of cygwin and native apps. I use MikTeX and the native ImageMagick, all other programs are cygwin's. Never noticed a problem. So you are saying that there is no need to output cygwin style paths to external programs? That would be great. I understand that cygwin programs can also use native windows paths with backslashes. Is that true? Not only it is true, but they can even cope with weird things as 'C:/this\is/a\strange/path'. Indeed, when properly quoted with single quotes, this is taken as C:/this/is/a/strange/path. The only problem which can arise with a cygwin app (if it is a badly ported unix app which doesn't expect win-style paths) is when it tries to establish if the path is absolute or not in order to prepend the current dir path to it. But this is not the case with the helper apps used by LyX. In this case I would like the following simple solution for cygwin: - Use native windows paths with backslashes in external_path() No, IMO it should always use windows paths but with forward slashes. Note that even notepad and word (microsoft applications) understand this, not counting all other non-microsoft programs. Initially I had your same idea, but after thinking of it I convinced myself that using backslashes can only hurt and does not help. - Depending on \cygwin_path_fix_needed, use either native windows paths with forward slashes or posix paths in latex_path() Yes. This does not need an additional checkbox, and is simple enough for anybody to understand. Not agreed. IMO the additional checkbox is an added value and I think it will be appreciated by the many hating the C:/xxx style and wanting the look and feel of a posix app. Also note that my patch will go unnoticed by users as no visible changes will occur. Simply, all bugs will be corrected in their eyes. Only recently the [EMAIL PROTECTED] bug has arised, and there is another one that still has gone unnoticed and that I spotted browsing the sources. Small things, easily fixed. And at least the [EMAIL PROTECTED] thing has nothing to do with external_path, but with latex_path and mixed up internal paths. Yes, but it was due
Re: [patch] fix bug 2344 and paths issues on cygwin
On Sat, Apr 01, 2006 at 01:46:39PM +0200, Georg Baum wrote: I fear we have been talking past each other. I never wanted a dirty patch. I wanted a correct one, but split up in smaller chunks. For example, the additional check box could be left out in the first version, hardcoding win style paths with forward slashes in external_path(). I also believe that external_path() could be made independant of cygwin_path_fix without touching the other problems. Sorry if this looks like I am wanting to make you jump through hoops. I really don't want that. I do want to resolve the current problems, but in a way that does not provoke future problems. That means: - All paths in LyX must be stored in the format decided by internal_path() - All path manipulation functions should therefore work with this internal format - All paths that are output to external programs must be converted by external_path() - All paths that are written in .tex files must be converted by latex_path() - All paths that are read in from external sources must be converted to internal format. In the case of LaTeX log file parsing this may require a new function latex_internal_path() that is the inverse of latex_path(). I believe that certain rc file settings do fall also in the category external. I think that we have a consensus now on everything except external_path(). It would be very nice if you could split up your original patch into parts along the lines above. If it turns out that one part is still large that is no problem. The important thing is that it does not address many problems at once. Understood. I'll leave the checkbox thing as it is now, i.e., the user can subvert the configure script decisions (a really bad idea) and arrange things such that LyX internally uses the format decided by internal_path(). My idea is that the internal and external formats should be the same and for the moment will hardcode a boolean forcing either a posix or a pseudo win-style (with forward shashes) format. Is that a correct interpretation of what you write above? Note that the way I will do, a latex_internal_path() is not necessary. The rc file settings can be in whatever format (even in pure win format with back slashes) and they will be converted on the fly to the desired internal format. -- Enrico
Re: Some data
On Sat, Apr 01, 2006 at 10:44:09AM +0200, Juergen Spitzmueller wrote: Abdelrazak Younes wrote: Hey! Congratulation to your wife and you! Hope everything is all right. Congratulations from me, too! Ditto! -- Enrico
Re: Windows build automake version problem.
On Fri, Mar 31, 2006 at 07:24:33PM -0600, Bo Peng wrote: The weird part is, -I./interfaces/cc/ has aspell.h. Any clue? If you are using the mingw compiler, I think that your problems may come from using make instead of mingw32-make. -- Enrico
Re: [patch] Cygwin polishing
On Sat, Apr 01, 2006 at 05:44:55PM +0200, Georg Baum wrote: Am Samstag, 1. April 2006 16:37 schrieb Enrico Forestieri: This is exactly what my patch does. I do not agree about the confusion. Here I meant confusion for programmers, not users. It simply does not make sense to make the path format that is used internally by LyX configurable. With internally used by LyX I mean the data in memory during execution of the program. I don't mean the paths that are passed to external programs or entered by the user in a file dialog. LyX has no problems with either C:/xxx or /c/xxx. It deals with C:/xxx when compiled for windows and it deals with /c/xxx when compiled for posix. So there is no need to add complexity, it already works in both cases. There are problems only when the two forms are mixed, like it is now. The checkbox in preferences is to be considered as a one-time switch. Check it and LyX always uses posix paths, uncheck it and LyX always uses C:/xxx like paths. The rationale is that who has cygwin and has all cygwin-apps, gain nothing from the win-style paths and actually he maybe *wants* to see posix paths. Then he can check the box and is done. I understand this argument, but I don't like the conclusions you draw. In one of my other mails I wrote that cygwin might need a display_path() function that converts internal paths to a representation that can be used in file dialogs, for example. external_path() should only be used for communicating with external programs, not for user interaction. Therefore external_path() should simply work, no need to make it pretty. Let us please postpone the user visible paths for now, and first get the internal representation right. In the actual implementation external_path is already used for display purposes, too. Georg, my idea is really simple and working. When LyX deals internally with pseudo-win style paths, it behaves exactly as the win32 version, when it deals internally with posix paths it behaves exactly as the unix version. Very simple and effective, no problems for the programmer as he already has to account for the C:/xxx style. Note that who uses cygwin for its posix features, may like to use miktex instead of tetex, or the native Imagemagick instead of the cygwin port. I took into account these cases also and in the cygwin installation I provide two scripts (convert and epstopdf) which deal with them. In this way, who accidentally checks or unchecks the checkbox is not going to have any surprise. IMO, the checkbox is added functionality and no confusion at all. That is true if the checkbox controls user visible paths, and is IMO not true if it controls paths passed to external programs. My idea is that the checkbox makes LyX behave as a native or posix app as regards paths. As regards os::external_path, it should be equivalent to os::internal_path, as it is on *nix. Do you mean with equivalent that it should perform the opposite conversion? No, I mean external_path == internal_path when output is not going to .tex files (and always using forward slashes). I don't understand. external_path == internal_path would mean that we neither need external_path nor internal_path. Do you really mean that? external-path and internal_path are already needed for the win32 version (if it was depending on me, I had avoided that), and in os_unix.C they are simply stubs returning their argument. So, for unix, external_path == internal_path already. My idea is that in cygwin it is should be the same but they should return either posix or pseudo win-style paths on demand. The problem with the checkbox is that normal users will probably not understand what it is for. The advantage fo the more general mechanism would be that all the complexity can be in the configure script, and users are only faced with it when defining a new converter. Not agreed. When they check or uncheck it, they immediately understand what it does as the paths they see in preferences (even the PATH prefix) and those they get from the file dialogs are of the requested type. They don't need to know that the configure script has already instructed LyX to output the correct path styles in .tex files. Moreover, nuking the checkbox maybe be seen as a regression... I was talking of the additional checkbox you introduced, not about the existing one. Uh? What additional checkbox? I simply connected the exiting one to a boolean different from cygwin_path_fix, as I think that the user should not be able to subvert the configure script test. That would be really dangerous and surprising for users: check the box and it works, uncheck the box and it doesn't work anymore. No, IMO it should always use windows paths but with forward slashes. Note that even notepad and word (microsoft applications) understand this, not counting all other non-microsoft programs
Re: [patch] fix bug 2344 and paths issues on cygwin
On Sat, Apr 01, 2006 at 05:55:07PM +0200, Georg Baum wrote: Am Samstag, 1. April 2006 17:07 schrieb Enrico Forestieri: Understood. I'll leave the checkbox thing as it is now, i.e., the user can subvert the configure script decisions (a really bad idea) and arrange things such that LyX internally uses the format decided by internal_path(). My idea is that the internal and external formats should be the same and for the moment will hardcode a boolean forcing either a posix or a pseudo win-style (with forward shashes) format. Is that a correct interpretation of what you write above? Almost. No boolean please (that would circumvent the whole idea of internal/external path). Simply hardcode the decision in internal_path and external_path. Later we can then think about paths visible to the user and replace some calls of external_path() by a new function display_path(). Georg, cygwin runs on windows and it understands both posix and win-style paths. So, what is external and what is internal? In the win32 version C:/xxx is the internal representation, in the *nix version /c/xxx is the internal representation. Why one of the two cannot be chosen as internal representation in cygwin (which bridges both worlds) ? Sincerely I cannot understand your point. If you fear that this fact can bring a major burden to a programmer, well, now I have spent quite some time on the subject and can tell you that it is exactly the contrary, i.e., a major burden can occur if you adopt a different representation for external and internal ;-) -- Enrico
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 01:11:50PM +0200, Georg Baum wrote: Am Samstag, 1. April 2006 18:48 schrieb Enrico Forestieri: On Sat, Apr 01, 2006 at 05:44:55PM +0200, Georg Baum wrote: Let us please postpone the user visible paths for now, and first get the internal representation right. Pretty please!!! ;-) In the actual implementation external_path is already used for display purposes, too. Georg, my idea is really simple and working. I doubt the latter, see below. The fact that you did not see problems does not necessarily mean that there are none. Indeed. I figured out another problem, see below. When LyX deals internally with pseudo-win style paths, it behaves exactly as the win32 version, when it deals internally with posix paths it behaves exactly as the unix version. Very simple and effective, no problems for the programmer as he already has to account for the C:/xxx style. That is no problem indeed. The problem is the runtime change of internal_path() format. I meant it as a one-time switch. external-path and internal_path are already needed for the win32 version (if it was depending on me, I had avoided that), and in os_unix.C they are simply stubs returning their argument. So, for unix, external_path == internal_path already. My idea is that in cygwin it is should be the same but they should return either posix or pseudo win-style paths on demand. I understood this now, but I don't agree. IMO the format of internal_path should be a compile time decision, not a runtime decision. If it was a runtime decision, it would have the following problems: - Implicit format change of .lyx files. I know that there are currently problems in this area due to the mixup, but for the future I would like to have only one representation of file names in .lyx files for a given platform. Indeed. When a .lyx file contains an absolute path, it has different styles depending on whether LyX is a win32 or posix app. This was one of the reasons I wanted to be able to switch the internal representation. I am always able to read a .lyx file produced by a win32 LyX using a cygwin LyX, but it may be not true the other way, as win32 doesn't understand posix. Perhaps it would be better to force a pseudo-win style when outputting file names to .lyx files in order to guarantee interoperability at least on windows. But if the internal format is fixed, we have added complexity. However, now I am almost convinced that this is unavoidable. - debugging: If something goes wrong on cygwin, we need to know the setting of internal_path(). Maybe. - what happens for example if a user starts with one setting, and then switches to the other and continues to work? Are all file names in memory magically changed? Or do you want to force him to close LyX and start over? The last one was my idea. It should not be changed at runtime. Anyway, I had wrapped all critical points with calls to either internal_path or external_path, so a on the fly conversion occurs and it would work. There are probably more implications that I don't think of yet. I am not going to do a final decision on this problem, and I don't want to discuss this further. You need to convince others if you want to do this. No need for this. I had already reached your same conclusion before reading your reply. The very technical reason that the internal format should be posix is that boost doesn't handle mixed formats. If there is agreement that it should go in I am willing to commit it for you (if by then you still have no acoount), but I don't think that my opinion about this problem will change. I think it is not necessary. It seems that this stubborn fellow got convinced at last ;-) However, as I said, this will add complexity because we are now outside of the two established and working schemes. What I mean is that in win32 and *nix internal_path == latex_path, whereas, when fixing the internal format, this is may not be true in cygwin anymore. As I wrote already: Please lets start with the cleanup of the internal mixup. That means: Add external_path()/internal_path() calls where necessary, and hardcode one format both in internal_path() and external_path(). When this is done you can easily implement whatever fancy runtime switches you like on top of that. Well, I think that I cannot hardcode a format in external_path as this would be a regression. Indeed, currently the external format is dictated by the cygwin_path_fix switch. If I do that, suddenly a user can find that its external application doesn't work anymore because it was expecting a given path style. So, for the moment I will not change the current semantics. Uh? What additional checkbox? I simply connected the exiting one to a boolean different from cygwin_path_fix, as I think that the user should not be able to subvert the configure script test. I thought it was an additional one. What I
Re: [patch] fix bug 2344 and paths issues on cygwin
On Sun, Apr 02, 2006 at 01:14:09PM +0200, Georg Baum wrote:
Am Samstag, 1. April 2006 21:17 schrieb Enrico Forestieri:
On Sat, Apr 01, 2006 at 05:55:07PM +0200, Georg Baum wrote:
Almost. No boolean please (that would circumvent the whole idea of
internal/external path). Simply hardcode the decision in internal_path
and external_path. Later we can then think about paths visible to the
user and replace some calls of external_path() by a new function
display_path().
Georg, cygwin runs on windows and it understands both posix and
win-style paths. So, what is external and what is internal?
In the win32 version C:/xxx is the internal representation, in
the *nix version /c/xxx is the internal representation.
Why one of the two cannot be chosen as internal representation
in cygwin (which bridges both worlds) ?
I already wrote that either could be used as internal representation. My
point is that this decision should be made at compile time, and it should
not be configurable at runtime which representation is chosen.
I didn't mean it as a runtime switch. Anyway, this controversy
is now resolved by the observation that boost dosn't deal with
mixed styles, so posix is to be used as the internal
representation style.
Sincerely I cannot understand your point. If you fear that this
fact can bring a major burden to a programmer, well, now I have
spent quite some time on the subject and can tell you that it is
exactly the contrary, i.e., a major burden can occur if you adopt
a different representation for external and internal ;-)
We are forced to do that on non-cygwin windows. So we have no choice but
use external_path() and internal_path() carefully. With this prerequisite
I see no additional burden to programmers if external_path() uses
something different than internal_path() on cygwin.
Well, I am facing a problem related to it now. Please, help this
C++ newbie to solve the following problem.
I had already the need to add an enum argument to internal_path.
Its natural declaration was in support/os.h in the
lyx::support::os namespace:
enum path_target {
DEFAULT,
LATEX
}
std::string internal_path(std::string const p,
path_target target = DEFAULT);
Now I have the need to add the same argument to ChangeExtension()
which is declared in support/filetools.h. This is because
ChangeExtension() is called either when the path is intended to
go in a .tex file or not. So I need to change the call to
ChangeExtension() in lyx::support::latex_path by adding the enum
argument with value LATEX.
How can I get a correct declaration of ChangeExtension()?
It should be:
std::string const
ChangeExtension(std::string const oldname, std::string const extension
path_target target = DEFAULT);
In C I would simply #include support/os.h within
support/filetools.h, but I don't think this is the correct C++
solution.
Would
extern enum path_target {
DEFAULT,
LATEX
}
in support/filetools.h work?
I'll try it, but as compiling LyX with debugging information
takes forever in the final link stage on windows, I rather
would like to not have it done by trial and error ;-)
--
Enrico
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 05:26:37PM +0200, Enrico Forestieri wrote: Come on, Georg, there are many choices by the configure script that cannot be undone by the user! Think about dvipng which once detected dictates the instant-preview image formats, and if it doesn't work correctly (how already reported and how also ^^^ ^^^ as as ;-) happened to me) no previews are generated. -- Enrico
Re: Testing of my patches under windows.
On Sun, Apr 02, 2006 at 05:57:55PM +0200, Michael Gerz wrote: [...] 5. Aspell [...] 5.4 Edit files [...] ./modules/speller/language.cpp: Isn't this ./modules/speller/default/language.cpp ? -- Enrico
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: Enrico Forestieri a écrit : On Sun, Apr 02, 2006 at 01:11:50PM +0200, Georg Baum wrote: - Implicit format change of .lyx files. I know that there are currently problems in this area due to the mixup, but for the future I would like to have only one representation of file names in .lyx files for a given platform. Indeed. When a .lyx file contains an absolute path, it has different styles depending on whether LyX is a win32 or posix app. This was one of the reasons I wanted to be able to switch the internal representation. I am always able to read a .lyx file produced by a win32 LyX using a cygwin LyX, but it may be not true the other way, as win32 doesn't understand posix. Perhaps it would be better to force a pseudo-win style when outputting file names to .lyx files in order to guarantee interoperability at least on windows. But if the internal format is fixed, we have added complexity. However, now I am almost convinced that this is unavoidable. I am not sure about what you both are talking about but the .lyx file should contains path with forward slashes only independently from the system. This is _very_ important for interoperability between windows user and unix/posix users exchanging lyx files (paths must be relative then). For the same reason, LyX produced latex files _must_ _always_ use path with forward slashes. It always contains paths with forward slashes, but according to the logic currently used, an absolute path may appear in the .lyx file. In the win32 version this is in a C:/xxx path style, whereas in a posix version it is like /c/xxx. Now, a cygwin version has no problem with either of them, but a win32 version doesn't understand the /c/xxx style. -- Enrico
Re: [patch] fix bug 2344 and paths issues on cygwin
On Sun, Apr 02, 2006 at 04:54:44PM +, Angus Leeming wrote: Enrico Forestieri [EMAIL PROTECTED] writes: In C I would simply #include support/os.h within support/filetools.h, but I don't think this is the correct C++ solution. You can't forward declare enums, so your proposed solution is fine for now. Thanks Angus. I'll use it and add a comment justifying the inclusion. -- Enrico
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 07:02:08PM +0200, Abdelrazak Younes wrote: Enrico Forestieri a écrit : On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: [...] It always contains paths with forward slashes, but according to the logic currently used, an absolute path may appear in the .lyx file. In the win32 version this is in a C:/xxx path style, whereas in a posix version it is like /c/xxx. Now, a cygwin version has no problem with either of them, but a win32 version doesn't understand the /c/xxx style. Ok, thanks for the clarification. IMHO C:/xxx is the way to go for both versions then, no need to make special case for cygwin in .lyx and .tex files. But I guess you have already reached that conclusion. IMHO, this should be the same for internal format because non-cygwin compilers don't understand /c/xxx either. No, .lyx and .tex files should be treated differently. I agree that paths going to .lyx files should be in the C:/xxx syntax, but paths for .tex files have to be in either format depending on the TeX engine used. Internal format should be posix in cygwin as it is dictated by boost. -- Enrico
Re: [patch] fix bug 2344 and paths issues on cygwin
On Sun, Apr 02, 2006 at 10:20:35PM +0200, Georg Baum wrote:
Am Sonntag, 2. April 2006 17:57 schrieb Enrico Forestieri:
Well, I am facing a problem related to it now. Please, help this
C++ newbie to solve the following problem.
I had already the need to add an enum argument to internal_path.
Its natural declaration was in support/os.h in the
lyx::support::os namespace:
enum path_target {
DEFAULT,
LATEX
}
std::string internal_path(std::string const p,
path_target target = DEFAULT);
May I ask you why you need it? Is that for conversion of paths that come
from latex?
No, it is for conversion of paths going to .tex files. See below
the reason I need it.
Now I have the need to add the same argument to ChangeExtension()
which is declared in support/filetools.h. This is because
ChangeExtension() is called either when the path is intended to
go in a .tex file or not. So I need to change the call to
ChangeExtension() in lyx::support::latex_path by adding the enum
argument with value LATEX.
I don't see the need for it. Regardless how paths are represented
externally, all internal paths on all platforms have always forward
slashes, so ChangeExtension should just work.
No, it is not because of that. The point is that
lyx::support::latex_path() calls ChangeExtensions, which in turn
calls internal_path(), which would turn the path into posix in
cygwin.
Please, attached find the patch satifying your requests. All
internal paths are in posix style. External and latex paths may
be posix or windows style depending on cygwin_path_fix, exactly
as it was.
I have not introduced any new boolean and substantially left
things as they were. Only, all bugs are now corrected and there
is no mess of internal paths.
I strongly believe that external and latex path styles should be
selected independently. If you think that the user should be able
to subvert the decision of the configure script about latex
paths, I think that another checkbox can be added along the one
already existing. They could be labelled Use cygwin-style paths
in latex files and Use cygwin-style paths for external
programs. If you think that someone can be confused by those
labels, well, I don't know what to say (I really know, but won't
tell ;-))
The possibility of deciding the style of paths used for external
programs is quite user friendly and I think it is a must. After
all cygwin runs on windows.
--
Enrico
Index: src/frontends/qt2/QPrefs.C
===
--- src/frontends/qt2/QPrefs.C (revision 13547)
+++ src/frontends/qt2/QPrefs.C (working copy)
@@ -148,6 +148,11 @@ string const internal_path(QString const
return lyx::support::os::internal_path(fromqstr(input));
}
+string const internal_path_list(QString const input)
+{
+ return lyx::support::os::internal_path_list(fromqstr(input));
+}
+
}
@@ -253,7 +258,7 @@ void QPrefs::apply()
rc.template_path = internal_path(pathsmod-templateDirED-text());
rc.backupdir_path = internal_path(pathsmod-backupDirED-text());
rc.tempdir_path = internal_path(pathsmod-tempDirED-text());
- rc.path_prefix = fromqstr(pathsmod-pathPrefixED-text());
+ rc.path_prefix = internal_path_list(pathsmod-pathPrefixED-text());
// FIXME: should be a checkbox only
rc.lyxpipes = internal_path(pathsmod-lyxserverDirED-text());
@@ -467,6 +472,11 @@ QString const external_path(string const
return toqstr(lyx::support::os::external_path(input));
}
+QString const external_path_list(string const input)
+{
+ return toqstr(lyx::support::os::external_path_list(input));
+}
+
}
@@ -583,7 +593,7 @@ void QPrefs::update_contents()
pathsmod-templateDirED-setText(external_path(rc.template_path));
pathsmod-backupDirED-setText(external_path(rc.backupdir_path));
pathsmod-tempDirED-setText(external_path(rc.tempdir_path));
- pathsmod-pathPrefixED-setText(toqstr(rc.path_prefix));
+ pathsmod-pathPrefixED-setText(external_path_list(rc.path_prefix));
// FIXME: should be a checkbox only
pathsmod-lyxserverDirED-setText(external_path(rc.lyxpipes));
Index: src/frontends/qt2/ChangeLog
===
--- src/frontends/qt2/ChangeLog (revision 13547)
+++ src/frontends/qt2/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2006-04-03 Enrico Forestieri [EMAIL PROTECTED]
+
+ * QPrefs.C: Handle the PATH prefix style according to the
+ user-prefs style.
+
2006-03-10 Martin Vermeer [EMAIL PROTECTED]
* QChanges.C: fix bug 2212: First change is skipped in
Index: src/support/os_unix.C
===
--- src/support/os_unix.C (revision 13547)
+++ src/support/os_unix.C (working copy)
@@ -57,7 +57,19 @@ string external_path(string const p)
}
-string
