date:20070113

On Fri, Jan 12, 2007 at 11:07:55PM +0100, Abdelrazak Younes wrote:

 Abdelrazak Younes wrote:
  Could someone please test this under Linux?
  
  Enrico, if you could test it under Cygwin as well, that would be great.
 
 Take this patch if you want to see some debug outputs. It's working 
 perfectly here and it's really a _huge_ performance boost under Windows!

I tried it but honestly cannot see a difference with or without the
patch. I loaded a big document went in the middle and tried breaking
a paragraph. A lot of debug messages about cached things are spitted
out, but I cannot notice any difference in speed, which is already
good: a paragraph is broken and rejoined instantly, in practice.

Maybe this is language dependent or I was performing the wrong test.

-- 
Enrico

Re: [PATCH] caching translated string


Angus Leeming wrote:

Abdelrazak Younes [EMAIL PROTECTED] writes:

Abdelrazak Younes wrote:

Could someone please test this under Linux?

Enrico, if you could test it under Cygwin as well, that would be great.
Take this patch if you want to see some debug outputs. It's working 
perfectly here and it's really a _huge_ performance boost under Windows!


Doesn't your cache need to take account of the language?


The Message class is designed for a unique language. If a new language 
is asked, a new instance of the class will be created (see 
updateDocLang()) and the old one ditched (via the scoped_ptr). In 
effect, this means that the current cache will be erased. In practice, 
this doesn't matter much as the cache will be filled in again at the 
next paragraph break if the langauge is changed inside a section. This 
does not happens much and I reckon that the delay is OK if there is a 
language change. If not, then we can cache Message objects instead of 
ditching them upon language change.


That's what gettext 
is doing internally...


The problem is that we can't use this internal cache because.

Ie, the key shouldn't be just a string but rather 
pairstring, language.


If there is a need to do that my idea would be to maintain a map of 
language, Message at the Buffer level. See above.


Abdel.

Re: [PATCH] caching translated string


Enrico Forestieri wrote:

On Fri, Jan 12, 2007 at 11:07:55PM +0100, Abdelrazak Younes wrote:


Abdelrazak Younes wrote:

Could someone please test this under Linux?

Enrico, if you could test it under Cygwin as well, that would be great.
Take this patch if you want to see some debug outputs. It's working 
perfectly here and it's really a _huge_ performance boost under Windows!


I tried it but honestly cannot see a difference with or without the
patch. I loaded a big document went in the middle and tried breaking
a paragraph. A lot of debug messages about cached things are spitted
out, but I cannot notice any difference in speed, which is already
good: a paragraph is broken and rejoined instantly, in practice.


I don't expect any performance improvement under Linux and Cygwin. I 
think the internal gettext compiled with MSVC is at fault here. I tried 
with the external GnuWin32 gettext version and I see the same slowness.
I think the cygwin version (as well as the Linux version) are 
effectively using its internal cache.




Maybe this is language dependent or I was performing the wrong test.


Yes, I wanted you to check that the translation process is still working 
correctly. Especially, at the section level. Could you set create a 
document with the report class and set a different language of one 
'Chapter' section. If all goes well, the 'Chapter' part will be translated.


Abdel.

Re: [PATCH] caching translated string


Abdelrazak Younes wrote:


The problem is that we can't use this internal cache because.


because... it does not work with our way of setting the language at each 
gettext call.


Abdel.

Re: [patch] move OS dependent code to proper place

On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:

 Enrico Forestieri wrote:
 
  as a parameter introducer. To tell you the truth, the cygwin version
  of lyx that I make available for download is patched such that through
  an env variable it is possible to use either posix or windows style
  paths.
 
 Making a binary created from patched sources available is very bad IMO.

Thanks for your opinion. So, you are saying that if I find that a patch
does something useful I should not share it with others.

 Either this patch is for your personal convenience, then you should not
 make the binary available, or it is useful in general, then the patch
 should be included in the official version.

I find this to be a somewhat hypocritical attitude, as I tried to have
accepted a similar patch but it was rejected. But maybe when you say
useful in general you mean that it must be useful for all platforms
an not for a particular one (which is not yours).

 I don't know if the README in the package talks about the patch and where to
 get it, but if it does not then you are even breaking the GPL.

Now you are going a bit above the lines (even for a Friday).
Please, find attached the patch in question. As you can see it does not
introduce changed behaviour or anything else. Perhaps I forgot to put it
on the wiki, and you could have suggested that I should do it, instead
of going through a hideous legalese. But I take it as a Friday statement.

-- 
Enrico
Index: src/frontends/qt2/qfont_loader.C
===
--- src/frontends/qt2/qfont_loader.C(revision 15112)
+++ src/frontends/qt2/qfont_loader.C(working copy)
@@ -102,7 +102,11 @@ void FontLoader::initFontPath()
for (int i = 0 ; i  num_fonts_truetype ; ++i) {
string const font_current = 
AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
+#if defined(__CYGWIN__) || defined(__CYGWIN32__)
+   AddFontResource(os::windows_path(font_current).c_str());
+#else
AddFontResource(os::external_path(font_current).c_str());
+#endif
}
 #endif
 }
@@ -115,7 +119,11 @@ FontLoader::~FontLoader() {
for(int i = 0 ; i  num_fonts_truetype ; ++i) {
string const font_current = 
AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
+#if defined(__CYGWIN__) || defined(__CYGWIN32__)
+   RemoveFontResource(os::windows_path(font_current).c_str());
+#else
RemoveFontResource(os::external_path(font_current).c_str());
+#endif
}
 #endif
 }
Index: src/frontends/qt2/FileDialog.C
===
--- src/frontends/qt2/FileDialog.C  (revision 15112)
+++ src/frontends/qt2/FileDialog.C  (working copy)
@@ -20,6 +20,7 @@
 #include gettext.h
 
 #include support/filefilterlist.h
+#include support/os.h
 
 /** when this is defined, the code will use
  * QFileDialog::getOpenFileName and friends to create filedialogs.
@@ -30,7 +31,7 @@
  *
  * Therefore there is a tradeoff in enabling or disabling this (JMarc)
  */
-#ifdef Q_WS_MACX
+#if defined(Q_WS_MACX) || defined(Q_CYGWIN_WIN)
 #define USE_NATIVE_FILEDIALOG 1
 #endif
 
@@ -42,6 +43,8 @@ using lyx::support::MakeAbsPath;
 
 using lyx::support::FileFilterList;
 
+using lyx::support::os::internal_path;
+
 using std::endl;
 using std::string;
 
@@ -80,11 +83,11 @@ FileDialog::Result const FileDialog::sav
 
 #ifdef USE_NATIVE_FILEDIALOG
string const startsWith = MakeAbsPath(suggested, path);
-   result.second = fromqstr(
+   result.second = internal_path(fromqstr(
QFileDialog::getSaveFileName(toqstr(startsWith),
 toqstr(filters.as_string()),
 qApp-focusWidget() ? 
qApp-focusWidget() : qApp-mainWidget(),
-title_.c_str()));
+title_.c_str(;
 #else
LyXFileDialog dlg(path, filters, title_, private_-b1, private_-b2);
dlg.setMode(QFileDialog::AnyFile);
@@ -96,7 +99,7 @@ FileDialog::Result const FileDialog::sav
int res = dlg.exec();
lyxerr[Debug::GUI]  result   res  endl;
if (res == QDialog::Accepted)
-   result.second = fromqstr(dlg.selectedFile());
+   result.second = internal_path(fromqstr(dlg.selectedFile()));
dlg.hide();
 #endif
return result;
@@ -115,11 +118,11 @@ FileDialog::Result const FileDialog::ope
 
 #ifdef USE_NATIVE_FILEDIALOG
string const startsWith = MakeAbsPath(suggested, path);
-   result.second = fromqstr(
+   result.second = internal_path(fromqstr(
QFileDialog::getOpenFileName(toqstr(startsWith),
 toqstr(filters.as_string()),
 qApp-focusWidget() ? 
qApp-focusWidget()

Re: [patch] move OS dependent code to proper place

On Fri, Jan 12, 2007 at 05:50:10PM +0100, Georg Baum wrote:

 Enrico Forestieri wrote:
 
  Believe me, external_path could be completely ditched.
 
 Please stop talking of external_path. Yesterday you wrote that you don't
 want to discuss that anymore, and I don't want that either. I gave up
 trying to understand how it behaves now a long time ago, and I don't care
 anymore about it. The only thing I care about is that the result of an
 external_path call is only used for interfacing to other programs or
 display purposes (although we have makeDisplayPath for the latter that
 should take care of any needed transformations), and never for further use
 inside of LyX.

Ok. I'll take into account your lack of sense of humour in the future.

-- 
Enrico

Re: [patch] move OS dependent code to proper place


Enrico Forestieri wrote:

On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:


Enrico Forestieri wrote:


as a parameter introducer. To tell you the truth, the cygwin version
of lyx that I make available for download is patched such that through
an env variable it is possible to use either posix or windows style
paths.

Making a binary created from patched sources available is very bad IMO.


Thanks for your opinion. So, you are saying that if I find that a patch
does something useful I should not share it with others.


Yes ;-)




Either this patch is for your personal convenience, then you should not
make the binary available, or it is useful in general, then the patch
should be included in the official version.


I find this to be a somewhat hypocritical attitude, as I tried to have
accepted a similar patch but it was rejected.


But now you have more power to push it in :-) well, at least on trunk.



But maybe when you say
useful in general you mean that it must be useful for all platforms
an not for a particular one (which is not yours).


I don't know if the README in the package talks about the patch and where to
get it, but if it does not then you are even breaking the GPL.


Now you are going a bit above the lines (even for a Friday).
Please, find attached the patch in question. As you can see it does not
introduce changed behaviour or anything else. Perhaps I forgot to put it
on the wiki, and you could have suggested that I should do it, instead
of going through a hideous legalese. But I take it as a Friday statement.


Cool it down Enrico, this is just Georg way of stating fact in a cold 
manner...





Index: src/frontends/qt2/qfont_loader.C


Ah... this is for 1.4 then... Do we need sth similar for 1.5 or is it 
already in? I guess part of it (the font part) is already in.


Abdel.

Re: [PATCH] caching translated string

On Sat, Jan 13, 2007 at 09:39:44AM +0100, Abdelrazak Younes wrote:

 Yes, I wanted you to check that the translation process is still working 
 correctly. Especially, at the section level. Could you set create a 
 document with the report class and set a different language of one 
 'Chapter' section. If all goes well, the 'Chapter' part will be translated.

Yes, that is working. Otherwise I would have reported it.

-- 
Enrico

Re: Fix bug 3092.


Bo Peng wrote:

What I meant is something like follows. The patch does not work
correctly yet, but shows my point.

1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.


This part is good. The BufferList should not care about quitting and 
asking for user interaction.




2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE


Good in theory but you have to make sure that it works equally well on 
the three supported platform.




3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one


Be careful here, we should do that only if it is the last window.



4. closeEvent triggers LFUN_LYX_QUIT.


Only if it is the last window.



That is to say, no one takes the shortcut quitWriteAll. lyx-close
experts (Peter, Enrico, Abdel), what do you think? Anything seriously
wrong here?


See above. More comments below:


Index: src/bufferlist.C
===
--- src/bufferlist.C(revision 16658)
+++ src/bufferlist.C(working copy)
@@ -96,76 +96,6 @@
}


-bool BufferList::quitWriteBuffer(Buffer * buf)
-{
-BOOST_ASSERT(buf);
-
-docstring file;
-if (buf-isUnnamed())
-file = from_utf8(onlyFilename(buf-fileName()));
-else
-file = makeDisplayPath(buf-fileName(), 30);
-
-docstring const text =
-bformat(_(The document %1$s has unsaved changes.\n\n
-   Do you want to save the document or discard the 
changes?),

-   file);
-int const ret = Alert::prompt(_(Save changed document?),
-text, 0, 2, _(Save), _(Discard), _(Cancel));


I agree this has nothing to do here but we have to ask this question to 
the user nevertheless, don't we? So where is this part of the code 
transferred?



[...]


-bool BufferList::quitWriteAll()
-{
-BufferStorage::iterator it = bstore.begin();
-BufferStorage::iterator end = bstore.end();
-for (; it != end; ++it) {
-if ((*it)-isClean())
-continue;
-
-if (!quitWriteBuffer(*it))
-return false;
-}
-// now, all buffers have been written sucessfully
-// save file names to .lyx/session
-it = bstore.begin();
-for (; it != end; ++it) {
-// if master/slave are both open, do not save slave since it
-// will be automatically loaded when the master is loaded
-if ((*it)-getMasterBuffer() == (*it))


Same question here. Where is that transferred? I am probably missing 
something.



Index: src/lyxfunc.C
===
--- src/lyxfunc.C(revision 16658)
+++ src/lyxfunc.C(working copy)
@@ -1074,7 +1074,8 @@
case LFUN_LYX_QUIT:
// quitting is triggered by the gui code
// (leaving the event loop).
-if (theBufferList().quitWriteAll())
+dispatch(FuncRequest(LFUN_WINDOW_CLOSE));


Here you have to call LFUN_WINDOW_CLOSE for every window. The list is 
given to you by the Gui class.



+if (theBufferList().empty())
theApp()-gui().closeAllViews();


This Gui::closeAllViews() is redundant here if you have already closed 
all the windows (view == window).



break;

@@ -1703,13 +1704,19 @@
case LFUN_WINDOW_CLOSE:
BOOST_ASSERT(lyx_view_);
BOOST_ASSERT(theApp());
-// update bookmark pit of the current buffer before window 
close
-for (size_t i = 0; i  
LyX::ref().session().bookmarks().size(); ++i)

-gotoBookmark(i+1, false, false);
-// ask the user for saving changes or cancel quit
-if (!theBufferList().quitWriteAll())
-break;
-lyx_view_-close();
+// close buffer one by one


Be careful here, only if it is the last window.


+while (true) {
+string const file = lyx_view_-buffer()-fileName();
+dispatch(FuncRequest(LFUN_BUFFER_CLOSE));
+// all files closed
+if (theBufferList().empty()) {
+lyx_view_-close();
+break;
+// buffer close failed
+if (file == lyx_view_-buffer()-fileName())
+break;
+}
+}
return;

case LFUN_BOOKMARK_GOTO:
Index: src/frontends/qt4/GuiView.C
===
--- src/frontends/qt4/GuiView.C(revision 16658)
+++ src/frontends/qt4/GuiView.C(working copy)
@@ -237,7 +237,8 @@
// we may have been called through the close window button
// which bypasses the LFUN machinery.
if (!quitting_by_menu_) {
-if (!theBufferList().quitWriteAll()) {
+dispatch(FuncRequest(LFUN_LYX_QUIT));


Good in theory but you have to make sure that it works equally well on 
the three supported platform.



+if (!theBufferList().empty()) {


So this means that the user clicked [Cancel] here... But I

Re: [PATCH] caching translated string


Enrico Forestieri wrote:

On Sat, Jan 13, 2007 at 09:39:44AM +0100, Abdelrazak Younes wrote:

Yes, I wanted you to check that the translation process is still working 
correctly. Especially, at the section level. Could you set create a 
document with the report class and set a different language of one 
'Chapter' section. If all goes well, the 'Chapter' part will be translated.


Yes, that is working. Otherwise I would have reported it.


Very good then, I'll commit!

Abdel.

Re: Fix bug 3092.

Bo Peng wrote:
 What I meant is something like follows. The patch does not work
 correctly yet, but shows my point.
 
 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
 
 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
 
 3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
 
 4. closeEvent triggers LFUN_LYX_QUIT.
 
 That is to say, no one takes the shortcut quitWriteAll. lyx-close
 experts (Peter, Enrico, Abdel), what do you think? Anything seriously
 wrong here?

I think, the most important thing when quitting is that there
is one place where all prepare-to-quit code is located.

Does you patch support this?
How many ways of quitting exit?
1. menu exit - LFUN_LYX_QUIT
2. last window closed - LFUN_WINDOW_CLOSE - LFUN_LYX_QUIT

two only? have I forgotten one?

 
 Bo
 
 
 
 Index: src/bufferlist.C
 ===
 --- src/bufferlist.C(revision 16658)
 +++ src/bufferlist.C(working copy)
 @@ -96,76 +96,6 @@
 }
 
 
 -bool BufferList::quitWriteBuffer(Buffer * buf)
 -{
 -BOOST_ASSERT(buf);
 -
 -docstring file;
 -if (buf-isUnnamed())
 -file = from_utf8(onlyFilename(buf-fileName()));
 -else
 -file = makeDisplayPath(buf-fileName(), 30);
 -
 -docstring const text =
 -bformat(_(The document %1$s has unsaved changes.\n\n
 -   Do you want to save the document or discard the
 changes?),
 -   file);
 -int const ret = Alert::prompt(_(Save changed document?),
 -text, 0, 2, _(Save), _(Discard), _(Cancel));
 -
 -if (ret == 0) {
 -// FIXME: WriteAs can be asynch !
 -// but not right now...maybe we should remove that
 -
 -bool succeeded;
 -
 -if (buf-isUnnamed())
 -succeeded = writeAs(buf);
 -else
 -succeeded = menuWrite(buf);
 -
 -if (!succeeded)
 -return false;
 -} else if (ret == 1) {
 -// if we crash after this we could
 -// have no autosave file but I guess
 -// this is really inprobable (Jug)
 -if (buf-isUnnamed())
 -removeAutosaveFile(buf-fileName());
 -
 -} else {
 -return false;
 -}
 -
 -return true;
 -}
 -
 -
 -bool BufferList::quitWriteAll()
 -{
 -BufferStorage::iterator it = bstore.begin();
 -BufferStorage::iterator end = bstore.end();
 -for (; it != end; ++it) {
 -if ((*it)-isClean())
 -continue;
 -
 -if (!quitWriteBuffer(*it))
 -return false;
 -}
 -// now, all buffers have been written sucessfully
 -// save file names to .lyx/session
 -it = bstore.begin();
 -for (; it != end; ++it) {
 -// if master/slave are both open, do not save slave since it
 -// will be automatically loaded when the master is loaded
 -if ((*it)-getMasterBuffer() == (*it))
 -   
 LyX::ref().session().lastOpened().add(FileName((*it)-fileName()));
 -}
 -
 -return true;
 -}
 -
 -
 void BufferList::release(Buffer * buf)
 {
 BOOST_ASSERT(buf);
 Index: src/bufferlist.h
 ===
 --- src/bufferlist.h(revision 16658)
 +++ src/bufferlist.h(working copy)
 @@ -42,9 +42,6 @@
 iterator end();
 const_iterator end() const;
 
 -/// write all buffers, asking the user, returns false if cancelled
 -bool quitWriteAll();
 -
 /// create a new buffer
 Buffer * newBuffer(std::string const  s, bool ronly = false);
 
 @@ -104,8 +101,6 @@
 void setCurrentAuthor(docstring const  name, docstring const  email);
 
 private:
 -/// ask to save a buffer on quit, returns false if should cancel
 -bool quitWriteBuffer(Buffer * buf);
 
 typedef std::vectorBuffer * BufferStorage;
 
 Index: src/lyxfunc.C
 ===
 --- src/lyxfunc.C(revision 16658)
 +++ src/lyxfunc.C(working copy)
 @@ -1074,7 +1074,8 @@
 case LFUN_LYX_QUIT:
 // quitting is triggered by the gui code
 // (leaving the event loop).
 -if (theBufferList().quitWriteAll())
 +dispatch(FuncRequest(LFUN_WINDOW_CLOSE));
 +if (theBufferList().empty())
 theApp()-gui().closeAllViews();
 break;
 
 @@ -1703,13 +1704,19 @@
 case LFUN_WINDOW_CLOSE:
 BOOST_ASSERT(lyx_view_);
 BOOST_ASSERT(theApp());
 -// update bookmark pit of the current buffer before window
 close
 -for (size_t i = 0; i 
 LyX::ref().session().bookmarks().size(); ++i)
 -gotoBookmark(i+1, false, false);
 -// ask the user for saving changes or cancel quit
 -if (!theBufferList().quitWriteAll())
 -break;
 -lyx_view_-close();
 +// close buffer one by one
 +while (true) {
 +string const file =

Re: [patch] move OS dependent code to proper place

On Sat, Jan 13, 2007 at 10:03:39AM +0100, Abdelrazak Younes wrote:

 Enrico Forestieri wrote:
  On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:
  
  Enrico Forestieri wrote:
 
  as a parameter introducer. To tell you the truth, the cygwin version
  of lyx that I make available for download is patched such that through
  an env variable it is possible to use either posix or windows style
  paths.
  Making a binary created from patched sources available is very bad IMO.
  
  Thanks for your opinion. So, you are saying that if I find that a patch
  does something useful I should not share it with others.
 
 Yes ;-)

;-)

  Either this patch is for your personal convenience, then you should not
  make the binary available, or it is useful in general, then the patch
  should be included in the official version.
  
  I find this to be a somewhat hypocritical attitude, as I tried to have
  accepted a similar patch but it was rejected.
 
 But now you have more power to push it in :-) well, at least on trunk.

But i don't want to push anything in without consensus.

  But maybe when you say
  useful in general you mean that it must be useful for all platforms
  an not for a particular one (which is not yours).
  
  I don't know if the README in the package talks about the patch and where 
  to
  get it, but if it does not then you are even breaking the GPL.
  
  Now you are going a bit above the lines (even for a Friday).
  Please, find attached the patch in question. As you can see it does not
  introduce changed behaviour or anything else. Perhaps I forgot to put it
  on the wiki, and you could have suggested that I should do it, instead
  of going through a hideous legalese. But I take it as a Friday statement.
 
 Cool it down Enrico, this is just Georg way of stating fact in a cold 
 manner...

Yes, I know. We are using different locales ;-)

  
  
  Index: src/frontends/qt2/qfont_loader.C
 
 Ah... this is for 1.4 then... Do we need sth similar for 1.5 or is it 
 already in? I guess part of it (the font part) is already in.

No, we don't need it. I don't even need lyx ;-)

-- 
Enrico

Re: Fix bug 3092.


Peter Kümmel wrote:

Bo Peng wrote:

What I meant is something like follows. The patch does not work
correctly yet, but shows my point.

1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.

2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE

3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one

4. closeEvent triggers LFUN_LYX_QUIT.

That is to say, no one takes the shortcut quitWriteAll. lyx-close
experts (Peter, Enrico, Abdel), what do you think? Anything seriously
wrong here?


I think, the most important thing when quitting is that there
is one place where all prepare-to-quit code is located.

Does you patch support this?
How many ways of quitting exit?
1. menu exit - LFUN_LYX_QUIT
2. last window closed - LFUN_WINDOW_CLOSE - LFUN_LYX_QUIT

two only? have I forgotten one?


You already forgot you Mac experience? It's amazing to see how human 
beings manage to erase bad experiences from their memories :-)


IIRC there's another way on Mac.

Abdel.

Re: [PATCH] caching translated string


lyx crashes here with your patch:

msvcr80d.dll!10202b13() 
 	[Frames below may be incorrect and/or missing, no symbols loaded 
for msvcr80d.dll]	

shlwapi.dll!77f643d0()  
msvcr80d.dll!1021866b() 
shlwapi.dll!77f643dd()  
kernel32.dll!7c812a5b() 
msvcr80d.dll!10271754() 
msvcr80d.dll!102509a1() 
msvcr80d.dll!102509e4() 
msvcr80d.dll!1024ef7b() 
msvcr80d.dll!102509a1() 
msvcr80d.dll!102509e4() 
msvcr80d.dll!1024ef86() 
msvcr80d.dll!1024ef7b() 
msvcr80d.dll!102a0cd8() 
msvcr80d.dll!10220b1c() 
msvcr80d.dll!10203ca4() 
msvcr80d.dll!1021e039() 
msvcr80d.dll!102a0cd8() 
msvcr80d.dll!102a0ccd() 
msvcp80d.dll!10496402() 
msvcp80d.dll!10496078() 
msvcp80d.dll!104963e0() 
	lyx-qt4.exe!std::_Iterator_base::operator=(const std::_Iterator_base 
 _Right={...})  Line 145 + 0x27 bytes	C++

msvcp80d.dll!104963e0() 
msvcp80d.dll!104fe1fd() 
msvcp80d.dll!104f9a52() 
msvcp80d.dll!10491e82() 
msvcp80d.dll!104fe20d() 
msvcp80d.dll!104f9a52() 
msvcr80d.dll!10203ca4() 
ntdll.dll!7c90e027()
ntdll.dll!7c91392e()
msvcr80d.dll!102048e6() 
msvcr80d.dll!10203ca4() 
msvcr80d.dll!10213223() 
msvcr80d.dll!1021321a() 
lyx-qt4.exe!lyx::support::abort()  Line 25 + 0x8 bytes  C++
lyx-qt4.exe!error_handler(int err_sig=11)  Line 713 C++
msvcr80d.dll!10212fc0() 
ntdll.dll!7c911538()
ntdll.dll!7c910833()
lyx-qt4.exe!__tmainCRTStartup()  Line 603 + 0x17 bytes  C
 	lyx-qt4.exe!_except_handler4(_EXCEPTION_RECORD * 
ExceptionRecord=0x01a8e040, _EXCEPTION_REGISTRATION_RECORD * 
EstablisherFrame=0x01a8ffa8, _CONTEXT * ContextRecord=0x01a8e05c, void * 
DispatcherContext=0x01a8e014)  + 0x22 bytes	C

ntdll.dll!7c9037bf()
ntdll.dll!7c90378b()
ntdll.dll!7c937860()
ntdll.dll!7c90d4ea()
ntdll.dll!7c9116ff()
ntdll.dll!7c92812f()
ntdll.dll!7c9106eb()
ntdll.dll!7c90eafa()
ntdll.dll!7c9106ab()
ntdll.dll!7c9106eb()
ntdll.dll!7c9106ab()
ntdll.dll!7c9106eb()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
ntdll.dll!7c91056d()
ntdll.dll!7c9134d6()
ntdll.dll!7c914d8f()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
shlwapi.dll!77f643d0()  
shlwapi.dll!77f643dd()  
 	lyx-qt4.exe!std::char_traitsunsigned long::_Copy_s(unsigned long * 
_First1=0x020e0040, unsigned int _Dest_size=27848859, const unsigned 
long * _First2=0x, unsigned int _Count=27848856)  Line 215 + 
0xd bytes	C++
 	lyx-qt4.exe!std::_Traits_helper::copy_sstd::char_traitsunsigned 
long (unsigned long * _First1=0x020e0040, unsigned int _Size=27848859, 
const unsigned long * _First2=0x, unsigned int _Count=27848856, 
std::_Secure_char_traits_tag __formal={...})  Line 590 + 0x15 bytes	C++
 	lyx-qt4.exe!std::_Traits_helper::copy_sstd::char_traitsunsigned 
long (unsigned long * _First1=0x020e0040, unsigned int _Size=27848859, 
const unsigned long * _First2=0x, unsigned int _Count=27848856) 
 Line 582 + 0x21 bytes	C++
 	lyx-qt4.exe!std::basic_stringunsigned long,std::char_traitsunsigned 
long,std::allocatorunsigned long ::assign(const 
std::basic_stringunsigned long,std::char_traitsunsigned 
long,std::allocatorunsigned long   _Right={...}, unsigned int 
_Roff=0, unsigned int _Count=4294967295)  Line 1011 + 0x28 bytes	C++
 	lyx-qt4.exe!std::basic_stringunsigned long,std::char_traitsunsigned 
long,std::allocatorunsigned long ::basic_stringunsigned 
long,std::char_traitsunsigned long,std::allocatorunsigned long 
(const std::basic_stringunsigned long,std::char_traitsunsigned 
long,std::allocatorunsigned long   _Right={...})  Line 597	C++
 	lyx-qt4.exe!lyx::_(const 
std::basic_stringchar,std::char_traitschar,std::allocatorchar   
str=File|F)  Line 46 + 0x19 bytes	C++
 	lyx-qt4.exe!lyx::translateIfPossible(const std::basic_stringunsigned 
long,std::char_traitsunsigned long,std::allocatorunsigned long   
name={...})  Line 78 + 0x2d bytes	C++
 	lyx-qt4.exe!lyx::Menu::read(lyx::LyXLex  lex={...})  Line 352 + 
0x3b bytes	C++

lyx-qt4.exe!lyx::MenuBackend::read(lyx::LyXLex  lex={...})  Line 938   
C++
 	lyx-qt4.exe!lyx::LyX::readUIFile(const 
std::basic_stringchar,std::char_traitschar,std::allocatorchar   
name=stdmenus.inc)  Line 1124	C++
 	lyx-qt4.exe!lyx::LyX::readUIFile(const

Re: par breaking


Edwin Leuven wrote:
i've noticed that breaking a paragraph is much quicker than unbreaking 
it (cursor at beginning of par and then backspace)


i think that this has always been the case, but i was wondering whether 
there is something that can be done about it? (i guess i am looking at 
you abdel ;-)


This is fixed now!

Abdel.

Author: younes
Date: Sat Jan 13 10:31:47 2007
New Revision: 16662

URL: http://www.lyx.org/trac/changeset/16662
Log:
Messages:
- cache_: new cache for gettext translated string.

Modified:
lyx-devel/trunk/src/messages.C
lyx-devel/trunk/src/messages.h

Modified: lyx-devel/trunk/src/messages.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/messages.C?rev=16662
==
--- lyx-devel/trunk/src/messages.C (original)
+++ lyx-devel/trunk/src/messages.C Sat Jan 13 10:31:47 2007
@@ -21,16 +21,16 @@
 #include boost/regex.hpp

 #include cerrno
-
+#include map
+
+using std::endl;
+using std::string;

 namespace lyx {

 using support::package;
 using support::getEnv;
 using support::setEnv;
-
-using std::string;
-using std::endl;


 static boost::regex const reg(^([^\\[]*)\\[\\[[^\\]]*\\]\\]$);
@@ -114,10 +114,17 @@

~Pimpl() {}

-   docstring const get(string const  m) const
-   {
+   docstring const  get(string const  m) const
+   {
+   static docstring empty_string;
if (m.empty())
-   return from_ascii(m);
+   return empty_string;
+
+   // Look for the translated string in the cache.
+   CacheType::iterator it = cache_.find(m);
+   if (it != cache_.end())
+   return it-second;
+   // The string was not found, use gettext to generate it:

// In this order, see support/filetools.C:
string lang = getEnv(LC_ALL);
@@ -206,11 +213,18 @@
setlocale(LC_MESSAGES, lang.c_str());
 #endif
setlocale(LC_CTYPE, oldCTYPE.c_str());
-   return translated;
+
+   it = cache_.insert(std::make_pair(m, translated)).first;
+   return it-second;
}
 private:
///
string lang_;
+   typedef std::mapstring, docstring CacheType;
+   /// Internal cache for gettext translated strings.
+   /// This is needed for performance reason within \c updateLabels()
+   /// under Windows.
+   mutable CacheType cache_;
 };
 #endif

@@ -250,7 +264,7 @@
 {}


-docstring const Messages::get(string const  msg) const
+docstring const  Messages::get(string const  msg) const
 {
return pimpl_-get(msg);
 }

Modified: lyx-devel/trunk/src/messages.h
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/messages.h?rev=16662
==
--- lyx-devel/trunk/src/messages.h (original)
+++ lyx-devel/trunk/src/messages.h Sat Jan 13 10:31:47 2007
@@ -29,7 +29,7 @@
///
~Messages();
///
-   docstring const get(std::string const  msg) const;
+   docstring const  get(std::string const  msg) const;
 private:
class Pimpl;
boost::scoped_ptrPimpl pimpl_;

Re: Fix bug 3092.

Abdelrazak Younes wrote:
 Peter Kümmel wrote:
 Bo Peng wrote:
 What I meant is something like follows. The patch does not work
 correctly yet, but shows my point.

 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.

 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE

 3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one

 4. closeEvent triggers LFUN_LYX_QUIT.

 That is to say, no one takes the shortcut quitWriteAll. lyx-close
 experts (Peter, Enrico, Abdel), what do you think? Anything seriously
 wrong here?

 I think, the most important thing when quitting is that there
 is one place where all prepare-to-quit code is located.

 Does you patch support this?
 How many ways of quitting exit?
 1. menu exit - LFUN_LYX_QUIT
 2. last window closed - LFUN_WINDOW_CLOSE - LFUN_LYX_QUIT

 two only? have I forgotten one?
 
 You already forgot you Mac experience? It's amazing to see how human
 beings manage to erase bad experiences from their memories :-)

NO, NO, I haven't forgotten it ;)

The problem on the mac was that there is a auto generated
menu entry which doesn't triggers LFUN_LYX_QUIT, so it is item 1.

 
 IIRC there's another way on Mac.

Isn't this fixed now?

 
 Abdel.
 


Peter

Re: [PATCH] caching translated string


Edwin Leuven wrote:

lyx crashes here with your patch:


[...]
std::basic_stringchar,std::char_traitschar,std::allocatorchar   
str=File|F)  Line 46 + 0x19 bytesC++
 lyx-qt4.exe!lyx::translateIfPossible(const 


This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?

messages.h

~Messages();
///
-   docstring const  get(std::string const  msg) const;
+   docstring const get(std::string const  msg) const;

end of messages.C:

-docstring const  Messages::get(string const  msg) const
+docstring const Messages::get(string const  msg) const

Abdel.

Re: [PATCH] caching translated string


Abdelrazak Younes wrote:
This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?


yes, this gets rid of the crash...

Re: [PATCH] caching translated string


Edwin Leuven wrote:

Abdelrazak Younes wrote:
This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?


yes, this gets rid of the crash...


I cannot reproduce the crash, this is really weird. Could you revert the 
change and compile again. Maybe something went wrong when you compiled 
the first time...


Abdel.

Re: [PATCH] caching translated string


i compiled clean from scratch. have to run now...

Abdelrazak Younes wrote:

Edwin Leuven wrote:

Abdelrazak Younes wrote:
This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?


yes, this gets rid of the crash...


I cannot reproduce the crash, this is really weird. Could you revert the 
change and compile again. Maybe something went wrong when you compiled 
the first time...


Abdel.

Re: [PATCH] caching translated string


Edwin Leuven wrote:

i compiled clean from scratch. have to run now...


OK. I have my LyxLex cleanup on my local tree so this is maybe 
interfering at this point. But this is still weird.


Abdel.

Re: [patch] Re: one bug for the Qt/dialog people

[EMAIL PROTECTED] wrote:
  The patch works also perfectly in LyX 1.5; please apply it to trunk and
  branch.

 Yes, go ahead.

Thanks. Done.

Jürgen

Re: [PATCH] caching translated string


Abdelrazak Younes wrote:

Edwin Leuven wrote:

i compiled clean from scratch. have to run now...


OK. I have my LyxLex cleanup on my local tree so this is maybe 
interfering at this point. But this is still weird.


I cannot reproduce the crash with a clean tree either.

Abdel.

Re: [patch] move OS dependent code to proper place

Am Samstag, 13. Januar 2007 09:58 schrieb Enrico Forestieri:
 On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:
 
  Enrico Forestieri wrote:
  
   as a parameter introducer. To tell you the truth, the cygwin version
   of lyx that I make available for download is patched such that 
through
   an env variable it is possible to use either posix or windows style
   paths.
  
  Making a binary created from patched sources available is very bad IMO.
 
 Thanks for your opinion. So, you are saying that if I find that a patch
 does something useful I should not share it with others.

I admit that my wording above was not really what I meant. Maybe I should 
have taken some more time to write that message.
I have no problem at all with binaries from patched sources as long as it 
is clearly stated that the sources are patched, and where interested 
people can get the patch. What I don't like at all is making patched 
versions available without clearly stating that it is a patched version, 
because IMO users have a right to know what they use. This does not mean 
that patched versions are not useful, it is only a labelling issue. When 
Uwe distributed installers from patched sources labelled as LyX 1.4.0 
(IIRC) I wrote something similar.
AFAIK we are talking about 
ftp://ftp.lyx.org/pub/lyx/bin/1.4.3/lyx-1.4.3-cygwin.tar.gz. If not, 
please correct me. That file sits on the official ftp server together with 
binaries from unpatched sources in one directory, and the file 
README.cygwin in that directory only explains that this package is 
unofficial, but not that it is patched. Therefore it is very difficult for 
users to find out that they are not running a vanilla version.

  Either this patch is for your personal convenience, then you should not
  make the binary available, or it is useful in general, then the patch
  should be included in the official version.
 
 I find this to be a somewhat hypocritical attitude, as I tried to have
 accepted a similar patch but it was rejected. But maybe when you say
 useful in general you mean that it must be useful for all platforms
 an not for a particular one (which is not yours).

No I don't mean that. I mean useful for cygwin users in general. IIRC I 
was the only one besides you who had opinions on this patch. I stated two 
or three times already that I don't understand anymore what external_path 
currently does and that I don't care anymore whether it exists or not.
Therefore this statement was not hypocritical at all, but meant seriously. 
IIRC Lars had some concerns about some #ifdef __CYGWIN__ in the code. I 
share these concerns and would not like to have them at all in the main 
code, but I am sure that this could be avoided by putting this stuff in 
the os namespace and using a well defined interface (with possible noop 
functions on other platforms).

  I don't know if the README in the package talks about the patch and 
where to
  get it, but if it does not then you are even breaking the GPL.
 
 Now you are going a bit above the lines (even for a Friday).
 Please, find attached the patch in question. As you can see it does not
 introduce changed behaviour or anything else. Perhaps I forgot to put it
 on the wiki, and you could have suggested that I should do it, instead
 of going through a hideous legalese. But I take it as a Friday statement.

I admit that I was upset when I wrote the message, so I could have written 
that in a more friendlier way, but please note also that it was factually 
correct. Of course I know that it never was your intention to break the 
GPL, and that you would send the patch to anybody who asked for it. 
Unfortunately that is not enough: What is missing is a hint in the package 
itself where to get the patch (I just searched for such a hint, but did 
not find one). So can you please add it?


Georg

Re: [patch] move OS dependent code to proper place

Am Samstag, 13. Januar 2007 10:00 schrieb Enrico Forestieri:

 Ok. I'll take into account your lack of sense of humour in the future.

It was indeed not clear to me at all that this was intended as a joke. 
Because it was not the first time you brought up the external_path issue 
after the initial discussions it rather looked to me as if you where 
tyring to mention this again and again until it gets accepted.
I am glad to hear that this was a false impression, and I hope that you can 
understand my reaction a bit better now.


Georg

Re: [PATCH] caching translated string

Am Samstag, 13. Januar 2007 12:35 schrieb Abdelrazak Younes:
 Abdelrazak Younes wrote:
  Edwin Leuven wrote:
  i compiled clean from scratch. have to run now...
  
  OK. I have my LyxLex cleanup on my local tree so this is maybe 
  interfering at this point. But this is still weird.
 
 I cannot reproduce the crash with a clean tree either.

The change from docstring get() to docstring const  get() can only be 
dangerous if you change the callers at the same time to only store the 
reference. If this reference lives longer than the Messages instance then 
we have a problem. In all other cases the change is safe, and it is very 
mysterious why it causes a crash for Edwin. Or maybe this operation

it = cache_.insert(std::make_pair(m, translated)).first;

does not succeed? Maybe you should add a check for that. I can't imagine 
why this could fail, but if it fails you are returning something invalid.


Georg

Re: [PATCH] caching translated string


Georg Baum wrote:

Am Samstag, 13. Januar 2007 12:35 schrieb Abdelrazak Younes:

Abdelrazak Younes wrote:

Edwin Leuven wrote:

i compiled clean from scratch. have to run now...
OK. I have my LyxLex cleanup on my local tree so this is maybe 
interfering at this point. But this is still weird.

I cannot reproduce the crash with a clean tree either.


The change from docstring get() to docstring const  get() can only be 
dangerous if you change the callers at the same time to only store the 
reference. If this reference lives longer than the Messages instance then 
we have a problem. In all other cases the change is safe, and it is very 
mysterious why it causes a crash for Edwin. Or maybe this operation


it = cache_.insert(std::make_pair(m, translated)).first;

does not succeed? Maybe you should add a check for that. I can't imagine 
why this could fail, but if it fails you are returning something invalid.


OK, I'll add a check. Thanks.

Abdel.

Re: [PATCH] caching translated string

Maybe this helps against the crashes, it then there will be a
copy  again:

Abdelrazak Younes wrote:
 Abdelrazak Younes wrote:
 Could someone please test this under Linux?

 Enrico, if you could test it under Cygwin as well, that would be great.
 
 Take this patch if you want to see some debug outputs. It's working
 perfectly here and it's really a _huge_ performance boost under Windows!
 
 Abdel.
 
 
 
 
 Index: messages.C
 ===
 --- messages.C(revision 16645)
 +++ messages.C(working copy)
 @@ -21,7 +21,10 @@
  #include boost/regex.hpp
  
  #include cerrno
 +#include map
  
 +using std::endl;
 +using std::string;
  
  namespace lyx {
  
 @@ -29,10 +32,7 @@
  using support::getEnv;
  using support::setEnv;
  
 -using std::string;
 -using std::endl;
  
 -
  static boost::regex const reg(^([^\\[]*)\\[\\[[^\\]]*\\]\\]$);
  
  
 @@ -114,11 +114,17 @@
  
   ~Pimpl() {}
  
 - docstring const get(string const  m) const
 + docstring const  get(string const  m) const
   {
 + static docstring empty_string;
   if (m.empty())
 - return from_ascii(m);
 + return empty_string;
  
 + CacheType::iterator it = cache_.find(m);
 + if (it != cache_.end()) {
 + lyxerr  Cached translation   to_utf8(it-second) 
  endl;

empty_string = it-second;
return empty_string;

instead of 'return it-second;' because how long does it-second; live?

 + return it-second;
 + }
   // In this order, see support/filetools.C:
   string lang = getEnv(LC_ALL);
   if (lang.empty()) {
 @@ -206,11 +212,16 @@
   setlocale(LC_MESSAGES, lang.c_str());
  #endif
   setlocale(LC_CTYPE, oldCTYPE.c_str());
 - return translated;
 +
 + lyxerr  New translation   to_utf8(translated)  endl;
 + it = cache_.insert(std::make_pair(m, translated)).first;

same here:

empty_string = it-second;
return empty_string;

 + return it-second;
   }
  private:
   ///
   string lang_;
 + typedef std::mapstring, docstring CacheType;
 + mutable CacheType cache_;
  };
  #endif
  
 @@ -250,7 +261,7 @@
  {}
  
  
 -docstring const Messages::get(string const  msg) const
 +docstring const  Messages::get(string const  msg) const
  {

static empty_string = pimpl-get(msg);
return empty_string;

   return pimpl_-get(msg);
  }
 Index: messages.h
 ===
 --- messages.h(revision 16645)
 +++ messages.h(working copy)
 @@ -29,7 +29,7 @@
   ///
   ~Messages();
   ///
 - docstring const get(std::string const  msg) const;
 + docstring const  get(std::string const  msg) const;
  private:
   class Pimpl;
   boost::scoped_ptrPimpl pimpl_;


-- 
Peter Kümmel

Re: Result of: Python help needed for configure.py - MiKTeX-problem


Bo Peng schrieb:

The problem of this is line 77 in chkconfig.ltx (command definition of 
\TestItem) :


I did not like chkconfig.ltx but was not able to replace it.
chkconfig.ltx uses latex to check latex packages and generate a result
file.  It would be slower and cleaner to test each package one by one
in python, but I was not able to decipher the latex code.


chkconfig.ltx works fine and needn't to be replaced. The problem is here MiKTeX that quits the 
script instead of printing an error message and then continue.


regards Uwe

Re: another small bug for status 1.5.x

Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm:

 LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
 LyXFunc::dispatch: primary-selection-paste [15] is disabled at this  

This is of course wrong. I used LFUN_PRIMARY_SELECTION_PASTE instead of 
LFUN_CLIPBOARD_PASTE in pasteClipboard(). I did not notice that because I 
always pasted when the selection in the other program was still available, 
so LFUN_PRIMARY_SELECTION_PASTE did work for me.
I cannot use LFUN_CLIPBOARD_PASTE (infinite recursion), but this patch 
should now do exactly the same as current trunk if the external clipboard 
does not contain LyX formatted stuff.
Bennet, could you test this once again please? I only need a console log if 
this still does not work, but I am pretty sure that it works now.


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16664)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor  
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1814,10 +1814,13 @@ bool InsetTabular::copySelection(LCursor
 	odocstringstream os;
 	OutputParams const runparams;
 	paste_tabular-plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the Edit-Paste recent menu and the system clipboard.
+	cap::copySelection(cur, os.str());
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelection.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16664)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor 
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16664)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor 
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16664)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,39 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::readString(std::string const  s)
+{
+	params().compressed = false;
+
+	// remove dummy empty par
+	paragraphs().clear();
+	LyXLex lex(0, 0);
+	std::istringstream is(s);
+	lex.setStream(is);
+	FileName const name(tempName());
+	switch (readFile(lex, name)) {
+	case failure:
+		return false;
+	case wrongversion: {
+		// We need to call lyx2lyx, so write the input to a file
+		std::ofstream os(name.toFilesystemEncoding().c_str());
+		os  s;
+		os.close();
+		return readFile(name) == success;
+	}
+	case success:
+		break;
+	}
+
+	// After we have read a file, we must ensure that the buffer
+	// language is set and used in the gui.
+	// If you know of a better place to put this, please tell me. (Lgb)
+	updateDocLang(params().language);
+
+	return true;
+}
+
+
 bool Buffer::readFile(FileName const  filename)
 {
 	// Check if the file is compressed.
@@ -578,7 +611,7 @@ bool Buffer::readFile(FileName const  f
 	paragraphs().clear();
 	LyXLex lex(0, 0);
 	lex.setFile(filename);
-	if (!readFile(lex, filename))
+	if (readFile(lex, filename) != success)
 		return false;
 
 	// After we have read a file, we must ensure that the buffer
@@ -602,14 +635,15 @@ void Buffer::fully_loaded(bool const val
 }
 
 
-bool Buffer::readFile(LyXLex  lex, FileName const  filename)
+Buffer::ReadStatus Buffer::readFile(LyXLex  lex, FileName const  filename,
+		bool fromstring)
 {
 	BOOST_ASSERT(!filename.empty());
 
 	if (!lex.isOK()) {
 		Alert::error(_(Document could not be read),
 			 bformat(_(%1$s could not be read.), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	lex.next();
@@ -618,7 +652,7 @@ bool Buffer::readFile(LyXLex  lex, File
 	if (!lex.isOK()) {
 		Alert::error(_(Document could not be read),
 			 bformat(_(%1$s could not be read.), from_utf8(filename.absFilename(;
-		return

texlive as support for lyx

2007-01-13 Thread abdelkader belahcene


Hi,
since the new available latex on linux, will be texlive instead of
tetex, I think it 's  time  to support the texlive instead of tetex.
[ Now the required latex for lyx 1.4.2 (is tetex) ] or I am wrong ??

thanks for help
best regards
bela

Re: texlive as support for lyx

2007-01-13 Thread Sven Hoexter

On Sat, Jan 13, 2007 at 09:38:41AM +0100, abdelkader belahcene wrote:
 Hi,
 since the new available latex on linux, will be texlive instead of
 tetex, I think it 's  time  to support the texlive instead of tetex.
 [ Now the required latex for lyx 1.4.2 (is tetex) ] or I am wrong ??
AFAIK LyX works fine with texlive. At least the users of the Debian
package requested that we offer the choice between tetex and texlive and
since that's done I've got no complains. So I assume tetex and texlive are
interchangeable without causing trouble for LyX users.

Sven
-- 
If you won't forgive me the rest of my life
Let me apologize while I'm still alive
I know it's time to face all of my past mistakes
  [Less than Jake - Rest Of My Life]

Re: [PATCH] caching translated string


Peter Kümmel wrote:

Maybe this helps against the crashes, it then there will be a
copy  again:


[...]

-   return from_ascii(m);
+   return empty_string;
 
+		CacheType::iterator it = cache_.find(m);

+   if (it != cache_.end()) {
+   lyxerr  Cached translation   to_utf8(it-second) 
 endl;


empty_string = it-second;
return empty_string;

instead of 'return it-second;' because how long does it-second; live?


it-second points to the found object. Of course the it iterator would 
not live after the call but that's not important. I am pretty confident 
that this is not the problem.


Abdel.

Re: inputencoding default again

Dov Feldstern wrote:

 Georg Baum wrote:
 
 I propose to change the conversion of files with default inputencoding
 to be the same as with auto, together with the corresponding changes in
 LyX itself. The only difference between auto and default in LyX 1.5
 would then be that documents with auto would use the inputenc package,
 but documents with default would not.
 
 This is exactly the right behavior as far as Hebrew is concerned.

This is in now. Dov, could you please check whether it works for you?


Georg

Re: [patch] fix bug 2721 now with attached patch

Uwe Stöhr wrote:
 [1
 ** WARNING ** Unparsed material at end of special ignored.
 Current input buffer is --! /landplus90 true store--
 ]

 This can be ignored this has no consequences an tells that the input DVI
 file is in landscape. When this message doesn't appear dvipdfm doesn't
 recognize the landscape format and produces ugly PDFs. So not using dvips
 is makes it more worse than using dvips because using the dvips driver also
 fixes the bug when using dvipdfm! I tested this with with various larger
 documents. dvipdfm is not under development since 5 years now and therefore
 not recommended to use. So we should also use this when using dvipdfm.

Meanwhile, I had a look at geometry.sty. In fact, the options dvips and 
dvipdfm insert the same specials except that dvips additionally inserts the 
landscape correction, which is, as you describe above, just skipped by 
dvipdfm.

In the view of this, I'd say implementing the more elegant solution (which 
needed to implement an output param driver and pass that to writeLaTeX, is 
not worth it.

So, I finally think you should shove your latest patch in (trunk).

Jürgen

Re: Fix bug 3092.


I agree this has nothing to do here but we have to ask this question to
the user nevertheless, don't we? So where is this part of the code
transferred?


quitWriteBuffer() and close() are almost identical. By calling
LFUN_BUFFER_CLOSE, close() is called instead.


So this means that the user clicked [Cancel] here... But I fail to see
where is the code for that.


The close() function in bufferlist.C.

Bo

FS Encoding error


Georg, Enrico,

something is wrong with the file encoding in Buffer::save(). If I save 
changes to an (existing) file which is located in a path containing 
German Umlauts (Windows), an exception is thrown. The exception message 
isn't very useful. I says that the copy operation failed :-(


The value of pimpl_-filename.toFilesystemEncoding() is (console output):

   C:/dokumente und einstellungen/me/eigene 
dateien/foo/Veröffentlichungen/bar//foo.lyx


The value of s is:

  C:/dokumente und einstellungen/me/eigene 
dateien/foo/VerÃ¶ffentlichungen/bar/foo.lyx~


Any idea? (I surprises me that I am the only one having this problem)

Michael



// Should probably be moved to somewhere else: BufferView? LyXView?
bool Buffer::save() const
{
   ...
   // make a backup if the file already exists
   string s;
   if (lyxrc.make_backup  
fs::exists(pimpl_-filename.toFilesystemEncoding())) {

   s = fileName() + '~';
   if (!lyxrc.backupdir_path.empty())
   s = addName(lyxrc.backupdir_path,
   subst(os::internal_path(s),'/','!'));

   try {
   
fs::copy_file(pimpl_-filename.toFilesystemEncoding(), s, false);

   }
   catch (fs::filesystem_error const  fe) {
   Alert::error(_(Backup failure),
bformat(_(LyX was not able to make 
a backup copy in %1$s.\n
   Please 
check if the directory exists and is write

able.),
 
from_utf8(fs::path(s).branch_path().native_directory_string(;

   lyxerr  Fs error: 
 fe.what()  endl;
   }
   }
   ...
}

Re: Do we support user defined layout?

2007-01-13 Thread Lars Gullik Bjønnes

[EMAIL PROTECTED] writes:

| On Fri, 12 Jan 2007, Georg Baum wrote:
| 
|  Abdelrazak Younes wrote:
| 
|  Georg Baum wrote:
|  They are not different than the translatable ones. The only problem I can
|  imagine is that the cache could get out of date if somebody changes the
|  layout file.
| 
|  Do you mean in the Document settings? If yes, then we just need to reset
|  the cache when this is changed.
| 
|  No, I mean if somebody changes the layout file on disk. I don't know
|  whether we read layout files only on startup, or always if a buffer
|  is loaded, so I don't know whether this is already a problem or not.
| 
| When I messed with layouts as a user, LyX only read layout files on
| startup. So that's how the older versions did it and AFAIK this has
| not changed. However, I really hope LyX will be able to to re-read the
| layout files in the future so I think it'd be bad to add a constraint.

We read layout files lazily, they are read when first used.

What do we gain by re-reading?

-- 
Lgb

Re: [patch] fix bug 2721 now with attached patch

Jürgen wrote:

dvips is
for example also the default driver of hyperref and therefore also used
when producing DVI and PDF files. But dvipdfm takes the ready DVI-file so
it is driver independent.

I don't understand. dvips is a converter from dvi to PostScript, dvipdfm is
a converter from dvi to PDF. Both start from the dvi file. The point is
that geometry inserts dvi specials that might confuse dvipdfm or other
post-dvi tools.

I know that this is confusing, but in this case dvips is the driver which is
also used when you
simply run
latex test.tex
An this is what the patch is for.

the correct solution is not to hardcode a driver, but to use
always the correct one. That is, dvips when dvips is used, dvipdfm when
dvipdfm is used and pdftex when pdflatex is used.

I tested this again and you are right. But how can this be achieved? In converter.C there is already
a routine that checks for the landscape format to use the correct calling parameter

if (bp.orientation == ORIENTATION_LANDSCAPE)
result += -l;

But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a code newbie so can you help
me here? I would add a variable to store the information what converter is used. How can this
variable later be used for bufferparams.C?

I tested this with with various
larger documents. dvipdfm is not under development since 5 years now and
therefore not recommended to use.

But there's dvipdfmx. And some people just prefer dvipdfm over pdflatex (for
instance, because it generates smaller files).

Btw. Are the files really smaller? So there's a good new that the PDF filesize
is now smaller with
the new pdftex 1.4.

regards Uwe

Re: FS Encoding error

Michael Gerz wrote:

 Georg, Enrico,
 
 something is wrong with the file encoding in Buffer::save(). If I save
 changes to an (existing) file which is located in a path containing
 German Umlauts (Windows), an exception is thrown. The exception message
 isn't very useful. I says that the copy operation failed :-(
 
 The value of pimpl_-filename.toFilesystemEncoding() is (console output):
 
 C:/dokumente und einstellungen/me/eigene
 dateien/foo/Veröffentlichungen/bar//foo.lyx
 
 The value of s is:
 
C:/dokumente und einstellungen/me/eigene
 dateien/foo/VerÃ¶ffentlichungen/bar/foo.lyx~
 
 Any idea? (I surprises me that I am the only one having this problem)

You seem to be the only one who uses non-ascii filenames with a non-utf8
filesystem. As you can see above the encoding of s is wrong, because s is
initialized with Buffer::fileName(). That gives a utf8-encoded string, but
we need one in the filesystem encoding.
The attached (untested) patch fixes that, if it works please put it in, I
don't have so much time currently.


GeorgIndex: src/buffer.C
===
--- src/buffer.C	(Revision 16667)
+++ src/buffer.C	(Arbeitskopie)
@@ -714,25 +714,25 @@ bool Buffer::save() const
 	resetAutosaveTimers();
 
 	// make a backup if the file already exists
-	string s;
-	if (lyxrc.make_backup  fs::exists(pimpl_-filename.toFilesystemEncoding())) {
-		s = fileName() + '~';
+	string const encoded_file = pimpl_-filename.toFilesystemEncoding();
+	FileName s;
+	if (lyxrc.make_backup  fs::exists(encoded_file)) {
 		if (!lyxrc.backupdir_path.empty())
-			s = addName(lyxrc.backupdir_path,
-subst(os::internal_path(s),'/','!'));
+			s = FileName(addName(lyxrc.backupdir_path,
+			 subst(os::internal_path(pimpl_-filename.absFilename() + '~'), '/', '!')));
 
 		// It might very well be that this variant is just
 		// good enough. (Lgb)
 		// But to use this we need fs::copy_file to actually do a copy,
 		// even when the target file exists. (Lgb)
 		try {
-		fs::copy_file(pimpl_-filename.toFilesystemEncoding(), s, false);
+		fs::copy_file(encoded_file, s.toFilesystemEncoding(), false);
 		}
 		catch (fs::filesystem_error const  fe) {
 			Alert::error(_(Backup failure),
  bformat(_(LyX was not able to make a backup copy in %1$s.\n
 			Please check if the directory exists and is writeable.),
-	  from_utf8(fs::path(s).branch_path().native_directory_string(;
+	  from_utf8(fs::path(s.absFilename()).branch_path().native_directory_string(;
 			lyxerr[Debug::DEBUG]  Fs error: 
 	  fe.what()  endl;
 		}
@@ -744,7 +744,7 @@ bool Buffer::save() const
 	} else {
 		// Saving failed, so backup is not backup
 		if (lyxrc.make_backup)
-			rename(FileName(s), pimpl_-filename);
+			rename(s, pimpl_-filename);
 		return false;
 	}
 	return true;

Re: par breaking

2007-01-13 Thread Lars Gullik Bjønnes

Abdelrazak Younes [EMAIL PROTECTED] writes:

|   private:
|   ///
|   string lang_;
| + typedef std::mapstring, docstring CacheType;
| + /// Internal cache for gettext translated strings.
| + /// This is needed for performance reason within \c updateLabels()
| + /// under Windows.
| + mutable CacheType cache_;
|   };

I think the CacheType should be given a better name. Just to
describe loosely what kind of a cache it is.

-- 
Lgb

Re: [patch] fix bug 2721 now with attached patch

Uwe Stöhr wrote:
 But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a
 code newbie so can you help me here? I would add a variable to store the
 information what converter is used. How can this variable later be used for
 bufferparams.C?

I think you'd need to add a driver param to outputparams.[Ch], which is set 
in Converters::convert. In buffer.C, writeLaTeXSource, this param is queried 
and then passed to params().writeLaTeX (which would need an additonal param 
string const  driver).

But as I wrote in my last mail, I'm not sure anymore it's worth the effort.

  I tested this with with various
  larger documents. dvipdfm is not under development since 5 years now and
  therefore not recommended to use.
 
  But there's dvipdfmx. And some people just prefer dvipdfm over pdflatex
  (for instance, because it generates smaller files).

 Btw. Are the files really smaller? 

Sometimes, yes (depends on the contents)

 So there's a good new that the PDF 
 filesize is now smaller with the new pdftex 1.4.

I know. Still, dvipdfm has the advantage to support dvi specials. So, for 
instance, change tracking is visible in LyX.

Jürgen

Re: another small bug for status 1.5.x

2007-01-13 Thread Bennett Helm


On Jan 13, 2007, at 7:37 AM, Georg Baum wrote:


Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm:


LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
LyXFunc::dispatch: primary-selection-paste [15] is disabled at this


This is of course wrong. I used LFUN_PRIMARY_SELECTION_PASTE  
instead of
LFUN_CLIPBOARD_PASTE in pasteClipboard(). I did not notice that  
because I
always pasted when the selection in the other program was still  
available,

so LFUN_PRIMARY_SELECTION_PASTE did work for me.
I cannot use LFUN_CLIPBOARD_PASTE (infinite recursion), but this patch
should now do exactly the same as current trunk if the external  
clipboard

does not contain LyX formatted stuff.
Bennet, could you test this once again please? I only need a  
console log if

this still does not work, but I am pretty sure that it works now.


That works! Thanks again.

Bennett

Re: FS Encoding error


Georg,

I am working on an alternative patch right now that fixes this and 
another bug (regarding backup failure).


Give me some time to polish it.

Michael



Georg Baum schrieb:

Michael Gerz wrote:

  

Georg, Enrico,

something is wrong with the file encoding in Buffer::save(). If I save
changes to an (existing) file which is located in a path containing
German Umlauts (Windows), an exception is thrown. The exception message
isn't very useful. I says that the copy operation failed :-(

The value of pimpl_-filename.toFilesystemEncoding() is (console output):

C:/dokumente und einstellungen/me/eigene
dateien/foo/Veröffentlichungen/bar//foo.lyx

The value of s is:

   C:/dokumente und einstellungen/me/eigene
dateien/foo/VerÃ¶ffentlichungen/bar/foo.lyx~

Any idea? (I surprises me that I am the only one having this problem)



You seem to be the only one who uses non-ascii filenames with a non-utf8
filesystem. As you can see above the encoding of s is wrong, because s is
initialized with Buffer::fileName(). That gives a utf8-encoded string, but
we need one in the filesystem encoding.
The attached (untested) patch fixes that, if it works please put it in, I
don't have so much time currently.


Georg

Re: Fix bug 3092.

2007-01-13 Thread Lars Gullik Bjønnes

Peter Kümmel [EMAIL PROTECTED] writes:

| Bo Peng wrote:
|  What I meant is something like follows. The patch does not work
|  correctly yet, but shows my point.
|  
|  1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
|  
|  2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
|  
|  3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
|  
|  4. closeEvent triggers LFUN_LYX_QUIT.
|  
|  That is to say, no one takes the shortcut quitWriteAll. lyx-close
|  experts (Peter, Enrico, Abdel), what do you think? Anything seriously
|  wrong here?
| 
| I think, the most important thing when quitting is that there
| is one place where all prepare-to-quit code is located.
| 
| Does you patch support this?
| How many ways of quitting exit?
| 1. menu exit - LFUN_LYX_QUIT
| 2. last window closed - LFUN_WINDOW_CLOSE - LFUN_LYX_QUIT

and the third:
  3. direct LFUN_LYX_QUIT (short-cut, lyx-server...)

But I think you are right. All quitting should end up in
LDUN_LYX_QUIT and IMHO that should handle closing of the rest of the
windows and buffers.


-- 
Lgb

Re: Fix bug 3092.


Bo Peng wrote:

I agree this has nothing to do here but we have to ask this question to
the user nevertheless, don't we? So where is this part of the code
transferred?


quitWriteBuffer() and close() are almost identical. By calling
LFUN_BUFFER_CLOSE, close() is called instead.


Ahhh... very good then!

I think you may proceed with your cleanup but with caution ;-)

Abdel.

Re: par breaking


Lars Gullik Bjønnes wrote:

Abdelrazak Younes [EMAIL PROTECTED] writes:

|   private:
|   ///
|   string lang_;
| + typedef std::mapstring, docstring CacheType;
| + /// Internal cache for gettext translated strings.
| + /// This is needed for performance reason within \c updateLabels()
| + /// under Windows.
| + mutable CacheType cache_;
|   };

I think the CacheType should be given a better name. Just to
describe loosely what kind of a cache it is.


I've done that.

Abdel.

[patch] fix bug 2418


The fix for this is quite simple: call ImageMagick with an additional parameter.

The parameter only has an effect when at least mageMagick 6.2.6-4 is installed, for older versions 
it does nothing and keeps the current situation.


The fix is included in my win builds for ten months now, so thousands of users tested it without 
problems.

Can you please test it on Linux as well?
A test PDF-file is attached in bug 2418:
http://bugzilla.lyx.org/show_bug.cgi?id=2418

As the ImageMagick option was build especially for us, we should use it. And personally this was one 
of the most annoying bugs since I use PDF-images in all of my documents and then my documents 
consists of huge A4-sized whitespace monsters that totally destroys the layout.


Note this doesn't change the output result as the problem is only the display 
of PDF-images within LyX.

thanks and regards
Uwe
Index: convertDefault.py
===
--- convertDefault.py	(revision 16655)
+++ convertDefault.py	(working copy)
@@ -18,7 +18,7 @@
 
 # converts an image from $1 to $2 format
 import os, sys
-if os.system(r'convert -depth 8 %s %s' % (sys.argv[1], sys.argv[2])) != 0:
+if os.system(r'convert -define pdf:use-cropbox=true -depth 8 %s %s' % (sys.argv[1], sys.argv[2])) != 0:
 print  sys.stderr, sys.argv[0], 'ERROR'
 print  sys.stderr, 'Execution of convert failed.'
 sys.exit(1)

Re: slow opening of docs

2007-01-13 Thread Andre Poenitz

On Tue, Jan 09, 2007 at 07:52:10PM +0100, Edwin Leuven wrote:
 Abdelrazak Younes wrote:
 Could you profile this instead:
 lyx -e text UserGuide.lyx
 
 another try:
 
   %   cumulative   self  self total
  time   seconds   secondscalls  ms/call  ms/call  name
  16.00  0.04 0.0424961 0.00 0.00 
 lyx::LyXLex::Pimpl::nextToken()
  12.00  0.07 0.03   184108 0.00 0.00 
 lyx::Paragraph::setFont(int, lyx::LyXFont const)
   8.00  0.09 0.02   180583 0.00 0.00 
 lyx::Paragraph::insertChar(int, wchar_t, lyx::LyXFont
  const, lyx::Change const)
   8.00  0.11 0.0239984 0.00 0.00 
 lyx::LyXLex::getString() const
   8.00  0.13 0.02 1148 0.02 0.02 
 lyx::LyXTextClass::LyXTextClass(lyx::LyXTextClass con
 st)
 [...]

The total running time is too small to make any judgement.
Put this i a  repeat 100  loop.

Andre'

Re: FS Encoding error


Hi,

this patch fixes the encoding problem in the same way as Georg's patch. 
However, I also fixed a potential problem that may occur if no backup 
can be made successfully and I used proper variable names.


Folks, could someone please check this on Linux? A second Windows expert 
would be fine, too (maybe someone who uses French accents in path names?).


Michael



Georg Baum schrieb:

Michael Gerz wrote:

  

Georg, Enrico,

something is wrong with the file encoding in Buffer::save(). If I save
changes to an (existing) file which is located in a path containing
German Umlauts (Windows), an exception is thrown. The exception message
isn't very useful. I says that the copy operation failed :-(

The value of pimpl_-filename.toFilesystemEncoding() is (console output):

C:/dokumente und einstellungen/me/eigene
dateien/foo/Veröffentlichungen/bar//foo.lyx

The value of s is:

   C:/dokumente und einstellungen/me/eigene
dateien/foo/VerÃ¶ffentlichungen/bar/foo.lyx~

Any idea? (I surprises me that I am the only one having this problem)



You seem to be the only one who uses non-ascii filenames with a non-utf8
filesystem. As you can see above the encoding of s is wrong, because s is
initialized with Buffer::fileName(). That gives a utf8-encoded string, but
we need one in the filesystem encoding.
The attached (untested) patch fixes that, if it works please put it in, I
don't have so much time currently.


Georg
Index: buffer.C
===
--- buffer.C(Revision 16664)
+++ buffer.C(Arbeitskopie)
@@ -713,41 +713,40 @@
// We don't need autosaves in the immediate future. (Asger)
resetAutosaveTimers();
 
+   string const encodedFilename = pimpl_-filename.toFilesystemEncoding();
+
+   FileName backupName;
+   bool successfulBackup = false;
+
// make a backup if the file already exists
-   string s;
-   if (lyxrc.make_backup  
fs::exists(pimpl_-filename.toFilesystemEncoding())) {
-   s = fileName() + '~';
+   if (lyxrc.make_backup  fs::exists(encodedFilename)) {
+   backupName = FileName(fileName() + '~');
if (!lyxrc.backupdir_path.empty())
-   s = addName(lyxrc.backupdir_path,
-   subst(os::internal_path(s),'/','!'));
+   backupName = FileName(addName(lyxrc.backupdir_path,
+ 
subst(os::internal_path(backupName.absFilename()), '/', '!')));
 
-   // It might very well be that this variant is just
-   // good enough. (Lgb)
-   // But to use this we need fs::copy_file to actually do a copy,
-   // even when the target file exists. (Lgb)
try {
-   fs::copy_file(pimpl_-filename.toFilesystemEncoding(), s, 
false);
-   }
-   catch (fs::filesystem_error const  fe) {
+   fs::copy_file(encodedFilename, 
backupName.toFilesystemEncoding(), false);
+   successfulBackup = true;
+   } catch (fs::filesystem_error const  fe) {
Alert::error(_(Backup failure),
-bformat(_(LyX was not able to make a 
backup copy in %1$s.\n
-   Please check if 
the directory exists and is writeable.),
- 
from_utf8(fs::path(s).branch_path().native_directory_string(;
-   lyxerr[Debug::DEBUG]  Fs error: 
- fe.what()  endl;
+bformat(_(Cannot create backup file 
%1$s.\n
+  Please check whether the 
directory exists and is writeable.),
+
from_utf8(backupName.absFilename(;
+   lyxerr[Debug::DEBUG]  Fs error:   fe.what()  
endl;
}
}
 
if (writeFile(pimpl_-filename)) {
markClean();
removeAutosaveFile(fileName());
+   return true;
} else {
// Saving failed, so backup is not backup
-   if (lyxrc.make_backup)
-   rename(FileName(s), pimpl_-filename);
+   if (successfulBackup)
+   rename(backupName, pimpl_-filename);
return false;
}
-   return true;
 }

Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h

2007-01-13 Thread Andre Poenitz

On Fri, Jan 12, 2007 at 11:09:03PM +0100, Abdelrazak Younes wrote:
 Andre Poenitz wrote:
 Does this actually help?
 
 I would have expected that moving the method definition to the header
 would have been needed, too (possiby causing additional header pulled
 in)
 
 Year, that's what I ended up doing in a following commit.

It was a genuine question. With 'global optimization' features creeping
into recent compilers (icc, MSVC, maybe others) I could have imagined
that it 'worked' (apart from breaking C++ definition/declaration rules,
but MSVC is still pretty forgiving when it comes to violations).

So I understand now that the path helps, but only if the definition is
indeed put in the header. Right?

Andre'

accept/reject all changes undo


Hi,

invoking accept/reject all changes accidentally can be a nightmare, 
because you have to run undo as often as there are different changes 
in the document.


The technical reason for this is that these LFUNs iteratively look for 
the next change in the document and accept/reject each of them individually.


Unfortunately, I am not familiar with LyX's undo/redo mechanism. Two 
solutions come to my mind:


1. Select the complete document; accept the complete selection (i.e. 
document) in one step

Pros: simple to implement
Cons: may be slow; may be memory-consuming (depends on how undo is 
implemented); the cursor is set to the beginning of the document


2. Optimize 1: Find the first and last paragraph that contains a 
change; select this part of the document; accept the selection


Undo/redo gurus: Is there a better approach? Is there some kind of undo 
grouping concept that can be used in this case?


Any help is greatly appreciated!

Regards,
Michael

Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h


Andre Poenitz wrote:

On Fri, Jan 12, 2007 at 11:09:03PM +0100, Abdelrazak Younes wrote:

Andre Poenitz wrote:

Does this actually help?

I would have expected that moving the method definition to the header
would have been needed, too (possiby causing additional header pulled
in)

Year, that's what I ended up doing in a following commit.


It was a genuine question. With 'global optimization' features creeping
into recent compilers (icc, MSVC, maybe others) I could have imagined
that it 'worked' (apart from breaking C++ definition/declaration rules,
but MSVC is still pretty forgiving when it comes to violations).


I think that some link time optimisation is possible (maybe not that). 
Or more funky stuff like llvm...




So I understand now that the path helps, but only if the definition is
indeed put in the header. Right?


That's what I've come to understand also.

Abdel.

Re: Remaining selection/clipboard problems: How to proceed

Now that the clipboard works again on all platforms I give here a summary 
of the current status.

Am Freitag, 5. Januar 2007 17:05 schrieb Georg Baum:

 Let's start with our internal clipboard stack: This is advertised to the 
 user in the paste recent menu. If you know this it suddenly makes sense 
 that a middle mouse button press pushes the current selection to the 
 internal clipboard. So this is not a hack, but done on purpose. This is 
 only done for middle mouse button paste and not for C-v, since in the 
 latter case the stuff is already in the clipboard (at least if it comes 
 from within LyX). Unfortunately this is only done in text, not in math 
nor 
 in tables. The attached patch x.diff implements the same mechanism for 
 tables and math and should go in IMO. Any objections?

This has been applied.

 The next question: The clipboard stack is not really a paste recent 
 stack: If you copy something in LyX without pasting it is nevertheless 
 added, and anything that is pasted but comes from outside (selection or 
 clipboard) is not added. That means that it is a bit inconsistent. To 
make 
 it consistent, we could decouple the stack from the clipboard and always 
 fill it on paste. The only disadvantage I see in doing so is that items 
 that you only copy do not appear anymore in the stack. Opinions?

Nothing has been changed here, since there were too many opinions.

 Then we need to decide how the selection should work. The current 
 implementation is almost what I want: No difference between internal 
 and external selection, only one application global selection exists: 
 Everything you select in LyX is advertised to the X server and can be 
 requested by other applications. If you select something in another 
 application LyX receives a SelectionClear event and clears the internal 
 selection. What is missing for this to be fully implemented are some 
calls 
 to theSelection().haveSelection() if the selection was modified by the 
 keyboard. No haveSelection call is missing AFAIK for selection changes by 
 the mouse.
 
 Question: Do we want to advertise keyboard and mouse selections 
differently 
 to X? IMO we should not, and because we do our own selection handling and 
 don't use qApp-clipboard()-setText() for this there is no performance 
 penalty. Unless there are some very good reasons not to advertise 
 selection changes by keyboard to X I am going to add the missing 
 haveSelection calls.

This has been done, but only where we got a selection, not where we cleared 
it (for consistency reasons: This is the same as mouse selections are 
currently handled)

 Fake X selection for windows and Mac: The patch I originally sent is not 
 needed anymore if the patch x.diff in this message is applied, since then 
 the internal selection is always used if available. If we want to paste 
 the clipboard with the middle mouse button on systems that don't have a 
 selection then we should do it like the patch fake-selection.diff. This 
is 
 against the simple mental model of the selection, so I don't like it, 
 but if windows users agree that this is useful I won't object.

This is not in. AFAIK it is now as simple as the attached patch 
fake-selection2.diff.

 Persistent selection: Some people want that a selection is still 
available 
 for middle mouse button paste after it is not visible on screen anymore, 
 and several applications implement that. This is against the simple 
 mental model: The equation selection == highlighted text on screen 
 would not be true anymore. It is not needed either: It makes sense for 
 applications that don't have a clipboard, but since we have one we can as 
 well use C-c and C-v for copy/paste.
 If a majority does not agree with me and somebody volunteers to implement 
 persistent selections I can outline how it can be done, but I won't 
 implement it myself. This is not very difficult to do, but would require 
 some code reorganizations.

The attached patch is the forward ported version of a patch I sent some 
time ago. It is not complete (see FIXMEs), and not tested at all. Bo, if 
you want to finish this you have to look for missing calls of 
cap::finishSelection (they are need whenever the current selections is 
modified). I believe that I found almost all places where that is needed, 
but I might have missed some.

 Related to persistent selections: Should a recieved SelectionClear event 
 clear the LyX selection or not? Again, some apps do this and others 
don't. 
 http://www.jwz.org/doc/x-cut-and-paste.html recommends to honor this 
 request, and this is currently done in LyX.

Nothing has been changed here.

I am not going to do further changes, so if anybody wants fake selection on 
windows, persistent selection or something else please take care of that 
yourself. IMHO both fake selection and persistent would be candidates for 
1.5, all other stuff (extend the external clipboard to all importable 
formats, making the internal clipboard a grid etc) is

Re: [patch] fix bug 2418

Am Samstag, 13. Januar 2007 18:37 schrieb Uwe Stöhr:

 Can you please test it on Linux as well?

Sorry, my imagemagick is too old: 6.2.4

 Note this doesn't change the output result as the problem is only the 
display of PDF-images within LyX.

Why? I would think that it would also affect the conversion from pdf to eps 
for plain latex output. This would be fine for me personally.


Georg

PS: You should fix your documentation commits before doing any further 
changes IMO.

Re: another small bug for status 1.5.x

Am Mittwoch, 10. Januar 2007 23:46 schrieb Jean-Marc Lasgouttes:

 A question: what happens to relative filenames when copy-pasting a
 graphics or include inset? (the answer is probably: the same thing as
 before :)

Yes (i.e. nothing happens).


Georg

Re: python help needed

Am Mittwoch, 10. Januar 2007 23:18 schrieb José Matos:
 On Wednesday 10 January 2007 9:33 pm, Georg Baum wrote:
  Ah, now I know the problem: If we add string literals to document.body 
we
  need to prefix them with u to get unicode string literals: u'bla'. Now 
I
  know where to search.
 
   That is enough to drive anyone (read me) crazy. :-)

Me too, but I found a workaround:

# Unfortunately we have a mixture of unciode strings and plain strings,
# because we never use u'xxx' for string literals, but 'xxx'.
# Therefore we may have to try two times to normalize the data.
try:
document.body[i] = unicodedata.normalize(NFKD, document.body[i])
except TypeError:
document.body[i] = unicodedata.normalize(NFKD, 
unicode(document.body[i], 'utf-8'))

That works, now I have to find the next bug :-(


Georg

Re: [Cvslog] r16671 - in /lyx-devel/trunk: development/scons/scons_man...

Am Samstag, 13. Januar 2007 22:08 schrieb [EMAIL PROTECTED]:
 Add two files that are included by the beamer example file and that I 
forgot.
 Found out by Jean-Pierre Chretien.

Jean-Marc, I guess this is for 1.4.4, too?


Georg

Solution: can't start 1.5svn under windows - Bo?


Uwe Stöhr schrieb:

  Another user has this problem too. I made a lot of tests the last days
  together with this user but I'm still not able to reproduce it.

  It's maybe a manifest problem again.

I notices tha there is the file

Microsoft.VC80.CRT.manifest

in SVN's \development\Win32\packaging folder and our Scons script don't 
seem to process it.

Bo, do you know what this is for?


This was the problem!!! Now I spent two weeks of hard testing together with the users wh reported 
this first and I didn't came to this idea .-(

When I deliver this manifest fil togehter with the Dlls mentioned in this file, 
it works.

But OK, since we know the problem could you Bo have a look how the manifest-file can be processed: 
The msvc manifest file needs to be included running the mt.exe and I don't know how to do this.


thanks in advance and regards
Uwe

Re: [patch] fix bug 2418


 Why? I would think that it would also affect the conversion from pdf to eps
 for plain latex output. This would be fine for me personally.

In this case yes.

 PS: You should fix your documentation commits before doing any further
 changes IMO.

What do you mean? What is broken or incorrect?

regards Uwe

Re: [patch] move OS dependent code to proper place

On Sat, Jan 13, 2007 at 12:36:11PM +0100, Georg Baum wrote:

 Am Samstag, 13. Januar 2007 09:58 schrieb Enrico Forestieri:
  On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:
  
   Enrico Forestieri wrote:
   
as a parameter introducer. To tell you the truth, the cygwin version
of lyx that I make available for download is patched such that 
 through
an env variable it is possible to use either posix or windows style
paths.
   
   Making a binary created from patched sources available is very bad IMO.
  
  Thanks for your opinion. So, you are saying that if I find that a patch
  does something useful I should not share it with others.
 
 I admit that my wording above was not really what I meant. Maybe I should 
 have taken some more time to write that message.
 I have no problem at all with binaries from patched sources as long as it 
 is clearly stated that the sources are patched, and where interested 
 people can get the patch. What I don't like at all is making patched 
 versions available without clearly stating that it is a patched version, 
 because IMO users have a right to know what they use. This does not mean 
 that patched versions are not useful, it is only a labelling issue. When 
 Uwe distributed installers from patched sources labelled as LyX 1.4.0 
 (IIRC) I wrote something similar.
 AFAIK we are talking about 
 ftp://ftp.lyx.org/pub/lyx/bin/1.4.3/lyx-1.4.3-cygwin.tar.gz. If not, 
 please correct me. That file sits on the official ftp server together with 
 binaries from unpatched sources in one directory, and the file 
 README.cygwin in that directory only explains that this package is 
 unofficial, but not that it is patched. Therefore it is very difficult for 
 users to find out that they are not running a vanilla version.

It's very easy, instead. This is clearly stated in the README.txt file
contained in the package. Only, I forgot to add the patch together with
the sources of the other utilities packaged there. I would have sworn I
did that, but after checking it I discovered that I forgot to update the
script used to build the package.

I was trying to be careful about the GPL, but made a mistake, that's all.
Moreover, I find your criticism quite instrumental. See below.

   Either this patch is for your personal convenience, then you should not
   make the binary available, or it is useful in general, then the patch
   should be included in the official version.
  
  I find this to be a somewhat hypocritical attitude, as I tried to have
  accepted a similar patch but it was rejected. But maybe when you say
  useful in general you mean that it must be useful for all platforms
  an not for a particular one (which is not yours).
 
 No I don't mean that. I mean useful for cygwin users in general. IIRC I 
 was the only one besides you who had opinions on this patch. I stated two 
 or three times already that I don't understand anymore what external_path 
 currently does and that I don't care anymore whether it exists or not.
 Therefore this statement was not hypocritical at all, but meant seriously. 

No, I still maintain that it is hypocritical, because the patch was
already rejected in the past and, nonetheless, you suggest that it
should be included in the official version if it useful in general.
I think that this is clearly a case of pulling someone's leg.

 IIRC Lars had some concerns about some #ifdef __CYGWIN__ in the code. I 
 share these concerns and would not like to have them at all in the main 
 code, but I am sure that this could be avoided by putting this stuff in 
 the os namespace and using a well defined interface (with possible noop 
 functions on other platforms).

I find amusing your specific mention of __CYGWIN__ here, while forgetting
_WIN32 and __APPLE__, but I understand that _WIN32 and __APPLE__ are not
instrumental to your goal. Indeed, I think that you want to upset only me.

   I don't know if the README in the package talks about the patch and 
 where to
   get it, but if it does not then you are even breaking the GPL.
  
  Now you are going a bit above the lines (even for a Friday).
  Please, find attached the patch in question. As you can see it does not
  introduce changed behaviour or anything else. Perhaps I forgot to put it
  on the wiki, and you could have suggested that I should do it, instead
  of going through a hideous legalese. But I take it as a Friday statement.
 
 I admit that I was upset when I wrote the message, so I could have written 
 that in a more friendlier way, but please note also that it was factually 
 correct.

I don't know what I did to upset you this time. Sometimes you write
something in a joking way without thinking how it will be interpreted.
I think this is a problem with email. However, the point is not the
factual correctness but the fact that it was intended to be irritating.
See, even if you are correct, I mainly notice the intention to wound my
feelings.

 Of course I know that it never was

Re: Solution: can't start 1.5svn under windows - Bo?


This was the problem!!! Now I spent two weeks of hard testing together with the 
users wh reported
this first and I didn't came to this idea .-(
When I deliver this manifest fil togehter with the Dlls mentioned in this file, 
it works.


Congratulations on identifying the problem!! I still remember the days
I (we) struggled on the manifest problems, until, only by chance,
Abdel found out that .manifest file for QtCore.dll need to be
embedded.

I do not know whether or not I can embed this manifest file with
lyx.exe, since it has already been embedded with QtCore.dll.manifest.
Please try:

mt.exe /MANIFEST /path/to/this.manifest /outputresource:lyx.exe:1

on your lyx.exe file, and

mt.exe /MANIFEST /path/to/this.manifest /path/to/qtcore.dll.manifest
/outputresource:lyx.exe:1

and see if you can embed two manifest files at the same time.

Cheers,
Bo

Re: Remaining selection/clipboard problems: How to proceed


I am not going to do further changes, so if anybody wants fake selection on
windows, persistent selection or something else please take care of that
yourself.


Thank you very much. I get the persistent selection patch and will try
it later. I can not work on it soon because I will be extremely busy
in the next two weeks.

Cheers,
Bo

Re: [patch] move OS dependent code to proper place

On Sat, Jan 13, 2007 at 12:36:17PM +0100, Georg Baum wrote:

 Am Samstag, 13. Januar 2007 10:00 schrieb Enrico Forestieri:
 
  Ok. I'll take into account your lack of sense of humour in the future.
 
 It was indeed not clear to me at all that this was intended as a joke. 
 Because it was not the first time you brought up the external_path issue 
 after the initial discussions it rather looked to me as if you where 
 tyring to mention this again and again until it gets accepted.
 I am glad to hear that this was a false impression, and I hope that you can 
 understand my reaction a bit better now.

Given that both of us gave vent to one's anger, I think we can move on.

-- 
Enrico

Re: [patch] move OS dependent code to proper place

On Sun, Jan 14, 2007 at 03:02:26AM +0100, Enrico Forestieri wrote:

 I attach here a new version of the README.cygwin file intended to
 replace the existing one. I cannot do it, so someone else will have to.

I think that for better compliance with the GPL the patch should be
put alongside the package, so I attach here a revised README.cygwin
file and the patch itself.

-- 
Enrico

PS: I would like to stop here this thread, so I will not reply to any
other follow-up.
The archive lyx-1.4.3-cygwin.tar.gz contains an unofficial cygwin version
of LyX. Here you can find both a native Qt3 GUI version of LyX (no X-server
needed) and an Xforms/X11 binary which maybe preferred by Win98/ME users due
to its low demanding on resources. Please take a look at the included README
for instructions on installing the package. Note that this version of LyX
is patched to use either Windows- or posix-style paths. You can find the
patch in the lyx-1.4.3-cygwin.patch file.

The directory cygwin-package is a repository for the official cygwin
Qt3/X11 version of LyX. You don't need dowloanding the files contained in this
directory (and indeed you shouldn't) in order to install the official cygwin
version of LyX. Instead, you should use the setup.exe cygwin installation
tool, point it to your nearest cygwin mirror and select LyX for installation.
Index: src/frontends/qt2/qfont_loader.C
===
--- src/frontends/qt2/qfont_loader.C(revision 15112)
+++ src/frontends/qt2/qfont_loader.C(working copy)
@@ -102,7 +102,11 @@ void FontLoader::initFontPath()
for (int i = 0 ; i  num_fonts_truetype ; ++i) {
string const font_current = 
AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
+#if defined(__CYGWIN__) || defined(__CYGWIN32__)
+   AddFontResource(os::windows_path(font_current).c_str());
+#else
AddFontResource(os::external_path(font_current).c_str());
+#endif
}
 #endif
 }
@@ -115,7 +119,11 @@ FontLoader::~FontLoader() {
for(int i = 0 ; i  num_fonts_truetype ; ++i) {
string const font_current = 
AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
+#if defined(__CYGWIN__) || defined(__CYGWIN32__)
+   RemoveFontResource(os::windows_path(font_current).c_str());
+#else
RemoveFontResource(os::external_path(font_current).c_str());
+#endif
}
 #endif
 }
Index: src/frontends/qt2/FileDialog.C
===
--- src/frontends/qt2/FileDialog.C  (revision 15112)
+++ src/frontends/qt2/FileDialog.C  (working copy)
@@ -20,6 +20,7 @@
 #include gettext.h
 
 #include support/filefilterlist.h
+#include support/os.h
 
 /** when this is defined, the code will use
  * QFileDialog::getOpenFileName and friends to create filedialogs.
@@ -30,7 +31,7 @@
  *
  * Therefore there is a tradeoff in enabling or disabling this (JMarc)
  */
-#ifdef Q_WS_MACX
+#if defined(Q_WS_MACX) || defined(Q_CYGWIN_WIN)
 #define USE_NATIVE_FILEDIALOG 1
 #endif
 
@@ -42,6 +43,8 @@ using lyx::support::MakeAbsPath;
 
 using lyx::support::FileFilterList;
 
+using lyx::support::os::internal_path;
+
 using std::endl;
 using std::string;
 
@@ -80,11 +83,11 @@ FileDialog::Result const FileDialog::sav
 
 #ifdef USE_NATIVE_FILEDIALOG
string const startsWith = MakeAbsPath(suggested, path);
-   result.second = fromqstr(
+   result.second = internal_path(fromqstr(
QFileDialog::getSaveFileName(toqstr(startsWith),
 toqstr(filters.as_string()),
 qApp-focusWidget() ? 
qApp-focusWidget() : qApp-mainWidget(),
-title_.c_str()));
+title_.c_str(;
 #else
LyXFileDialog dlg(path, filters, title_, private_-b1, private_-b2);
dlg.setMode(QFileDialog::AnyFile);
@@ -96,7 +99,7 @@ FileDialog::Result const FileDialog::sav
int res = dlg.exec();
lyxerr[Debug::GUI]  result   res  endl;
if (res == QDialog::Accepted)
-   result.second = fromqstr(dlg.selectedFile());
+   result.second = internal_path(fromqstr(dlg.selectedFile()));
dlg.hide();
 #endif
return result;
@@ -115,11 +118,11 @@ FileDialog::Result const FileDialog::ope
 
 #ifdef USE_NATIVE_FILEDIALOG
string const startsWith = MakeAbsPath(suggested, path);
-   result.second = fromqstr(
+   result.second = internal_path(fromqstr(
QFileDialog::getOpenFileName(toqstr(startsWith),
 toqstr(filters.as_string()),
 qApp-focusWidget() ? 
qApp-focusWidget() : qApp-mainWidget(),
-title_.c_str()));
+

session: save/restore window position bug

2007-01-13 Thread Bennett Helm

On Mac with the save/restore window position option checked, every  
time I quit LyX, the number stored in the session file for WindowPosY  
is decremented by 20, causing the LyX window to open higher and  
higher on the screen (eventually going off the top resulting in there  
being no way to bring it back down).


Bennett

Re: session: save/restore window position bug


On 1/13/07, Bennett Helm [EMAIL PROTECTED] wrote:

On Mac with the save/restore window position option checked, every
time I quit LyX, the number stored in the session file for WindowPosY
is decremented by 20, causing the LyX window to open higher and
higher on the screen (eventually going off the top resulting in there
being no way to bring it back down).


This is qt4 stuff and Peter should know this well. I guess it is
caused by some differences in what is saved (geometry of outer frame?)
and what is used (workarea only?).

Cheers,
Bo

Re: [patch] Re: one bug for the Qt/dialog people

2007-01-13 Thread jean-marc

> The patch works also perfectly in LyX 1.5; please apply it to trunk and 
> branch. 

Yes, go ahead. 

JMarc

Re: [PATCH] caching translated string

On Fri, Jan 12, 2007 at 11:07:55PM +0100, Abdelrazak Younes wrote:

> Abdelrazak Younes wrote:
> > Could someone please test this under Linux?
> > 
> > Enrico, if you could test it under Cygwin as well, that would be great.
> 
> Take this patch if you want to see some debug outputs. It's working 
> perfectly here and it's really a _huge_ performance boost under Windows!

I tried it but honestly cannot see a difference with or without the
patch. I loaded a big document went in the middle and tried breaking
a paragraph. A lot of debug messages about cached things are spitted
out, but I cannot notice any difference in speed, which is already
good: a paragraph is broken and rejoined instantly, in practice.

Maybe this is language dependent or I was performing the wrong test.

-- 
Enrico

Re: [PATCH] caching translated string


Angus Leeming wrote:

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak Younes wrote:

Could someone please test this under Linux?

Enrico, if you could test it under Cygwin as well, that would be great.
Take this patch if you want to see some debug outputs. It's working 
perfectly here and it's really a _huge_ performance boost under Windows!


Doesn't your cache need to take account of the language?


The Message class is designed for a unique language. If a new language 
is asked, a new instance of the class will be created (see 
updateDocLang()) and the old one ditched (via the scoped_ptr). In 
effect, this means that the current cache will be erased. In practice, 
this doesn't matter much as the cache will be filled in again at the 
next paragraph break if the langauge is changed inside a section. This 
does not happens much and I reckon that the delay is OK if there is a 
language change. If not, then we can cache Message objects instead of 
ditching them upon language change.


That's what gettext 
is doing internally...


The problem is that we can't use this internal cache because.

Ie, the key shouldn't be just a string but rather 
pair.


If there is a need to do that my idea would be to maintain a map of 
 at the Buffer level. See above.


Abdel.

Re: [PATCH] caching translated string


Enrico Forestieri wrote:

On Fri, Jan 12, 2007 at 11:07:55PM +0100, Abdelrazak Younes wrote:


Abdelrazak Younes wrote:

Could someone please test this under Linux?

Enrico, if you could test it under Cygwin as well, that would be great.
Take this patch if you want to see some debug outputs. It's working 
perfectly here and it's really a _huge_ performance boost under Windows!


I tried it but honestly cannot see a difference with or without the
patch. I loaded a big document went in the middle and tried breaking
a paragraph. A lot of debug messages about cached things are spitted
out, but I cannot notice any difference in speed, which is already
good: a paragraph is broken and rejoined instantly, in practice.


I don't expect any performance improvement under Linux and Cygwin. I 
think the internal gettext compiled with MSVC is at fault here. I tried 
with the external GnuWin32 gettext version and I see the same slowness.
I think the cygwin version (as well as the Linux version) are 
effectively using its internal cache.




Maybe this is language dependent or I was performing the wrong test.


Yes, I wanted you to check that the translation process is still working 
correctly. Especially, at the section level. Could you set create a 
document with the report class and set a different language of one 
'Chapter' section. If all goes well, the 'Chapter' part will be translated.


Abdel.

Re: [PATCH] caching translated string


Abdelrazak Younes wrote:


The problem is that we can't use this internal cache because.


because... it does not work with our way of setting the language at each 
gettext call.


Abdel.

Re: [patch] move OS dependent code to proper place

On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:

> Enrico Forestieri wrote:
> 
> > as a parameter introducer. To tell you the truth, the cygwin version
> > of lyx that I make available for download is patched such that through
> > an env variable it is possible to use either posix or windows style
> > paths.
> 
> Making a binary created from patched sources available is very bad IMO.

Thanks for your opinion. So, you are saying that if I find that a patch
does something useful I should not share it with others.

> Either this patch is for your personal convenience, then you should not
> make the binary available, or it is useful in general, then the patch
> should be included in the official version.

I find this to be a somewhat hypocritical attitude, as I tried to have
accepted a similar patch but it was rejected. But maybe when you say
"useful in general" you mean that it must be useful for all platforms
an not for a particular one (which is not yours).

> I don't know if the README in the package talks about the patch and where to
> get it, but if it does not then you are even breaking the GPL.

Now you are going a bit above the lines (even for a Friday).
Please, find attached the patch in question. As you can see it does not
introduce changed behaviour or anything else. Perhaps I forgot to put it
on the wiki, and you could have suggested that I should do it, instead
of going through a hideous legalese. But I take it as a Friday statement.

-- 
Enrico
Index: src/frontends/qt2/qfont_loader.C
===
--- src/frontends/qt2/qfont_loader.C(revision 15112)
+++ src/frontends/qt2/qfont_loader.C(working copy)
@@ -102,7 +102,11 @@ void FontLoader::initFontPath()
for (int i = 0 ; i < num_fonts_truetype ; ++i) {
string const font_current = 
AddName(fonts_dir, win_fonts_truetype[i] + ".ttf");
+#if defined(__CYGWIN__) || defined(__CYGWIN32__)
+   AddFontResource(os::windows_path(font_current).c_str());
+#else
AddFontResource(os::external_path(font_current).c_str());
+#endif
}
 #endif
 }
@@ -115,7 +119,11 @@ FontLoader::~FontLoader() {
for(int i = 0 ; i < num_fonts_truetype ; ++i) {
string const font_current = 
AddName(fonts_dir, win_fonts_truetype[i] + ".ttf");
+#if defined(__CYGWIN__) || defined(__CYGWIN32__)
+   RemoveFontResource(os::windows_path(font_current).c_str());
+#else
RemoveFontResource(os::external_path(font_current).c_str());
+#endif
}
 #endif
 }
Index: src/frontends/qt2/FileDialog.C
===
--- src/frontends/qt2/FileDialog.C  (revision 15112)
+++ src/frontends/qt2/FileDialog.C  (working copy)
@@ -20,6 +20,7 @@
 #include "gettext.h"
 
 #include "support/filefilterlist.h"
+#include "support/os.h"
 
 /** when this is defined, the code will use
  * QFileDialog::getOpenFileName and friends to create filedialogs.
@@ -30,7 +31,7 @@
  *
  * Therefore there is a tradeoff in enabling or disabling this (JMarc)
  */
-#ifdef Q_WS_MACX
+#if defined(Q_WS_MACX) || defined(Q_CYGWIN_WIN)
 #define USE_NATIVE_FILEDIALOG 1
 #endif
 
@@ -42,6 +43,8 @@ using lyx::support::MakeAbsPath;
 
 using lyx::support::FileFilterList;
 
+using lyx::support::os::internal_path;
+
 using std::endl;
 using std::string;
 
@@ -80,11 +83,11 @@ FileDialog::Result const FileDialog::sav
 
 #ifdef USE_NATIVE_FILEDIALOG
string const startsWith = MakeAbsPath(suggested, path);
-   result.second = fromqstr(
+   result.second = internal_path(fromqstr(
QFileDialog::getSaveFileName(toqstr(startsWith),
 toqstr(filters.as_string()),
 qApp->focusWidget() ? 
qApp->focusWidget() : qApp->mainWidget(),
-title_.c_str()));
+title_.c_str(;
 #else
LyXFileDialog dlg(path, filters, title_, private_->b1, private_->b2);
dlg.setMode(QFileDialog::AnyFile);
@@ -96,7 +99,7 @@ FileDialog::Result const FileDialog::sav
int res = dlg.exec();
lyxerr[Debug::GUI] << "result " << res << endl;
if (res == QDialog::Accepted)
-   result.second = fromqstr(dlg.selectedFile());
+   result.second = internal_path(fromqstr(dlg.selectedFile()));
dlg.hide();
 #endif
return result;
@@ -115,11 +118,11 @@ FileDialog::Result const FileDialog::ope
 
 #ifdef USE_NATIVE_FILEDIALOG
string const startsWith = MakeAbsPath(suggested, path);
-   result.second = fromqstr(
+   result.second = internal_path(fromqstr(
QFileDialog::getOpenFileName(toqstr(startsWith),
 toqstr(filters.as_string()),

Re: [patch] move OS dependent code to proper place

On Fri, Jan 12, 2007 at 05:50:10PM +0100, Georg Baum wrote:

> Enrico Forestieri wrote:
> 
> > Believe me, external_path could be completely ditched.
> 
> Please stop talking of external_path. Yesterday you wrote that you don't
> want to discuss that anymore, and I don't want that either. I gave up
> trying to understand how it behaves now a long time ago, and I don't care
> anymore about it. The only thing I care about is that the result of an
> external_path call is only used for interfacing to other programs or
> display purposes (although we have makeDisplayPath for the latter that
> should take care of any needed transformations), and never for further use
> inside of LyX.

Ok. I'll take into account your lack of sense of humour in the future.

-- 
Enrico

Re: [patch] move OS dependent code to proper place


Enrico Forestieri wrote:

On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:


Enrico Forestieri wrote:


as a parameter introducer. To tell you the truth, the cygwin version
of lyx that I make available for download is patched such that through
an env variable it is possible to use either posix or windows style
paths.

Making a binary created from patched sources available is very bad IMO.


Thanks for your opinion. So, you are saying that if I find that a patch
does something useful I should not share it with others.


Yes ;-)




Either this patch is for your personal convenience, then you should not
make the binary available, or it is useful in general, then the patch
should be included in the official version.


I find this to be a somewhat hypocritical attitude, as I tried to have
accepted a similar patch but it was rejected.


But now you have more power to push it in :-) well, at least on trunk.



But maybe when you say
"useful in general" you mean that it must be useful for all platforms
an not for a particular one (which is not yours).


I don't know if the README in the package talks about the patch and where to
get it, but if it does not then you are even breaking the GPL.


Now you are going a bit above the lines (even for a Friday).
Please, find attached the patch in question. As you can see it does not
introduce changed behaviour or anything else. Perhaps I forgot to put it
on the wiki, and you could have suggested that I should do it, instead
of going through a hideous legalese. But I take it as a Friday statement.


Cool it down Enrico, this is just Georg way of stating fact in a cold 
manner...





Index: src/frontends/qt2/qfont_loader.C


Ah... this is for 1.4 then... Do we need sth similar for 1.5 or is it 
already in? I guess part of it (the font part) is already in.


Abdel.

Re: [PATCH] caching translated string

On Sat, Jan 13, 2007 at 09:39:44AM +0100, Abdelrazak Younes wrote:

> Yes, I wanted you to check that the translation process is still working 
> correctly. Especially, at the section level. Could you set create a 
> document with the report class and set a different language of one 
> 'Chapter' section. If all goes well, the 'Chapter' part will be translated.

Yes, that is working. Otherwise I would have reported it.

-- 
Enrico

Re: Fix bug 3092.


Bo Peng wrote:

What I meant is something like follows. The patch does not work
correctly yet, but shows my point.

1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.


This part is good. The BufferList should not care about quitting and 
asking for user interaction.




2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE


Good in theory but you have to make sure that it works equally well on 
the three supported platform.




3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one


Be careful here, we should do that only if it is the last window.



4. closeEvent triggers LFUN_LYX_QUIT.


Only if it is the last window.



That is to say, no one takes the shortcut quitWriteAll. lyx-close
experts (Peter, Enrico, Abdel), what do you think? Anything seriously
wrong here?


See above. More comments below:


Index: src/bufferlist.C
===
--- src/bufferlist.C(revision 16658)
+++ src/bufferlist.C(working copy)
@@ -96,76 +96,6 @@
}


-bool BufferList::quitWriteBuffer(Buffer * buf)
-{
-BOOST_ASSERT(buf);
-
-docstring file;
-if (buf->isUnnamed())
-file = from_utf8(onlyFilename(buf->fileName()));
-else
-file = makeDisplayPath(buf->fileName(), 30);
-
-docstring const text =
-bformat(_("The document %1$s has unsaved changes.\n\n"
-   "Do you want to save the document or discard the 
changes?"),

-   file);
-int const ret = Alert::prompt(_("Save changed document?"),
-text, 0, 2, _(""), _(""), _(""));


I agree this has nothing to do here but we have to ask this question to 
the user nevertheless, don't we? So where is this part of the code 
transferred?



[...]


-bool BufferList::quitWriteAll()
-{
-BufferStorage::iterator it = bstore.begin();
-BufferStorage::iterator end = bstore.end();
-for (; it != end; ++it) {
-if ((*it)->isClean())
-continue;
-
-if (!quitWriteBuffer(*it))
-return false;
-}
-// now, all buffers have been written sucessfully
-// save file names to .lyx/session
-it = bstore.begin();
-for (; it != end; ++it) {
-// if master/slave are both open, do not save slave since it
-// will be automatically loaded when the master is loaded
-if ((*it)->getMasterBuffer() == (*it))


Same question here. Where is that transferred? I am probably missing 
something.



Index: src/lyxfunc.C
===
--- src/lyxfunc.C(revision 16658)
+++ src/lyxfunc.C(working copy)
@@ -1074,7 +1074,8 @@
case LFUN_LYX_QUIT:
// quitting is triggered by the gui code
// (leaving the event loop).
-if (theBufferList().quitWriteAll())
+dispatch(FuncRequest(LFUN_WINDOW_CLOSE));


Here you have to call LFUN_WINDOW_CLOSE for every window. The list is 
given to you by the Gui class.



+if (theBufferList().empty())
theApp()->gui().closeAllViews();


This Gui::closeAllViews() is redundant here if you have already closed 
all the windows (view == window).



break;

@@ -1703,13 +1704,19 @@
case LFUN_WINDOW_CLOSE:
BOOST_ASSERT(lyx_view_);
BOOST_ASSERT(theApp());
-// update bookmark pit of the current buffer before window 
close
-for (size_t i = 0; i < 
LyX::ref().session().bookmarks().size(); ++i)

-gotoBookmark(i+1, false, false);
-// ask the user for saving changes or cancel quit
-if (!theBufferList().quitWriteAll())
-break;
-lyx_view_->close();
+// close buffer one by one


Be careful here, only if it is the last window.


+while (true) {
+string const file = lyx_view_->buffer()->fileName();
+dispatch(FuncRequest(LFUN_BUFFER_CLOSE));
+// all files closed
+if (theBufferList().empty()) {
+lyx_view_->close();
+break;
+// buffer close failed
+if (file == lyx_view_->buffer()->fileName())
+break;
+}
+}
return;

case LFUN_BOOKMARK_GOTO:
Index: src/frontends/qt4/GuiView.C
===
--- src/frontends/qt4/GuiView.C(revision 16658)
+++ src/frontends/qt4/GuiView.C(working copy)
@@ -237,7 +237,8 @@
// we may have been called through the close window button
// which bypasses the LFUN machinery.
if (!quitting_by_menu_) {
-if (!theBufferList().quitWriteAll()) {
+dispatch(FuncRequest(LFUN_LYX_QUIT));


Good in theory but you have to make sure that it works equally well on 
the three supported platform.



+if (!theBufferList().empty()) {


So this means that the user clicked [Cancel] here...

Re: [PATCH] caching translated string


Enrico Forestieri wrote:

On Sat, Jan 13, 2007 at 09:39:44AM +0100, Abdelrazak Younes wrote:

Yes, I wanted you to check that the translation process is still working 
correctly. Especially, at the section level. Could you set create a 
document with the report class and set a different language of one 
'Chapter' section. If all goes well, the 'Chapter' part will be translated.


Yes, that is working. Otherwise I would have reported it.


Very good then, I'll commit!

Abdel.

Re: Fix bug 3092.

Bo Peng wrote:
> What I meant is something like follows. The patch does not work
> correctly yet, but shows my point.
> 
> 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
> 
> 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
> 
> 3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
> 
> 4. closeEvent triggers LFUN_LYX_QUIT.
> 
> That is to say, no one takes the shortcut quitWriteAll. lyx-close
> experts (Peter, Enrico, Abdel), what do you think? Anything seriously
> wrong here?

I think, the most important thing when quitting is that there
is one place where all prepare-to-quit code is located.

Does you patch support this?
How many ways of quitting exit?
1. menu exit -> LFUN_LYX_QUIT
2. last window closed -> LFUN_WINDOW_CLOSE -> LFUN_LYX_QUIT

two only? have I forgotten one?

> 
> Bo
> 
> 
> 
> Index: src/bufferlist.C
> ===
> --- src/bufferlist.C(revision 16658)
> +++ src/bufferlist.C(working copy)
> @@ -96,76 +96,6 @@
> }
> 
> 
> -bool BufferList::quitWriteBuffer(Buffer * buf)
> -{
> -BOOST_ASSERT(buf);
> -
> -docstring file;
> -if (buf->isUnnamed())
> -file = from_utf8(onlyFilename(buf->fileName()));
> -else
> -file = makeDisplayPath(buf->fileName(), 30);
> -
> -docstring const text =
> -bformat(_("The document %1$s has unsaved changes.\n\n"
> -   "Do you want to save the document or discard the
> changes?"),
> -   file);
> -int const ret = Alert::prompt(_("Save changed document?"),
> -text, 0, 2, _(""), _(""), _(""));
> -
> -if (ret == 0) {
> -// FIXME: WriteAs can be asynch !
> -// but not right now...maybe we should remove that
> -
> -bool succeeded;
> -
> -if (buf->isUnnamed())
> -succeeded = writeAs(buf);
> -else
> -succeeded = menuWrite(buf);
> -
> -if (!succeeded)
> -return false;
> -} else if (ret == 1) {
> -// if we crash after this we could
> -// have no autosave file but I guess
> -// this is really inprobable (Jug)
> -if (buf->isUnnamed())
> -removeAutosaveFile(buf->fileName());
> -
> -} else {
> -return false;
> -}
> -
> -return true;
> -}
> -
> -
> -bool BufferList::quitWriteAll()
> -{
> -BufferStorage::iterator it = bstore.begin();
> -BufferStorage::iterator end = bstore.end();
> -for (; it != end; ++it) {
> -if ((*it)->isClean())
> -continue;
> -
> -if (!quitWriteBuffer(*it))
> -return false;
> -}
> -// now, all buffers have been written sucessfully
> -// save file names to .lyx/session
> -it = bstore.begin();
> -for (; it != end; ++it) {
> -// if master/slave are both open, do not save slave since it
> -// will be automatically loaded when the master is loaded
> -if ((*it)->getMasterBuffer() == (*it))
> -   
> LyX::ref().session().lastOpened().add(FileName((*it)->fileName()));
> -}
> -
> -return true;
> -}
> -
> -
> void BufferList::release(Buffer * buf)
> {
> BOOST_ASSERT(buf);
> Index: src/bufferlist.h
> ===
> --- src/bufferlist.h(revision 16658)
> +++ src/bufferlist.h(working copy)
> @@ -42,9 +42,6 @@
> iterator end();
> const_iterator end() const;
> 
> -/// write all buffers, asking the user, returns false if cancelled
> -bool quitWriteAll();
> -
> /// create a new buffer
> Buffer * newBuffer(std::string const & s, bool ronly = false);
> 
> @@ -104,8 +101,6 @@
> void setCurrentAuthor(docstring const & name, docstring const & email);
> 
> private:
> -/// ask to save a buffer on quit, returns false if should cancel
> -bool quitWriteBuffer(Buffer * buf);
> 
> typedef std::vector BufferStorage;
> 
> Index: src/lyxfunc.C
> ===
> --- src/lyxfunc.C(revision 16658)
> +++ src/lyxfunc.C(working copy)
> @@ -1074,7 +1074,8 @@
> case LFUN_LYX_QUIT:
> // quitting is triggered by the gui code
> // (leaving the event loop).
> -if (theBufferList().quitWriteAll())
> +dispatch(FuncRequest(LFUN_WINDOW_CLOSE));
> +if (theBufferList().empty())
> theApp()->gui().closeAllViews();
> break;
> 
> @@ -1703,13 +1704,19 @@
> case LFUN_WINDOW_CLOSE:
> BOOST_ASSERT(lyx_view_);
> BOOST_ASSERT(theApp());
> -// update bookmark pit of the current buffer before window
> close
> -for (size_t i = 0; i <
> LyX::ref().session().bookmarks().size(); ++i)
> -gotoBookmark(i+1, false, false);
> -// ask the user for saving changes or cancel quit
> -if (!theBufferList().quitWriteAll())
> -break;
>

Re: [patch] move OS dependent code to proper place

On Sat, Jan 13, 2007 at 10:03:39AM +0100, Abdelrazak Younes wrote:

> Enrico Forestieri wrote:
> > On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:
> > 
> >> Enrico Forestieri wrote:
> >>
> >>> as a parameter introducer. To tell you the truth, the cygwin version
> >>> of lyx that I make available for download is patched such that through
> >>> an env variable it is possible to use either posix or windows style
> >>> paths.
> >> Making a binary created from patched sources available is very bad IMO.
> > 
> > Thanks for your opinion. So, you are saying that if I find that a patch
> > does something useful I should not share it with others.
> 
> Yes ;-)

;-)

> >> Either this patch is for your personal convenience, then you should not
> >> make the binary available, or it is useful in general, then the patch
> >> should be included in the official version.
> > 
> > I find this to be a somewhat hypocritical attitude, as I tried to have
> > accepted a similar patch but it was rejected.
> 
> But now you have more power to push it in :-) well, at least on trunk.

But i don't want to push anything in without consensus.

> > But maybe when you say
> > "useful in general" you mean that it must be useful for all platforms
> > an not for a particular one (which is not yours).
> > 
> >> I don't know if the README in the package talks about the patch and where 
> >> to
> >> get it, but if it does not then you are even breaking the GPL.
> > 
> > Now you are going a bit above the lines (even for a Friday).
> > Please, find attached the patch in question. As you can see it does not
> > introduce changed behaviour or anything else. Perhaps I forgot to put it
> > on the wiki, and you could have suggested that I should do it, instead
> > of going through a hideous legalese. But I take it as a Friday statement.
> 
> Cool it down Enrico, this is just Georg way of stating fact in a cold 
> manner...

Yes, I know. We are using different locales ;-)

> > 
> > 
> > Index: src/frontends/qt2/qfont_loader.C
> 
> Ah... this is for 1.4 then... Do we need sth similar for 1.5 or is it 
> already in? I guess part of it (the font part) is already in.

No, we don't "need" it. I don't even "need" lyx ;-)

-- 
Enrico

Re: Fix bug 3092.


Peter Kümmel wrote:

Bo Peng wrote:

What I meant is something like follows. The patch does not work
correctly yet, but shows my point.

1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.

2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE

3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one

4. closeEvent triggers LFUN_LYX_QUIT.

That is to say, no one takes the shortcut quitWriteAll. lyx-close
experts (Peter, Enrico, Abdel), what do you think? Anything seriously
wrong here?


I think, the most important thing when quitting is that there
is one place where all prepare-to-quit code is located.

Does you patch support this?
How many ways of quitting exit?
1. menu exit -> LFUN_LYX_QUIT
2. last window closed -> LFUN_WINDOW_CLOSE -> LFUN_LYX_QUIT

two only? have I forgotten one?


You already forgot you Mac experience? It's amazing to see how human 
beings manage to erase bad experiences from their memories :-)


IIRC there's another way on Mac.

Abdel.

Re: [PATCH] caching translated string


lyx crashes here with your patch:

msvcr80d.dll!10202b13() 
 	[Frames below may be incorrect and/or missing, no symbols loaded 
for msvcr80d.dll]	

shlwapi.dll!77f643d0()  
msvcr80d.dll!1021866b() 
shlwapi.dll!77f643dd()  
kernel32.dll!7c812a5b() 
msvcr80d.dll!10271754() 
msvcr80d.dll!102509a1() 
msvcr80d.dll!102509e4() 
msvcr80d.dll!1024ef7b() 
msvcr80d.dll!102509a1() 
msvcr80d.dll!102509e4() 
msvcr80d.dll!1024ef86() 
msvcr80d.dll!1024ef7b() 
msvcr80d.dll!102a0cd8() 
msvcr80d.dll!10220b1c() 
msvcr80d.dll!10203ca4() 
msvcr80d.dll!1021e039() 
msvcr80d.dll!102a0cd8() 
msvcr80d.dll!102a0ccd() 
msvcp80d.dll!10496402() 
msvcp80d.dll!10496078() 
msvcp80d.dll!104963e0() 
>	lyx-qt4.exe!std::_Iterator_base::operator=(const std::_Iterator_base 
& _Right={...})  Line 145 + 0x27 bytes	C++

msvcp80d.dll!104963e0() 
msvcp80d.dll!104fe1fd() 
msvcp80d.dll!104f9a52() 
msvcp80d.dll!10491e82() 
msvcp80d.dll!104fe20d() 
msvcp80d.dll!104f9a52() 
msvcr80d.dll!10203ca4() 
ntdll.dll!7c90e027()
ntdll.dll!7c91392e()
msvcr80d.dll!102048e6() 
msvcr80d.dll!10203ca4() 
msvcr80d.dll!10213223() 
msvcr80d.dll!1021321a() 
lyx-qt4.exe!lyx::support::abort()  Line 25 + 0x8 bytes  C++
lyx-qt4.exe!error_handler(int err_sig=11)  Line 713 C++
msvcr80d.dll!10212fc0() 
ntdll.dll!7c911538()
ntdll.dll!7c910833()
lyx-qt4.exe!__tmainCRTStartup()  Line 603 + 0x17 bytes  C
 	lyx-qt4.exe!_except_handler4(_EXCEPTION_RECORD * 
ExceptionRecord=0x01a8e040, _EXCEPTION_REGISTRATION_RECORD * 
EstablisherFrame=0x01a8ffa8, _CONTEXT * ContextRecord=0x01a8e05c, void * 
DispatcherContext=0x01a8e014)  + 0x22 bytes	C

ntdll.dll!7c9037bf()
ntdll.dll!7c90378b()
ntdll.dll!7c937860()
ntdll.dll!7c90d4ea()
ntdll.dll!7c9116ff()
ntdll.dll!7c92812f()
ntdll.dll!7c9106eb()
ntdll.dll!7c90eafa()
ntdll.dll!7c9106ab()
ntdll.dll!7c9106eb()
ntdll.dll!7c9106ab()
ntdll.dll!7c9106eb()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
ntdll.dll!7c91056d()
ntdll.dll!7c9134d6()
ntdll.dll!7c914d8f()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
shlwapi.dll!77f643d0()  
shlwapi.dll!77f643dd()  
 	lyx-qt4.exe!std::char_traits::_Copy_s(unsigned long * 
_First1=0x020e0040, unsigned int _Dest_size=27848859, const unsigned 
long * _First2=0x, unsigned int _Count=27848856)  Line 215 + 
0xd bytes	C++
 	lyx-qt4.exe!std::_Traits_helper::copy_s >(unsigned long * _First1=0x020e0040, unsigned int _Size=27848859, 
const unsigned long * _First2=0x, unsigned int _Count=27848856, 
std::_Secure_char_traits_tag __formal={...})  Line 590 + 0x15 bytes	C++
 	lyx-qt4.exe!std::_Traits_helper::copy_s >(unsigned long * _First1=0x020e0040, unsigned int _Size=27848859, 
const unsigned long * _First2=0x, unsigned int _Count=27848856) 
 Line 582 + 0x21 bytes	C++
 	lyx-qt4.exe!std::basic_stringlong>,std::allocator >::assign(const 
std::basic_stringlong>,std::allocator > & _Right={...}, unsigned int 
_Roff=0, unsigned int _Count=4294967295)  Line 1011 + 0x28 bytes	C++
 	lyx-qt4.exe!std::basic_stringlong>,std::allocator >::basic_stringlong,std::char_traits,std::allocator 
>(const std::basic_stringlong>,std::allocator > & _Right={...})  Line 597	C++
 	lyx-qt4.exe!lyx::_(const 
std::basic_string & 
str="File|F")  Line 46 + 0x19 bytes	C++
 	lyx-qt4.exe!lyx::translateIfPossible(const std::basic_stringlong,std::char_traits,std::allocator > & 
name={...})  Line 78 + 0x2d bytes	C++
 	lyx-qt4.exe!lyx::Menu::read(lyx::LyXLex & lex={...})  Line 352 + 
0x3b bytes	C++

lyx-qt4.exe!lyx::MenuBackend::read(lyx::LyXLex & lex={...})  Line 938   
C++
 	lyx-qt4.exe!lyx::LyX::readUIFile(const 
std::basic_string & 
name="stdmenus.inc")  Line 1124	C++
 	lyx-qt4.exe!lyx::LyX::readUIFile(const 
std::basic_string & 
name="default")  Line 1118 + 0xf bytes	C++

lyx-qt4.exe!lyx::LyX::init()  Line 826 + 0xd bytes  C++
 	lyx-qt4.exe!lyx::LyX::init(int & argc=1, char * * argv=0x003e56a8) 
Line 473 + 0x8 bytes	C++
 	lyx-qt4.exe!lyx::LyX::exec(int & argc=1, char * *

Re: par breaking


Edwin Leuven wrote:
i've noticed that breaking a paragraph is much quicker than "unbreaking" 
it (cursor at beginning of par and then backspace)


i think that this has always been the case, but i was wondering whether 
there is something that can be done about it? (i guess i am looking at 
you abdel ;-)


This is fixed now!

Abdel.

Author: younes
Date: Sat Jan 13 10:31:47 2007
New Revision: 16662

URL: http://www.lyx.org/trac/changeset/16662
Log:
Messages:
- cache_: new cache for gettext translated string.

Modified:
lyx-devel/trunk/src/messages.C
lyx-devel/trunk/src/messages.h

Modified: lyx-devel/trunk/src/messages.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/messages.C?rev=16662
==
--- lyx-devel/trunk/src/messages.C (original)
+++ lyx-devel/trunk/src/messages.C Sat Jan 13 10:31:47 2007
@@ -21,16 +21,16 @@
 #include 

 #include 
-
+#include 
+
+using std::endl;
+using std::string;

 namespace lyx {

 using support::package;
 using support::getEnv;
 using support::setEnv;
-
-using std::string;
-using std::endl;


 static boost::regex const reg("^([^\\[]*)\\[\\[[^\\]]*\\]\\]$");
@@ -114,10 +114,17 @@

~Pimpl() {}

-   docstring const get(string const & m) const
-   {
+   docstring const & get(string const & m) const
+   {
+   static docstring empty_string;
if (m.empty())
-   return from_ascii(m);
+   return empty_string;
+
+   // Look for the translated string in the cache.
+   CacheType::iterator it = cache_.find(m);
+   if (it != cache_.end())
+   return it->second;
+   // The string was not found, use gettext to generate it:

// In this order, see support/filetools.C:
string lang = getEnv("LC_ALL");
@@ -206,11 +213,18 @@
setlocale(LC_MESSAGES, lang.c_str());
 #endif
setlocale(LC_CTYPE, oldCTYPE.c_str());
-   return translated;
+
+   it = cache_.insert(std::make_pair(m, translated)).first;
+   return it->second;
}
 private:
///
string lang_;
+   typedef std::map CacheType;
+   /// Internal cache for gettext translated strings.
+   /// This is needed for performance reason within \c updateLabels()
+   /// under Windows.
+   mutable CacheType cache_;
 };
 #endif

@@ -250,7 +264,7 @@
 {}


-docstring const Messages::get(string const & msg) const
+docstring const & Messages::get(string const & msg) const
 {
return pimpl_->get(msg);
 }

Modified: lyx-devel/trunk/src/messages.h
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/messages.h?rev=16662
==
--- lyx-devel/trunk/src/messages.h (original)
+++ lyx-devel/trunk/src/messages.h Sat Jan 13 10:31:47 2007
@@ -29,7 +29,7 @@
///
~Messages();
///
-   docstring const get(std::string const & msg) const;
+   docstring const & get(std::string const & msg) const;
 private:
class Pimpl;
boost::scoped_ptr pimpl_;

Re: Fix bug 3092.

Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Bo Peng wrote:
>>> What I meant is something like follows. The patch does not work
>>> correctly yet, but shows my point.
>>>
>>> 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
>>>
>>> 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
>>>
>>> 3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
>>>
>>> 4. closeEvent triggers LFUN_LYX_QUIT.
>>>
>>> That is to say, no one takes the shortcut quitWriteAll. lyx-close
>>> experts (Peter, Enrico, Abdel), what do you think? Anything seriously
>>> wrong here?
>>
>> I think, the most important thing when quitting is that there
>> is one place where all prepare-to-quit code is located.
>>
>> Does you patch support this?
>> How many ways of quitting exit?
>> 1. menu exit -> LFUN_LYX_QUIT
>> 2. last window closed -> LFUN_WINDOW_CLOSE -> LFUN_LYX_QUIT
>>
>> two only? have I forgotten one?
> 
> You already forgot you Mac experience? It's amazing to see how human
> beings manage to erase bad experiences from their memories :-)

NO, NO, I haven't forgotten it ;)

The problem on the mac was that there is a auto generated
menu entry which doesn't triggers LFUN_LYX_QUIT, so it is item 1.

> 
> IIRC there's another way on Mac.

Isn't this fixed now?

> 
> Abdel.
> 


Peter

Re: [PATCH] caching translated string


Edwin Leuven wrote:

lyx crashes here with your patch:


[...]
std::basic_string & 
str="File|F")  Line 46 + 0x19 bytesC++
 lyx-qt4.exe!lyx::translateIfPossible(const 


This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?

messages.h

~Messages();
///
-   docstring const & get(std::string const & msg) const;
+   docstring const get(std::string const & msg) const;

end of messages.C:

-docstring const & Messages::get(string const & msg) const
+docstring const Messages::get(string const & msg) const

Abdel.

Re: [PATCH] caching translated string


Abdelrazak Younes wrote:
This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?


yes, this gets rid of the crash...

Re: [PATCH] caching translated string


Edwin Leuven wrote:

Abdelrazak Younes wrote:
This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?


yes, this gets rid of the crash...


I cannot reproduce the crash, this is really weird. Could you revert the 
change and compile again. Maybe something went wrong when you compiled 
the first time...


Abdel.

Re: [PATCH] caching translated string


i compiled clean from scratch. have to run now...

Abdelrazak Younes wrote:

Edwin Leuven wrote:

Abdelrazak Younes wrote:
This is weird, I did not touch this part and it works fine on my 
platform. Maybe there is sth wrong when passing const ref instead of 
full docstring copy I cannot immagine why...


Could you try to remove to do this change and try again?


yes, this gets rid of the crash...


I cannot reproduce the crash, this is really weird. Could you revert the 
change and compile again. Maybe something went wrong when you compiled 
the first time...


Abdel.

Re: [PATCH] caching translated string


Edwin Leuven wrote:

i compiled clean from scratch. have to run now...


OK. I have my LyxLex cleanup on my local tree so this is maybe 
interfering at this point. But this is still weird.


Abdel.

Re: [patch] Re: one bug for the Qt/dialog people

[EMAIL PROTECTED] wrote:
> > The patch works also perfectly in LyX 1.5; please apply it to trunk and
> > branch.
>
> Yes, go ahead.

Thanks. Done.

Jürgen

Re: [PATCH] caching translated string


Abdelrazak Younes wrote:

Edwin Leuven wrote:

i compiled clean from scratch. have to run now...


OK. I have my LyxLex cleanup on my local tree so this is maybe 
interfering at this point. But this is still weird.


I cannot reproduce the crash with a clean tree either.

Abdel.

Re: [patch] move OS dependent code to proper place

Am Samstag, 13. Januar 2007 09:58 schrieb Enrico Forestieri:
> On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote:
> 
> > Enrico Forestieri wrote:
> > 
> > > as a parameter introducer. To tell you the truth, the cygwin version
> > > of lyx that I make available for download is patched such that 
through
> > > an env variable it is possible to use either posix or windows style
> > > paths.
> > 
> > Making a binary created from patched sources available is very bad IMO.
> 
> Thanks for your opinion. So, you are saying that if I find that a patch
> does something useful I should not share it with others.

I admit that my wording above was not really what I meant. Maybe I should 
have taken some more time to write that message.
I have no problem at all with binaries from patched sources as long as it 
is clearly stated that the sources are patched, and where interested 
people can get the patch. What I don't like at all is making patched 
versions available without clearly stating that it is a patched version, 
because IMO users have a right to know what they use. This does not mean 
that patched versions are not useful, it is only a labelling issue. When 
Uwe distributed installers from patched sources labelled as "LyX 1.4.0" 
(IIRC) I wrote something similar.
AFAIK we are talking about 
ftp://ftp.lyx.org/pub/lyx/bin/1.4.3/lyx-1.4.3-cygwin.tar.gz. If not, 
please correct me. That file sits on the official ftp server together with 
binaries from unpatched sources in one directory, and the file 
README.cygwin in that directory only explains that this package is 
unofficial, but not that it is patched. Therefore it is very difficult for 
users to find out that they are not running a vanilla version.

> > Either this patch is for your personal convenience, then you should not
> > make the binary available, or it is useful in general, then the patch
> > should be included in the official version.
> 
> I find this to be a somewhat hypocritical attitude, as I tried to have
> accepted a similar patch but it was rejected. But maybe when you say
> "useful in general" you mean that it must be useful for all platforms
> an not for a particular one (which is not yours).

No I don't mean that. I mean "useful for cygwin users in general". IIRC I 
was the only one besides you who had opinions on this patch. I stated two 
or three times already that I don't understand anymore what external_path 
currently does and that I don't care anymore whether it exists or not.
Therefore this statement was not hypocritical at all, but meant seriously. 
IIRC Lars had some concerns about some #ifdef __CYGWIN__ in the code. I 
share these concerns and would not like to have them at all in the main 
code, but I am sure that this could be avoided by putting this stuff in 
the os namespace and using a well defined interface (with possible noop 
functions on other platforms).

> > I don't know if the README in the package talks about the patch and 
where to
> > get it, but if it does not then you are even breaking the GPL.
> 
> Now you are going a bit above the lines (even for a Friday).
> Please, find attached the patch in question. As you can see it does not
> introduce changed behaviour or anything else. Perhaps I forgot to put it
> on the wiki, and you could have suggested that I should do it, instead
> of going through a hideous legalese. But I take it as a Friday statement.

I admit that I was upset when I wrote the message, so I could have written 
that in a more friendlier way, but please note also that it was factually 
correct. Of course I know that it never was your intention to break the 
GPL, and that you would send the patch to anybody who asked for it. 
Unfortunately that is not enough: What is missing is a hint in the package 
itself where to get the patch (I just searched for such a hint, but did 
not find one). So can you please add it?

Georg

Re: [patch] move OS dependent code to proper place

Am Samstag, 13. Januar 2007 10:00 schrieb Enrico Forestieri:

> Ok. I'll take into account your lack of sense of humour in the future.

It was indeed not clear to me at all that this was intended as a joke. 
Because it was not the first time you brought up the external_path issue 
after the initial discussions it rather looked to me as if you where 
tyring to mention this again and again until it gets accepted.
I am glad to hear that this was a false impression, and I hope that you can 
understand my reaction a bit better now.


Georg

Re: [PATCH] caching translated string

Am Samstag, 13. Januar 2007 12:35 schrieb Abdelrazak Younes:
> Abdelrazak Younes wrote:
> > Edwin Leuven wrote:
> >> i compiled clean from scratch. have to run now...
> > 
> > OK. I have my LyxLex cleanup on my local tree so this is maybe 
> > interfering at this point. But this is still weird.
> 
> I cannot reproduce the crash with a clean tree either.

The change from "docstring get()" to "docstring const & get()" can only be 
dangerous if you change the callers at the same time to only store the 
reference. If this reference lives longer than the Messages instance then 
we have a problem. In all other cases the change is safe, and it is very 
mysterious why it causes a crash for Edwin. Or maybe this operation

it = cache_.insert(std::make_pair(m, translated)).first;

does not succeed? Maybe you should add a check for that. I can't imagine 
why this could fail, but if it fails you are returning something invalid.

Georg

Re: [PATCH] caching translated string


Georg Baum wrote:

Am Samstag, 13. Januar 2007 12:35 schrieb Abdelrazak Younes:

Abdelrazak Younes wrote:

Edwin Leuven wrote:

i compiled clean from scratch. have to run now...
OK. I have my LyxLex cleanup on my local tree so this is maybe 
interfering at this point. But this is still weird.

I cannot reproduce the crash with a clean tree either.


The change from "docstring get()" to "docstring const & get()" can only be 
dangerous if you change the callers at the same time to only store the 
reference. If this reference lives longer than the Messages instance then 
we have a problem. In all other cases the change is safe, and it is very 
mysterious why it causes a crash for Edwin. Or maybe this operation


it = cache_.insert(std::make_pair(m, translated)).first;

does not succeed? Maybe you should add a check for that. I can't imagine 
why this could fail, but if it fails you are returning something invalid.


OK, I'll add a check. Thanks.

Abdel.

Re: [PATCH] caching translated string

Maybe this helps against the crashes, it then there will be a
copy  again:

Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Could someone please test this under Linux?
>>
>> Enrico, if you could test it under Cygwin as well, that would be great.
> 
> Take this patch if you want to see some debug outputs. It's working
> perfectly here and it's really a _huge_ performance boost under Windows!
> 
> Abdel.
> 
> 
> 
> 
> Index: messages.C
> ===
> --- messages.C(revision 16645)
> +++ messages.C(working copy)
> @@ -21,7 +21,10 @@
>  #include 
>  
>  #include 
> +#include 
>  
> +using std::endl;
> +using std::string;
>  
>  namespace lyx {
>  
> @@ -29,10 +32,7 @@
>  using support::getEnv;
>  using support::setEnv;
>  
> -using std::string;
> -using std::endl;
>  
> -
>  static boost::regex const reg("^([^\\[]*)\\[\\[[^\\]]*\\]\\]$");
>  
>  
> @@ -114,11 +114,17 @@
>  
>   ~Pimpl() {}
>  
> - docstring const get(string const & m) const
> + docstring const & get(string const & m) const
>   {
> + static docstring empty_string;
>   if (m.empty())
> - return from_ascii(m);
> + return empty_string;
>  
> + CacheType::iterator it = cache_.find(m);
> + if (it != cache_.end()) {
> + lyxerr << "Cached translation " << to_utf8(it->second) 
> << endl;

empty_string = it->second;
return empty_string;

instead of 'return it->second;' because how long does it->second; live?

> + return it->second;
> + }
>   // In this order, see support/filetools.C:
>   string lang = getEnv("LC_ALL");
>   if (lang.empty()) {
> @@ -206,11 +212,16 @@
>   setlocale(LC_MESSAGES, lang.c_str());
>  #endif
>   setlocale(LC_CTYPE, oldCTYPE.c_str());
> - return translated;
> +
> + lyxerr << "New translation " << to_utf8(translated) << endl;
> + it = cache_.insert(std::make_pair(m, translated)).first;

same here:

empty_string = it->second;
return empty_string;

> + return it->second;
>   }
>  private:
>   ///
>   string lang_;
> + typedef std::map CacheType;
> + mutable CacheType cache_;
>  };
>  #endif
>  
> @@ -250,7 +261,7 @@
>  {}
>  
>  
> -docstring const Messages::get(string const & msg) const
> +docstring const & Messages::get(string const & msg) const
>  {

static empty_string = pimpl->get(msg);
return empty_string;

>   return pimpl_->get(msg);
>  }
> Index: messages.h
> ===
> --- messages.h(revision 16645)
> +++ messages.h(working copy)
> @@ -29,7 +29,7 @@
>   ///
>   ~Messages();
>   ///
> - docstring const get(std::string const & msg) const;
> + docstring const & get(std::string const & msg) const;
>  private:
>   class Pimpl;
>   boost::scoped_ptr pimpl_;


-- 
Peter Kümmel

Re: Result of: Python help needed for configure.py - MiKTeX-problem


Bo Peng schrieb:

The problem of this is line 77 in chkconfig.ltx (command definition of 
\TestItem) :


I did not like chkconfig.ltx but was not able to replace it.
chkconfig.ltx uses latex to check latex packages and generate a result
file.  It would be slower and cleaner to test each package one by one
in python, but I was not able to decipher the latex code.


chkconfig.ltx works fine and needn't to be replaced. The problem is here MiKTeX that quits the 
script instead of printing an error message and then continue.


regards Uwe

Re: another small bug for status 1.5.x