Minimum compiler version

[Peter Kümmel]

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter

Build bot reactivated

[Peter Kümmel]

I've reactivated the build-bot for Windows binaries of the 
master branch. It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).


http://syntheticpp.github.io/LyX-bleeding-edge

Maybe it helps a bit for 2.2.

Peter

Re: Upgrade to boost 1.59?

[Peter Kümmel]

Am 23.10.2015 um 18:13 schrieb Vincent van Ravesteijn:


Op 23 okt. 2015 17:37 schreef "Jean-Marc Lasgouttes"
mailto:lasgout...@lyx.org>>:
 >
 > I think we should upgrade our local copy of boost to 1.59
before alpha (or at least before beta).
 >
 > Is the procedure documented somewhere?
 >
 > Also, what can we do to hide the warnings related to
auto_ptr? If we are out of ideas, I propose to compile with
-Wno-deprecated-functions in C++11 mode.
 >
 > JMarc

I have it documented somewhere. Should I put it in
development.lyx ?

Vincent



I could do it. I've done it already multiple times.

Peter

(a little, little back ;)

Re: [LyX/master] On Linux show in crash message box the backtrace

[Peter Kümmel]

On 25.08.2014 23:54, Scott Kostyshak wrote:

On Sat, Jun 14, 2014 at 5:26 AM, Peter Kümmel  wrote:

commit 2f17858115247a1f2b9e341e7cbe96148911c1ad
Author: Peter Kümmel 
Date:   Sat Jun 7 11:12:31 2014 +0200

 On Linux show in crash message box the backtrace


Would this be easy to extend to show the backtrace on assertions also?

Scott



Yes, just call printCallStack() where you need it.

Peter

Re: [LyX/master] print callstack on assert

[Peter Kümmel]

On 28.08.2014 00:20, Richard Heck wrote:

On 08/27/2014 01:52 PM, Peter Kümmel wrote:

commit ada262a78b2ec12e9697783b27523b8c13b51066
Author: Peter Kümmel 
Date:   Wed Aug 27 19:40:40 2014 +0200

 print callstack on assert

diff --git a/src/support/lassert.cpp b/src/support/lassert.cpp
index 281330e..fa2ffb0 100644
--- a/src/support/lassert.cpp
+++ b/src/support/lassert.cpp
@@ -10,6 +10,7 @@
   */
  #include 
+#include 
  #include "support/convert.h"
  #include "support/debug.h"
@@ -35,13 +36,21 @@ namespace lyx {
  using namespace std;
  using namespace support;
-// TODO Should we try to print the call stack in the course of these?
+
+void doAssertWithCallstack(bool value)
+{
+if (!value) {
+printCallStack();
+BOOST_ASSERT(false);
+}
+}
+


What about:

 printCallStack();
 BOOST_ASSERT(value);

It seems worth printing the call stack whether we are going to abort or not.

Richard




Doesn't this produce too much noise for all the "true" cases? (it is declared 
in assert.h ATM)

But feel free to change it to your needs.


Is it still a cmake-build only feature?

Peter

Re: Major document corruption

[Peter Kümmel]

On 16.06.2014 22:35, Murat Yildizoglu wrote:

Is this bug that haunts the new version is specific to the OSX version?
I am so stressed that I save every two minutes :-(


On Linux you could setup a cron job which calls a script:

crontab -e

http://stackoverflow.com/questions/5398014/using-crontab-to-execute-script-every-minute-and-another-every-24-hours



Le lundi 16 juin 2014, Maria Gouskova mailto:gousk...@gmail.com>> a écrit :

Hi all,

So LyX (2.1.0, Mac OS 10.6) stopped responding after I did something
fairly routine to a file (adding references), and I forced the program
to quit. Now I can reopen LyX, but the file I was working on will not
open--LyX just beachballs. To figure this out, I opened the .lyx file
in a text editor, and saw that about 2/3rds of the file just got
lopped off! The lyx.emergency file is missing those parts, too. I
restored the previous version of the file via Dropbox so I didn't lose
much work.

So, is it this?

http://www.lyx.org/trac/ticket/9049

Maria



--


*Prof. Murat Yildizoglu*

Note: Please use the following address as such

UNIVERSITE DE BORDEAUX
GREThA (UMR CNRS 5113)
MURAT YILDIZOGLU
16 AVENUE LEON DUGUIT
CS 50057
33608 PESSAC CEDEX
FRANCE

Bureau : E-331

mail: yildi-at-u-bordeaux4.fr 

web: yildizoglu.info 

Re: Major document corruption

[Peter Kümmel]

On 16.06.2014 22:35, Murat Yildizoglu wrote:

Is this bug that haunts the new version is specific to the OSX version?
I am so stressed that I save every two minutes :-(


You mean you copy the file, so lyx can't touch it any more?
Saving by LyX alone doesn't help, because saving with LyX could also destroy 
your files.



Le lundi 16 juin 2014, Maria Gouskova mailto:gousk...@gmail.com>> a écrit :

Hi all,

So LyX (2.1.0, Mac OS 10.6) stopped responding after I did something
fairly routine to a file (adding references), and I forced the program
to quit. Now I can reopen LyX, but the file I was working on will not
open--LyX just beachballs. To figure this out, I opened the .lyx file
in a text editor, and saw that about 2/3rds of the file just got
lopped off! The lyx.emergency file is missing those parts, too. I
restored the previous version of the file via Dropbox so I didn't lose
much work.

So, is it this?

http://www.lyx.org/trac/ticket/9049

Maria



--


*Prof. Murat Yildizoglu*

Note: Please use the following address as such

UNIVERSITE DE BORDEAUX
GREThA (UMR CNRS 5113)
MURAT YILDIZOGLU
16 AVENUE LEON DUGUIT
CS 50057
33608 PESSAC CEDEX
FRANCE

Bureau : E-331

mail: yildi-at-u-bordeaux4.fr 

web: yildizoglu.info 

Re: LyX 2.1.1, Again

[Peter Kümmel]

On 16.06.2014 17:56, Jean-Marc Lasgouttes wrote:

16/06/2014 17:26, Richard Heck:


OK. It seems to me we are ready to freeze strings for 2.1.1. Any
objection or comment?


I think the time is right.

JMarc




Could someone define LYX_CALLSTACK_PRINTING in support when LyX
is compiled with automake on Linux and with with GCC?
Then we get a backtrace in the crash dialog. Would help us a lot
in localizing the "the mystery crash".

Peter

Re: Data Saving Patch 2

[Peter Kümmel]

On 09.06.2014 13:27, Georg Baum wrote:

Jürgen Spitzmüller wrote:


I tried with latest master (including your recent changes), and I still
get the warning.
* Open document
* Edit
* Save
=> No warning
* Edit more
* Save again
=> This time, the warning dialog pops up.


I see it as well with this recipe, and fixed it at f792e70d0a. This shows
clearly that there was a gap both in Richards and my testing, otherwise we
would have seen it. Given the fact that there is still a highly nontrivial
change missing to fix the last (known) regression (the file permission
problem) I don't think anymore that saving to a temp file first and then
renaming it is safe enough for 2.1.1. We simply cannot test it enough to
ensure that it does not make the situation worse.

Therefore I vote for taking it out for 2.1.1 (but keep the higher number of
flush()). If you disagree then both bf782ee02a and f792e70d0a should be
backported of course.



Yes, touching 19 files looks a bit too complicated for a fix.

Could you not just ensure that no valid backup/autosave file will be 
overwritten?

With two backupfile it could look like this:
- write to backup file 1
- write to the settings that backup 1 is latest valid backup file
- next time read from settings which the last valid one was, and use the other
- after successfully writing the backup file update the settings
- then save the master lyx file

When LyX crashs while writing the backup file there is still the last one and 
the master file.
When LyX crash while writing the settings it will overwrite the latest backup,
but there is still the second latest backup file valid and the master
When LyX then crashs while writing the master lyx file there is at least one
backup file valid.



Georg

Re: [PATCH 1/1] On Linux show in crash message box the backtrace

[Peter Kümmel]

This patch is for 2.1.x, but could I commit to master?

> ---

  src/LyX.cpp   |2 +-
  src/frontends/alert.h |3 ++-
  src/frontends/qt4/GuiAlert.cpp|   15 +++
  src/frontends/qt4/GuiProgress.cpp |   12 
  src/frontends/qt4/GuiProgress.h   |4 ++--
  src/support/CMakeLists.txt|4 
  src/support/ProgressInterface.h   |2 +-
  src/support/Systemcall.cpp|2 +-
  src/support/lassert.cpp   |   35 ++-
  src/support/lassert.h |2 +-
  10 files changed, 49 insertions(+), 32 deletions(-)

diff --git a/src/LyX.cpp b/src/LyX.cpp
index b784831..98c5705 100644
--- a/src/LyX.cpp
+++ b/src/LyX.cpp
@@ -667,7 +667,7 @@ static void error_handler(int err_sig)
if (!msg.empty()) {
lyxerr << "\nlyx: " << msg << endl;
// try to make a GUI message
-   Alert::error(_("LyX crashed!"), msg);
+   Alert::error(_("LyX crashed!"), msg, true);
}

// Deinstall the signal handlers
diff --git a/src/frontends/alert.h b/src/frontends/alert.h
index 4f05234..b96ca1e 100644
--- a/src/frontends/alert.h
+++ b/src/frontends/alert.h
@@ -48,8 +48,9 @@ void warning(docstring const & title, docstring const & 
message,
  /**
   * Display a warning to the user. Title should be a short (general) summary.
   * Only use this if the user cannot perform some remedial action.
+ * On some systems it is possible to show a backtrace.
   */
-void error(docstring const & title, docstring const & message);
+void error(docstring const & title, docstring const & message, bool backtrace 
= false);

  /**
   * Informational message. Use very very sparingly. That is, you must
diff --git a/src/frontends/qt4/GuiAlert.cpp b/src/frontends/qt4/GuiAlert.cpp
index 4e9a8e4..14cce93 100644
--- a/src/frontends/qt4/GuiAlert.cpp
+++ b/src/frontends/qt4/GuiAlert.cpp
@@ -24,6 +24,7 @@
  #include "support/debug.h"
  #include "support/docstring.h"
  #include "support/lstrings.h"
+#include "support/lassert.h"
  #include "support/ProgressInterface.h"

  #include 
@@ -197,12 +198,17 @@ void warning(docstring const & title0, docstring const & 
message,
title0, message, askshowagain);
  }

-void doError(docstring const & title0, docstring const & message)
+void doError(docstring const & title0, docstring const & message, bool 
backtrace)
  {
lyxerr << "Error: " << title0 << '\n'
   << "\n"
   << message << endl;

+   QString details;
+   if (backtrace) {
+   details = 
QString::fromLocal8Bit(to_local8bit(printCallStack()).c_str());
+   }
+
if (!use_gui)
return;

@@ -223,7 +229,8 @@ void doError(docstring const & title0, docstring const & 
message)

ProgressInterface::instance()->error(
toqstr(title),
-   toqstr(message));
+   toqstr(message),
+   details);

qApp->restoreOverrideCursor();

@@ -231,14 +238,14 @@ void doError(docstring const & title0, docstring const & 
message)
theApp()->startLongOperation();
  }

-void error(docstring const & title0, docstring const & message)
+void error(docstring const & title0, docstring const & message, bool backtrace)
  {
  #ifdef EXPORT_in_THREAD
InGuiThread().call(&doError,
  #else
doError(
  #endif
-   title0, message);
+   title0, message, backtrace);
  }

  void doInformation(docstring const & title0, docstring const & message)
diff --git a/src/frontends/qt4/GuiProgress.cpp 
b/src/frontends/qt4/GuiProgress.cpp
index ab8c6bd..a44438d 100644
--- a/src/frontends/qt4/GuiProgress.cpp
+++ b/src/frontends/qt4/GuiProgress.cpp
@@ -56,8 +56,8 @@ GuiProgress::GuiProgress()
SLOT(doWarning(QString const &, QString const &)));
connect(this, SIGNAL(toggleWarning(QString const &, QString const &, 
QString const &)),
SLOT(doToggleWarning(QString const &, QString const &, QString 
const &)));
-   connect(this, SIGNAL(error(QString const &, QString const &)),
-   SLOT(doError(QString const &, QString const &)));
+   connect(this, SIGNAL(error(QString const &, QString const &, QString const 
&)),
+   SLOT(doError(QString const &, QString const &, QString const 
&)));
connect(this, SIGNAL(information(QString const &, QString const &)),
SLOT(doInformation(QString const &, QString const &)));
connect(this, SIGNAL(triggerFlush()),
@@ -183,9 +183,13 @@ void GuiProgress::doToggleWarning(QString const & title, 
QString const & msg, QS
  }


-void GuiProgress::doError(QString const & title, QString const & message)
+void GuiProgress::doError(QString const & title, QString const & message, QString 
const & details)
  {
-   QMessageBox::cri

Re: [PATCH 1/1] On Linux show in crash message box the backtrace

[Peter Kümmel]

--- a/src/support/CMakeLists.txt
+++ b/src/support/CMakeLists.txt
@@ -36,6 +36,10 @@ else()
set(support_linkback_headers "")
  endif()

+if(UNIX AND CMAKE_COMPILER_IS_GNUCC AND NOT APPLE)
+   add_definitions(-DLYX_CALLSTACK_PRINTING)
+endif()
+



Automake build needs to be patched.

Peter

Re: [LyX/master] build with mingw on Windows and Linux

[Peter Kümmel]

On 07.06.2014 11:24, Georg Baum wrote:

Peter Kümmel wrote:


commit 080fca85a8fb6714afd7c34e4070687705fa1cb2
Author: Peter Kümmel 
Date:   Sat Jun 7 07:59:52 2014 +0200

 build with mingw on Windows and Linux


Very nice!


Georg




It even works with the C libraries from the msvc dependency download.
But you have to disable hunspell (by deleting the hunspell headers).

Peter

Re: LyX 2.1.1

[Peter Kümmel]

On 03.06.2014 18:02, Richard Heck wrote:


With this patch in place, I would like to move toward a 2.1.1 release as soon 
as possible. This does not fix the random
crash people have been seeing, but it should prevent really serious dataloss, 
and that is a very good reason for a release.

What other bugs do people think we should try to fix before 2.1.1? Any? Other 
than the one that is such a mystery?

Richard



What about showing a backtrace in the crash dialog (on Linux)?
See PATCH.

Peter

Re: LyX 2.1.0 fatal crash

[Peter Kümmel]

On 30.05.2014 17:53, Paul A. Rubin wrote:

I just lost two to three days of work when LyX 2.1.0 crashed. I have no idea
what triggered the crash (I think I had just clicked into the middle of a
line) and cannot reproduce it. Both the document file and the emergency file
are identically corrupted (truncated). Both are 13.0 KB; the correct length
would be approximately 150 KB. There's nothing that I can find in the buffer
directory (which survived) that would seem to be of use figuring out what
happened.

I've seen reports of lost work recently, but don't know if there is a bug
ticket open on it (or multiple tickets), and I'm not sure I can provide
enough useful information to help. Is this a known issue? Is there any info
beyond the above that might be of use? The OS is Linux Mint 16.

Paul


Sorry to hear you lost three days of work! And thanks for being
still interested in LyX!

At least this shows that current practice of using only one emergency
file does not protect against loosing user data.

LyX should change its strategy here. Maybe 5 rolling emergency files,
in the hope a LyX crash does not delete files which it does not write
to when crashing.

Peter

Re: Build bot on travis

[Peter Kümmel]

On 29.05.2014 13:57, Georg Baum wrote:

Peter Kümmel wrote:


On 26.05.2014 20:57, Georg Baum wrote:


Very nice! Especially the MinGW part is very interesting. Do you have any
plans to put this into the main repo?


No, and I've lost commit rights with the switch to git.
But feel free to chery-pick from the build-bot-* branches.


This is a pity. Unfortunately my git skills are not good enough to chery-
pick something from a different repo. Each time I try to do something non-
trivial with git I fail to find the right --pretty-please --don't-assume-
what-i-want --do-what-i-typed options to make it actually do what I want,
and end up feeling like the creators of http://git-man-page-
generator.lokaltog.net/.



OK, then I will ruin some of my evenings ;)



Georg

Re: Build bot on travis

[Peter Kümmel]

On 26.05.2014 20:57, Georg Baum wrote:

Peter Kuemmel wrote:


Finally I had the time to setup an automatic build for LyX:

 http://syntheticpp.github.io/LyX-bleeding-edge

Runs since several weeks now, so I assume it is quite stable.

It uses MinGW (which is new at all) on Linux.
It generates zips for Windows, master and 2.1.x.
The spell checker stuff is missing due to mingw/3rdparty libs.

At least for Windows users this is a way to get an actual build,
and it could be used by non-hackers to verify a bugfix.


Very nice! Especially the MinGW part is very interesting. Do you have any
plans to put this into the main repo?


No, and I've lost commit rights with the switch to git.
But feel free to chery-pick from the build-bot-* branches.




Georg

Re: Build bot on travis

[Peter Kümmel]

On 26.05.2014 13:28, Scott Kostyshak wrote:

On Sun, May 25, 2014 at 2:07 PM, Peter Kuemmel  wrote:

Finally I had the time to setup an automatic build for LyX:

 http://syntheticpp.github.io/LyX-bleeding-edge

Runs since several weeks now, so I assume it is quite stable.

It uses MinGW (which is new at all) on Linux.
It generates zips for Windows, master and 2.1.x.
The spell checker stuff is missing due to mingw/3rdparty libs.

At least for Windows users this is a way to get an actual build,
and it could be used by non-hackers to verify a bugfix.


This is neat, Peter. Thanks for sharing. It did not seem like you were
asking for feedback, but I can't help but dream :). There are only a
few GCC warnings. If we cleaned them up, would you be interested in
adding a -Werror to either this build or a separate Travis build?


Shouldn't  -Werror not handled by the defaults in the build systems, then
everyone would test it. MinGW on travis is 4.7, and handling warning from
newer compilers would be more interesting.



Scott

Re: Build bot on travis

[Peter Kümmel]

On 26.05.2014 10:58, Jean-Marc Lasgouttes wrote:

25/05/2014 20:07, Peter Kuemmel:

Finally I had the time to setup an automatic build for LyX:

 http://syntheticpp.github.io/LyX-bleeding-edge

Runs since several weeks now, so I assume it is quite stable.

It uses MinGW (which is new at all) on Linux.
It generates zips for Windows, master and 2.1.x.
The spell checker stuff is missing due to mingw/3rdparty libs.

At least for Windows users this is a way to get an actual build,
and it could be used by non-hackers to verify a bugfix.


Hello Peter,

This is very interesting. I would be nice too to generate builds for the 
features/str-metrics branch if possible. This
would help to get feedback from windows users about correctness and performance 
of the new code.

JMarc




Setting up a branch is a bit complicated. What about adding a branch
which is used for test builds in general, not only for str-metrics, and
with the policy to allow hard resets after a notice to the ml?

Peter

Re: Saying Hi !

[Peter Kümmel]

On 28.04.2014 22:31, Tommaso Cucinotta wrote:

On 28/04/14 07:15, Peter Kümmel wrote:

When designing the transfer protocol you should
evaluate Google's Protocol Buffers:

https://developers.google.com/protocol-buffers/docs/overview

Would guarantee a clean interface to the outer world. And you
don't have to think about parsing incoming bytes.


this reminded my of CORBA: we could use it to have seamless invocations
among remote instances of LyX, couldn't we :-) ?


To ride a more recent wave, we should use websockets/json, then a webfrontent
would be possible, and we would be more attractive for the javascript people.

And then sometimes lyx could switch from C++ to javascript ;)

Peter



LyX seems to already have its own way to serialize LFUNs, but I guess we'll
have to serialize more, and specifically DocIterator(s)...

 T.

Re: Saying Hi !

[Peter Kümmel]

On 27.04.2014 22:58, Tommaso Cucinotta wrote:

On 27/04/14 19:33, Scott Kostyshak wrote:

I don't know much about this topic


just in case you missed it, this video shows quickly what it's all about:

   http://retis.sssup.it/~tommaso/lyx-collaborate.ogv

in a kind of mock-up that crashes in a few seconds :-)!

 T.




When designing the transfer protocol you should
evaluate Google's Protocol Buffers:

https://developers.google.com/protocol-buffers/docs/overview

Would guarantee a clean interface to the outer world. And you
don't have to think about parsing incoming bytes.

Peter

Re: RC1 crashes on OSX 10.9

[Peter Kümmel]

On 12.04.2014 09:29, Murat Yildizoglu wrote:

More tests :

Close LyX, Re open it. Reopen the document.
Add a new table
Merge the heading rows
fill the table
let autosave -> no problem
add a new line
copy another line on it
let the autosave> no problem.

So, I have difficulty to locate the factor that triggers this hanging.

Sorry for not being able to help you more :-(


You could try to find LyX's "preferences" file and change the autosave interval 
to 1 second:

# The time interval between auto-saves in seconds.
\autosave 1




Murat Yildizoglu 
11 avril 2014 14:09
More test:

I have merged two cells, waited fro the autobackup, no problem

I have added a new line and copied an old line on it, no problem either.

The auto-bacup takes place.


Vincent van Ravesteijn 
11 avril 2014 12:58

Do you remember that you used the move column/row feature?

If we do not set the mutlicol properties correctly, we might for loop over a 
columns but never find the end  Or
something like that.

Vincent

Vincent van Ravesteijn 
11 avril 2014 12:43


-- Both tables have a cell with with "multicolumn=1" and a cell with
"multicolumn=2" after each other.


[...]




[...]


[...]


Vincent
Vincent van Ravesteijn 
11 avril 2014 11:56


Before the crash I have indeed moved some tables in the document between a 
sigle column and a double column areas.
But it has not crashed immediately. I have started to write some 
supplementary text, and I have the impression
that it crashed either during an automatic save or when I clicked CMD+S, I 
cannot remember exactly. The table are
as they should be in the recovered document, but I have lost the major part 
of the text I have added after having
moved the tables (this text has been added in a section before the tables).

Ok, be careful, if it crashes when you save it, you're sort of losing text.
Further:
-- the example that Uwe added to the bug report was also a table using 
multi-columns
-- the fact that both times it is reported as a random crash usually indicates 
it is triggered by auto-save
-- the fact that the emergency file is written until a certain Table inset 
indicates that there is a problem writing
the document and that is thus triggers a crash during auto-save
-- also I get the impression we end up in an infinite loop.
Vincent
Murat Yildizoglu 
11 avril 2014 11:49
Before the crash I have indeed moved some tables in the document between a 
sigle column and a double column areas.
But it has not crashed immediately. I have started to write some supplementary 
text, and I have the impression that it
crashed either during an automatic save or when I clicked CMD+S, I cannot 
remember exactly. The table are as they
should be in the recovered document, but I have lost the major part of the text 
I have added after having moved the
tables (this text has been added in a section before the tables).




--
Université de Bordeaux  CNRS 


Prof. Murat Yildizoglu 

GREThA (UMR CNRS 5113)
UNIVERSITE DE BORDEAUX
GREThA (UMR CNRS 5113)
MURAT YILDIZOGLU
16 AVENUE LEON DUGUIT
CS 50057
33608 PESSAC CEDEX
FRANCE

Bureau : E-331

yildizoglu.info 

Re: Corkboard code

[Peter Kümmel]

On 18.10.2013 03:32, Vincent van Ravesteijn wrote:


Be warned that this is an orphan branch (i.e. it is not connected to the lyx 
history).

Vincent



Is it possible to integrate an orphan branch without loosing history?

Peter

Re: Corkboard code

[Peter Kümmel]

On 05.11.2013 01:37, Rob Oakes wrote:


On 10/26/2013 03:00 AM, Peter Kümmel wrote:

Hi Rob,

did you make any progress? What is the current status of the code,
and what is your plan? Is someone still working on it?

If current state is not too "hopeless" I would also work on it.

Peter


Hi Peter,

Unfortunately, I have not been able to make much progress. I've got a
couple of projects at work that are sapping nearly all of my time. Free
or otherwise. (We are several weeks over a deadline.)

The current state is actually pretty good. There is some refactoring
that needs to happen so that the code exists inside of a single cohesive
class, and that then needs to be integrated in to the LyX GUI.

On the side of the model, there is some additional work that needs to be
done so that we can support features in the corkboard, but I've got some
good ideas on how it needs to be implemented.

If you're interested, let's set up a Google chat to discuss the current
state. I can describe most everything in a half hour or so. Right now,
that is an easier commitment for me to make than trying to discuss over
email. (Which has been somewhat hard to monitor.)

Cheers,

Rob



Hi Rob,

thanks for the update. Then I start to have a look at current code and
don't wait for your changes. Maybe I come back to to you later.

Cheers,
Peter

Re: Corkboard code

[Peter Kümmel]

On 18.10.2013 04:01, Rob Oakes wrote:


I'm in the process of merging this code into the LyX codebase.
I'll push what I have as soon as I have a chance.
(Probably tomorrow or Saturday.)



Hi Rob,

did you make any progress? What is the current status of the 
code,

and what is your plan? Is someone still working on it?

If current state is not too "hopeless" I would also work on it.

Peter

Re: Corkboard code

[Peter Kümmel]

On 18.10.2013 03:32, Vincent van Ravesteijn wrote:



Apparently Rob has multiple servers.

I pushed the code into the GSOC repo.

http://git.lyx.org/?p=gsoc.git;a=shortlog;h=refs/heads/outliner/master


Be warned that this is an orphan branch (i.e. it is not
connected to the lyx history).

Vincent



Thanks, this is what I was looking for.
Somehow I've overseen the wiki entry and on
  http://www.lyx.org/HowToUseGIT
the link is not listed.

Peter

Clang's memory error detector.

[Peter Kümmel]

Attached a patch to build with Clang and with its "sanitize" 
flags.

It should help to detect wrong memory usage:


http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation

(Some sanitize flags are also available in GCC 4.7/4.8)


Short build recipe for Linux:

1. Build Clang
clone my Clang meta repository:

  git clone https://github.com/syntheticpp/Der-Clang.git

you should be automatically on branch release_33.
Then checkout llvm/clang:

  git submodule init
  git submodule update

Make a build folder and build clang:

  cmake ../Der-Clang/llvm
  make -j8
  make install


2. Build LyX with Clang:

  cmake -DLYX_CLANG=1 ../lyx-devel


Opening some help files didn't report any errors ;)

Peter
>From a305ac0ea77ae705805fb9685ba46cd8cc166926 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Peter=20K=C3=BCmmel?= 
Date: Thu, 17 Oct 2013 20:51:56 +0200
Subject: [PATCH] Add option to build on Linux with Clang's sanitize flags

---
 CMakeLists.txt |   27 -
 development/cmake/modules/Clang-sanitize.cmake |  131 
 2 files changed, 153 insertions(+), 5 deletions(-)
 create mode 100644 development/cmake/modules/Clang-sanitize.cmake

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ccb4a6c..f1b5b1e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -45,10 +45,6 @@ set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
 # Supress regeneration
 set(CMAKE_SUPPRESS_REGENERATION FALSE)
 
-if(NOT help AND NOT HELP)
-	# 'project' triggers the searching for a compiler
-	project(${LYX_PROJECT})
-endif()
 
 if(UNIX)
 	set(ARCH_TRIPLET )
@@ -97,6 +93,7 @@ LYX_OPTION(QUIET"Don't generate verbose makefiles" OFF ALL)
 LYX_OPTION(INSTALL_PREFIX   "Install path for LyX" OFF ALL)
 LYX_OPTION(BUNDLE   "Build bundle  (experimental) " OFF ALL)
 LYX_OPTION(ENABLE_URLTESTS  "Enable for URL tests" OFF ALL)
+LYX_OPTION(CLANG"Use Clang and enable sanitize options" OFF ALL)
 
 # GCC specific
 LYX_OPTION(PROFILE  "Build profile version" OFF GCC)
@@ -132,6 +129,16 @@ endif()
 
 # Check option dependencies
 
+if(LYX_CLANG)
+set(CMAKE_C_COMPILER   "clang"   CACHE PATH "Clang C compiler" FORCE)
+set(CMAKE_CXX_COMPILER "clang++" CACHE PATH "Clang C++ compiler" FORCE)
+endif()
+
+if(NOT help AND NOT HELP)
+	# 'project' triggers the searching for a compiler
+	project(${LYX_PROJECT})
+endif()
+
 if(LYX_DMG)
 	set(LYX_BUNDLE ON)
 	set(LYX_CPACK ON)
@@ -203,7 +210,17 @@ endif()
 
 
 set(LYX_GCC11_MODE)
-if(UNIX OR MINGW)
+
+
+if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
+include(Clang-sanitize)
+set(clang_flags "--std=c++11 ${clang_flags}")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${clang_flags}")
+if(UNIX)
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
+endif()
+elseif(CMAKE_COMPILER_IS_GNUCC)
 	execute_process(COMMAND ${CMAKE_CXX_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION)
 	message(STATUS "Using GCC version ${GCC_VERSION}")
 	if(NOT GCC_VERSION VERSION_LESS 4.4)
diff --git a/development/cmake/modules/Clang-sanitize.cmake b/development/cmake/modules/Clang-sanitize.cmake
new file mode 100644
index 000..dcd356d
--- /dev/null
+++ b/development/cmake/modules/Clang-sanitize.cmake
@@ -0,0 +1,131 @@
+# http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
+
+list(APPEND clflg -fno-omit-frame-pointer)
+
+#set(sanitize-thread 1)
+
+if(NOT sanitize-thread)
+list(APPEND clflg -fsanitize=address)
+# AddressSanitizer, a memory error detector.
+
+list(APPEND clflg -fsanitize=init-order)
+# Make AddressSanitizer check for dynamic initialization order problems.
+# Implied by -fsanitize=address.
+
+list(APPEND clflg -fsanitize=address-full)
+# AddressSanitizer with all the experimental features listed below.
+endif()
+
+list(APPEND clflg -fsanitize=integer)
+# Enables checks for undefined or suspicious integer behavior.
+
+if(sanitize-thread)
+
+# gdb configuration:
+#  - .gdbinit: set disable-randomization off
+#  - gdb -ex 'set disable-randomization off' --args 
+# TSAN_OPTIONS
+
+list(APPEND clflg -fsanitize=thread)
+# ThreadSanitizer, a data race detector.
+endif()
+
+#list(APPEND clflg -fsanitize=memory)
+# MemorySanitizer, an experimental detector of uninitialized reads. Not ready for widespread use.
+
+#list(APPEND clflg -fsanitize=undefined) # Qt uses reinterpret_cast(0)->staticMetaObject
+# Fast and compatible undefined behavior checker. Enables the undefined behavior checks
+# that have small runtime cost and no impact on address space layout or ABI.
+# This includes all of the checks listed below other than unsigned-integer-overflow.
+
+list(APPEND clflg -fsanitize=undefined-trap)
+# This includes all sanitizers included by -fsanitize=undefined, except those that require runtime support.
+# This group of sanitizers are generally used in conjunction with the -fsanitize-undefined-tra

Re: Corkboard code

[Peter Kümmel]

On 17.10.2013 17:13, Vincent van Ravesteijn wrote:


Op 17 okt. 2013 07:27 schreef "Peter Kümmel"
mailto:syntheti...@gmx.net>>:


Hi, I wanna have a look at the corkboard code, but haven't
found a git branch anywhere, only Rob's bazaar repository with
changes from February. Is there something more actual?



The code thay Ashley produced lives somewhere on Rob's
server. It was never transferred into the LyX codebase, so
it was not really possible to put it in the git repo.



Rob's server is https://launchpad.net/lyx-outline ?
I'm asking because there are only commits from Rob.

And at the end of the wiki page 
http://wiki.lyx.org/GSoC/NonLinearWriting
commits are listed which I could not find anywhere, for 
instance:


Vincent's e770c7a:
- Changed the base class of the manager class from 
QMainWindow to QWidget and class name from MainWindow to 
CorkboardWidget or CorkboardManager.

- Reimplemented show() function.

Thanks,
Peter

Corkboard code

[Peter Kümmel]

Hi, I wanna have a look at the corkboard code, but haven't
found a git branch anywhere, only Rob's bazaar repository with
changes from February. Is there something more actual?

Thanks,
Peter

Re: r40402 - lyx-devel/trunk/src/support

[Peter Kümmel]

On 07.12.2011 16:01, Richard Heck wrote:

On 12/07/2011 04:13 AM, Peter Kuemmel wrote:

intention was to have it in 2.0.2, but it was harder than I thought, and
I've been busy (as have we all). Still, the last set of
discussions suggested some real ways forward.


What is the current status? Have you tested the last patches?


Haven't had the energy to get back into it.



One problem was that all processes will be killed,
what would be no issue when lyx is exited afterwards.


Richard

Re: Cmake patch

[Peter Kümmel]

On 07.12.2011 09:24, Benjamin Piwowarski wrote:


On Dec 6, 2011, at 10:14 PM, Peter Kümmel wrote:


On 01.12.2011 10:01, Benjamin Piwowarski wrote:

Hi,

please find two patches (in the same file) for cmake building:
- the first sets the compiler to gcc for Xcode (based on Xcode version)


What happens if the compiler is not set? Does it use clang?

yes


Couldn't we also
build lyx with clang?

we could - but there is at least one compilation issue.



I've fixed one issue and it compiles with clang from trunk (>3.0).

Or do you think it is a better to compile with gcc anyway?

Peter

Re: CMake problems was: removing scons

[Peter Kümmel]

There is another issue I noticed:

Even if I just have compiled LyX and thus all libs are upt to date, the 
po-files are recreated. This
is unnecessary because nothing has been changed. Is it possible to check also 
for the po files if
something was changed and compile only then?



Same here, I've tried to fix it, but somehow Studio "thinks" it has to recreate 
the .pot files.
The copy_if_different cmake-trick does not work.

(Therefore the idea to use jom)

Peter

Re: Cmake patch

[Peter Kümmel]

On 01.12.2011 10:01, Benjamin Piwowarski wrote:

Hi,

please find two patches (in the same file) for cmake building:
- the first sets the compiler to gcc for Xcode (based on Xcode version)


What happens if the compiler is not set? Does it use clang? Couldn't we also
build lyx with clang?

-- you could use endif() and else()

Peter


- the second sets a full path for Doxyfile (in sourcedoc/CMakelists.txt) so 
that the doxydoc target works

Benjamin

Re: Some remaining CMake problems

[Peter Kümmel]

On 05.12.2011 22:19, Uwe Stöhr wrote:

Am 05.12.2011 13:36, schrieb Vincent van Ravesteijn:


1 Warning(s)


This seems not harmful. This is just a warning that tells you that 
static_mutex.cpp is sort of empty
because BOOST_HAS_THREADS is not defined. This shouldn't also be related to 
CMake.

Is it a real problem for you ?


No, I only wanted to report everything I found. If it's not a problem, fine 
with me.


Problem 2:

The compile tex2lyx.exe does not have an icon. But it should have the same icon 
as the compiled
lyx.exe


If you grep for "lyx.rc", you'll see how to fix this.

I fixed it in r40375.


Thanks. I backported this to branch.


Problem 3:

The compiled tex2lyx.exe is broken. You can test by trying to import a TeX file of 
your choice ->
it will always fail. But when I build it with SCons, it works fine. Moreover, 
when compiling
branch with CMake, it works too, only in trunk it fails.


It works for me.


It still doesn't work for me. I build LyX using the build.bat in the SVN folder 
development/cmake.
Does it work for you also when compiling calling this script?


When I call it from the debugger I get:
"Unable to determine the path to the LyX binary from the command line tex2lyx"

Seems there are problems with the pathes.




thanks and regards
Uwe

Re: Trunk tarballs broken by cmake & boost

[Peter Kümmel]

On 06.12.2011 00:14, Pavel Sanda wrote:

cmake folks,

its impossible to create tarballs of trunk because of changing locations
of various CMakeLists.txt files without changing makefiles accordingly.
quick fix is to simply kill these files in tarballs but i guess you dont
want that (see attachment for crude version).

please fix it in a ways it is convenient for cmake (run "make dist" to see 
various errors).


Peter, building from tarballs with included boost is broken:


AH! I found a reason for the zipped boost-header file ;)



make[2]: Entering directory `/trash/lyx-2.1.0svn/boost'
g++ -DHAVE_CONFIG_H -I. -I..  -DBOOST_USER_CONFIG="" -I../boost 
-Wextra -Wall-O -MT c_regex_traits.o -MD -MP -MF .deps/c_regex_traits.Tpo -c -o 
c_regex_traits.o `test -f 'libs/regex/src/c_regex_traits.cpp' || echo 
'./'`libs/regex/src/c_regex_traits.cpp
libs/regex/src/c_regex_traits.cpp:24:25: error: internals.hpp: No such file or 
directory



Couldn't find the file where I have to add the new boost files.



pavel

Re: Trunk tarballs broken by cmake & boost

[Peter Kümmel]

On 06.12.2011 00:14, Pavel Sanda wrote:

cmake folks,

its impossible to create tarballs of trunk because of changing locations
of various CMakeLists.txt files without changing makefiles accordingly.
quick fix is to simply kill these files in tarballs but i guess you dont
want that (see attachment for crude version).

please fix it in a ways it is convenient for cmake (run "make dist" to see 
various errors).


Peter, building from tarballs with included boost is broken:


make dist is broken because it tries to pack .svn dirs.



make[2]: Entering directory `/trash/lyx-2.1.0svn/boost'
g++ -DHAVE_CONFIG_H -I. -I..  -DBOOST_USER_CONFIG="" -I../boost 
-Wextra -Wall-O -MT c_regex_traits.o -MD -MP -MF .deps/c_regex_traits.Tpo -c -o 
c_regex_traits.o `test -f 'libs/regex/src/c_regex_traits.cpp' || echo 
'./'`libs/regex/src/c_regex_traits.cpp
libs/regex/src/c_regex_traits.cpp:24:25: error: internals.hpp: No such file or 
directory


pavel

Re: Some remaining CMake problems

[Peter Kümmel]

On 05.12.2011 02:11, Uwe Stöhr wrote:

Am 05.12.2011 02:05, schrieb Uwe Stöhr:

I have still some problems with CMake:


Problem 4:

I want to compile the lyx.exe in devel mode with its console (to e.g. see 
shortcut conflicts).

I therefore compile with the compiler option

-DLYX_CONSOLE=ON

But the result is still a lyx.exe without a console. What can I do to get the 
console?

regards Uwe




LYX_INSTALL overwrites LYX_CONSOLE:

if(LYX_INSTALL)
set(LYX_NLS ON)
if (WIN32)
set(LYX_HUNSPELL ON)
endif()
set(LYX_CONSOLE OFF)
set(LYX_PACKAGE_SUFFIX ON)
set(LYX_RELEASE ON)
set(LYX_PROFILE OFF)
endif()


But I've added added a way to overwrite this:

-DLYX_CONSOLE=FORCE

Peter

Re: CMake problems was: removing scons

[Peter Kümmel]

On 28.11.2011 01:54, Uwe Stöhr wrote:

Am 28.11.2011 01:50, schrieb Uwe Stöhr:


After some fiddling I got it to compile.


There is one warning when compiling the po-files:

CUSTOMBUILD : cygwin warning :  
[D:\LyXSVN\lyx-devel\compile-result\po\translations.vcxproj]
  MS-DOS style path detected: D:/LyXSVN/lyx-devel/compile-result/po/fi.po
  Preferred POSIX equivalent is: 
/cygdrive/d/LyXSVN/lyx-devel/compile-result/
po/fi.po
  CYGWIN environment variable option "nodosfilewarning" turns off this 
warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

I had the same problem with SCons and did not find a solution tom get rid of 
this. Any idea?


"CYGWIN environment variable option "nodosfilewarning" turns off this warning."

The environment varable helps:

set cygwin=nodosfilewarning

or add it globally.



regards Uwe

Re: LyX trunk builded with Qt creator on Ubuntu 11.10

[Peter Kümmel]

On 02.12.2011 20:25, André Pönitz wrote:

On Thu, Dec 01, 2011 at 08:49:16PM -0500, Richard Heck wrote:

On 12/01/2011 06:41 PM, André Pönitz wrote:

On Thu, Dec 01, 2011 at 06:36:33AM +0200, Nicu Tofan wrote:

Hello!

I've created the attached .pro file from the source files in the trunk, while
looking into CMakeLists. The purpose was for me to be able to use QtCreator to
examine/change the source code. I have also tried for some time to include the
invocation of mkres.sh script as a custom build step and failed. As such,
mkres.sh must be run before attempting a build.
Please note that this is for my personal use (and for whoever wants to use it),
it's not a proposal/request to use qmake/QtCreator/.pro files as an alternative
official build method. This implies that I am fully aware that LyX has no
official .pro support and it was not designed to be constructed this way.

Creating fully functional .pro files would be a lot of work, and it's
not needed to use Qt Creator. You can directly use the CMakeList.txt
or (since yesterday ;-}) the Makefile.am.


Can you explain quickly what this means? I have in the past just used
the import facility of Qt Creator, and it seems to work fine.


Then why change it? [We are probably talking about the same thing
anyway]

The autotools support was a contribution, and it seems to be rather
basic when it comes to building, but seemingly parses the LyX


It nicely calls autogen.sh, then configure, and then make.
Do you miss the target list in the make dialog?


Makefile.am's fine (which was actually used as sanity check before
integration)

Would be just File->Open File or Project, either lyx-devel/CMakeLists.txt
or lyx-devel/Makefile.am. Or add that on the command line when starting
Creator.

[Btw I always recommend using sessions, even if they are still too clumsy to
setup for my taste (use is easy later...)]


AH, never tried session. The only way to restore breakpoints?



Andre'

PS: Better discuss this on qt-crea...@qt-project.org?

Re: LyX 2.0.2 Source Available for Testing

[Peter Kümmel]

On 26.11.2011 11:01, Peter Kümmel wrote:

On 26.11.2011 02:18, Richard Heck wrote:

On 11/25/2011 04:14 PM, Peter Kümmel wrote:

On 25.11.2011 18:49, Richard Heck wrote:


I have put the LyX 2.0.2 tarballs here:
   http://frege.brown.edu/lyx/
Please let me know if you have any problems, and let me know the status
of binaries, too. I'll plan to do the real release in a few days,
possibly Monday.

Richard



For cmake builds with msvc attached patch is needed.


OK, so what is the procedure at this point? I assume we should commit
this and rebuild. Then do I delete the existing 2.0.2 tag and redo it?
or what?



I think it would be enough when the changes are in the final release,


I've overseen that this package _is_ the final release. So you are right
in moving the tag.


and doesn't needs more testting, because the patch is not critical:

- CMakeLists: changed download address
- FindLyXGettext: is tested by trunk
- Makefile.am: wrong files in package

I commit, and you simply do the finale release.

Peter

PS.
Nice link, didn't know TLP is available as pdf, Wittgenstein died 1951.

Re: LyX 2.0.2 Source Available for Testing

[Peter Kümmel]

On 26.11.2011 02:18, Richard Heck wrote:

On 11/25/2011 04:14 PM, Peter Kümmel wrote:

On 25.11.2011 18:49, Richard Heck wrote:


I have put the LyX 2.0.2 tarballs here:
  http://frege.brown.edu/lyx/
Please let me know if you have any problems, and let me know the status
of binaries, too. I'll plan to do the real release in a few days,
possibly Monday.

Richard



For cmake builds with msvc attached patch is needed.


OK, so what is the procedure at this point? I assume we should commit
this and rebuild. Then do I delete the existing 2.0.2 tag and redo it?
or what?



I think it would be enough when the changes are in the final release,
and doesn't needs more testting, because the patch is not critical:

- CMakeLists: changed download address
- FindLyXGettext: is tested by trunk
- Makefile.am: wrong files in package

I commit, and you simply do the finale release.

Peter

PS.
Nice link, didn't know TLP is available as pdf, Wittgenstein died 1951.

Re: LyX 2.0.2 Source Available for Testing

[Peter Kümmel]

On 25.11.2011 18:49, Richard Heck wrote:


I have put the LyX 2.0.2 tarballs here:
 http://frege.brown.edu/lyx/
Please let me know if you have any problems, and let me know the status
of binaries, too. I'll plan to do the real release in a few days,
possibly Monday.

Richard



For cmake builds with msvc attached patch is needed.

Peter
Index: development/cmake/CMakeLists.txt
===
--- development/cmake/CMakeLists.txt	(revision 40281)
+++ development/cmake/CMakeLists.txt	(working copy)
@@ -109,13 +109,14 @@
 	message(STATUS)
 	set(LYX_DEPENDENCIES_DIR ${CMAKE_BINARY_DIR}/msvc2010-deps)
 	message(STATUS "Using downloaded dependencies in ${LYX_DEPENDENCIES_DIR}")
-	set(deps_files lyx20-deps-msvc2010-x86.zip)
+	set(deps_files lyx20-deps-msvc2010.zip)
+	set(deps_server http://downloads.sourceforge.net/project/lyx/Win_installers/Dependencies)
 	foreach(it ${deps_files})
 		set(already_downloaded already_downloaded-NOTFOUND CACHE PATH "downloaded" FORCE)
 		find_file(already_downloaded ${it} "${LYX_DEPENDENCIES_DIR}/download")
 		if(NOT already_downloaded)
 			message(STATUS "Downloading ${it} ...")
-			file(DOWNLOAD ftp://ftp.devel.lyx.org/pub/contrib/windows/${it} ${LYX_DEPENDENCIES_DIR}/download/${it} SHOW_PROGRESS)
+			file(DOWNLOAD ${deps_server}/${it} ${LYX_DEPENDENCIES_DIR}/download/${it} SHOW_PROGRESS)
 			execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${LYX_DEPENDENCIES_DIR}/download/${it}
 		  WORKING_DIRECTORY ${LYX_DEPENDENCIES_DIR})
 		endif()
Index: development/cmake/modules/FindLyXGettext.cmake
===
--- development/cmake/modules/FindLyXGettext.cmake	(revision 40281)
+++ development/cmake/modules/FindLyXGettext.cmake	(working copy)
@@ -12,7 +12,7 @@
 #ALL option is used, the translations will also be created when
 #building the default target.
 
-set(hints "HINTS ${GNUWIN32_DIR}/deps20/gettext-tools")
+set(hints HINTS "${GNUWIN32_DIR}/gettext-tools")
 FIND_PROGRAM(GETTEXT_MSGMERGE_EXECUTABLE msgmerge  ${hints})
 FIND_PROGRAM(GETTEXT_MSGFMT_EXECUTABLE   msgfmt${hints})
 FIND_PROGRAM(GETTEXT_XGETTEXT_EXECUTABLE xgettext  ${hints})
Index: development/Makefile.am
===
--- development/Makefile.am	(revision 40281)
+++ development/Makefile.am	(working copy)
@@ -147,7 +147,7 @@
 cmake/pcheaders.h \
 cmake/boost/CMakeLists.txt \
 cmake/doc/CMakeLists.txt \
-cmake/doc/ReplaceValues.pl \
+cmake/doc/ReplaceValues.py \
 cmake/intl/CMakeLists.txt \
 cmake/intl/libgnuintl.h \
 cmake/lyx2lyx/CMakeLists.txt \

Re: tar'ed boost headers

[Peter Kümmel]

On 23.11.2011 02:13, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

[...]

That is just a number. How does that change anything?
On bad effect you will get with i a tar.gz is unwanted size
increase in subversion repository size. (one boost.tar.gz each time it
is updated.)




| 13 updates would be the break-even.

What do you mean?

Boost is already in the repo, each current update will enlarge the repo
by very little. Each new boost.tar.gz on the other hand will enlarge the
repo with the full size of the tar.gz.



Yes, when it is already in it doesn't count.

I wonder if git uses a binary diff?

Peter

Re: Some warnings with gcc 4.7

[Peter Kümmel]

On 22.11.2011 21:37, André Pönitz wrote:

On Tue, Nov 22, 2011 at 08:29:44PM +0100, Peter Kümmel wrote:

On 21.11.2011 23:32, André Pönitz wrote:

On Mon, Nov 21, 2011 at 10:53:49PM +0100, Peter Kümmel wrote:

On 21.11.2011 21:24, André Pönitz wrote:


First guess: gcc sees 'virtual' on two member functions but no virtual
destructor, cannot prove that delete operates only on static type ==



Yes, seems the warning is completely valid: GuiWorkArea::Private has a
virtual table but no virtual destructor. It points to superfluous
virtual functions which are wrong in GuiWorkArea::Private and only
slow down the code.


We seem to have different opions on what constitutes a "valid" warning.

I am not a native English speaker, but in my limited understanding of
the language

   "GuiWorkArea.cpp:327:9: warning: deleting object of polymorphic class type
   ‘lyx::frontend::GuiWorkArea::Private’ which has non-virtual destructor might
   cause undefined behaviour "


But this statement is still correct (polymorphic and non-virtual destructor),
the other was only my optinion. It is like a hint to a coding-rule.


This particular code is safe, and the compiler has all the information
necessary to even prove it. It chose to complain instead.

Next year we'll get compiler warnings on "i = 1;" as there's the
possibility that the programmer meant to say "i = 2;" ...

And I don't buy the "coding rule" reasoning as the line number given
by the compiler is completely unrelated to the two lines that need
to be changed to solve the "issue" properly.

A naive follow-up on the compiler's advice would have been to make
the destructor virtual, which would have "wasted" a dozen more cyles.



Maybe the warning isn't perfect, but in principle I find it a good idea
to get a message by the compiler in this case.



Andre"

Re: Some warnings with gcc 4.7

[Peter Kümmel]

On 21.11.2011 23:32, André Pönitz wrote:

On Mon, Nov 21, 2011 at 10:53:49PM +0100, Peter Kümmel wrote:

On 21.11.2011 21:24, André Pönitz wrote:


First guess: gcc sees 'virtual' on two member functions but no virtual
destructor, cannot prove that delete operates only on static type ==



Yes, seems the warning is completely valid: GuiWorkArea::Private has a
virtual table but no virtual destructor. It points to superfluous
virtual functions which are wrong in GuiWorkArea::Private and only
slow down the code.


We seem to have different opions on what constitutes a "valid" warning.

I am not a native English speaker, but in my limited understanding of
the language

   "GuiWorkArea.cpp:327:9: warning: deleting object of polymorphic class type
   ‘lyx::frontend::GuiWorkArea::Private’ which has non-virtual destructor might
   cause undefined behaviour "


But this statement is still correct (polymorphic and non-virtual destructor),
the other was only my optinion. It is like a hint to a coding-rule.



and

   "GuiWorkArea.cpp:112:9: warning: declaring a virtual function in a
   class that is never subclassed might make generated code slower than
   needed when using bad code generators which are not able to substitute
   a direct base call after detecting the fact. As I am a good compiler
   and just detected the possibility to perform said optimization, I just
   applied it and did not even bother you with a warning.
   Now, please forget what you just saw."

are not equivalent.

Andre'

PS: Spoiler ahead.

The line numbers differ.

Re: 'Reply' sends to list.

[Peter Kümmel]

On 21.11.2011 23:11, Vincent van Ravesteijn wrote:

I use thunderbird, and all I know now is that I have to somehow install

locally

a duplicate filter.




I use thunderbird as well.

And I didn't install any filter.


And I tought I missed something.

My current workflow is:
  - click reply
  - change "To:" to lyx-devel
  - click send
  - feed the spell checker dialog

Seems nothing happens the last years ;)




Maybe its the mailserver. I use gmail (lyx.org) and previously the email of
work. Never saw any duplication?

Maybe you can try your lyx address?

Vincent

Re: 'Reply' sends to list.

[Peter Kümmel]

On 21.11.2011 23:11, Vincent van Ravesteijn wrote:

I use thunderbird, and all I know now is that I have to somehow install

locally

a duplicate filter.




I use thunderbird as well.

And I didn't install any filter.

Maybe its the mailserver. I use gmail (lyx.org) and previously the email of
work. Never saw any duplication?

Maybe you can try your lyx address?


AH! And Lars is back on the list, Lars do you here me? I don't have a lyx 
address ;)



Vincent

Re: Some warnings with gcc 4.7

[Peter Kümmel]

On 21.11.2011 21:24, André Pönitz wrote:


First guess: gcc sees 'virtual' on two member functions but no virtual
destructor, cannot prove that delete operates only on static type ==



Yes, seems the warning is completely valid: GuiWorkArea::Private has a
virtual table but no virtual destructor. It points to superfluous
virtual functions which are wrong in GuiWorkArea::Private and only
slow down the code.


dynamic type (even though it could in theory, as all is in one
compilation unit...), and chooses to squeak "just in case" instead of
assuming the programmer roughly knows what he does.

You could try to remove the two 'virtual' in GuiWorkArea::Private
and check whether the message is gone.

GuiWorkArea itself already inherits a virtual constructor. If that
triggered the compiler warning it would be even more eccentric.

Andre'

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 20:50, André Pönitz wrote:

On Mon, Nov 21, 2011 at 10:11:11AM +0100, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:



This is boost warning if I am not mistaken.
I guess the boost people can trivially change this to std::unique_ptr.

Systemcall.cpp: In constructor 
‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
string&)’:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.



| The SIGNAL/SLOT macro. In Qt5 there will be a template based connect without
| any macros (but mocing will remain).

That is good news.


Which, lacking run-time introspection in the core language, will only
work for connections with defined targets at compile time, i.e. no
simple "service discovery" through plugins, or over the network etc.


we not even have shared libraries.



But sure, LyX's signal/slot use would be covered.

Andre'

Re: 'Reply' sends to list.

[Peter Kümmel]

On 21.11.2011 11:46, Stephan Witt wrote:

Am 21.11.2011 um 09:54 schrieb Lars Gullik Bjønnes:


Stephan Witt  writes:

| Am 20.11.2011 um 23:16 schrieb Lars Gullik Bjønnes:



Stephan Witt  writes:

| Am 08.11.2011 um 22:40 schrieb Abdelrazak Younes:



On 08/11/2011 22:10, Peter Kümmel wrote:

On 08.11.2011 22:07, Vincent van Ravesteijn wrote:

Op 8-11-2011 22:03, Peter Kümmel schreef:

On 08.11.2011 21:59, Vincent van Ravesteijn wrote:

Op 8-11-2011 21:48, Peter Kümmel schreef:

Is it still necessary to disable the reply function for this list?

Most people are now used to press "reply all" which only
produces unneeded duplicates.

Peter


I don't understand what the problem is of "reply all".


I got your email twice, that's the problem.


You can do something about it yourself.


I don't understand. How could I prevent you to send me a private email?


By using a bit more intelligent mail program :-)



| I have to edit most of the to addresses of my replies and my reply to field 
too.
| AFAICS, only Pavel is one of the rare people sending mails with the
| "correct" reply to.

Actaully I would argue that he, and you. are the ones doing it wrong.



| Wrong? Why?

F.ex. you setting a Reply-To: on an answer to my mail, and discarding
all my careful added Tos and Ccs.


AFAICS you are sending your mails to lyx-devel only.
So when you're using more addressees it is carefully added indeed.
I'll respect this in the future for your mails.

OTOH, e.g. Peter is one of those who don't want to get the answers twice.

The problem I have is: I'm used to Apple-Mail because of the perfect fit
to the other tools I'm using. And I don't have the time to learn how to mimic
procmail filters with some super clever Applescript and I couldn't find one
on the net either. So, perhaps the more intelligent mail program
regarding mailing-list communication is thunderbird, e.g. But I don't want
to use it. It's like an outlaw in the workflow I'm used to and I'm not sure
it plays well with my calendars and contacts.



I use thunderbird, and all I know now is that I have to somehow install locally
a duplicate filter.



Stephan

Re: 'Reply' sends to list.

[Peter Kümmel]

On 21.11.2011 08:28, Stephan Witt wrote:

Am 20.11.2011 um 23:16 schrieb Lars Gullik Bjønnes:


Stephan Witt  writes:

| Am 08.11.2011 um 22:40 schrieb Abdelrazak Younes:



On 08/11/2011 22:10, Peter Kümmel wrote:

On 08.11.2011 22:07, Vincent van Ravesteijn wrote:

Op 8-11-2011 22:03, Peter Kümmel schreef:

On 08.11.2011 21:59, Vincent van Ravesteijn wrote:

Op 8-11-2011 21:48, Peter Kümmel schreef:

Is it still necessary to disable the reply function for this list?

Most people are now used to press "reply all" which only
produces unneeded duplicates.

Peter


I don't understand what the problem is of "reply all".


I got your email twice, that's the problem.


You can do something about it yourself.


I don't understand. How could I prevent you to send me a private email?


By using a bit more intelligent mail program :-)



| I have to edit most of the to addresses of my replies and my reply to field 
too.
| AFAICS, only Pavel is one of the rare people sending mails with the
| "correct" reply to.

Actaully I would argue that he, and you. are the ones doing it wrong.


Wrong? Why?

I understand that it's not wise to force everybody to reply-to list.
But if I decide to get the reply only once and get it from the list...
what's wrong with sending my 2cent emails to list and set the reply-to
to the list address too? Do you mean it's too much manual work?

BTW, not everybody has the opportunity or is in the mood to use procmail.
I cannot believe that you don't know that.


"oh lord won't you buy me a mercedes benz"



Stephan

Re: Trunk not compilable with new boost?

[Peter Kümmel]

On 21.11.2011 11:29, Kornel Benko wrote:

Am Sonntag, 20. November 2011 um 21:51:25, schrieb Peter 
Kümmel

On 20.11.2011 21:31, Kornel Benko wrote:

Am Sonntag, 20. November 2011 um 20:57:24, schrieb Kornel Benko

I get now:
...
Linking CXX executable ../bin/lyx
...
../lib/libboost_regex.a(regex.cpp.o): In function 
`boost::re_detail::get_mem_block()':
regex.cpp:(.text+0x133): undefined reference to 
`boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&,
 bool)'
regex.cpp:(.text+0x158): undefined reference to 
`boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()'
regex.cpp:(.text+0x17e): undefined reference to 
`boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()'
../lib/libboost_regex.a(regex.cpp.o): In function 
`boost::re_detail::put_mem_block(void*)':
regex.cpp:(.text+0x1a6): undefined reference to 
`boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&,
 bool)'
regex.cpp:(.text+0x1cf): undefined reference to 
`boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()'
...

Kornel


Solved, corrected the cmake-build now.


rm -rf is your (dangerous) friend ;)



Kornel


It was a clean build. But nonetheless, the appropriate CMakeLists.txt is 
corrected now.


Sorry, I've tested it on Ubuntu and got no errors, didn't realized that there 
is a new file.



Kornel

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 10:10, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.

Oh well... I'll wait half a year before repeating that test. Hopefully a
new version of Qt will have been released by then.




| There will be 4.8. But updating to 5.0 is maybe superfluous: much
| trouble but no benefit, not much will happen on the QWidget side.

I think Qt might need to change a bit for the new C++11 compilers that
will be released during the next years. Not to use the new C++11


Most things are trivial. They only haven't tested it with 4.7.


features, but to at least compile with the new compilers.
(And the errors that I see with lyx and gnu++11 can just as well be gcc
problems as Qt problems as of now.)

Re: tar'ed boost headers

[Peter Kümmel]

On 21.11.2011 09:51, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

| On 20.11.2011 23:23, Lars Gullik Bjønnes wrote:

Peter Kümmel   writes:

| Currently we have 4800 files in trunk.
| 1500 file are boost headers. These 1500
| files we never touch, but we check them out,
| check them for changes, and so on.

so?



| adding or removing files on a boost update, setting
| the eol-sytle property.

Hmm.

eol-style seems like a red herring. That should be solvable with
.subversion settings. Or are there problems with this that I have not
seen?

adding/removing files on boost update: But you are not going to use the
upstreams boost.tgz are you? So you will have to create a new one each
time, a new release is out?





| It is simple to replace the files with one tar.gz
| which will be extracted while the autogen.sh or cmake run.



| What do you think about replacing boost/boost
| by boost/boost.tar.gz and attached patch?

I think it makes life harder.




| The patch wasn't hard.



And what you do gain by this added complexity?



| I have to move around 1500 files less.

That is just a number. How does that change anything?
On bad effect you will get with i a tar.gz is unwanted size
increase in subversion repository size. (one boost.tar.gz each time it
is updated.)



13 updates would be the break-even.

Re: 'Reply' sends to list.

[Peter Kümmel]

On 21.11.2011 08:51, Vincent van Ravesteijn wrote:



Actaully I would argue that he, and you. are the ones doing it wrong.


Wrong? Why?

I understand that it's not wise to force everybody to reply-to list.
But if I decide to get the reply only once and get it from the list...
what's wrong with sending my 2cent emails to list and set the reply-to
to the list address too? Do you mean it's too much manual work?


No, because you're forcing your will onto others. If I want to reply to
you, I don't want you to overrule me by sending my reply to the list. If
I want to reply to all, I don't want you to overrule me by removing all
people from the cc list.



BTW, not everybody has the opportunity or is in the mood to use procmail.
I cannot believe that you don't know that.


Well, I do not use procmail, and I never get the mails twice.


When I send you two mails you get only one?




Stephan


Vincent

Re: tar'ed boost headers

[Peter Kümmel]

On 20.11.2011 23:24, Lars Gullik Bjønnes wrote:

André Pönitz  writes:

| On Sun, Nov 20, 2011 at 09:54:48PM +0100, Peter Kümmel wrote:

On 20.11.2011 21:47, Peter Kümmel wrote:

Currently we have 4800 files in trunk.
1500 file are boost headers. These 1500
files we never touch, but we check them out,
check them for changes, and so on.



| How many of these 1500 files are used by LyX?

I really feel that you are shooting ants.

IMHO using time to only work with a distributions boost would be better
than fiddling aroung with this.


Yes, most linux versions now should come with a usable boost version,
and on Windows we could put it into the dependencies package.

Peter

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:


This is boost warning if I am not mistaken.
I guess the boost people can trivially change this to std::unique_ptr.

Systemcall.cpp: In constructor 
‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
string&)’:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.


The SIGNAL/SLOT macro. In Qt5 there will be a template based connect without
any macros (but mocing will remain).



Oh well... I'll wait half a year before repeating that test. Hopefully a
new version of Qt will have been released by then.

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.

Oh well... I'll wait half a year before repeating that test. Hopefully a
new version of Qt will have been released by then.



There will be 4.8. But updating to 5.0 is maybe superfluous: much
trouble but no benefit, not much will happen on the QWidget side.

Peter

Re: tar'ed boost headers

[Peter Kümmel]

On 20.11.2011 23:23, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

| Currently we have 4800 files in trunk.
| 1500 file are boost headers. These 1500
| files we never touch, but we check them out,
| check them for changes, and so on.

so?


adding or removing files on a boost update, setting
the eol-sytle property.



| It is simple to replace the files with one tar.gz
| which will be extracted while the autogen.sh or cmake run.



| What do you think about replacing boost/boost
| by boost/boost.tar.gz and attached patch?

I think it makes life harder.



The patch wasn't hard.


And what you do gain by this added complexity?


I have to move around 1500 files less.

Re: tar'ed boost headers

[Peter Kümmel]

On 20.11.2011 22:30, André Pönitz wrote:

On Sun, Nov 20, 2011 at 09:54:48PM +0100, Peter Kümmel wrote:

On 20.11.2011 21:47, Peter Kümmel wrote:

Currently we have 4800 files in trunk.
1500 file are boost headers. These 1500
files we never touch, but we check them out,
check them for changes, and so on.


How many of these 1500 files are used by LyX?

Andre'



Boost ships a tool which extracts all dependencies for a include.
The 1500 files is the output. Not sure if these 1500 file are
really needed.

Peter

Re: tar'ed boost headers

[Peter Kümmel]

On 20.11.2011 21:47, Peter Kümmel wrote:

Currently we have 4800 files in trunk.
1500 file are boost headers. These 1500
files we never touch, but we check them out,
check them for changes, and so on.

It is simple to replace the files with one tar.gz
which will be extracted while the autogen.sh or cmake run.

What do you think about replacing boost/boost
by boost/boost.tar.gz and attached patch?



13MB are needed by the extracted headers, 990kB by boost.tar.gz.


Peter

Re: Trunk not compilable with new boost?

[Peter Kümmel]

On 20.11.2011 21:31, Kornel Benko wrote:

Am Sonntag, 20. November 2011 um 20:57:24, schrieb Kornel Benko

I get now:
...
Linking CXX executable ../bin/lyx
...
../lib/libboost_regex.a(regex.cpp.o): In function 
`boost::re_detail::get_mem_block()':
regex.cpp:(.text+0x133): undefined reference to 
`boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&,
 bool)'
regex.cpp:(.text+0x158): undefined reference to 
`boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()'
regex.cpp:(.text+0x17e): undefined reference to 
`boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()'
../lib/libboost_regex.a(regex.cpp.o): In function 
`boost::re_detail::put_mem_block(void*)':
regex.cpp:(.text+0x1a6): undefined reference to 
`boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&,
 bool)'
regex.cpp:(.text+0x1cf): undefined reference to 
`boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()'
...

Kornel


Solved, corrected the cmake-build now.


rm -rf is your (dangerous) friend ;)



Kornel

tar'ed boost headers

[Peter Kümmel]

Currently we have 4800 files in trunk.
1500 file are boost headers. These 1500
files we never touch, but we check them out,
check them for changes, and so on.

It is simple to replace the files with one tar.gz
which will be extracted while the autogen.sh or cmake run.

What do you think about replacing boost/boost
by boost/boost.tar.gz and attached patch?

Peter

Index: boost/CMakeLists.txt
===
--- boost/CMakeLists.txt	(Revision 40235)
+++ boost/CMakeLists.txt	(Arbeitskopie)
@@ -4,5 +4,11 @@
 # Copyright (c) 2006-2011 Peter Kümmel, 
 #
 
+if (NOT EXISTS ${CMAKE_BINARY_DIR}/boost/boost)
+  message(STATUS "Extracting boost ...")
+  execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${CMAKE_SOURCE_DIR}/boost/boost.tar.gz
+  WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/boost)
+endif()
+
 add_subdirectory(libs) 
 
Index: autogen.sh
===
--- autogen.sh	(Revision 40235)
+++ autogen.sh	(Arbeitskopie)
@@ -87,6 +87,12 @@
 echo "Building po/POTFILES.in..."
 make -s -f po/Rules-lyx srcdir=po top_srcdir=. po/POTFILES.in
 
+if [ ! -d boost/boost ]
+then
+echo "Extracing boost headers..."
+tar -xf boost/boost.tar.gz -C boost
+fi
+
 echo
 echo 'run "./configure ; make"'
 echo
Index: CMakeLists.txt
===
--- CMakeLists.txt	(Revision 40235)
+++ CMakeLists.txt	(Arbeitskopie)
@@ -482,7 +482,7 @@
 		set(Lyx_Boost_Libraries boost_signals boost_regex)
 	endif()
 	add_definitions(-DBOOST_USER_CONFIG="")
-	include_directories(${TOP_SRC_DIR}/boost)
+	include_directories(${TOP_BINARY_DIR}/boost)
 	add_subdirectory(boost "${TOP_BINARY_DIR}/boost")
 endif()
 

Re: r40232 - in lyx-devel/trunk/src: . support

[Peter Kümmel]

On 20.11.2011 21:13, Jean-Marc Lasgouttes wrote:

Le Sun Nov 20 20:44:09 2011, kuem...@lyx.org a écrit :

+#include "support/metahash.h"
+
+typedef boost::mpl::string<'\\end','_lay','out'>   end_layout;
+typedef boost::mpl::string<'\\end','in','set'> end_inset;


Note how you forgot the _ above in end_inset. This kind of problem is a
typical reason why I do not like much this thing. What problem does it
solve that we cannot solve by grouping of if/else clauses? This is not
even particularly elegant IMO.



But such strings are added only one time, so being more careful than
with other stuff should avoid it.
(And if we would have unit tests it would be no problem.)


JMarc

Re: [patch] tex2lyx support for external templates - MSVC hack

[Peter Kümmel]

On 20.11.2011 16:45, Georg Baum wrote:

Peter Kümmel wrote:


The idea is nice, but the 4-character restriction makes it quite
unreadable IMHO.


Played around a bit and found this readable solution:


typedef boost::mpl::string<'\\end','_lay','out'>  end_layout;
typedef boost::mpl::string<'\\end','in','set'>end_inset;

...


switch (boost::hash_value(token)) {
case hash_string::value:
LYXERR0("Solitary \\end_layout in line "<<  lex.lineNumber()<<  "\n"
<<  "Missing \\begin_layout ?");
return;
case hash_string::value:
LYXERR0("Solitary \\end_inset in line "<<  lex.lineNumber()<<  "\n"
<<  "Missing \\begin_inset ?");
return;
default:
;
};



This is indeed readable, and I like it. The speed argument is not
unimportant, since tex2lyx can be quite slow for larger docs. Nevertheless I
would propose not to use it as long as major tex2lyx backports to 2.0.x are
planned. Maybe after 2.0.3 this could indeed be the way to go.


Then I prepare the future switch.




Georg

Re: [patch] tex2lyx support for external templates - MSVC hack

[Peter Kümmel]

The idea is nice, but the 4-character restriction makes it quite unreadable
IMHO.


Played around a bit and found this readable solution:


typedef boost::mpl::string<'\\end','_lay','out'> end_layout;
typedef boost::mpl::string<'\\end','in','set'>   end_inset;

...


switch (boost::hash_value(token)) {
case hash_string::value:
LYXERR0("Solitary \\end_layout in line " << lex.lineNumber() << 
"\n"
<< "Missing \\begin_layout ?");
return;
case hash_string::value:
LYXERR0("Solitary \\end_inset in line " << lex.lineNumber() << 
"\n"
<< "Missing \\begin_inset ?");
return;
default:
;
};



See attached patch. (doesn't compile with included boost version, and under GCC 
"tr1" is needed in #include)

Peter
Index: src/Text.cpp
===
--- src/Text.cpp	(revision 40192)
+++ src/Text.cpp	(working copy)
@@ -67,9 +67,66 @@
 #include "support/textutils.h"
 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 
+
+
+using namespace boost;
+namespace meta
+{
+#ifdef _MSC_VER
+#pragma warning(push)
+// disable addition overflow warning
+#pragma warning(disable:4307)
+#endif
+
+template 
+struct hash_combine
+{
+  typedef mpl::size_t<
+Seed::value ^ (static_cast(Value::value)
+  + 0x9e3779b9 + (Seed::value << 6) + (Seed::value >> 2))
+  > type;
+};
+
+#ifdef _MSC_VER
+#pragma warning(pop)
+#endif
+
+// Hash any sequence of integral wrapper types
+template 
+struct hash_sequence
+  : mpl::fold<
+Sequence
+  , mpl::size_t<0>
+  , hash_combine
+>::type
+{};
+
+// For hashing std::strings et al that don't include the zero-terminator
+template 
+struct hash_string
+  : hash_sequence
+{};
+
+// Hash including terminating zero for char arrays
+template 
+struct hash_cstring
+  : hash_combine<
+hash_sequence
+  , mpl::size_t<0>
+>::type
+{};
+
+} // namespace meta
+
+
+
 using namespace std;
 using namespace lyx::support;
 
@@ -81,6 +138,8 @@
 static bool moveItem(Paragraph & fromPar, pos_type fromPos,
 	Paragraph & toPar, pos_type toPos, BufferParams const & params)
 {
+
+
 	// Note: moveItem() does not honour change tracking!
 	// Therefore, it should only be used for breaking and merging paragraphs
 
@@ -315,6 +374,8 @@
 	return *owner_;
 }
 
+typedef boost::mpl::string<'\\end','_lay','out'> end_layout;
+typedef boost::mpl::string<'\\end','in','set'>   end_inset;
 
 void Text::readParToken(Paragraph & par, Lexer & lex,
 	string const & token, Font & font, Change & change, ErrorList & errorList)
@@ -322,6 +383,22 @@
 	Buffer * buf = const_cast(&owner_->buffer());
 	BufferParams const & bp = buf->params();
 
+	using namespace meta;
+
+
+	switch (boost::hash_value(token)) {
+		case hash_string::value:
+			LYXERR0("Solitary \\end_layout in line " << lex.lineNumber() << "\n"
+<< "Missing \\begin_layout ?");
+			return;
+		case hash_string::value:
+			LYXERR0("Solitary \\end_inset in line " << lex.lineNumber() << "\n"
+<< "Missing \\begin_inset ?");
+			return;
+		default:
+			;
+	};
+
 	if (token[0] != '\\') {
 		docstring dstr = lex.getDocString();
 		par.appendString(dstr, font, change);
@@ -372,12 +449,12 @@
 
 		par.params().read(lex);
 
-	} else if (token == "\\end_layout") {
+	/*} else if (token == "\\end_layout") {
 		LYXERR0("Solitary \\end_layout in line " << lex.lineNumber() << "\n"
 		   << "Missing \\begin_layout ?");
 	} else if (token == "\\end_inset") {
 		LYXERR0("Solitary \\end_inset in line " << lex.lineNumber() << "\n"
-		   << "Missing \\begin_inset ?");
+		   << "Missing \\begin_inset ?");*/
 	} else if (token == "\\begin_inset") {
 		Inset * inset = readInset(lex, buf);
 		if (inset)

Re: [patch] tex2lyx support for external templates - MSVC hack

[Peter Kümmel]

On 19.11.2011 15:26, Peter Kümmel wrote:

On 17.11.2011 21:48, Georg Baum wrote:

Peter Kümmel wrote:


Isn't there a better C/C++ way of solving this? For instance, couldn't it
somehow be 'transformed' into a switch/case statement?


A proper parser would of course use something like an enum for each string
literal (ideally automatically generated from a formal grammar, as well as
the big switch statement). TeX however is such a difficult language that I
fear that such a solution is not realistic. Therefore I think that the
current somewhat ad-hoc approach is not too bad.


What does boost say?

Found this:
http://arcticinteractive.com/2009/04/18/compile-time-string-hashing-boost-

mpl/


switch (boost::hash_value("bunnies"))
{
case meta::hash_cstring<   mpl::string<'bunn','ies'>   >::value:
 std::cout<<   "bunnies!\n";
 break;


The idea is nice, but the 4-character restriction makes it quite unreadable
IMHO.



Currently the default size is 32 and it could be changed by a macro:

www.boost.org/doc/libs/1_48_0/libs//mpl/doc/refmanual/limit-string-size.html


But you are right the  typedef needs a type '' not a string "" so only 4 bytes
could be passed within '' on 32bit systems:

typedef boost::mpl::string<'lyx2'> lyx;



I assume it will run faster because computing the hash and then jumping to the
case statement should be faster than to do a lot of string compares.

(boost 1.48 is out!)

Peter

Re: [patch] tex2lyx support for external templates - MSVC hack

[Peter Kümmel]

On 17.11.2011 21:48, Georg Baum wrote:

Peter Kümmel wrote:


Isn't there a better C/C++ way of solving this? For instance, couldn't it
somehow be 'transformed' into a switch/case statement?


A proper parser would of course use something like an enum for each string
literal (ideally automatically generated from a formal grammar, as well as
the big switch statement). TeX however is such a difficult language that I
fear that such a solution is not realistic. Therefore I think that the
current somewhat ad-hoc approach is not too bad.


What does boost say?

Found this:
http://arcticinteractive.com/2009/04/18/compile-time-string-hashing-boost-

mpl/


switch (boost::hash_value("bunnies"))
{
case meta::hash_cstring<  mpl::string<'bunn','ies'>  >::value:
std::cout<<  "bunnies!\n";
break;


The idea is nice, but the 4-character restriction makes it quite unreadable
IMHO.



Currently the default size is 32 and it could be changed by a macro:

www.boost.org/doc/libs/1_48_0/libs//mpl/doc/refmanual/limit-string-size.html

I assume it will run faster because computing the hash and then jumping to the
case statement should be faster than to do a lot of string compares.

(boost 1.48 is out!)

Peter

Re: Qt creator?

[Peter Kümmel]

On 19.11.2011 04:45, Richard Heck wrote:

On 11/18/2011 07:44 PM, Xu Wang wrote:

I'm learning Qt from  "C++ GUI Programming with Qt 4" and am curious
if most LyX developers write Qt C++ code using a text editor or Qt
Creator? I would like to get used to doing whatever others are doing
to make communication and questions easier.


I don't know that there is any standard choice. Probably depends to some
extent on the platform. But I will say this: One of the lead developers
of Qt Creator is a long-time LyX coder, so there's something to be said
on that score.


Wasn't he (Is still?) a vi-guy ;)


And, speaking for me, there's not much I want in an IDE
that isn't there in Qt Creator.

rh

Re: Qt creator?

[Peter Kümmel]

On 19.11.2011 10:10, Abdelrazak Younes wrote:

On 19/11/2011 04:45, Richard Heck wrote:

On 11/18/2011 07:44 PM, Xu Wang wrote:

I'm learning Qt from  "C++ GUI Programming with Qt 4" and am curious
if most LyX developers write Qt C++ code using a text editor or Qt
Creator? I would like to get used to doing whatever others are doing
to make communication and questions easier.


I don't know that there is any standard choice. Probably depends to some
extent on the platform. But I will say this: One of the lead developers
of Qt Creator is a long-time LyX coder, so there's something to be said
on that score. And, speaking for me, there's not much I want in an IDE
that isn't there in Qt Creator.


I could have said exactly the same :-)


Has anybody tried QtCreator under Windows with Msvc and cdb?
Is it a serious alternative to Studio?

Peter

Re: [patch] tex2lyx support for external templates - MSVC hack

[Peter Kümmel]

On 17.11.2011 20:49, Peter Kümmel wrote:

On 17.11.2011 20:40, Georg Baum wrote:

Uwe Stöhr wrote:


The attached patch adds support for the template "chess", "Gnumeric" and
"PDFPages".

I had to introduce a trick to overcome MSVC's limitation of 128 else-if
statements per routine. OK with it?


I like the principal idea (splitting parse_text() into smaller pieces), but
I don't like the way you do it, because the same limit will be quickly hit
again. I would propose something different: Move similar stuff into own
functions, e.g. all the font stuff (from textrm to noun could go into a bool
parse_font(), and then it would look like

... else if (t.cs() == "listof") {
...
} else if parse_font(...) {
;
} else if (t.cs() == "lyxadded" ...

The grouping of similar stuff would also increase the readability. Other
candidates would be parse_specialchar(), parse_quotes etc. You only need to
be careful with the order (the current order of if-statements is partly
arbitrary, but partly needed exactly like that).


Georg



Isn't there a better C/C++ way of solving this? For instance, couldn't it
somehow be 'transformed' into a switch/case statement?



What does boost say?

Found this:
http://arcticinteractive.com/2009/04/18/compile-time-string-hashing-boost-mpl/

switch (boost::hash_value("bunnies"))
{
case meta::hash_cstring< mpl::string<'bunn','ies'> >::value:
  std::cout << "bunnies!\n";
  break;

Re: [patch] tex2lyx support for external templates - MSVC hack

[Peter Kümmel]

On 17.11.2011 20:40, Georg Baum wrote:

Uwe Stöhr wrote:


The attached patch adds support for the template "chess", "Gnumeric" and
"PDFPages".

I had to introduce a trick to overcome MSVC's limitation of 128 else-if
statements per routine. OK with it?


I like the principal idea (splitting parse_text() into smaller pieces), but
I don't like the way you do it, because the same limit will be quickly hit
again. I would propose something different: Move similar stuff into own
functions, e.g. all the font stuff (from textrm to noun could go into a bool
parse_font(), and then it would look like

... else if (t.cs() == "listof") {
...
} else if parse_font(...) {
;
} else if (t.cs() == "lyxadded" ...

The grouping of similar stuff would also increase the readability. Other
candidates would be parse_specialchar(), parse_quotes etc. You only need to
be careful with the order (the current order of if-statements is partly
arbitrary, but partly needed exactly like that).


Georg



Isn't there a better C/C++ way of solving this? For instance, couldn't it
somehow be 'transformed' into a switch/case statement?

Peter

Re: CMake problems was: removing scons

[Peter Kümmel]

On 14.11.2011 08:58, Peter Kümmel wrote:

On 13.11.2011 21:21, Uwe Stöhr wrote:

Today I took the time and restarted from scratch, meaning to set up a clean new 
build system.
I followed the instructions bit by bit but CMake does not compile. In contrary 
to my old system it
even didn't start a compilation.

I fail to execute the build.bat script. Windows stops at this construct:


First you should start with plain cmake commands. The batch script is only a 
try to simplify things.
But I'll have a look at it.

Peter




if [%GNUWIN32_DIR%]==[] (
echo GNUWIN32_DIR not set.
echo Downloading win32 deps.
set DEPENDENCIES_DOWNLOAD="-DLYX_DEPENDENCIES_DOWNLOAD=1"
) else (
echo LyX deps : "%GNUWIN32_DIR%"
set PATH=%GNUWIN32_DIR%\bin;%PATH%
)

and tells me that there is a syntax error. When I change the construct to

if [%GNUWIN32_DIR%]==[] (
echo GNUWIN32_DIR not set.
) else (
::echo LyX deps : "%GNUWIN32_DIR%"
::set PATH=%GNUWIN32_DIR%\bin;%PATH%
)

I also get a syntax error that ")" is not allowed at this position. I played 
with this now for more
than an hour and also read the batch file syntax definition and parsed some 
forums - without any
success.
Also when I omit this structure and use

set PATH=%GNUWIN32_DIR%\bin;%PATH

directly, I get no syntax error, but nothing happens. The script finishes 
without invoking a
compilation.
I use the script that is currently in SVN trunk and invoke it from within a 
MSVC console with the
command
build.bat -install

Can anybody help me please?


Somehow reusing PATH does not work: set PATH=%GNUWIN32_DIR%\bin;%PATH%
But this has nothing to do with cmake, it's ms batch file scripting.

I would set all needed environment variables and call a batch script with a 
one-line cmake call.

Peter





regards Uwe

Re: CMake problems was: removing scons

[Peter Kümmel]

On 13.11.2011 21:21, Uwe Stöhr wrote:

Today I took the time and restarted from scratch, meaning to set up a clean new 
build system.
I followed the instructions bit by bit but CMake does not compile. In contrary 
to my old system it
even didn't start a compilation.

I fail to execute the build.bat script. Windows stops at this construct:


First you should start with plain cmake commands. The batch script is only a 
try to simplify things.
But I'll have a look at it.

Peter




if [%GNUWIN32_DIR%]==[] (
echo GNUWIN32_DIR not set.
echo Downloading win32 deps.
set DEPENDENCIES_DOWNLOAD="-DLYX_DEPENDENCIES_DOWNLOAD=1"
) else (
echo LyX deps : "%GNUWIN32_DIR%"
set PATH=%GNUWIN32_DIR%\bin;%PATH%
)

and tells me that there is a syntax error. When I change the construct to

if [%GNUWIN32_DIR%]==[] (
echo GNUWIN32_DIR not set.
) else (
::echo LyX deps : "%GNUWIN32_DIR%"
::set PATH=%GNUWIN32_DIR%\bin;%PATH%
)

I also get a syntax error that ")" is not allowed at this position. I played 
with this now for more
than an hour and also read the batch file syntax definition and parsed some 
forums - without any
success.
Also when I omit this structure and use

set PATH=%GNUWIN32_DIR%\bin;%PATH

directly, I get no syntax error, but nothing happens. The script finishes 
without invoking a
compilation.
I use the script that is currently in SVN trunk and invoke it from within a 
MSVC console with the
command
build.bat -install

Can anybody help me please?

regards Uwe

Re: 'Reply' sends to list.

[Peter Kümmel]

On 10.11.2011 20:35, Peter Kümmel wrote:

On 09.11.2011 11:41, Vincent van Ravesteijn wrote:



I don't understand what the problem is of "reply all".


I got your email twice, that's the problem.


You can do something about it yourself.


I don't understand. How could I prevent you to send me a private email?



Read this again:

To prevent duplication you either send to the list from the same
e-mail address as that is subscribed to the list, or you specify a
reply-to address that is the same as the address that is subscribed to
the list.


The email addresses are the same.



I'm convinced that when the mailing list daemon sees that your address
is CC'ed to an e-mail, it will not send you a duplicate. However, this
doesn't work if you are cc'ed by an address that is not subscribed to
the list.


OK, test it with this mail.


Test failed ;(





Jurgen had the same problem after the last mailing list disaster and it
seems he fixed it in this way.

Vincent

Re: 'Reply' sends to list.

[Peter Kümmel]

On 09.11.2011 11:41, Vincent van Ravesteijn wrote:



I don't understand what the problem is of "reply all".


I got your email twice, that's the problem.


You can do something about it yourself.


I don't understand. How could I prevent you to send me a private email?



Read this again:

To prevent duplication you either send to the list from the same
e-mail address as that is subscribed to the list, or you specify a
reply-to address that is the same as the address that is subscribed to
the list.


The email addresses are the same.



I'm convinced that when the mailing list daemon sees that your address
is CC'ed to an e-mail, it will not send you a duplicate. However, this
doesn't work if you are cc'ed by an address that is not subscribed to
the list.


OK, test it with this mail.



Jurgen had the same problem after the last mailing list disaster and it
seems he fixed it in this way.

Vincent

Re: Exporting UserGuide with trunk build

[Peter Kümmel]

On 10.11.2011 20:05, José Matos wrote:

On 11/10/2011 06:22 PM, Peter Kümmel wrote:

I have  a python error on startup

ImportError: No module named _ctypes

Maybe this is the error?

I use the python from the deps package: 2.7

Peter


_ctypes belongs to python standard installation, so if it is not there
then the installation has issues. :-)



Works now. Nobody updated the address for the new deps package in cmake.

Peter

Re: Exporting UserGuide with trunk build

[Peter Kümmel]

On 09.11.2011 20:56, Uwe Stöhr wrote:

Am 08.11.2011 21:10, schrieb Peter Kümmel:


Why could I not export the UserGuide from a trunk build on Windows?
I always get these errors:

! LaTeX Error: Command \DH unavailable in encoding OT1.
! LaTeX Error: Command \dh unavailable in encoding OT1.

Is it my fault?


Seems to be a problem with your settings. Assure that your LaTeX distro uses 
the fontenc T1. The


All my settings are corrupted lyx, email ;)


Userguide needs and uses T1. The UserGuide in trunk is identical to the one in 
branch and I can
compile the file with LyX 2.0.2 and 2.1svn without errors and only 3 warnings 
that I cannot figure
out why and where they appear.
A command \dh is not used in the Userguide. You can export the userguide to 
LaTeX and check if you
find "\dh". if so, please send me your TeX file.

regards Uwe



I have  a python error on startup

ImportError: No module named _ctypes

Maybe this is the error?

I use the python from the deps package: 2.7

Peter

Re: 'Reply' sends to list.

[Peter Kümmel]

On 08.11.2011 22:07, Vincent van Ravesteijn wrote:

Op 8-11-2011 22:03, Peter Kümmel schreef:

On 08.11.2011 21:59, Vincent van Ravesteijn wrote:

Op 8-11-2011 21:48, Peter Kümmel schreef:

Is it still necessary to disable the reply function for this list?

Most people are now used to press "reply all" which only
produces unneeded duplicates.

Peter


I don't understand what the problem is of "reply all".


I got your email twice, that's the problem.


You can do something about it yourself.


I don't understand. How could I prevent you to send me a private email?


 That's easier than to try to
change the rest of the world.


Are you already so old ;)



Vincent

Re: 'Reply' sends to list.

[Peter Kümmel]

On 08.11.2011 21:59, Vincent van Ravesteijn wrote:

Op 8-11-2011 21:48, Peter Kümmel schreef:

Is it still necessary to disable the reply function for this list?

Most people are now used to press "reply all" which only
produces unneeded duplicates.

Peter


I don't understand what the problem is of "reply all".


I got your email twice, that's the problem.



To prevent duplication you either send to the list from the same e-mail
address as that is subscribed to the list, or you specify a reply-to
address that is the same as the address that is subscribed to the list.

Vincent

'Reply' sends to list.

[Peter Kümmel]

Send it again, just demonstrate all subscribers how 'useful' these duplicates 
are.

--

Is it still necessary to disable the reply function for this list?

Most people are now used to press "reply all" which only
produces unneeded duplicates.

Peter

'Reply' sends to list.

[Peter Kümmel]

Is it still necessary to disable the reply function for this list?

Most people are now used to press "reply all" which only
produces unneeded duplicates.

Peter

Re: Canceling Background Export

[Peter Kümmel]

Some version of this strategy seems necessary, since one possible reason
to want to stop the export thread is that one of the converters is in an
infinite loop. Since we depend on external converters, this kind of
thing can easily happen and not be under our control. (Of course none of
the LyX converters would ever behave so badly!)

Here's an idea that might work within the current framework:

1. Send a signal to the background export thread, which it will
presumably process no matter what else it might be doing.


Event loop is blocked of the background task. We should change
the implementation of Systemcall to a asynchronous one (no sleep and no 
processEvents).



2. Kill whatever external processes have been started for image
conversion, etc, and set some kind of boolean so that no more will be
started while we're at it.


Already done, but we must not kill all available processes. Maybe we
could use the thread pointer to select the correct processes.


3. Finally, set another boolean as a signal to the main export routine
that it should abort. This can be checked when convenient, since my
sense is that this backend export is not what is expensive.


See the 'extern bool isProcessingEnabled;' hack in attached patch.

It already feels a bit snappier.

Peter



Peter's patch does something along these lines, but at the wrong level,
it seems to me. We don't want to disable ALL background processing, I
wouldn't have thought, since that might include image conversions
demanded by the main thread. And we wouldn't want to kill all background
processes, for the same reason.

Richard



Index: src/Converter.cpp
===
--- src/Converter.cpp	(revision 40157)
+++ src/Converter.cpp	(working copy)
@@ -348,6 +348,12 @@
 	FileName outfile = from_file;
 	for (Graph::EdgePath::const_iterator cit = edgepath.begin();
 	 cit != edgepath.end(); ++cit) {
+
+extern bool isProcessingEnabled;
+if (!isProcessingEnabled) {
+  return false;
+}
+
 		Converter const & conv = converterlist_[*cit];
 		bool dummy = conv.To->dummy() && conv.to != "program";
 		if (!dummy) {
Index: src/frontends/qt4/GuiProgress.cpp
===
--- src/frontends/qt4/GuiProgress.cpp	(revision 40157)
+++ src/frontends/qt4/GuiProgress.cpp	(working copy)
@@ -184,7 +184,12 @@
 	QMessageBox::information(qApp->focusWidget(), title, message);
 }
 
+void GuiProgress::abortAllProcessesClicked()
+{
+abortAndDisableProcessing();
+}
 
+
 } // namespace frontend
 } // namespace lyx
 
Index: src/frontends/qt4/GuiProgress.h
===
--- src/frontends/qt4/GuiProgress.h	(revision 40157)
+++ src/frontends/qt4/GuiProgress.h	(working copy)
@@ -54,7 +54,6 @@
 	void clearMessages();
 	void appendLyXErrMessage(QString const & text);
 
-
 	void clearMessageText();
 	void updateStatusBarMessage(QString const &);
 	void triggerFlush();
@@ -76,6 +75,7 @@
 	void doToggleWarning(QString const & title, QString const & msg, QString const & formatted);
 	void doError(QString const &, QString const &);
 	void doInformation(QString const &, QString const &);
+void abortAllProcessesClicked();
 
 	void updateWithLyXErr();
 	void startFlushing();
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(revision 40157)
+++ src/frontends/qt4/GuiView.cpp	(working copy)
@@ -249,6 +249,15 @@
 dynamic_cast(progress_),
 SIGNAL(clearMessageText()),
 gv, SLOT(clearMessageText()));
+
+// fit into LyX
+QPushButton* abortButton = new QPushButton();
+abortButton->setText("Abort processes");
+abortButton->show();
+
+// Forward abort signal down to SystemCall via ProgressInterface.
+connect(abortButton, SIGNAL(clicked()),
+dynamic_cast(progress_), SLOT(abortAllProcessesClicked()));
 	}
 
 	~GuiViewPrivate()
@@ -554,6 +563,9 @@
 		break;
 	}
 	view->message(msg);
+if (ProgressInterface::instance()) {
+ProgressInterface::instance()->enableProcessing();
+}
 }
 
 
Index: src/output_latex.cpp
===
--- src/output_latex.cpp	(revision 40157)
+++ src/output_latex.cpp	(working copy)
@@ -685,7 +685,9 @@
 
 	// FIXME UNICODE
 	os << from_utf8(everypar);
-	par.latex(bparams, outerfont, os, runparams, start_pos, end_pos);
+	if (!par.latex(bparams, outerfont, os, runparams, start_pos, end_pos)) {
+return;
+  }
 
 	// Make sure that \\par is done with the font of the last
 	// character if this has another size as the default.
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp	(revision 40157)
+++ src/Paragraph.cpp	(working copy)
@@ -2278,7 +2278,7 @@
 
 
 // This one spits out the text of the paragraph
-void Paragraph

Exporting UserGuide with trunk build

[Peter Kümmel]

Why could I not export the UserGuide from a trunk build on Windows?
I always get these errors:

! LaTeX Error: Command \DH unavailable in encoding OT1.
! LaTeX Error: Command \dh unavailable in encoding OT1.

Is it my fault?
Peter

Re: Canceling Background Export

[Peter Kümmel]

On 06.11.2011 23:02, Vincent van Ravesteijn wrote:

Op 6-11-2011 22:42, Peter Kümmel schreef:

On 06.11.2011 17:32, Peter Kümmel wrote:




In the end, this all comes down to rewriting the export logic.



I assume it isn't that complicated: kill all processes, and disable
starting new ones until the gui tells that the doExport is finished.

See attached patch.



One problem is, all processes will be killed, not only these started
by doExport. But a mapping to the export thread would solve it.



I did try the patch. I opened the user guide, previewed it as dvi, and
cancelled.

After that, I had to wait still a long time because the export just
continued. Only the processes weren't started. Maybe this doesn't take
that long in the release version, but still.



Takes it so long to generate the latex file? Then no processes are used,
so nothing could be stopped.

Is the reaction to the stop faster with your changes?


Vincent

Re: Canceling Background Export

[Peter Kümmel]

On 06.11.2011 17:32, Peter Kümmel wrote:




In the end, this all comes down to rewriting the export logic.



I assume it isn't that complicated: kill all processes, and disable
starting new ones until the gui tells that the doExport is finished.

See attached patch.



One problem is, all processes will be killed, not only these started
by doExport. But a mapping to the export thread would solve it.

... and I know, I've used spaces in the patch ;)

Peter

Re: tex2lyx uncompilable after r 40139

[Peter Kümmel]

On 06.11.2011 21:29, Uwe Stöhr wrote:

After r40139 I get 8 unresolved externals:



Updating src_tex2lyx_copied_files in scons_manifest.py should fix it.

here the cmake changes:
http://www.lyx.org/trac/changeset/40139/lyx-devel/trunk/src/tex2lyx/CMakeLists.txt




regards Uwe

Re: Canceling Background Export

[Peter Kümmel]

In the end, this all comes down to rewriting the export logic.



I assume it isn't that complicated: kill all processes, and disable
starting new ones until the gui tells that the doExport is finished.

See attached patch.

Peter


I would guess it would look like this:

1. Get the conversion path to the exported format
  2. Generate the backend source
  3. Acquire information about which files to be converted, and/or other.
  4. Do all conversions and other time-consuming actions.
5. Repeat steps (2),3-4 for all other nodes in the conversion path

Assuming that all time-consuming actions are done in a loop in step 4,
we can check for the "cancel" boolean in this loop after each conversion
(completed or killed). Optionally we can keep track of the spawned
processes in step 4, and kill these when we want to cancel. After
setting the "cancel" boolean and killing the processes, the loop and
thread will exit nicely.

Vincent


Index: src/frontends/qt4/GuiProgress.cpp
===
--- src/frontends/qt4/GuiProgress.cpp	(Revision 40135)
+++ src/frontends/qt4/GuiProgress.cpp	(Arbeitskopie)
@@ -184,7 +184,12 @@
 	QMessageBox::information(qApp->focusWidget(), title, message);
 }
 
+void GuiProgress::abortAllProcessesClicked()
+{
+abortAndDisableProcessing();
+}
 
+
 } // namespace frontend
 } // namespace lyx
 
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(Revision 40135)
+++ src/frontends/qt4/GuiView.cpp	(Arbeitskopie)
@@ -249,6 +249,15 @@
 dynamic_cast(progress_),
 SIGNAL(clearMessageText()),
 gv, SLOT(clearMessageText()));
+
+// fit into LyX
+QPushButton* abortButton = new QPushButton();
+abortButton->setText("Abort processes");
+abortButton->show();
+
+// Forward abort signal down to SystemCall via ProgressInterface.
+connect(abortButton, SIGNAL(clicked()),
+dynamic_cast(progress_), SLOT(abortAllProcessesClicked()));
 	}
 
 	~GuiViewPrivate()
@@ -554,6 +563,9 @@
 		break;
 	}
 	view->message(msg);
+if (ProgressInterface::instance()) {
+ProgressInterface::instance()->enableProcessing();
+}
 }
 
 
Index: src/frontends/qt4/GuiProgress.h
===
--- src/frontends/qt4/GuiProgress.h	(Revision 40135)
+++ src/frontends/qt4/GuiProgress.h	(Arbeitskopie)
@@ -54,7 +54,6 @@
 	void clearMessages();
 	void appendLyXErrMessage(QString const & text);
 
-
 	void clearMessageText();
 	void updateStatusBarMessage(QString const &);
 	void triggerFlush();
@@ -76,6 +75,7 @@
 	void doToggleWarning(QString const & title, QString const & msg, QString const & formatted);
 	void doError(QString const &, QString const &);
 	void doInformation(QString const &, QString const &);
+void abortAllProcessesClicked();
 
 	void updateWithLyXErr();
 	void startFlushing();
Index: src/support/Systemcall.cpp
===
--- src/support/Systemcall.cpp	(Revision 40135)
+++ src/support/Systemcall.cpp	(Arbeitskopie)
@@ -32,7 +32,10 @@
 #include 
 #include 
 #include 
+#include 
 
+
+
 #define USE_QPROCESS
 
 
@@ -93,8 +96,20 @@
 }
 
 
+void ProgressInterface::abortAndDisableProcessing()
+{
+SystemcallPrivate::setProcessingEnabled(false);
+SystemcallPrivate::killCurrentProcesses();
+}
 
 
+void ProgressInterface::enableProcessing()
+{
+  SystemcallPrivate::setProcessingEnabled(true);
+}
+
+
+
 // Reuse of instance
 #ifndef USE_QPROCESS
 int Systemcall::startscript(Starttype how, string const & what,
@@ -236,6 +251,11 @@
 {
 	lyxerr << "\nRunning: " << what << endl;
 
+if (!SystemcallPrivate::isProcessingEnabled()) {
+LYXERR0("Systemcall: disabled ");
+return 30;
+}
+
 	string outfile;
 	string errfile;
 	QString cmd = QString::fromLocal8Bit(
@@ -257,6 +277,8 @@
 		return 0;
 	}
 
+// when we are here we know that we don't use SystemCall asynchronously
+d.appendAsKillableProcess();
 	if (!d.waitWhile(SystemcallPrivate::Running, process_events,
 			 os::timeout_min() * 60 * 1000)) {
 		LYXERR0("Systemcall: '" << cmd << "' did not finish!");
@@ -337,6 +359,9 @@
 	connect(process_, SIGNAL(finished(int, QProcess::ExitStatus)), SLOT(processFinished(int, QProcess::ExitStatus)));
 }
 
+bool SystemcallPrivate::is_processing_enabled_ = true;
+QMutex SystemcallPrivate::killable_processes_mutex_;
+QSet SystemcallPrivate::killable_processes_;
 
 void SystemcallPrivate::startProcess(QString const & cmd, string const & path)
 {
@@ -553,6 +578,7 @@
 void SystemcallPrivate::killProcess()
 {
 	killProcess(process_);
+removeAsKillableProcess();
 }
 
 
@@ -567,8 +593,52 @@
 	}
 }
 
+void SystemcallPrivate::enableProcessing()
+{
+  SystemcallPrivate::setProcessingEnabled(true);
+}
 
+void SystemcallPrivate::abortAndStopFurtherProcessing()
+{
+  SystemcallPrivat

Re: Failed svn installation on arch linux

[Peter Kümmel]

On 23.10.2011 16:40, Enrico Forestieri wrote:

On Sun, Oct 23, 2011 at 08:28:41AM -0500, stefano franchi wrote:


On Sat, Oct 22, 2011 at 1:40 PM, Enrico Forestieri  wrote:

On Sat, Oct 22, 2011 at 10:16:03AM -0500, stefano franchi wrote:


I followed instructions and got the same error as above.

Grepping for IconButton, as suggested, does not find anything. That
is, the file  moc_FancyLineEdit.cpp
is where it should, but it does not contain any ref to IconButton


Please, can you report the output of the following command?

$ which bc

For example, I get:

$ which bc
/usr/bin/bc


No output, I don't have that program installed, it seems.
What is it?


$ whatis bc
bc (1)   - An arbitrary precision calculator language
bc (1posix)  - arbitrary-precision arithmetic language

Install bc and it will work. It is used to get the Qt version in hex format from
the x.y.z decimal format and pass it to the moc compiler. Without bc you should
see moc invoked like this:

moc-qt4 -DQT_VERSION=0x0 -o moc_FancyLineEdit.cpp ...

Notice the -DQT_VERSION=0x0 flag, which should instead be something like
-DQT_VERSION=0x040704. So, moc would be instructed that you have Qt version 
0.0.0
and thus some part of the sources are omitted from compilation.

Remember to remove the old moc_FancyLineEdit.cpp or to touch
src/frontends/qt4/FancyLineEdit.h before launching make.



Yes indeed, that's the reason: in ./src/frontends/qt4/Makefile you will find

QT_VERSION = $(shell IFS=.; set -- `echo $(QT4_VERSION)`; \
 echo 0x0`echo "obase=16; $$1*65536+$$2*256+$$3" | bc`)

so no bc, no QT_VERSION. A very quick&dirty hack would be to edit the Makefile:

QT_VERSION = 0x040704

Peter

Re: Failed svn installation on arch linux

[Peter Kümmel]

On 23.10.2011 15:34, stefano franchi wrote:

On Sat, Oct 22, 2011 at 5:53 PM, Peter Kümmel  wrote:



Check if it exisits: find . -name moc_\* | xargs grep IconButton
This should find it in './src/frontends/qt4/moc_FancyLineEdit.cpp'



I followed instructions and got the same error as above.

Grepping for IconButton, as suggested, does not find anything. That
is, the file  moc_FancyLineEdit.cpp
is where it should, but it does not contain any ref to IconButton



Strange, I only could remember the same error when my disk was full.
Is the file empty or does it only miss the refs to IconButton?



Peter,

if you mean the file moc_FancyLineEdit.cpp, then it is certainly not
empty. But there are no references to IconButton in it.
I am appending the whole file below, just in case.



OK, looks like you are using moc of 4.7.4 but the QT_VERSION is not set
correctly because moc ignores the IconButton class (#if QT_VERSION >= 0x040600).

Do you also have an older version of Qt installed on your system?

Peter



Stefano




/
** Meta object code from reading C++ file 'FancyLineEdit.h'
**
** Created: Sat Oct 22 09:06:27 2011
**  by: The Qt Meta Object Compiler version 62 (Qt 4.7.4)
**
** WARNING! All changes made in this file will be lost!
*/

#include "../../../../trunk/src/frontends/qt4/FancyLineEdit.h"
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'FancyLineEdit.h' doesn't include."
#elif Q_MOC_OUTPUT_REVISION != 62
#error "This file was generated using the moc from 4.7.4. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif

QT_BEGIN_MOC_NAMESPACE
static const uint qt_meta_data_lyx__frontend__FancyLineEdit[] = {

  // content:
5,   // revision
0,   // classname
0,0, // classinfo
3,   14, // methods
0,0, // properties
1,   29, // enums/sets
0,0, // constructors
0,   // flags
3,   // signalCount

  // signals: signature, parameters, type, tag, flags
   35,   30,   29,   29, 0x05,
   55,   29,   29,   29, 0x05,
   75,   29,   29,   29, 0x05,

  // enums: name, flags, count, data
   96, 0x0,2,   33,

  // enum data: key, value
  101, uint(lyx::frontend::FancyLineEdit::Left),
  106, uint(lyx::frontend::FancyLineEdit::Right),

0// eod
};

static const char qt_meta_stringdata_lyx__frontend__FancyLineEdit[] = {
 "lyx::frontend::FancyLineEdit\0\0side\0"
 "buttonClicked(Side)\0leftButtonClicked()\0"
 "rightButtonClicked()\0Side\0Left\0Right\0"
};

const QMetaObject lyx::frontend::FancyLineEdit::staticMetaObject = {
 {&QLineEdit::staticMetaObject,
qt_meta_stringdata_lyx__frontend__FancyLineEdit,
   qt_meta_data_lyx__frontend__FancyLineEdit, 0 }
};

#ifdef Q_NO_DATA_RELOCATION
const QMetaObject&lyx::frontend::FancyLineEdit::getStaticMetaObject()
{ return staticMetaObject; }
#endif //Q_NO_DATA_RELOCATION

const QMetaObject *lyx::frontend::FancyLineEdit::metaObject() const
{
 return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject :
&staticMetaObject;
}

void *lyx::frontend::FancyLineEdit::qt_metacast(const char *_clname)
{
 if (!_clname) return 0;
 if (!strcmp(_clname, qt_meta_stringdata_lyx__frontend__FancyLineEdit))
 return static_cast(const_cast<  FancyLineEdit*>(this));
 return QLineEdit::qt_metacast(_clname);
}

int lyx::frontend::FancyLineEdit::qt_metacall(QMetaObject::Call _c,
int _id, void **_a)
{
 _id = QLineEdit::qt_metacall(_c, _id, _a);
 if (_id<  0)
 return _id;
 if (_c == QMetaObject::InvokeMetaMethod) {
 switch (_id) {
 case 0: buttonClicked((*reinterpret_cast<  Side(*)>(_a[1]))); break;
 case 1: leftButtonClicked(); break;
 case 2: rightButtonClicked(); break;
 default: ;
 }
 _id -= 3;
 }
 return _id;
}

// SIGNAL 0
void lyx::frontend::FancyLineEdit::buttonClicked(Side _t1)
{
 void *_a[] = { 0, const_cast(reinterpret_cast(&_t1)) };
 QMetaObject::activate(this,&staticMetaObject, 0, _a);
}

// SIGNAL 1
void lyx::frontend::FancyLineEdit::leftButtonClicked()
{
 QMetaObject::activate(this,&staticMetaObject, 1, 0);
}

// SIGNAL 2
void lyx::frontend::FancyLineEdit::rightButtonClicked()
{
 QMetaObject::activate(this,&staticMetaObject, 2, 0);
}
QT_END_MOC_NAMESPACE

Re: Failed svn installation on arch linux

[Peter Kümmel]

Check if it exisits: find . -name moc_\* | xargs grep IconButton
This should find it in './src/frontends/qt4/moc_FancyLineEdit.cpp'



I followed instructions and got the same error as above.

Grepping for IconButton, as suggested, does not find anything. That
is, the file  moc_FancyLineEdit.cpp
is where it should, but it does not contain any ref to IconButton



Strange, I only could remember the same error when my disk was full.
Is the file empty or does it only miss the refs to IconButton?

Peter

Re: Failed svn installation on arch linux

[Peter Kümmel]

FancyLineEdit.cpp:(.text+0xf2c): undefined reference to
`lyx::frontend::IconButton::staticMetaObject'


The moc file is missing.



Check if it exisits: find . -name moc_\* | xargs grep IconButton
This should find it in './src/frontends/qt4/moc_FancyLineEdit.cpp'

Peter

Re: Failed svn installation on arch linux

[Peter Kümmel]

This is a clean build right?

If you mean: make clean; make


Better would be to build out of source and to completely remove all old build 
files:
 - start with a clean svn checkout (svn co 
svn://svn.lyx.org/lyx/lyx-devel/trunk), sources then in 'trunk'
 - ONLY call ./autogen.sh within 'trunk'
 - then create a new folder on the same level as 'trunk', for instance 
'lyx-build'
 - cd into 'lyx-build' and call ../trunk/configure
 - build

To start over remove all files in 'lyx-build'.

Peter

Re: Failed svn installation on arch linux

[Peter Kümmel]

On 22.10.2011 03:47, stefano franchi wrote:

On Fri, Oct 21, 2011 at 7:47 PM, Lars Gullik Bjønnes  wrote:

stefano franchi  writes:

[...]
| Lars,



| did you mean "make d=1"? I tried "make V=1" and nothing changed in the output.
| I'm currently trying again with the debug option.

No, I belive that I meant V=1, I want to see the acutal link command.

[...]

| CXXLD  lyx


what this exapand do

--
   Lgb




Ok, this is the last screenful of make V=1 output. I am not sure it's
going to help, but then again, I don't know what I'm supposed to be
looking for:

ar cru liblyxinsets.a ExternalSupport.o ExternalTemplate.o
ExternalTransforms.o RenderButton.o RenderGraphic.o RenderPreview.o
Inset.o InsetArgument.o InsetBibitem.o InsetBibtex.o InsetBox.o
InsetBranch.o InsetCaption.o InsetCitation.o InsetCollapsable.o
InsetCommand.o InsetCommandParams.o InsetERT.o InsetExternal.o
InsetFlex.o InsetFloat.o InsetFloatList.o InsetFoot.o InsetFootlike.o
InsetGraphicsParams.o InsetGraphics.o InsetHyperlink.o InsetInclude.o
InsetIndex.o InsetInfo.o InsetLabel.o InsetLayout.o InsetLine.o
InsetListings.o InsetListingsParams.o InsetMarginal.o InsetNewline.o
InsetNewpage.o InsetNomencl.o InsetNote.o InsetPhantom.o
InsetPreview.o InsetQuotes.o InsetRef.o InsetScript.o InsetSpace.o
InsetSpecialChar.o InsetTabular.o InsetText.o InsetTOC.o InsetVSpace.o
InsetWrap.o
ranlib liblyxinsets.a
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT main.o
-MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
mv -f .deps/main.Tpo .deps/main.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
AspellChecker.o -MD -MP -MF .deps/AspellChecker.Tpo -c -o
AspellChecker.o AspellChecker.cpp
mv -f .deps/AspellChecker.Tpo .deps/AspellChecker.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
BiblioInfo.o -MD -MP -MF .deps/BiblioInfo.Tpo -c -o BiblioInfo.o
BiblioInfo.cpp
mv -f .deps/BiblioInfo.Tpo .deps/BiblioInfo.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT Box.o
-MD -MP -MF .deps/Box.Tpo -c -o Box.o Box.cpp
mv -f .deps/Box.Tpo .deps/Box.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
Compare.o -MD -MP -MF .deps/Compare.Tpo -c -o Compare.o Compare.cpp
mv -f .deps/Compare.Tpo .deps/Compare.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
Dimension.o -MD -MP -MF .deps/Dimension.Tpo -c -o Dimension.o
Dimension.cpp
mv -f .deps/Dimension.Tpo .deps/Dimension.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
EnchantChecker.o -MD -MP -MF .deps/EnchantChecker.Tpo -c -o
EnchantChecker.o EnchantChecker.cpp
mv -f .deps/EnchantChecker.Tpo .deps/EnchantChecker.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
HunspellChecker.o -MD -MP -MF .deps/HunspellChecker.Tpo -c -o
HunspellChecker.o HunspellChecker.cpp
mv -f .deps/HunspellChecker.Tpo .deps/HunspellChecker.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
PersonalWordList.o -MD -MP -MF .deps/PersonalWordList.Tpo -c -o
PersonalWordList.o PersonalWordList.cpp
mv -f .deps/PersonalWordList.Tpo .deps/PersonalWordList.Po
g++ -DHAVE_CONFIG_H -I. -I..   -I../src -I../boost -pthread
-I/usr/include/enchant -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/hunspell   -DQT_NO_STL
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/QtCore -O2 -MT
PrinterParams.o -MD -MP -MF .deps/PrinterParams.Tpo -c -o
PrinterParams.o PrinterPar

Re: removing scons

[Peter Kümmel]

On 21.10.2011 14:30, Pavel Sanda wrote:

Peter Kümmel wrote:

i would be happy to know whether complete remerge of strings with
cmake on windows setup gives completely identical .po files as with
autotools remerge. scons remerge were not compatible and we spent
megabytes (literally) of storage just because of the cosmetic and
newline issues (i actually suspect that two-digit percentage of our
git repo is spent just for this nonsense).

anyone on win willing to test?



I could test it.  What files after running which tool should I check?


update svn tree to r39901. remerge .po strings with cmake and diff sk.po
against the current trunk sk.po. how the diff looks like?



After the last patches the patch looks ok.


pavel

--- E:/sandbox/lyx/trunk/po/sk39.po	Sa Okt 22 01:27:20 2011
+++ E:/sandbox/lyx/trunk/po/sk.po	Sa Okt 22 01:28:03 2011
@@ -1,15 +1,15 @@
 # Slovak translation of LyX
 # Copyright (C) 2003, 2006
 # Zdenko Podobný 
-# 
+#
 # Kornel Benko , 2009.
 # Kornel Benko , 2009, 2010, 2011.
 msgid ""
 msgstr ""
 "Project-Id-Version: LyX-2.1\n"
 "Report-Msgid-Bugs-To: lyx-devel@lists.lyx.org\n"
-"POT-Creation-Date: 2011-10-22 01:26+0200\n"
-"PO-Revision-Date: 2011-10-17 15:04+0200\n"
+"POT-Creation-Date: 2011-10-21 15:13+0200\n"
+"PO-Revision-Date: 2011-10-21 15:16+0200\n"
 "Last-Translator: Kornel Benko \n"
 "Language-Team: Slovak \n"
 "Language: sk\n"
@@ -438,9 +438,9 @@
 msgid "Select your branch"
 msgstr "Vyberte svoju vetvu"
 
-#: src/frontends/qt4/ui/BranchesUi.ui:25 src/frontends/qt4/ui/IndicesUi.ui:114
-msgid "&New:"
-msgstr "&Nové:"
+#: src/frontends/qt4/ui/BranchesUi.ui:25
+msgid "&New:[[branch]]"
+msgstr "Nová:"
 
 #: src/frontends/qt4/ui/BranchesUi.ui:35
 msgid ""
@@ -1929,6 +1929,10 @@
 msgid "&Use multiple indexes"
 msgstr "Použiť viacnásobné indexy"
 
+#: src/frontends/qt4/ui/IndicesUi.ui:114
+msgid "&New:[[index]]"
+msgstr "Nový:"
+
 #: src/frontends/qt4/ui/IndicesUi.ui:124
 msgid ""
 "Enter the name of the desired index (e.g. \"Index of Names\") and hit \"Add\""
@@ -24314,6 +24318,9 @@
 msgid "Unknown user"
 msgstr "Neznámy používateľ"
 
+#~ msgid "&New:"
+#~ msgstr "&Nové:"
+
 #~ msgid "Enter the command to load the language package (default: babel)"
 #~ msgstr "Zadajte príkaz na nahranie jazykového balíku (štandardne babel)"
 

Re: removing scons

[Peter Kümmel]

On 22.10.2011 00:55, Peter Kümmel wrote:

On 21.10.2011 14:30, Pavel Sanda wrote:

Peter Kümmel wrote:

i would be happy to know whether complete remerge of strings with
cmake on windows setup gives completely identical .po files as with
autotools remerge. scons remerge were not compatible and we spent
megabytes (literally) of storage just because of the cosmetic and
newline issues (i actually suspect that two-digit percentage of our
git repo is spent just for this nonsense).

anyone on win willing to test?



I could test it.  What files after running which tool should I check?


update svn tree to r39901. remerge .po strings with cmake and diff sk.po
against the current trunk sk.po. how the diff looks like?

pavel



I also get big differences, and worse the po files are broken:

svn:
#: src/frontends/qt4/ui/AboutUi.ui:131 src/frontends/qt4/ui/CompareUi.ui:163

cmake on Windows (notice the different line breaks):
#: src/frontends/qt4/ui/AboutUi.ui:131
   src/frontends/qt4/ui/CompareUi.ui:163




Fixed it.


Peter

Re: removing scons

[Peter Kümmel]

On 21.10.2011 14:30, Pavel Sanda wrote:

Peter Kümmel wrote:

i would be happy to know whether complete remerge of strings with
cmake on windows setup gives completely identical .po files as with
autotools remerge. scons remerge were not compatible and we spent
megabytes (literally) of storage just because of the cosmetic and
newline issues (i actually suspect that two-digit percentage of our
git repo is spent just for this nonsense).

anyone on win willing to test?



I could test it.  What files after running which tool should I check?


update svn tree to r39901. remerge .po strings with cmake and diff sk.po
against the current trunk sk.po. how the diff looks like?

pavel



I also get big differences, and worse the po files are broken:

svn:
#: src/frontends/qt4/ui/AboutUi.ui:131 src/frontends/qt4/ui/CompareUi.ui:163

cmake on Windows (notice the different line breaks):
#: src/frontends/qt4/ui/AboutUi.ui:131 
 src/frontends/qt4/ui/CompareUi.ui:163 


Peter

Re: removing scons

[Peter Kümmel]

On 19.10.2011 15:20, Pavel Sanda wrote:

Vincent van Ravesteijn wrote:

Op 16-10-2011 16:50, Uwe Stöhr schreef:

Am 16.10.2011 14:17, schrieb Georg Baum:


some time ago we discussed the removal of scons, and somebody mentioned
that
you use it for the installer. Could you please make a list of features
that
you need and which are missing in cmake?


- remerging the po-files
- compiling the po-files


Did you even check what is possible with CMake nowadays ?


i would be happy to know whether complete remerge of strings with
cmake on windows setup gives completely identical .po files as with
autotools remerge. scons remerge were not compatible and we spent
megabytes (literally) of storage just because of the cosmetic and
newline issues (i actually suspect that two-digit percentage of our
git repo is spent just for this nonsense).

anyone on win willing to test?



I could test it.  What files after running which tool should I check?

Peter


pavel

Re: removing scons

[Peter Kümmel]

It should be easy to port that batch file to cmake. Please try that, all the
needed information is in the two mentioned INSTALL files. Maybe you can also
use the already existing development/cmake/build.bat as a abse. I don't have
a windows development machine here so I can't test that.



I've updated 'development/cmake/build.bat'.

Please call it from an empty build directory. Without any environment
variables set it downloads gnuwin32, for instance

  C:\builddir> D:\LyXSVN\lyx-devel\development\cmake\build.bat

I've tested the 'install' rule with a Studio Express 10. Here it installs lyx
into C:\builddir\LYX_INSTALLED. ATM it doesn't copy Qt and the gnuwin32 files,
but this could also be fixed if you need it.

We could use this batch file as starting point for your fixes and wishes.

Peter

Re: git vs svn trunk

[Peter Kümmel]

Here you could download an already checked out git repository:

ftp://ftp.lyx.org/pub/lyx/devel/git-devel/



The link is in the wiki:

http://wiki.lyx.org/Devel/Git

It contains the complete history with branches until r38741.

When fetching stops with a perl error remove all *.db
in .git/svn/.caches, see


http://stackoverflow.com/questions/3135477/git-svn-rebase-resulted-in-byte-order-is-not-compatible-error

Peter

Re: git vs svn trunk

[Peter Kümmel]

On 04.10.2011 16:25, Tommaso Cucinotta wrote:

Il 04/10/2011 10:08, Vincent van Ravesteijn - TNW ha scritto:

Hi Tommaso,

No, we don't have one yet. Uptil now it is all manual labor.

However, I happen to have installed a git repo on my own server now,
to which I will gradually add more functionality.


Also, I think in the end I probably found out that I can be happy with
git-svn, but the problem is that it is still checking out (ehm,
fetching) the ~40 thousands revisions since this morning (over my ADSL
line -- still ~22K out of the ~40K we have). If I stop it and delete the
whole thing, and issue a



Here you could download a already checked out git repository:

ftp://ftp.lyx.org/pub/lyx/devel/git-devel/




git-svn clone -r3 svn://svn.lyx.org/lyx/lyx-devel/trunk

or

git-svn fetch -r3 svn://svn.lyx.org/lyx/lyx-devel/trunk

do you think I could avoid to have the whole history of LyX with me ?

  T.