date:20130507


Le 07/05/13 06:13, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

What about this different logic instead? It relies on the size/height of
the window, not on the dock position.


No strong preference here. P


The advantage is that it also does something reasonable when the widget 
is not docked (or when it is docked and you set the LyX window to 
ridiculous size :)


Then I'll push it and see what happens. I'll revert if there are complaints.

JMarc

Unit testing: The Small Plan

Hello list,

I'd like to come up with a small plan for getting started with unit testing:

==
1.) Directory structure: tests/unit/
==

* Unit tests stay their own directory separated from src/.
* Below tests/unit the directory structure mirrors the structure of
src/.
* The reason for the subfolder unit is, that unit tests are not the
only type of tests. Unit tests test the single units of the source.

==
2.) Mocking: googlemock
==

This weekend I researched for alternatives, but there was none
that made a stable impression to me apart from googlemock.

With C++ mocking can take two approaches:

2.a) Turning classes into Templates, to be able to replace members by mocks.

http://programmaticallyspeaking.blogspot.de/2010/04/beautiful-dependency-injection-in-c.html

This seems to invasive into the existing sources for me.

2.b) Inheriting the mocks from the real objects, so that they are of the
same type.

This is the approach of googlemock.

Googlemock can be used with any mocking framework. It best integrates with
googletest.

==
3.) Testing framework: any
==

Unit tests are independent units, so any framework or none can be used.
For the reason of mocks, googletest is recommended.

==
4.) Runnig all tests
==

To be able to run all tests at once they need to be detected.

* The naming pattern of the binary to support this: whateverTest
* A successful test binary returns 0, the others an Error.
* The global test detector and runner is a Python script.

==
5.) Dependency injection
==

Dependency injection (the mock objects) is more difficult with C++
for multiple reasons like the missing garbage collection or reflection.

The approach that looks most forward and less intrusive for the sources
to me, is to directly access the private members by making them public
during testing and only during testing.

That is not really kosher, but at least a simple way to get started
directly.

It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.

\Elmar

--
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

regular crashes on OSX

hi guys,

i have been experiencing regular crashes on my mac (see below)

they seem to happen when i open or close a document, but not in a systematic 
way (or at least i haven't found a reproducible way to trigger the bug)

am i the only one experiencing these?

i am using lyx 2.0.5 from the official installer

thanks, ed.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   QtGui   0x00eac9c9 QAction::isEnabled() const + 
9
1   QtGui   0x00e95bb4 
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 244
2   QtGui   0x00e95c9c 
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 476
3   QtGui   0x00e95e1e 
qt_mac_set_modal_state(NSMenu*, bool) + 62
4   QtGui   0x00e993c8 
QMenuBarPrivate::macUpdateMenuBarImmediatly() + 1144
5   libobjc.A.dylib 0x99a82586 -[NSObject performSelector:] 
+ 62
6   QtGui   0x00e677f9 
-[NSApplication(QApplicationIntegration) qt_sendPostedMessage:] + 89
7   QtGui   0x00e676b6 
-[NSApplication(QApplicationIntegration) qt_sendEvent:] + 118
8   QtGui   0x00e67871 -[QNSApplication sendEvent:] 
+ 49
9   com.apple.AppKit0x9273069c -[NSApplication run] + 951
10  QtGui   0x00e71802 
QEventDispatcherMac::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 1570
11  QtCore  0x00d12a61 
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 65
12  QtCore  0x00d12d8a 
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 170
13  QtCore  0x00d14120 QCoreApplication::exec() + 
176
14  org.lyx.lyx 0x00103a6f lyx::Lexer::Pimpl::~Pimpl() 
+ 29605
15  org.lyx.lyx 0x00017a17 
boost::exception_detail::copy_boost_exception(boost::exception*, 
boost::exception const*) + 929
16  org.lyx.lyx 0x0001782f 
boost::exception_detail::copy_boost_exception(boost::exception*, 
boost::exception const*) + 441
17  org.lyx.lyx 0x0001775d 
boost::exception_detail::copy_boost_exception(boost::exception*, 
boost::exception const*) + 231

growing menu

everytime i close a document, i get a new reconfigure item in the LyX menu on 
my mac

again: am i alone?

thanks, ed.

Re: regular crashes on OSX

2013-05-07 Thread Anders Ekberg

Same for me. But when I quit LyX, not when only closing a document.
Been aiming to post a bug report, but as you I can't really find any
consistency in the behavior (or a minimum example). LyX 2.0.5.1 on OS X
10.8.3.

/Anders


On 2013-05-07 15:45, Edwin Leuven e.leu...@gmail.com wrote:

hi guys,

i have been experiencing regular crashes on my mac (see below)

they seem to happen when i open or close a document, but not in a
systematic way (or at least i haven't found a reproducible way to trigger
the bug)

am i the only one experiencing these?

i am using lyx 2.0.5 from the official installer

thanks, ed.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   QtGui  0x00eac9c9 QAction::isEnabled() const
+ 9
1   QtGui  0x00e95bb4
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 244
2   QtGui  0x00e95c9c
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 476
3   QtGui  0x00e95e1e
qt_mac_set_modal_state(NSMenu*, bool) + 62
4   QtGui  0x00e993c8
QMenuBarPrivate::macUpdateMenuBarImmediatly() + 1144
5   libobjc.A.dylib0x99a82586 -[NSObject
performSelector:] + 62
6   QtGui  0x00e677f9
-[NSApplication(QApplicationIntegration) qt_sendPostedMessage:] + 89
7   QtGui  0x00e676b6
-[NSApplication(QApplicationIntegration) qt_sendEvent:] + 118
8   QtGui  0x00e67871 -[QNSApplication
sendEvent:] + 49
9   com.apple.AppKit   0x9273069c -[NSApplication run] + 951
10  QtGui  0x00e71802
QEventDispatcherMac::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
+ 1570
11  QtCore 0x00d12a61
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 65
12  QtCore 0x00d12d8a
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 170
13  QtCore 0x00d14120 QCoreApplication::exec() +
176
14  org.lyx.lyx0x00103a6f lyx::Lexer::Pimpl::~Pimpl()
+ 29605
15  org.lyx.lyx0x00017a17
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 929
16  org.lyx.lyx0x0001782f
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 441
17  org.lyx.lyx0x0001775d
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 231

Re: regular crashes on OSX


On 05/07/2013 10:03 AM, Anders Ekberg wrote:

Same for me. But when I quit LyX, not when only closing a document.
Been aiming to post a bug report, but as you I can't really find any
consistency in the behavior (or a minimum example). LyX 2.0.5.1 on OS X
10.8.3.


Stephan is aware of these problems. It seems they have something to do 
with the system on which the binary is built. There is going to be some 
discussion about it shortly, I believe.


Richard



/Anders


On 2013-05-07 15:45, Edwin Leuven e.leu...@gmail.com wrote:


hi guys,

i have been experiencing regular crashes on my mac (see below)

they seem to happen when i open or close a document, but not in a
systematic way (or at least i haven't found a reproducible way to trigger
the bug)

am i the only one experiencing these?

i am using lyx 2.0.5 from the official installer

thanks, ed.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   QtGui   0x00eac9c9 QAction::isEnabled() const
+ 9
1   QtGui   0x00e95bb4
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 244
2   QtGui   0x00e95c9c
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 476
3   QtGui   0x00e95e1e
qt_mac_set_modal_state(NSMenu*, bool) + 62
4   QtGui   0x00e993c8
QMenuBarPrivate::macUpdateMenuBarImmediatly() + 1144
5   libobjc.A.dylib 0x99a82586 -[NSObject
performSelector:] + 62
6   QtGui   0x00e677f9
-[NSApplication(QApplicationIntegration) qt_sendPostedMessage:] + 89
7   QtGui   0x00e676b6
-[NSApplication(QApplicationIntegration) qt_sendEvent:] + 118
8   QtGui   0x00e67871 -[QNSApplication
sendEvent:] + 49
9   com.apple.AppKit0x9273069c -[NSApplication run] + 951
10  QtGui   0x00e71802
QEventDispatcherMac::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
+ 1570
11  QtCore  0x00d12a61
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 65
12  QtCore  0x00d12d8a
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 170
13  QtCore  0x00d14120 QCoreApplication::exec() +
176
14  org.lyx.lyx 0x00103a6f lyx::Lexer::Pimpl::~Pimpl()
+ 29605
15  org.lyx.lyx 0x00017a17
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 929
16  org.lyx.lyx 0x0001782f
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 441
17  org.lyx.lyx 0x0001775d
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 231

Branch Open Again



Branch is open again for commits. The official release of 2.0.6 will be 
tomorrow.


Richard

[2.0.x] Some potential bugs spotted by llvm


Richard,

Here is a backport of some of my llvm warning squashing effort already 
applied to master. I selected only the warnings that can lead to bugs.


OK to apply to branch?

JMarc
From 6e4460ab4c2c8783b664070cf2d1c693106ed8c2 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes lasgout...@lyx.org
Date: Fri, 3 May 2013 14:15:10 +0200
Subject: [PATCH] Some potential bugs spotted by llvm/clang

src/TextClass.h
src/insets/InsetTabular.h

  Overloaded virtual method missing the 'const' qualifier

src/insets/InsetCommandParams.h

  Missing constructor (breaks compilation with llvm/clang)

src/frontends/qt4/GuiWorkArea.cpp

  Missing parenthesis: `+' has priority over `?:' (I do not know
  whether this has a visible effect).

src/mathed/InsetMathFont.cpp

  Use of == instead of = in mathmlize()
---
 src/TextClass.h   |2 +-
 src/frontends/qt4/GuiWorkArea.cpp |2 +-
 src/insets/InsetCommandParams.h   |2 ++
 src/insets/InsetTabular.h |2 +-
 src/mathed/InsetMathFont.cpp  |4 ++--
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/TextClass.h b/src/TextClass.h
index dc47192..dc30062 100644
--- a/src/TextClass.h
+++ b/src/TextClass.h
@@ -361,7 +361,7 @@ public:
 	/// \return true if there is a Layout with latexname lay
 	bool hasLaTeXLayout(std::string const  lay) const;
 	/// A DocumentClass nevers count as loaded, since it is dynamic
-	virtual bool loaded() { return false; }
+	virtual bool loaded() const { return false; }
 	/// \return the layout object of an inset given by name. If the name
 	/// is not found as such, the part after the ':' is stripped off, and
 	/// searched again. In this way, an error fallback can be provided:
diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index df9dfe8..049831d 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -940,7 +940,7 @@ void GuiWorkArea::generateSyntheticMouseEvent()
 		buffer_view_-scroll(up ? -step : step);
 		buffer_view_-updateMetrics();
 	} else {
-		buffer_view_-scrollDocView(value + up ? -step : step, false);
+		buffer_view_-scrollDocView(value + (up ? -step : step), false);
 	}
 
 	// In which paragraph do we have to set the cursor ?
diff --git a/src/insets/InsetCommandParams.h b/src/insets/InsetCommandParams.h
index 7dc59fa..219d79b 100644
--- a/src/insets/InsetCommandParams.h
+++ b/src/insets/InsetCommandParams.h
@@ -31,6 +31,8 @@ class Lexer;
 
 class ParamInfo {
 public:
+	///
+	ParamInfo() {}
 	/// Types of parameters
 	enum ParamType {
 		LATEX_OPTIONAL,/// normal optional argument
diff --git a/src/insets/InsetTabular.h b/src/insets/InsetTabular.h
index bc4542c..2049e54 100644
--- a/src/insets/InsetTabular.h
+++ b/src/insets/InsetTabular.h
@@ -55,7 +55,7 @@ public:
 	///
 	InsetCode lyxCode() const { return CELL_CODE; }
 	///
-	Inset * clone() { return new InsetTableCell(*this); }
+	Inset * clone() const { return new InsetTableCell(*this); }
 	///
 	bool getStatus(Cursor  cur, FuncRequest const  cmd,
 		FuncStatus  status) const;
diff --git a/src/mathed/InsetMathFont.cpp b/src/mathed/InsetMathFont.cpp
index efd43ce..9c02a3c 100644
--- a/src/mathed/InsetMathFont.cpp
+++ b/src/mathed/InsetMathFont.cpp
@@ -140,7 +140,7 @@ void InsetMathFont::htmlize(HtmlStream  os) const
 	 || tag == textbf)
 		variant = bold;
 	else if (tag == mathcal)
-		variant == script;
+		variant = script;
 	else if (tag == mathit || tag == textsl
 	 || tag == emph || tag == textit)
 		variant = italic;
@@ -180,7 +180,7 @@ void InsetMathFont::mathmlize(MathStream  os) const
 	 || tag == textbf)
 		variant = bold;
 	else if (tag == mathcal)
-		variant == script;
+		variant = script;
 	else if (tag == mathit || tag == textsl
 	 || tag == emph || tag == textit)
 		variant = italic;
-- 
1.7.0.4

Re: [2.0.x] Some potential bugs spotted by llvm


On 05/07/2013 11:38 AM, Jean-Marc Lasgouttes wrote:

Richard,

Here is a backport of some of my llvm warning squashing effort already 
applied to master. I selected only the warnings that can lead to bugs.


OK to apply to branch?


Yes, this looks fine.

Richard

Re: Unit testing: The Small Plan


On 05/07/2013 04:57 AM, Elmar Hinz wrote:

Hello list,

I'd like to come up with a small plan for getting started with unit 
testing:


I am a total ignoramus when it comes to unit testing, so I will leave it 
to others

who actually know something to express a view.

Richard

Re: growing menu

Edwin Leuven wrote:
 everytime i close a document, i get a new reconfigure item in the LyX menu 
 on my mac
 
 again: am i alone?

IIRC more times reported and nothing new, try bugzilla or archives.
I even thought that it was already fixed.
Pavel

Re: Unit testing: The Small Plan

Elmar Hinz wrote:
 If somebody can give improvements to the plan, it's welcome.

I guess people will let you do almost anything what you like in test/*
but they will become much more picky when it comes to changes in src/.
Perhaps the best way is to try example, post patch here and
and look what people think.

Pavel

Re: Unit testing: The Small Plan


Op 7-5-2013 10:57, Elmar Hinz schreef:

Hello list,

I'd like to come up with a small plan for getting started with unit 
testing:


I would like to see some examples of mocking  and injection.

I tried to write some tests using the google framework, and started with 
the Buffer class. This immediately gives you the problem that it is 
dependent on a large number of other classes. So, this would mean that 
you have to fake a large part of the LyX codebase.


Then I tried to link against all libraries of LyX, but then I ran into 
problems that the application was not initialized (e.g., Package, 
translations etc.)


I'm afraid we can't do much testing until the above is solved.

My attempt thus far can be found at: 
git://git.lyx.org/developers/vfr/lyx.git


That is not really kosher, but at least a simple way to get started 
directly.


It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.


Ideally, one would not need to care about private variables because we 
are only interested in that the public interface does what it is 
supposed to do. Right ?


Vincent

Re: Unit testing: The Small Plan

On Tue, May 7, 2013 at 9:20 PM, Pavel Sanda sa...@lyx.org wrote:

 Elmar Hinz wrote:
  If somebody can give improvements to the plan, it's welcome.

 I guess people will let you do almost anything what you like in test/*
 but they will become much more picky when it comes to changes in src/.
 Perhaps the best way is to try example, post patch here and
 and look what people think.

 Pavel


Hi Pavel,

as long as people don't become picky it's a good sign.
They even shouldn't become picky, during big refactoring of the sources.

It works in two steps. In the first step you write tests, that prove the
existing API is fully functioning.

Then you start with new functions or other kind of refactoring.  The test
bell should immediately ring
when something is broken, long before people get picky at all.

The drawback may be that people don't notice that you are working until you
come out with the new feature.

Fotunatly the world is never that perfect.

\Elmar

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: growing menu

Am 07.05.2013 um 15:47 schrieb Edwin Leuven e.leu...@gmail.com:

 everytime i close a document, i get a new reconfigure item in the LyX menu 
 on my mac
 
 again: am i alone?

No. This and the crashes are caused by using the Cocoa framework and the code 
moving the menu items from the Tools to the LyX menu. The LyX 2.0.6 release is 
build with Carbon because of these problems. But, yes, I know Carbon is a dead 
end. It has to be corrected for Cocoa too. On my 10.8.3 system Qt-4.8.4 even 
refuses to compile the Carbon API. They have disabled it totally for x86_64 and 
for i386 one gets a compile error.

Another effect is the behavior regarding bug #8538 
(http://www.lyx.org/trac/ticket/8538). The build with Qt-4.8.4-Carbon is not 
affected by this bug. The \Omega is now rendered again.

Regards,
Stephan

Re: growing menu


Le 07/05/13 21:46, Stephan Witt a écrit :

Am 07.05.2013 um 15:47 schrieb Edwin Leuven e.leu...@gmail.com:


everytime i close a document, i get a new reconfigure item in the
LyX menu on my mac

again: am i alone?


No. This and the crashes are caused by using the Cocoa framework and
the code moving the menu items from the Tools to the LyX menu. The
LyX 2.0.6 release is build with Carbon because of these problems.
But, yes, I know Carbon is a dead end. It has to be corrected for
Cocoa too. On my 10.8.3 system Qt-4.8.4 even refuses to compile the
Carbon API. They have disabled it totally for x86_64 and for i386 one
gets a compile error.


I'll try to see if I can handle the double menus thing. Did you try already?


Another effect is the behavior regarding bug #8538
(http://www.lyx.org/trac/ticket/8538). The build with Qt-4.8.4-Carbon
is not affected by this bug. The \Omega is now rendered again.


I remember that we shared some ideas abot fixing Qt for this \omega
problem. Did you find time to try it?

JMarc

[2.0.x] compatibility with automake 1.13


Richard, what about this for 2.0.x?

JMarc

Re: Unit testing: The Small Plan

 I would like to see some examples of mocking  and injection.


Thank you, Vincent,


 I tried to write some tests using the google framework, and started with
 the Buffer class. This immediately gives you the problem that it is
 dependent on a large number of other classes. So, this would mean that you
 have to fake a large part of the LyX codebase.


Well yes, actually I would start with the smallest class and do the Buffer
class as the last one. I guess it requires a lot of experiance to tame that.


 Then I tried to link against all libraries of LyX, but then I ran into
 problems that the application was not initialized (e.g., Package,
 translations etc.)

 I'm afraid we can't do much testing until the above is solved.


So a few tests already brought up a vision of what need to be solved.
That's exactly their most important strength. They are a perfect teacher.

Here we find out how everything currently depends on everything. We
couldn't even take a little piece out, to use it as a library for something
completly different.

Regards

\Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: [2.0.x] compatibility with automake 1.13


Le 07/05/13 22:04, Jean-Marc Lasgouttes a écrit :

Richard, what about this for 2.0.x?

JMarc


Now with the patches
From c76a91a23261b0f919838461ce23cadfc5ebb519 Mon Sep 17 00:00:00 2001
From: Stephan Witt sw...@lyx.org
Date: Fri, 18 Jan 2013 21:17:18 +0100
Subject: [PATCH 1/2] add support for automake 1.13

---
 autogen.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index 8b48960..8239558 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -16,12 +16,12 @@ test $automake_version !=   {
 }
 
 case $automake_version in
-*' '1.[8-9]*|*' '1.1[012]*)
+*' '1.[8-9]*|*' '1.1[0123]*)
;;
 *)
 
echo This automake version is not supported by LyX.
-   echo LyX only supports automake 1.8 to 1.12.
+   echo LyX only supports automake 1.8 to 1.13.
exit 1
;;
 esac
-- 
1.8.1.2

From 390fa0dd990c419f003850bfe494b99f4a44931e Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes lasgout...@lyx.org
Date: Mon, 21 Jan 2013 10:15:27 +0100
Subject: [PATCH 2/2] Fix compatibility with automake 1.13

Do not use AM_PROG_MKDIR_P, which is obsolete. We use  the AC_* version
now, which requires autoconf=2.59d. This also mean that we need to use
the variable MKDIR_P instead of mkdir_p.
---
 INSTALL   | 4 ++--
 autogen.sh| 4 ++--
 intl/Makefile.in  | 2 +-
 m4/intl.m4| 3 ++-
 m4/po.m4  | 3 ++-
 po/Makefile.in.in | 2 +-
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/INSTALL b/INSTALL
index dd490db..42e0b98 100644
--- a/INSTALL
+++ b/INSTALL
@@ -35,8 +35,8 @@ Note for Git checkouts
 
 If you have checked this out from Git, you need to have:
 * automake = 1.8
-* autoconf = 2.59c
-* gettext = 0.12
+* autoconf = 2.59d
+* gettext = 0.16.1
 Then type ./autogen.sh to build the needed configuration
 files and proceed as stated above/below.
 
diff --git a/autogen.sh b/autogen.sh
index 8239558..2884481 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -38,11 +38,11 @@ test $autoversion !=   {
 
 
 case $autoversion in
-*' '2.59[cd]|*' '2.60[ab]|*' '2.6[0-9])
+*' '2.59d|*' '2.60[ab]|*' '2.6[0-9])
;;
 *)
echo This autoconf version is not supported by LyX.
-   echo LyX only supports autoconf 2.59c-2.69.
+   echo LyX only supports autoconf 2.59d-2.69.
exit 1
;;
 esac
diff --git a/intl/Makefile.in b/intl/Makefile.in
index 525922e..49e8e70 100644
--- a/intl/Makefile.in
+++ b/intl/Makefile.in
@@ -62,7 +62,7 @@ INSTALL_DATA = @INSTALL_DATA@
 mkinstalldirs = $(SHELL) @install_sh@ -d
 install_sh = $(SHELL) @install_sh@
 MKDIR_P = @MKDIR_P@
-mkdir_p = @mkdir_p@
+mkdir_p = @MKDIR_P@
 
 l = @INTL_LIBTOOL_SUFFIX_PREFIX@
 
diff --git a/m4/intl.m4 b/m4/intl.m4
index dcefb11..286efc9 100644
--- a/m4/intl.m4
+++ b/m4/intl.m4
@@ -25,7 +25,8 @@ dnlUSE_INCLUDED_LIBINTL, BUILD_INCLUDED_LIBINTL.
 AC_DEFUN([AM_INTL_SUBDIR],
 [
   AC_REQUIRE([AC_PROG_INSTALL])dnl
-  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake
+  AC_REQUIRE([AC_PROG_MKDIR_P])dnl defined by autoconf
+dnl  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake (obsolete)
   AC_REQUIRE([AC_PROG_CC])dnl
   AC_REQUIRE([AC_CANONICAL_HOST])dnl
   AC_REQUIRE([gt_GLIBC2])dnl
diff --git a/m4/po.m4 b/m4/po.m4
index 00133ef..815c873 100644
--- a/m4/po.m4
+++ b/m4/po.m4
@@ -24,7 +24,8 @@ AC_DEFUN([AM_PO_SUBDIRS],
 [
   AC_REQUIRE([AC_PROG_MAKE_SET])dnl
   AC_REQUIRE([AC_PROG_INSTALL])dnl
-  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake
+  AC_REQUIRE([AC_PROG_MKDIR_P])dnl defined by autoconf
+dnl  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake (obsolete)
   AC_REQUIRE([AM_NLS])dnl
 
   dnl Perform the following tests also if --disable-nls has been given,
diff --git a/po/Makefile.in.in b/po/Makefile.in.in
index 33534f9..01bef6d 100644
--- a/po/Makefile.in.in
+++ b/po/Makefile.in.in
@@ -43,7 +43,7 @@ INSTALL_DATA = @INSTALL_DATA@
 mkinstalldirs = $(SHELL) @install_sh@ -d
 install_sh = $(SHELL) @install_sh@
 MKDIR_P = @MKDIR_P@
-mkdir_p = @mkdir_p@
+mkdir_p = @MKDIR_P@
 
 GMSGFMT_ = @GMSGFMT@
 GMSGFMT_no = @GMSGFMT@
-- 
1.8.1.2

Re: growing menu

Am 07.05.2013 um 21:50 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 Le 07/05/13 21:46, Stephan Witt a écrit :
 Am 07.05.2013 um 15:47 schrieb Edwin Leuven e.leu...@gmail.com:
 
 everytime i close a document, i get a new reconfigure item in the
 LyX menu on my mac
 
 again: am i alone?
 
 No. This and the crashes are caused by using the Cocoa framework and
 the code moving the menu items from the Tools to the LyX menu. The
 LyX 2.0.6 release is build with Carbon because of these problems.
 But, yes, I know Carbon is a dead end. It has to be corrected for
 Cocoa too. On my 10.8.3 system Qt-4.8.4 even refuses to compile the
 Carbon API. They have disabled it totally for x86_64 and for i386 one
 gets a compile error.
 
 I'll try to see if I can handle the double menus thing. Did you try already?

Not really. I think it's simply a bug. It should work.
The Reconfigure menu item has the MenuRole QAction::ApplicationSpecificRole.

 
 Another effect is the behavior regarding bug #8538
 (http://www.lyx.org/trac/ticket/8538). The build with Qt-4.8.4-Carbon
 is not affected by this bug. The \Omega is now rendered again.
 
 I remember that we shared some ideas abot fixing Qt for this \omega
 problem. Did you find time to try it?

Yes, but it was neither funny nor successful. After learning how to debug the
Qt frameworks I thought I can fix it. But
1. I cannot find the location where the font property symbolFont ever gets
assigned a true value. It seems like it's done by comparing some names.
2. Even if I force symbolFont = true where you've spotted it's use it makes no
difference. Obviously, this not the right place or not the only place to fix it.

I'll try to address that again later.

Stephan

Re: Unit testing: The Small Plan

 Ideally, one would not need to care about private variables because we
are only interested in that the public interface does what it is supposed
to do. Right ?

Yes, at least as far as it concerns the testing.

Denpendency Injection has other aspects.

As an example, if there is a class that prints to stdout you mayby would
not test that, taking it as an interal behaviour.
With DI you inject the output stream, with the result that you can use
different printers in future.

Lyx already does this in many caes. Exactly that is dependancy injection.

Now you could drop in a MockStream to prove that the class uses the stream
object like expacted.

Regards

\Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

Does anybody know somethng about this bug? Is it true that tables in ltr 
mode should have ltr columns? What does this mean anyway?


JMarc


 Message original 
Sujet: [Bug 347378] Re: Two columns in Hebrew is in LTR
Date : Tue, 07 May 2013 19:08:00 -
De : Bug Watch Updater 347...@bugs.launchpad.net
Répondre à : Bug 347378 347...@bugs.launchpad.net
Pour : lasgout...@lyx.org

** Changed in: lyx
   Status: New = Fix Released

--
You received this bug notification because you are subscribed to lyx in
Ubuntu.
https://bugs.launchpad.net/bugs/347378

Title:
  Two columns in Hebrew is in LTR

Status in LyX - The Document Processor:
  Fix Released
Status in “lyx” package in Ubuntu:
  New

Bug description:
  Dear interested parties,

  Hebrew is RTL and that means that multiple columns should be ordered
  RTL as well.

  Currently, this isn't the case. When I select two columns they are
  created in LTR order.

  Using lyx 1.6.1-1~intrepid1 from intrepid-backports.

  Many blessings.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lyx/+bug/347378/+subscriptions

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR


Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:
Does anybody know somethng about this bug? Is it true that tables in 
ltr mode should have ltr columns? What does this mean anyway?


JMarc


Yes, I 'fixed' it.

It isn't about tables, it is about a two column document.

It means that you read the right side of the page before the left side.

Vincent

Re: growing menu


Le 07/05/13 22:13, Stephan Witt a écrit :

I remember that we shared some ideas abot fixing Qt for this \omega
problem. Did you find time to try it?


Yes, but it was neither funny nor successful. After learning how to debug the
Qt frameworks I thought I can fix it. But
1. I cannot find the location where the font property symbolFont ever gets
assigned a true value. It seems like it's done by comparing some names.
2. Even if I force symbolFont = true where you've spotted it's use it makes no
difference. Obviously, this not the right place or not the only place to fix it.

I'll try to address that again later.


Is there abug report against qt? Shall we file one?

JMarc

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR


Le 07/05/13 22:41, Vincent van Ravesteijn a écrit :

Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:

Does anybody know somethng about this bug? Is it true that tables in
ltr mode should have ltr columns? What does this mean anyway?

JMarc


Yes, I 'fixed' it.

It isn't about tables, it is about a two column document.

It means that you read the right side of the page before the left side.


Do you have a pointer?

JMarc

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

Op 7 mei 2013 23:15 schreef Jean-Marc Lasgouttes lasgout...@lyx.org het
volgende:

 Le 07/05/13 22:41, Vincent van Ravesteijn a écrit :

 Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:

 Does anybody know somethng about this bug? Is it true that tables in
 ltr mode should have ltr columns? What does this mean anyway?

 JMarc


 Yes, I 'fixed' it.

 It isn't about tables, it is about a two column document.

 It means that you read the right side of the page before the left side.


 Do you have a pointer?

 JMarc


Bug 6389.

Vincent

Re: DIFFICULTY WITH PASTING IMAGE IN LYX

2013-05-07 Thread Scott Kostyshak

On Wed, May 1, 2013 at 1:26 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 1-5-2013 18:03, Kamal Garg schreef:

 I know Only one way of pasting pictures in lyx, that is by selecting insert
 graphic option in toolbar.(shown in image)

 i  am trying to copy image(*.jpg).but direct simple way:ctrl+c(copying )
 from my folder of pictures  and ctrl+v (paste)for pasting image in lyx  is
 not working.

 Sir, if there is another way of doing the same,then let me know.


 This is indeed not working. It's a missing feature. It's probably not so
 difficult to implement.

 There is another way to do this. You can drag the image from the explorer
 onto the LyX window and paste it like this.

Kamal,

Can you file an enhancement request for this?
http://www.lyx.org/trac

Scott

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR


Le 07/05/13 23:26, Vincent van Ravesteijn a écrit :

  Yes, I 'fixed' it.
 
  It isn't about tables, it is about a two column document.
 
  It means that you read the right side of the page before the left side.
 
  Do you have a pointer?

Bug 6389.


Ouch. I'm glad I did not see it at the time :)

But it seems that there is no better solution unfortunately.

JMarc

Re: Unit testing: The Small Plan

2013-05-07 Thread Cyrille Artho

Hi Elmar,
I think your plan covers the question HOW do we want to unit test the
software well. However, we have not thought much about the WHAT do we
want to test? question. Essentially, we need to think about which
classes/functions to test first.

I think it is not realistic to aim for a high test coverage with software
as large as LyX. Unit tests make sense in certain cases and less in others.
So we should identify these use cases first, and start with a few selective
unit tests. We can then grow them as we see fit.

For user-driven actions (LFUNs), LyX already has a test framework. However,
these tests do not cover internals of LyX.

Which internals do not require a complex sequence of actions (or a complex
internal state) to be tested? (Those that do are maybe better covered with
other types of tests.) Where has the code changed often in the past, and is
expected to change often in the future? What kinds of (internal) functions
are often covered by bug reports and thus warrant better test automation?

I hope some of the veteran developers can help answer these questions.

Elmar Hinz wrote:

Hello list,

I'd like to come up with a small plan for getting started with unit testing:

==
1.) Directory structure: tests/unit/
==

* Unit tests stay their own directory separated from src/.
* Below tests/unit the directory structure mirrors the structure of src/.
* The reason for the subfolder unit is, that unit tests are not the
only type of tests. Unit tests test the single units of the source.

==
2.) Mocking: googlemock
==

This weekend I researched for alternatives, but there was none
that made a stable impression to me apart from googlemock.

With C++ mocking can take two approaches:

2.a) Turning classes into Templates, to be able to replace members by mocks.

http://programmaticallyspeaking.blogspot.de/2010/04/beautiful-dependency-injection-in-c.html

This seems to invasive into the existing sources for me.

2.b) Inheriting the mocks from the real objects, so that they are of the
same type.

This is the approach of googlemock.

Googlemock can be used with any mocking framework. It best integrates with
googletest.

==
3.) Testing framework: any
==

Unit tests are independent units, so any framework or none can be used.
For the reason of mocks, googletest is recommended.

==
4.) Runnig all tests
==

To be able to run all tests at once they need to be detected.

* The naming pattern of the binary to support this: whateverTest
* A successful test binary returns 0, the others an Error.
* The global test detector and runner is a Python script.

==
5.) Dependency injection
==

Dependency injection (the mock objects) is more difficult with C++
for multiple reasons like the missing garbage collection or reflection.

The approach that looks most forward and less intrusive for the sources
to me, is to directly access the private members by making them public
during testing and only during testing.

That is not really kosher, but at least a simple way to get started directly.

It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.

\Elmar

--
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

--
Regards,
Cyrille Artho - http://artho.com/
Love is the delusion that one woman differs from another.
-- H.L. Mencken

Re: growing menu

Am 07.05.2013 um 23:13 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 Le 07/05/13 22:13, Stephan Witt a écrit :
 I remember that we shared some ideas abot fixing Qt for this \omega
 problem. Did you find time to try it?
 
 Yes, but it was neither funny nor successful. After learning how to debug the
 Qt frameworks I thought I can fix it. But
 1. I cannot find the location where the font property symbolFont ever gets
 assigned a true value. It seems like it's done by comparing some names.
 2. Even if I force symbolFont = true where you've spotted it's use it makes 
 no
 difference. Obviously, this not the right place or not the only place to fix 
 it.
 
 I'll try to address that again later.
 
 Is there abug report against qt? Shall we file one?

I have not searched but this is one possible outcome.

Stephan

Re: Source view window


Le 07/05/13 06:13, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

What about this different logic instead? It relies on the size/height of
the window, not on the dock position.


No strong preference here. P


The advantage is that it also does something reasonable when the widget 
is not docked (or when it is docked and you set the LyX window to 
ridiculous size :)


Then I'll push it and see what happens. I'll revert if there are complaints.

JMarc

Unit testing: The Small Plan

Hello list,

I'd like to come up with a small plan for getting started with unit testing:

==
1.) Directory structure: "tests/unit/"
==

* Unit tests stay their own directory separated from src/.
* Below "tests/unit" the directory structure mirrors the structure of
"src/".
* The reason for the subfolder "unit" is, that unit tests are not the
only type of tests. Unit tests test the single units of the source.

==
2.) Mocking: googlemock
==

This weekend I researched for alternatives, but there was none
that made a stable impression to me apart from googlemock.

With C++ mocking can take two approaches:

2.a) Turning classes into Templates, to be able to replace members by mocks.

http://programmaticallyspeaking.blogspot.de/2010/04/beautiful-dependency-injection-in-c.html

This seems to invasive into the existing sources for me.

2.b) Inheriting the mocks from the real objects, so that they are of the
same type.

This is the approach of googlemock.

Googlemock can be used with any mocking framework. It best integrates with
googletest.

==
3.) Testing framework: any
==

Unit tests are independent units, so any framework or none can be used.
For the reason of mocks, googletest is recommended.

==
4.) Runnig all tests
==

To be able to run all tests at once they need to be detected.

* The naming pattern of the binary to support this: whateverTest
* A successful test binary returns 0, the others an Error.
* The global test detector and runner is a Python script.

==
5.) Dependency injection
==

Dependency injection (the mock objects) is more difficult with C++
for multiple reasons like the missing garbage collection or reflection.

The approach that looks most forward and less intrusive for the sources
to me, is to directly access the private members by making them public
during testing and only during testing.

That is not really kosher, but at least a simple way to get started
directly.

It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.

\Elmar

--
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

regular crashes on OSX

hi guys,

i have been experiencing regular crashes on my mac (see below)

they seem to happen when i open or close a document, but not in a systematic 
way (or at least i haven't found a reproducible way to trigger the bug)

am i the only one experiencing these?

i am using lyx 2.0.5 from the official installer

thanks, ed.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   QtGui   0x00eac9c9 QAction::isEnabled() const + 
9
1   QtGui   0x00e95bb4 
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 244
2   QtGui   0x00e95c9c 
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 476
3   QtGui   0x00e95e1e 
qt_mac_set_modal_state(NSMenu*, bool) + 62
4   QtGui   0x00e993c8 
QMenuBarPrivate::macUpdateMenuBarImmediatly() + 1144
5   libobjc.A.dylib 0x99a82586 -[NSObject performSelector:] 
+ 62
6   QtGui   0x00e677f9 
-[NSApplication(QApplicationIntegration) qt_sendPostedMessage:] + 89
7   QtGui   0x00e676b6 
-[NSApplication(QApplicationIntegration) qt_sendEvent:] + 118
8   QtGui   0x00e67871 -[QNSApplication sendEvent:] 
+ 49
9   com.apple.AppKit0x9273069c -[NSApplication run] + 951
10  QtGui   0x00e71802 
QEventDispatcherMac::processEvents(QFlags) + 1570
11  QtCore  0x00d12a61 
QEventLoop::processEvents(QFlags) + 65
12  QtCore  0x00d12d8a 
QEventLoop::exec(QFlags) + 170
13  QtCore  0x00d14120 QCoreApplication::exec() + 
176
14  org.lyx.lyx 0x00103a6f lyx::Lexer::Pimpl::~Pimpl() 
+ 29605
15  org.lyx.lyx 0x00017a17 
boost::exception_detail::copy_boost_exception(boost::exception*, 
boost::exception const*) + 929
16  org.lyx.lyx 0x0001782f 
boost::exception_detail::copy_boost_exception(boost::exception*, 
boost::exception const*) + 441
17  org.lyx.lyx 0x0001775d 
boost::exception_detail::copy_boost_exception(boost::exception*, 
boost::exception const*) + 231

growing menu

everytime i close a document, i get a new "reconfigure" item in the LyX menu on 
my mac

again: am i alone?

thanks, ed.

Re: regular crashes on OSX

2013-05-07 Thread Anders Ekberg

Same for me. But when I quit LyX, not when only closing a document.
Been aiming to post a bug report, but as you I can't really find any
consistency in the behavior (or a minimum example). LyX 2.0.5.1 on OS X
10.8.3.

/Anders


On 2013-05-07 15:45, "Edwin Leuven"  wrote:

>hi guys,
>
>i have been experiencing regular crashes on my mac (see below)
>
>they seem to happen when i open or close a document, but not in a
>systematic way (or at least i haven't found a reproducible way to trigger
>the bug)
>
>am i the only one experiencing these?
>
>i am using lyx 2.0.5 from the official installer
>
>thanks, ed.
>
>
>
>Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>0   QtGui  0x00eac9c9 QAction::isEnabled() const
>+ 9
>1   QtGui  0x00e95bb4
>qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 244
>2   QtGui  0x00e95c9c
>qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 476
>3   QtGui  0x00e95e1e
>qt_mac_set_modal_state(NSMenu*, bool) + 62
>4   QtGui  0x00e993c8
>QMenuBarPrivate::macUpdateMenuBarImmediatly() + 1144
>5   libobjc.A.dylib0x99a82586 -[NSObject
>performSelector:] + 62
>6   QtGui  0x00e677f9
>-[NSApplication(QApplicationIntegration) qt_sendPostedMessage:] + 89
>7   QtGui  0x00e676b6
>-[NSApplication(QApplicationIntegration) qt_sendEvent:] + 118
>8   QtGui  0x00e67871 -[QNSApplication
>sendEvent:] + 49
>9   com.apple.AppKit   0x9273069c -[NSApplication run] + 951
>10  QtGui  0x00e71802
>QEventDispatcherMac::processEvents(QFlags)
>+ 1570
>11  QtCore 0x00d12a61
>QEventLoop::processEvents(QFlags) + 65
>12  QtCore 0x00d12d8a
>QEventLoop::exec(QFlags) + 170
>13  QtCore 0x00d14120 QCoreApplication::exec() +
>176
>14  org.lyx.lyx0x00103a6f lyx::Lexer::Pimpl::~Pimpl()
>+ 29605
>15  org.lyx.lyx0x00017a17
>boost::exception_detail::copy_boost_exception(boost::exception*,
>boost::exception const*) + 929
>16  org.lyx.lyx0x0001782f
>boost::exception_detail::copy_boost_exception(boost::exception*,
>boost::exception const*) + 441
>17  org.lyx.lyx0x0001775d
>boost::exception_detail::copy_boost_exception(boost::exception*,
>boost::exception const*) + 231
>
>

Re: regular crashes on OSX


On 05/07/2013 10:03 AM, Anders Ekberg wrote:

Same for me. But when I quit LyX, not when only closing a document.
Been aiming to post a bug report, but as you I can't really find any
consistency in the behavior (or a minimum example). LyX 2.0.5.1 on OS X
10.8.3.


Stephan is aware of these problems. It seems they have something to do 
with the system on which the binary is built. There is going to be some 
discussion about it shortly, I believe.


Richard



/Anders


On 2013-05-07 15:45, "Edwin Leuven"  wrote:


hi guys,

i have been experiencing regular crashes on my mac (see below)

they seem to happen when i open or close a document, but not in a
systematic way (or at least i haven't found a reproducible way to trigger
the bug)

am i the only one experiencing these?

i am using lyx 2.0.5 from the official installer

thanks, ed.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   QtGui   0x00eac9c9 QAction::isEnabled() const
+ 9
1   QtGui   0x00e95bb4
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 244
2   QtGui   0x00e95c9c
qt_mac_set_modal_state_helper_recursive(NSMenu*, NSMenu*, bool) + 476
3   QtGui   0x00e95e1e
qt_mac_set_modal_state(NSMenu*, bool) + 62
4   QtGui   0x00e993c8
QMenuBarPrivate::macUpdateMenuBarImmediatly() + 1144
5   libobjc.A.dylib 0x99a82586 -[NSObject
performSelector:] + 62
6   QtGui   0x00e677f9
-[NSApplication(QApplicationIntegration) qt_sendPostedMessage:] + 89
7   QtGui   0x00e676b6
-[NSApplication(QApplicationIntegration) qt_sendEvent:] + 118
8   QtGui   0x00e67871 -[QNSApplication
sendEvent:] + 49
9   com.apple.AppKit0x9273069c -[NSApplication run] + 951
10  QtGui   0x00e71802
QEventDispatcherMac::processEvents(QFlags)
+ 1570
11  QtCore  0x00d12a61
QEventLoop::processEvents(QFlags) + 65
12  QtCore  0x00d12d8a
QEventLoop::exec(QFlags) + 170
13  QtCore  0x00d14120 QCoreApplication::exec() +
176
14  org.lyx.lyx 0x00103a6f lyx::Lexer::Pimpl::~Pimpl()
+ 29605
15  org.lyx.lyx 0x00017a17
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 929
16  org.lyx.lyx 0x0001782f
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 441
17  org.lyx.lyx 0x0001775d
boost::exception_detail::copy_boost_exception(boost::exception*,
boost::exception const*) + 231

Branch Open Again



Branch is open again for commits. The official release of 2.0.6 will be 
tomorrow.


Richard

[2.0.x] Some potential bugs spotted by llvm


Richard,

Here is a backport of some of my llvm warning squashing effort already 
applied to master. I selected only the warnings that can lead to bugs.


OK to apply to branch?

JMarc
>From 6e4460ab4c2c8783b664070cf2d1c693106ed8c2 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Fri, 3 May 2013 14:15:10 +0200
Subject: [PATCH] Some potential bugs spotted by llvm/clang

src/TextClass.h
src/insets/InsetTabular.h

  Overloaded virtual method missing the 'const' qualifier

src/insets/InsetCommandParams.h

  Missing constructor (breaks compilation with llvm/clang)

src/frontends/qt4/GuiWorkArea.cpp

  Missing parenthesis: `+' has priority over `?:' (I do not know
  whether this has a visible effect).

src/mathed/InsetMathFont.cpp

  Use of == instead of = in mathmlize()
---
 src/TextClass.h   |2 +-
 src/frontends/qt4/GuiWorkArea.cpp |2 +-
 src/insets/InsetCommandParams.h   |2 ++
 src/insets/InsetTabular.h |2 +-
 src/mathed/InsetMathFont.cpp  |4 ++--
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/TextClass.h b/src/TextClass.h
index dc47192..dc30062 100644
--- a/src/TextClass.h
+++ b/src/TextClass.h
@@ -361,7 +361,7 @@ public:
 	/// \return true if there is a Layout with latexname lay
 	bool hasLaTeXLayout(std::string const & lay) const;
 	/// A DocumentClass nevers count as loaded, since it is dynamic
-	virtual bool loaded() { return false; }
+	virtual bool loaded() const { return false; }
 	/// \return the layout object of an inset given by name. If the name
 	/// is not found as such, the part after the ':' is stripped off, and
 	/// searched again. In this way, an error fallback can be provided:
diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index df9dfe8..049831d 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -940,7 +940,7 @@ void GuiWorkArea::generateSyntheticMouseEvent()
 		buffer_view_->scroll(up ? -step : step);
 		buffer_view_->updateMetrics();
 	} else {
-		buffer_view_->scrollDocView(value + up ? -step : step, false);
+		buffer_view_->scrollDocView(value + (up ? -step : step), false);
 	}
 
 	// In which paragraph do we have to set the cursor ?
diff --git a/src/insets/InsetCommandParams.h b/src/insets/InsetCommandParams.h
index 7dc59fa..219d79b 100644
--- a/src/insets/InsetCommandParams.h
+++ b/src/insets/InsetCommandParams.h
@@ -31,6 +31,8 @@ class Lexer;
 
 class ParamInfo {
 public:
+	///
+	ParamInfo() {}
 	/// Types of parameters
 	enum ParamType {
 		LATEX_OPTIONAL,/// normal optional argument
diff --git a/src/insets/InsetTabular.h b/src/insets/InsetTabular.h
index bc4542c..2049e54 100644
--- a/src/insets/InsetTabular.h
+++ b/src/insets/InsetTabular.h
@@ -55,7 +55,7 @@ public:
 	///
 	InsetCode lyxCode() const { return CELL_CODE; }
 	///
-	Inset * clone() { return new InsetTableCell(*this); }
+	Inset * clone() const { return new InsetTableCell(*this); }
 	///
 	bool getStatus(Cursor & cur, FuncRequest const & cmd,
 		FuncStatus & status) const;
diff --git a/src/mathed/InsetMathFont.cpp b/src/mathed/InsetMathFont.cpp
index efd43ce..9c02a3c 100644
--- a/src/mathed/InsetMathFont.cpp
+++ b/src/mathed/InsetMathFont.cpp
@@ -140,7 +140,7 @@ void InsetMathFont::htmlize(HtmlStream & os) const
 	 || tag == "textbf")
 		variant = "bold";
 	else if (tag == "mathcal")
-		variant == "script";
+		variant = "script";
 	else if (tag == "mathit" || tag == "textsl"
 	 || tag == "emph" || tag == "textit")
 		variant = "italic";
@@ -180,7 +180,7 @@ void InsetMathFont::mathmlize(MathStream & os) const
 	 || tag == "textbf")
 		variant = "bold";
 	else if (tag == "mathcal")
-		variant == "script";
+		variant = "script";
 	else if (tag == "mathit" || tag == "textsl"
 	 || tag == "emph" || tag == "textit")
 		variant = "italic";
-- 
1.7.0.4

Re: [2.0.x] Some potential bugs spotted by llvm


On 05/07/2013 11:38 AM, Jean-Marc Lasgouttes wrote:

Richard,

Here is a backport of some of my llvm warning squashing effort already 
applied to master. I selected only the warnings that can lead to bugs.


OK to apply to branch?


Yes, this looks fine.

Richard

Re: Unit testing: The Small Plan


On 05/07/2013 04:57 AM, Elmar Hinz wrote:

Hello list,

I'd like to come up with a small plan for getting started with unit 
testing:


I am a total ignoramus when it comes to unit testing, so I will leave it 
to others

who actually know something to express a view.

Richard

Re: growing menu

Edwin Leuven wrote:
> everytime i close a document, i get a new "reconfigure" item in the LyX menu 
> on my mac
> 
> again: am i alone?

IIRC more times reported and nothing new, try bugzilla or archives.
I even thought that it was already fixed.
Pavel

Re: Unit testing: The Small Plan

Elmar Hinz wrote:
> If somebody can give improvements to the plan, it's welcome.

I guess people will let you do almost anything what you like in test/*
but they will become much more picky when it comes to changes in src/.
Perhaps the best way is to try example, post patch here and
and look what people think.

Pavel

Re: Unit testing: The Small Plan


Op 7-5-2013 10:57, Elmar Hinz schreef:

Hello list,

I'd like to come up with a small plan for getting started with unit 
testing:


I would like to see some examples of mocking  and injection.

I tried to write some tests using the google framework, and started with 
the Buffer class. This immediately gives you the problem that it is 
dependent on a large number of other classes. So, this would mean that 
you have to fake a large part of the LyX codebase.


Then I tried to link against all libraries of LyX, but then I ran into 
problems that the application was not initialized (e.g., Package, 
translations etc.)


I'm afraid we can't do much testing until the above is solved.

My attempt thus far can be found at: 
git://git.lyx.org/developers/vfr/lyx.git


That is not really kosher, but at least a simple way to get started 
directly.


It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.


Ideally, one would not need to care about private variables because we 
are only interested in that the public interface does what it is 
supposed to do. Right ?


Vincent

Re: Unit testing: The Small Plan

On Tue, May 7, 2013 at 9:20 PM, Pavel Sanda  wrote:

> Elmar Hinz wrote:
> > If somebody can give improvements to the plan, it's welcome.
>
> I guess people will let you do almost anything what you like in test/*
> but they will become much more picky when it comes to changes in src/.
> Perhaps the best way is to try example, post patch here and
> and look what people think.
>
> Pavel
>

Hi Pavel,

as long as people don't become picky it's a good sign.
They even shouldn't become picky, during big refactoring of the sources.

It works in two steps. In the first step you write tests, that prove the
existing API is fully functioning.

Then you start with new functions or other kind of refactoring.  The test
bell should immediately ring
when something is broken, long before people get picky at all.

The drawback may be that people don't notice that you are working until you
come out with the new feature.

Fotunatly the world is never that perfect.

\Elmar

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: growing menu

Am 07.05.2013 um 15:47 schrieb Edwin Leuven :

> everytime i close a document, i get a new "reconfigure" item in the LyX menu 
> on my mac
> 
> again: am i alone?

No. This and the crashes are caused by using the Cocoa framework and the code 
moving the menu items from the Tools to the LyX menu. The LyX 2.0.6 release is 
build with Carbon because of these problems. But, yes, I know Carbon is a dead 
end. It has to be corrected for Cocoa too. On my 10.8.3 system Qt-4.8.4 even 
refuses to compile the Carbon API. They have disabled it totally for x86_64 and 
for i386 one gets a compile error.

Another effect is the behavior regarding bug #8538 
(http://www.lyx.org/trac/ticket/8538). The build with Qt-4.8.4-Carbon is not 
affected by this bug. The \Omega is now rendered again.

Regards,
Stephan

Re: growing menu


Le 07/05/13 21:46, Stephan Witt a écrit :

Am 07.05.2013 um 15:47 schrieb Edwin Leuven :


everytime i close a document, i get a new "reconfigure" item in the
LyX menu on my mac

again: am i alone?


No. This and the crashes are caused by using the Cocoa framework and
the code moving the menu items from the Tools to the LyX menu. The
LyX 2.0.6 release is build with Carbon because of these problems.
But, yes, I know Carbon is a dead end. It has to be corrected for
Cocoa too. On my 10.8.3 system Qt-4.8.4 even refuses to compile the
Carbon API. They have disabled it totally for x86_64 and for i386 one
gets a compile error.


I'll try to see if I can handle the double menus thing. Did you try already?


Another effect is the behavior regarding bug #8538
(http://www.lyx.org/trac/ticket/8538). The build with Qt-4.8.4-Carbon
is not affected by this bug. The \Omega is now rendered again.


I remember that we shared some ideas abot fixing Qt for this \omega
problem. Did you find time to try it?

JMarc

[2.0.x] compatibility with automake 1.13


Richard, what about this for 2.0.x?

JMarc

Re: Unit testing: The Small Plan

> I would like to see some examples of mocking  and injection.
>
>
Thank you, Vincent,


> I tried to write some tests using the google framework, and started with
> the Buffer class. This immediately gives you the problem that it is
> dependent on a large number of other classes. So, this would mean that you
> have to fake a large part of the LyX codebase.
>

Well yes, actually I would start with the smallest class and do the Buffer
class as the last one. I guess it requires a lot of experiance to tame that.


> Then I tried to link against all libraries of LyX, but then I ran into
> problems that the application was not initialized (e.g., Package,
> translations etc.)
>
> I'm afraid we can't do much testing until the above is solved.
>

So a few tests already brought up a vision of what need to be solved.
That's exactly their most important strength. They are a perfect teacher.

Here we find out how everything currently depends on everything. We
couldn't even take a little piece out, to use it as a library for something
completly different.

Regards

\Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: [2.0.x] compatibility with automake 1.13


Le 07/05/13 22:04, Jean-Marc Lasgouttes a écrit :

Richard, what about this for 2.0.x?

JMarc


Now with the patches
>From c76a91a23261b0f919838461ce23cadfc5ebb519 Mon Sep 17 00:00:00 2001
From: Stephan Witt 
Date: Fri, 18 Jan 2013 21:17:18 +0100
Subject: [PATCH 1/2] add support for automake 1.13

---
 autogen.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index 8b48960..8239558 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -16,12 +16,12 @@ test "$automake_version" != "" && {
 }
 
 case $automake_version in
-*' '1.[8-9]*|*' '1.1[012]*)
+*' '1.[8-9]*|*' '1.1[0123]*)
;;
 *)
 
echo "This automake version is not supported by LyX."
-   echo "LyX only supports automake 1.8 to 1.12."
+   echo "LyX only supports automake 1.8 to 1.13."
exit 1
;;
 esac
-- 
1.8.1.2

>From 390fa0dd990c419f003850bfe494b99f4a44931e Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Mon, 21 Jan 2013 10:15:27 +0100
Subject: [PATCH 2/2] Fix compatibility with automake 1.13

Do not use AM_PROG_MKDIR_P, which is obsolete. We use  the AC_* version
now, which requires autoconf>=2.59d. This also mean that we need to use
the variable MKDIR_P instead of mkdir_p.
---
 INSTALL   | 4 ++--
 autogen.sh| 4 ++--
 intl/Makefile.in  | 2 +-
 m4/intl.m4| 3 ++-
 m4/po.m4  | 3 ++-
 po/Makefile.in.in | 2 +-
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/INSTALL b/INSTALL
index dd490db..42e0b98 100644
--- a/INSTALL
+++ b/INSTALL
@@ -35,8 +35,8 @@ Note for Git checkouts
 
 If you have checked this out from Git, you need to have:
 * automake >= 1.8
-* autoconf >= 2.59c
-* gettext >= 0.12
+* autoconf >= 2.59d
+* gettext >= 0.16.1
 Then type "./autogen.sh" to build the needed configuration
 files and proceed as stated above/below.
 
diff --git a/autogen.sh b/autogen.sh
index 8239558..2884481 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -38,11 +38,11 @@ test "$autoversion" != "" && {
 
 
 case $autoversion in
-*' '2.59[cd]|*' '2.60[ab]|*' '2.6[0-9])
+*' '2.59d|*' '2.60[ab]|*' '2.6[0-9])
;;
 *)
echo "This autoconf version is not supported by LyX."
-   echo "LyX only supports autoconf 2.59c-2.69."
+   echo "LyX only supports autoconf 2.59d-2.69."
exit 1
;;
 esac
diff --git a/intl/Makefile.in b/intl/Makefile.in
index 525922e..49e8e70 100644
--- a/intl/Makefile.in
+++ b/intl/Makefile.in
@@ -62,7 +62,7 @@ INSTALL_DATA = @INSTALL_DATA@
 mkinstalldirs = $(SHELL) @install_sh@ -d
 install_sh = $(SHELL) @install_sh@
 MKDIR_P = @MKDIR_P@
-mkdir_p = @mkdir_p@
+mkdir_p = @MKDIR_P@
 
 l = @INTL_LIBTOOL_SUFFIX_PREFIX@
 
diff --git a/m4/intl.m4 b/m4/intl.m4
index dcefb11..286efc9 100644
--- a/m4/intl.m4
+++ b/m4/intl.m4
@@ -25,7 +25,8 @@ dnlUSE_INCLUDED_LIBINTL, BUILD_INCLUDED_LIBINTL.
 AC_DEFUN([AM_INTL_SUBDIR],
 [
   AC_REQUIRE([AC_PROG_INSTALL])dnl
-  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake
+  AC_REQUIRE([AC_PROG_MKDIR_P])dnl defined by autoconf
+dnl  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake (obsolete)
   AC_REQUIRE([AC_PROG_CC])dnl
   AC_REQUIRE([AC_CANONICAL_HOST])dnl
   AC_REQUIRE([gt_GLIBC2])dnl
diff --git a/m4/po.m4 b/m4/po.m4
index 00133ef..815c873 100644
--- a/m4/po.m4
+++ b/m4/po.m4
@@ -24,7 +24,8 @@ AC_DEFUN([AM_PO_SUBDIRS],
 [
   AC_REQUIRE([AC_PROG_MAKE_SET])dnl
   AC_REQUIRE([AC_PROG_INSTALL])dnl
-  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake
+  AC_REQUIRE([AC_PROG_MKDIR_P])dnl defined by autoconf
+dnl  AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake (obsolete)
   AC_REQUIRE([AM_NLS])dnl
 
   dnl Perform the following tests also if --disable-nls has been given,
diff --git a/po/Makefile.in.in b/po/Makefile.in.in
index 33534f9..01bef6d 100644
--- a/po/Makefile.in.in
+++ b/po/Makefile.in.in
@@ -43,7 +43,7 @@ INSTALL_DATA = @INSTALL_DATA@
 mkinstalldirs = $(SHELL) @install_sh@ -d
 install_sh = $(SHELL) @install_sh@
 MKDIR_P = @MKDIR_P@
-mkdir_p = @mkdir_p@
+mkdir_p = @MKDIR_P@
 
 GMSGFMT_ = @GMSGFMT@
 GMSGFMT_no = @GMSGFMT@
-- 
1.8.1.2

Re: growing menu

Am 07.05.2013 um 21:50 schrieb Jean-Marc Lasgouttes :

> Le 07/05/13 21:46, Stephan Witt a écrit :
>> Am 07.05.2013 um 15:47 schrieb Edwin Leuven :
>> 
>>> everytime i close a document, i get a new "reconfigure" item in the
>>> LyX menu on my mac
>>> 
>>> again: am i alone?
>> 
>> No. This and the crashes are caused by using the Cocoa framework and
>> the code moving the menu items from the Tools to the LyX menu. The
>> LyX 2.0.6 release is build with Carbon because of these problems.
>> But, yes, I know Carbon is a dead end. It has to be corrected for
>> Cocoa too. On my 10.8.3 system Qt-4.8.4 even refuses to compile the
>> Carbon API. They have disabled it totally for x86_64 and for i386 one
>> gets a compile error.
> 
> I'll try to see if I can handle the double menus thing. Did you try already?

Not really. I think it's simply a bug. It should work.
The Reconfigure menu item has the MenuRole QAction::ApplicationSpecificRole.

> 
>> Another effect is the behavior regarding bug #8538
>> (http://www.lyx.org/trac/ticket/8538). The build with Qt-4.8.4-Carbon
>> is not affected by this bug. The \Omega is now rendered again.
> 
> I remember that we shared some ideas abot fixing Qt for this \omega
> problem. Did you find time to try it?

Yes, but it was neither funny nor successful. After learning how to debug the
Qt frameworks I thought I can fix it. But
1. I cannot find the location where the font property "symbolFont" ever gets
assigned a true value. It seems like it's done by comparing some names.
2. Even if I force symbolFont = true where you've spotted it's use it makes no
difference. Obviously, this not the right place or not the only place to fix it.

I'll try to address that again later.

Stephan

Re: Unit testing: The Small Plan

> Ideally, one would not need to care about private variables because we
are only interested in that the public interface does what it is supposed
to do. Right ?

Yes, at least as far as it concerns the testing.

Denpendency Injection has other aspects.

As an example, if there is a class that prints to stdout you mayby would
not test that, taking it as an "interal" behaviour.
With DI you inject the output stream, with the result that you can use
different printers in future.

Lyx already does this in many caes. Exactly that is dependancy injection.

Now you could drop in a MockStream to prove that the class uses the stream
object like expacted.

Regards

\Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

Does anybody know somethng about this bug? Is it true that tables in ltr 
mode should have ltr columns? What does this mean anyway?


JMarc


 Message original 
Sujet: [Bug 347378] Re: Two columns in Hebrew is in LTR
Date : Tue, 07 May 2013 19:08:00 -
De : Bug Watch Updater <347...@bugs.launchpad.net>
Répondre à : Bug 347378 <347...@bugs.launchpad.net>
Pour : lasgout...@lyx.org

** Changed in: lyx
   Status: New => Fix Released

--
You received this bug notification because you are subscribed to lyx in
Ubuntu.
https://bugs.launchpad.net/bugs/347378

Title:
  Two columns in Hebrew is in LTR

Status in LyX - The Document Processor:
  Fix Released
Status in “lyx” package in Ubuntu:
  New

Bug description:
  Dear interested parties,

  Hebrew is RTL and that means that multiple columns should be ordered
  RTL as well.

  Currently, this isn't the case. When I select two columns they are
  created in LTR order.

  Using lyx 1.6.1-1~intrepid1 from intrepid-backports.

  Many blessings.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lyx/+bug/347378/+subscriptions

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR


Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:
Does anybody know somethng about this bug? Is it true that tables in 
ltr mode should have ltr columns? What does this mean anyway?


JMarc


Yes, I 'fixed' it.

It isn't about tables, it is about a two column document.

It means that you read the right side of the page before the left side.

Vincent

Re: growing menu


Le 07/05/13 22:13, Stephan Witt a écrit :

I remember that we shared some ideas abot fixing Qt for this \omega
problem. Did you find time to try it?


Yes, but it was neither funny nor successful. After learning how to debug the
Qt frameworks I thought I can fix it. But
1. I cannot find the location where the font property "symbolFont" ever gets
assigned a true value. It seems like it's done by comparing some names.
2. Even if I force symbolFont = true where you've spotted it's use it makes no
difference. Obviously, this not the right place or not the only place to fix it.

I'll try to address that again later.


Is there abug report against qt? Shall we file one?

JMarc

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR


Le 07/05/13 22:41, Vincent van Ravesteijn a écrit :

Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:

Does anybody know somethng about this bug? Is it true that tables in
ltr mode should have ltr columns? What does this mean anyway?

JMarc


Yes, I 'fixed' it.

It isn't about tables, it is about a two column document.

It means that you read the right side of the page before the left side.


Do you have a pointer?

JMarc

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

Op 7 mei 2013 23:15 schreef "Jean-Marc Lasgouttes"  het
volgende:
>
> Le 07/05/13 22:41, Vincent van Ravesteijn a écrit :
>
>> Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:
>>>
>>> Does anybody know somethng about this bug? Is it true that tables in
>>> ltr mode should have ltr columns? What does this mean anyway?
>>>
>>> JMarc
>>
>>
>> Yes, I 'fixed' it.
>>
>> It isn't about tables, it is about a two column document.
>>
>> It means that you read the right side of the page before the left side.
>
>
> Do you have a pointer?
>
> JMarc
>

Bug 6389.

Vincent

Re: DIFFICULTY WITH PASTING IMAGE IN LYX

2013-05-07 Thread Scott Kostyshak

On Wed, May 1, 2013 at 1:26 PM, Vincent van Ravesteijn  wrote:
> Op 1-5-2013 18:03, Kamal Garg schreef:
>
> I know Only one way of pasting pictures in lyx, that is by selecting insert
> graphic option in toolbar.(shown in image)
>
> i  am trying to copy image(*.jpg).but direct simple way:ctrl+c(copying )
> from my folder of pictures  and ctrl+v (paste)for pasting image in lyx  is
> not working.
>
> Sir, if there is another way of doing the same,then let me know.
>
>
> This is indeed not working. It's a missing feature. It's probably not so
> difficult to implement.
>
> There is another way to do this. You can drag the image from the explorer
> onto the LyX window and paste it like this.

Kamal,

Can you file an enhancement request for this?
http://www.lyx.org/trac

Scott

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR


Le 07/05/13 23:26, Vincent van Ravesteijn a écrit :

 >> Yes, I 'fixed' it.
 >>
 >> It isn't about tables, it is about a two column document.
 >>
 >> It means that you read the right side of the page before the left side.
 >
 > Do you have a pointer?

Bug 6389.


Ouch. I'm glad I did not see it at the time :)

But it seems that there is no better solution unfortunately.

JMarc

Re: Unit testing: The Small Plan

2013-05-07 Thread Cyrille Artho

Hi Elmar,
I think your plan covers the question "HOW do we want to unit test the
software" well. However, we have not thought much about the "WHAT do we
want to test?" question. Essentially, we need to think about which
classes/functions to test first.

For user-driven actions (LFUNs), LyX already has a test framework. However,
these tests do not cover internals of LyX.

I hope some of the veteran developers can help answer these questions.

Elmar Hinz wrote:

Hello list,

I'd like to come up with a small plan for getting started with unit testing:

==
1.) Directory structure: "tests/unit/"
==

* Unit tests stay their own directory separated from src/.
* Below "tests/unit" the directory structure mirrors the structure of "src/".
* The reason for the subfolder "unit" is, that unit tests are not the
only type of tests. Unit tests test the single units of the source.

==
2.) Mocking: googlemock
==

This weekend I researched for alternatives, but there was none
that made a stable impression to me apart from googlemock.

With C++ mocking can take two approaches:

2.a) Turning classes into Templates, to be able to replace members by mocks.

http://programmaticallyspeaking.blogspot.de/2010/04/beautiful-dependency-injection-in-c.html

This seems to invasive into the existing sources for me.

2.b) Inheriting the mocks from the real objects, so that they are of the
same type.

This is the approach of googlemock.

Googlemock can be used with any mocking framework. It best integrates with
googletest.

==
3.) Testing framework: any
==

Unit tests are independent units, so any framework or none can be used.
For the reason of mocks, googletest is recommended.

==
4.) Runnig all tests
==

To be able to run all tests at once they need to be detected.

* The naming pattern of the binary to support this: whateverTest
* A successful test binary returns 0, the others an Error.
* The global test detector and runner is a Python script.

==
5.) Dependency injection
==

Dependency injection (the mock objects) is more difficult with C++
for multiple reasons like the missing garbage collection or reflection.

The approach that looks most forward and less intrusive for the sources
to me, is to directly access the private members by making them public
during testing and only during testing.

That is not really kosher, but at least a simple way to get started directly.

It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.

\Elmar

--
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

--
Regards,
Cyrille Artho - http://artho.com/
Love is the delusion that one woman differs from another.
-- H.L. Mencken

Re: growing menu