Re: 2.4.0 plan for #12215 [LyX crashes with async processes (Qt6 only)] ?

[André Pönitz]

Hi.

On Fri, Nov 11, 2022 at 03:16:05PM -0500, Scott Kostyshak wrote:
> The following issue seems pretty bad:
>
>   https://www.lyx.org/trac/ticket/12215

That's linked from

   https://bugreports.qt.io/browse/QTBUG-108604

now.

Best regards,
Andre'
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Fix nullptr warning

[André Pönitz]

On Tue, Mar 03, 2020 at 05:47:20AM +0100, Richard Kimberly Heck wrote:
> commit 84e91772eb255076384c96f662b56a0fbdf635a4
> Author: Richard Kimberly Heck 
> Date:   Tue Mar 3 00:08:46 2020 -0500
> 
> Fix nullptr warning
> ---
>  src/frontends/qt/GuiToc.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/frontends/qt/GuiToc.h b/src/frontends/qt/GuiToc.h
> index f29a9af..48f68b3 100644
> --- a/src/frontends/qt/GuiToc.h
> +++ b/src/frontends/qt/GuiToc.h
> @@ -32,7 +32,7 @@ public:
>   GuiToc(
>   GuiView & parent, ///< the main window where to dock.
>   Qt::DockWidgetArea area = Qt::LeftDockWidgetArea, ///< Position 
> of the dock (and also drawer)
> - Qt::WindowFlags flags = 0);
> + Qt::WindowFlags flags = nullptr);

The initialization of QFlags with nullptr will be removed in Qt 6. 

Both 

Qt::WindowFlags flags = nullptr);

and

Qt::WindowFlags flags = {});

would work.

Andre'
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Qt/QXmpp help

[André Pönitz]

On Mon, Oct 14, 2013 at 11:07:11PM +0100, Tommaso Cucinotta wrote:
 Hi,
 
 I'm trying this harmless line
 
   #include qxmpp/QXmppClient.h
 
 within a LyX source file that otherwise compiles fine (GuiChat.h from the 
 lyx-collaborative patch) and I end up with a compilation hell like this [1].
 The GuiChat.h file is also added to MOCHEADER in Makefile.am.
 Any nice advice on what's wrong ?
 
 Thx,
 
   T.
 
 $ make V=1
 [...]
 g++ -DHAVE_CONFIG_H -I. -I../../..  -DQT_NO_STL -DQT_NO_KEYWORDS 
 -DQT_NO_CAST_TO_ASCII -DQT_NO_STL -I../../../src -I../../../src/frontends 
 -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore 
 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork   -I../../../boost  
 -Wextra -Wall-g -O -MT GuiChat.o -MD -MP -MF .deps/GuiChat.Tpo -c -o 
 GuiChat.o GuiChat.cpp
 

LyX uses -DQT_NO_KEYWORDS to disable the 'slots' macro definition in
qglobal.h, yet qxmpp uses it in it's public interface.

Short of changing QXmppClient.h to use 'Q_SLOTS' instead of 'slots'
a possible workaround on the user side would be to use it like that:

#undef QT_NO_KEYWORDS 
#include qxmpp/QXmppClient.h
#define QT_NO_KEYWORDS


Andre'

Re: Qt/QXmpp help

[André Pönitz]

On Mon, Oct 14, 2013 at 11:50:18PM +0100, Tommaso Cucinotta wrote:
 On 14/10/13 23:34, Tommaso Cucinotta wrote:
  a possible workaround on the user side would be to use it like that:
 
  #undef QT_NO_KEYWORDS 
  #include qxmpp/QXmppClient.h
  #define QT_NO_KEYWORDS
  
  unfortunately it doesn't seem to change much... next hint :D ?

It actually should, assuming that's the only #include pulling such
headers in.

 Ok, for now I found this way, later we can see whether there's anything
 better:
 
 #ifndef QGUICHAT_H
 #define QGUICHAT_H
 
 #undef QT_NO_KEYWORDS 
 
 Right at the beginning of my .h file. I guess this way I let Qt headers
 properly introduce the slot macro, and it all happily compiles :-) ?
 
 So, what's the point of compiling with QT_NO_KEYWORDS ? Just a matter of
 LyX code style ? But in this case it prevents use of a library :( ?

The general point is to prevent having no macros with the unusual
non-ALL_CAPS style, and for LyX in particular to prevent a clash with
boost/signals naming.

Andre'

Re: Qt/QXmpp help

[André Pönitz]

On Mon, Oct 14, 2013 at 11:07:11PM +0100, Tommaso Cucinotta wrote:
> Hi,
> 
> I'm trying this harmless line
> 
>   #include 
> 
> within a LyX source file that otherwise compiles fine (GuiChat.h from the 
> lyx-collaborative patch) and I end up with a compilation hell like this [1].
> The GuiChat.h file is also added to MOCHEADER in Makefile.am.
> Any nice advice on what's wrong ?
> 
> Thx,
> 
>   T.
> 
> $ make V=1
> [...]
> g++ -DHAVE_CONFIG_H -I. -I../../..  -DQT_NO_STL -DQT_NO_KEYWORDS 
> -DQT_NO_CAST_TO_ASCII -DQT_NO_STL -I../../../src -I../../../src/frontends 
> -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore 
> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork   -I../../../boost  
> -Wextra -Wall-g -O -MT GuiChat.o -MD -MP -MF .deps/GuiChat.Tpo -c -o 
> GuiChat.o GuiChat.cpp
> 

LyX uses -DQT_NO_KEYWORDS to disable the 'slots' macro definition in
qglobal.h, yet qxmpp uses it in it's public interface.

Short of changing QXmppClient.h to use 'Q_SLOTS' instead of 'slots'
a possible workaround on the "user" side would be to use it like that:

#undef QT_NO_KEYWORDS 
#include 
#define QT_NO_KEYWORDS


Andre'

Re: Qt/QXmpp help

[André Pönitz]

On Mon, Oct 14, 2013 at 11:50:18PM +0100, Tommaso Cucinotta wrote:
> On 14/10/13 23:34, Tommaso Cucinotta wrote:
> >> a possible workaround on the "user" side would be to use it like that:
> >>
> >> #undef QT_NO_KEYWORDS 
> >> #include 
> >> #define QT_NO_KEYWORDS
> > 
> > unfortunately it doesn't seem to change much... next hint :D ?

It actually should, assuming that's the only #include pulling such
headers in.

> Ok, for now I found this way, later we can see whether there's anything
> better:
> 
> #ifndef QGUICHAT_H
> #define QGUICHAT_H
> 
> #undef QT_NO_KEYWORDS 
> 
> Right at the beginning of my .h file. I guess this way I let Qt headers
> properly introduce the "slot" macro, and it all happily compiles :-) ?
> 
> So, what's the point of compiling with QT_NO_KEYWORDS ? Just a matter of
> LyX code style ? But in this case it prevents use of a library :( ?

The general point is to prevent having no macros with the "unusual"
non-ALL_CAPS style, and for LyX in particular to prevent a clash with
boost/signals naming.

Andre'

Re: Setting all po files in utf8?

[André Pönitz]

On Sat, May 11, 2013 at 12:15:32PM +0200, Jean-Marc Lasgouttes wrote:
 Le 11/05/2013 11:18, Pavel Sanda a écrit :
 We need to know when beer^H^H^H^Hwine supply arrived in order to
 correctly interpret messages posted. Last meeting report was pretty
 punctual about this point AFAIR.
 
 We bought 10 liters of beer yesterday, but did not drink a lot of it yet.

O tempora! O mores!

Andre'

Re: Setting all po files in utf8?

[André Pönitz]

On Sat, May 11, 2013 at 12:15:32PM +0200, Jean-Marc Lasgouttes wrote:
> Le 11/05/2013 11:18, Pavel Sanda a écrit :
> >We need to know when beer^H^H^H^Hwine supply arrived in order to
> >correctly interpret messages posted. Last meeting report was pretty
> >punctual about this point AFAIR.
> 
> We bought 10 liters of beer yesterday, but did not drink a lot of it yet.

O tempora! O mores!

Andre'

Re: Compilers used for compiling LyX?

[André Pönitz]

On Mon, Oct 29, 2012 at 11:28:58AM +0100, Lars Gullik Bjønnes wrote:
 Jean-Marc Lasgouttes lasgout...@lyx.org writes:
 
 | Le 29/10/2012 06:36, Liviu Andronic a écrit :
  On Sun, Oct 28, 2012 at 11:58 AM, Jean-Marc Lasgouttes
  lasgout...@lyx.org wrote:
  I have 4.4 on my ubuntu 10.04 install.
 
  Are you sure? Ubuntu Lucid ships Qt 4.6.2 [1].
  [1]
  http://packages.ubuntu.com/search?keywords=libqt4searchon=namessuite=allsection=all
 
 | I meant gcc 4.4. Qt is 4.6 of course.
 
 When does support of 10.04 stop?

https://wiki.ubuntu.com/Releases mentions

 Normal Ubuntu releases are supported for 18 months. Previous Ubuntu
  LTS (Long Term Support) releases are supported for 3 years on the
  desktop and 5 years on the server. Starting with Ubuntu 12.04 LTS,
  LTS releases will be supported for 5 years on both the desktop and
  the server.

That would make official support for 10.04 LTS ending in April 2013.

 IMHO, when a distro goes into not-supported-mode we should not have to
 care about it anymore. Of course the LTS distros pose a problem in
 that respect.

Right, and right. 

I am not sure supporting 5 year cycles is worthwhile.

Andre'

Re: Compilers used for compiling LyX?

[André Pönitz]

On Mon, Oct 29, 2012 at 11:28:58AM +0100, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes  writes:
> 
> | Le 29/10/2012 06:36, Liviu Andronic a écrit :
> >> On Sun, Oct 28, 2012 at 11:58 AM, Jean-Marc Lasgouttes
> >>  wrote:
> >>> I have 4.4 on my ubuntu 10.04 install.
> >>>
> >> Are you sure? Ubuntu Lucid ships Qt 4.6.2 [1].
> >> [1]
> >> http://packages.ubuntu.com/search?keywords=libqt4=names=all=all
> >
> | I meant gcc 4.4. Qt is 4.6 of course.
> 
> When does support of 10.04 stop?

https://wiki.ubuntu.com/Releases mentions

 "Normal Ubuntu releases are supported for 18 months. Previous Ubuntu
  LTS (Long Term Support) releases are supported for 3 years on the
  desktop and 5 years on the server. Starting with Ubuntu 12.04 LTS,
  LTS releases will be supported for 5 years on both the desktop and
  the server."

That would make official support for 10.04 LTS ending in April 2013.

> IMHO, when a distro goes into not-supported-mode we should not have to
> care about it anymore. Of course the LTS distros pose a problem in
> that respect.

Right, and right. 

I am not sure supporting 5 year cycles is worthwhile.

Andre'

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[André Pönitz]

On Sun, Oct 28, 2012 at 01:46:05PM +0100, Stephan Witt wrote:
  Can you point me to the rules for coding style please?
  
  I only know of the old files in development/coding.
 
 The best match I found is:
 
  - Adapt the formatting of your code to the one used in the
other parts of LyX. In case there is different formatting for
the same construct, use the one used more often.
 
 So this implies one should care for *own* code, IMHO.

The vague formulation of In case there is different formatting
for the same construct, use the one used more often. was a result
of LyX not having a lot of written, but quite a few unwritten
rules, and the majority vote pretty much gives the same result
as having all rules explicit.

It was meant as a general permission, or even encouragement, to
strive for a uniform code base, especially, but not restricted to
cases where there are witten rules that are followed, and if the
reformatting (as was e.g. done by Lars here) is separated from
functional changes.

It is really easier to apply mechanical refactoring on top of
a uniform code base and to spot deviation from existing known
-to-work-well patterns easier this way.

Andre'

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[André Pönitz]

On Sun, Oct 28, 2012 at 01:46:05PM +0100, Stephan Witt wrote:
> >> Can you point me to the rules for coding style please?
> > 
> > I only know of the old files in development/coding.
> 
> The best match I found is:
> 
>  - Adapt the formatting of your code to the one used in the
>other parts of LyX. In case there is different formatting for
>the same construct, use the one used more often.
> 
> So this implies one should care for *own* code, IMHO.

The vague formulation of "In case there is different formatting
for the same construct, use the one used more often." was a result
of LyX not having a lot of written, but quite a few unwritten
rules, and the "majority vote" pretty much gives the same result
as having all rules explicit.

It was meant as a general permission, or even encouragement, to
strive for a uniform code base, especially, but not restricted to
cases where there are witten rules that are followed, and if the
reformatting (as was e.g. done by Lars here) is separated from
functional changes.

It is really easier to apply mechanical refactoring on top of
a uniform code base and to spot deviation from existing known
-to-work-well patterns easier this way.

Andre'

Re: boost

[André Pönitz]

I thought I could simply shut up. Alas, it looks like I can't.

On Sat, Oct 27, 2012 at 01:12:21AM +0200, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:
 
 | | BTW after some decade we still include boost in our tarballs and maintain
 | | its updates. What was the original reason and is it still needed?
 
 | My preferences are as follows:
 
 | 0. Standard C++
 | 1. Something with the same apis/behaviour as standard C++
 | 2. Use something that is destined for standardization.
 | 3. third party libraries.
 
 These are guidlines of course. More special requirements require more
 special measures.

My preferences are

   - Make it work.
   - Make it painless.

Even with the relativization it is clear that you rank the use of
certain technologies higher than the actual outcome of using them. 

From a user point's of view it does absolutely not matter what line of
code led to a certain behaviour, as long as it meets the expectation
regarding functionality, robustness, performance, etc.

Of course, given two unknown approaches, taking the one with the
Standard label is expected to the better one, because, well, it's
standard, and one would expect it to work best and most painless,
as a lot of people spend time on working it out.

Unfortunately, that's not the the story we've seen with LyX. Working
solutions have been replaced by presumably standard technologies
long before these have been ready for prime time, i.e. had sufficient
compiler support across the range and were painless to use.

The boostification led to a situation where the codebase was barely
compilable on not-so-bleeding edge machines anymore, essentially
locking out part of the audience, and causing extra load on other
when trying to find workarounds for the worst damages.

The NVI experiment. Applying library implementation idioms to
application programming. Good for pain, but no gain.

The LyX as CAS frontend idea. Dead as the result of not having usable
facilities to interface external processes using the the blessed core
technologies only.

Etc etc.

Keep your list of preferences, in the order you have, but, _please_,
qualify the items with a if it helps the users.

Andre'

Re: Compilers used for compiling LyX?

[André Pönitz]

On Sat, Oct 27, 2012 at 01:35:26AM +0200, Lars Gullik Bjønnes wrote:
 
 Do any of you have feeling what compilers are use to compile LyX
 now-a-days, that at what version they are?
 
 Would be fun to see how far off we are from being able to use C++11.

Might be worth a look:

http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

Andre'

Re: Compilers used for compiling LyX?

[André Pönitz]

On Sat, Oct 27, 2012 at 02:00:42AM +0200, Pavel Sanda wrote:
 Lars Gullik Bj?nnes wrote:
  Do any of you have feeling what compilers are use to compile LyX
  now-a-days, that at what version they are?
 
 The oldest gcc I'm still encountering on actively used boxes around
 is 4.2.1, but from my experiments with compiling/using LyX, the real 
 stopper is Qt version, because while we (should) still compile with
 Qt 4.2.x

This is, by the way, an absurd restriction. There's Qt 4.8.3 by now.
Even shipped by stock Ubuntu. Qt 4.2.0 is from 2006. 4.2.3 from May 2007.

I am sure we would not insist on using boost from 2007. Or gcc 4.1.2
(also 2007).

Andre'

Re: boost

[André Pönitz]

On Sat, Oct 27, 2012 at 11:23:48AM +0200, Lars Gullik Bjønnes wrote:
 André Pönitz andre.poen...@mathematik.tu-chemnitz.de writes:
 
 | I thought I could simply shut up. Alas, it looks like I can't.
 
 | On Sat, Oct 27, 2012 at 01:12:21AM +0200, Lars Gullik Bjønnes wrote:
  lar...@gullik.org (Lars Gullik Bjønnes) writes:
  
  | | BTW after some decade we still include boost in our tarballs and 
  maintain
  | | its updates. What was the original reason and is it still needed?
  
  | My preferences are as follows:
  
  | 0. Standard C++
  | 1. Something with the same apis/behaviour as standard C++
  | 2. Use something that is destined for standardization.
  | 3. third party libraries.
  
  These are guidlines of course. More special requirements require more
  special measures.
 
 | My preferences are
 
 tl;dr

Summary: 

   - Make it work.
   - Make it painless.

It's a shorter list than yours.

Andre'

Re: boost

[André Pönitz]

I thought I could simply shut up. Alas, it looks like I can't.

On Sat, Oct 27, 2012 at 01:12:21AM +0200, Lars Gullik Bjønnes wrote:
> lar...@gullik.org (Lars Gullik Bjønnes) writes:
> 
> | | BTW after some decade we still include boost in our tarballs and maintain
> | | its updates. What was the original reason and is it still needed?
> >
> | My preferences are as follows:
> >
> | 0. Standard C++
> | 1. Something with the same apis/behaviour as standard C++
> | 2. Use something that is destined for standardization.
> | 3. third party libraries.
> 
> These are guidlines of course. More special requirements require more
> special measures.

My preferences are

   - Make it work.
   - Make it painless.

Even with the relativization it is clear that you rank the use of
certain technologies higher than the actual outcome of using them. 

>From a user point's of view it does absolutely not matter what line of
code led to a certain behaviour, as long as it meets the expectation
regarding functionality, robustness, performance, etc.

Of course, given two unknown approaches, taking the one with the
"Standard" label is expected to the better one, because, well, it's
standard, and one would expect it to work best and most painless,
as a lot of people spend time on working it out.

Unfortunately, that's not the the story we've seen with LyX. Working
solutions have been replaced by presumably "standard" technologies
long before these have been ready for prime time, i.e. had sufficient
compiler support across the range and were painless to use.

The boostification led to a situation where the codebase was barely
compilable on not-so-bleeding edge machines anymore, essentially
locking out part of the audience, and causing extra load on other
when trying to find workarounds for the worst damages.

The NVI experiment. Applying library implementation idioms to
application programming. Good for pain, but no gain.

The "LyX as CAS frontend" idea. Dead as the result of not having usable
facilities to interface external processes using the the blessed core
technologies only.

Etc etc.

Keep your list of preferences, in the order you have, but, _please_,
qualify the items with a "if it helps the users."

Andre'

Re: Compilers used for compiling LyX?

[André Pönitz]

On Sat, Oct 27, 2012 at 01:35:26AM +0200, Lars Gullik Bjønnes wrote:
> 
> Do any of you have feeling what compilers are use to compile LyX
> now-a-days, that at what version they are?
> 
> Would be fun to see how far off we are from being able to use C++11.

Might be worth a look:

http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

Andre'

Re: Compilers used for compiling LyX?

[André Pönitz]

On Sat, Oct 27, 2012 at 02:00:42AM +0200, Pavel Sanda wrote:
> Lars Gullik Bj?nnes wrote:
> > Do any of you have feeling what compilers are use to compile LyX
> > now-a-days, that at what version they are?
> 
> The oldest gcc I'm still encountering on actively used boxes around
> is 4.2.1, but from my experiments with compiling/using LyX, the real 
> stopper is Qt version, because while we (should) still compile with
> Qt 4.2.x

This is, by the way, an absurd restriction. There's Qt 4.8.3 by now.
Even shipped by stock Ubuntu. Qt 4.2.0 is from 2006. 4.2.3 from May 2007.

I am sure we would not insist on using boost from 2007. Or gcc 4.1.2
(also 2007).

Andre'

Re: boost

[André Pönitz]

On Sat, Oct 27, 2012 at 11:23:48AM +0200, Lars Gullik Bjønnes wrote:
> André Pönitz <andre.poen...@mathematik.tu-chemnitz.de> writes:
> 
> | I thought I could simply shut up. Alas, it looks like I can't.
> >
> | On Sat, Oct 27, 2012 at 01:12:21AM +0200, Lars Gullik Bjønnes wrote:
> >> lar...@gullik.org (Lars Gullik Bjønnes) writes:
> >> 
> >> | | BTW after some decade we still include boost in our tarballs and 
> >> maintain
> >> | | its updates. What was the original reason and is it still needed?
> >> >
> >> | My preferences are as follows:
> >> >
> >> | 0. Standard C++
> >> | 1. Something with the same apis/behaviour as standard C++
> >> | 2. Use something that is destined for standardization.
> >> | 3. third party libraries.
> >> 
> >> These are guidlines of course. More special requirements require more
> >> special measures.
> >
> | My preferences are
> 
> tl;dr

Summary: 

   - Make it work.
   - Make it painless.

It's a shorter list than yours.

Andre'

Re: [PATCH 5/5] src/lyxfind.cpp: use local typedef to simplify

[André Pönitz]

On Wed, Oct 24, 2012 at 01:27:40AM +0200, Lars Gullik Bjønnes wrote:
 André Pönitz andre.poen...@mathematik.tu-chemnitz.de writes:
 
 | On Tue, Oct 23, 2012 at 11:14:42PM +0200, lar...@gullik.org wrote:
  From: Lars Gullik Bjønnes lar...@gullik.org
  
  Use a local typedef pairstring, string P to avoid having to repeat
  that multiple times.
  ---
   src/lyxfind.cpp | 72
  -
   1 file changed, 40 insertions(+), 32 deletions(-)
  
  diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
  index a19724b..33dbd8a 100644
  --- a/src/lyxfind.cpp
  +++ b/src/lyxfind.cpp
  @@ -495,54 +495,62 @@ typedef vectorpairstring, string  Escapes;
   /// @note Beware of order
   Escapes const  get_regexp_escapes()
   {
  +  typedef std::pairstd::string, std::string P;
  +
 
 | Conveniently adding a std:: or three, so next time the discussion
 | comes up we can reasonably claim that it is used inconsistently
 | and the 'using' on top could go...
 
 What is your agenda really?

Preventing attempts to turn the LyX code base into a guinea pig for
programming experiments again. Especially the kind of experiment that
add a burden for others.

Andre'

Re: [PATCH 5/5] src/lyxfind.cpp: use local typedef to simplify

[André Pönitz]

On Wed, Oct 24, 2012 at 01:27:40AM +0200, Lars Gullik Bjønnes wrote:
> André Pönitz <andre.poen...@mathematik.tu-chemnitz.de> writes:
> 
> | On Tue, Oct 23, 2012 at 11:14:42PM +0200, lar...@gullik.org wrote:
> >> From: Lars Gullik Bjønnes <lar...@gullik.org>
> >> 
> >> Use a local typedef pair<string, string> P to avoid having to repeat
> >> that multiple times.
> >> ---
> >>  src/lyxfind.cpp | 72
> >> -
> >>  1 file changed, 40 insertions(+), 32 deletions(-)
> >> 
> >> diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
> >> index a19724b..33dbd8a 100644
> >> --- a/src/lyxfind.cpp
> >> +++ b/src/lyxfind.cpp
> >> @@ -495,54 +495,62 @@ typedef vector<pair<string, string> > Escapes;
> >>  /// @note Beware of order
> >>  Escapes const & get_regexp_escapes()
> >>  {
> >> +  typedef std::pair<std::string, std::string> P;
> >> +
> >
> | Conveniently adding a std:: or three, so next time the discussion
> | comes up we can reasonably claim that it is used "inconsistently"
> | and the 'using' on top could go...
> 
> What is your agenda really?

Preventing attempts to turn the LyX code base into a guinea pig for
programming experiments again. Especially the kind of experiment that
add a burden for others.

Andre'

Re: [PATCH 11/13] Use make_shared to create shared_ptr

[André Pönitz]

On Tue, Oct 23, 2012 at 02:27:14PM +0200, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:
 
 | Jean-Marc Lasgouttes lasgout...@lyx.org writes:
 
 | | Le 23/10/12 01:21, Lars Gullik Bjønnes a écrit :
  Anyhow... I am going to ditch the hole series. Pick what you want from
  it if anything.
 
  I just cannot stand the hostility.
 
 | | Come on. André is bored and he feel happy to be rude like in the good
 | | old days. Nothing really personnal :)
 
 | I am pretty sure he means is personal, and I just cannot be bothered
 | with it.
 
 | | Apart from the std:: namespace issue that seems a bit disruptive and
 | | controversial, the other patches make sense to me. Moving away from
 | | tr1 in particular.
 
 | What I think you should do is to remove the using namespace std, and
 | add std:: wherever needed except for on string, as that really is all
 | over, and use using std::string for that.
 
 A patch that does exactly that is attached.
 
 C++11 would make the code look a lot nicer, esp. thru the use of range
 based for, and auto:
 
 std::vectorstring::iterator at = somevec.begin();
 std::vectorstring::iterator end = someved.end();
 for (; at != end; ++at) {
 ...
 }
 
 would be replaced with:
 
 for (auto  s: somevec) {
 ...
 }

Range-based for is certainly one of the (scores of) obviously cool
and useful features in C++11 (which is in general way more pragmatic
than 98/03) and I am all for using it - once it has been established
that it's supported by all the setups the project cares for. There
is even some chance it is.

Obligatory rude snide remark #1: It is nice to see the iterator-over-all
faction to be back at values, or references.

I also don't mind modest use of auto, preferably in cases where it is
a chore to write out the full type, such as having to namespace-qualify
it. Using auto instead of int or such is a bit of a stretch, though.

Obligatory rude snide remark #2: Luckily, having boost::auto has been
outlawed by The Committee.

Note, however, that the proposal to use range-based for is orthogonal to
the one of full namespace qualification, and I'd even argue it goes into
he opposite direction in spirit.

Obligatory rude snide remark #3: Omitted, for personal reasons.

Andre'

Re: [PATCH 5/5] src/lyxfind.cpp: use local typedef to simplify

[André Pönitz]

On Tue, Oct 23, 2012 at 11:14:42PM +0200, lar...@gullik.org wrote:
 From: Lars Gullik Bjønnes lar...@gullik.org
 
 Use a local typedef pairstring, string P to avoid having to repeat
 that multiple times.
 ---
  src/lyxfind.cpp | 72 
 -
  1 file changed, 40 insertions(+), 32 deletions(-)
 
 diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
 index a19724b..33dbd8a 100644
 --- a/src/lyxfind.cpp
 +++ b/src/lyxfind.cpp
 @@ -495,54 +495,62 @@ typedef vectorpairstring, string  Escapes;
  /// @note Beware of order
  Escapes const  get_regexp_escapes()
  {
 + typedef std::pairstd::string, std::string P;
 +

Conveniently adding a std:: or three, so next time the discussion
comes up we can reasonably claim that it is used inconsistently
and the 'using' on top could go...

Andre'

Re: [PATCH 11/13] Use make_shared to create shared_ptr

[André Pönitz]

On Tue, Oct 23, 2012 at 02:27:14PM +0200, Lars Gullik Bjønnes wrote:
> lar...@gullik.org (Lars Gullik Bjønnes) writes:
> 
> | Jean-Marc Lasgouttes  writes:
> >
> | | Le 23/10/12 01:21, Lars Gullik Bjønnes a écrit :
> >>> Anyhow... I am going to ditch the hole series. Pick what you want from
> >>> it if anything.
> >>>
> >>> I just cannot stand the hostility.
> >>
> | | Come on. André is bored and he feel happy to be rude like in the good
> | | old days. Nothing really personnal :)
> >
> | I am pretty sure he means is personal, and I just cannot be bothered
> | with it.
> >
> | | Apart from the std:: namespace issue that seems a bit disruptive and
> | | controversial, the other patches make sense to me. Moving away from
> | | tr1 in particular.
> >
> | What I think you should do is to remove the "using namespace std", and
> | add std:: wherever needed except for on string, as that really is all
> | over, and use "using std::string" for that.
> 
> A patch that does exactly that is attached.
> 
> C++11 would make the code look a lot nicer, esp. thru the use of range
> based for, and auto:
> 
> std::vector::iterator at = somevec.begin();
> std::vector::iterator end = someved.end();
> for (; at != end; ++at) {
> ...
> }
> 
> would be replaced with:
> 
> for (auto & s: somevec) {
> ...
> }

Range-based for is certainly one of the (scores of) "obviously cool
and useful" features in C++11 (which is in general way more pragmatic
than 98/03) and I am all for using it - once it has been established
that it's supported by all the setups the project cares for. There
is even some chance it is.

Obligatory rude snide remark #1: It is nice to see the iterator-over-all
faction to be back at values, or references.

I also don't mind modest use of "auto", preferably in cases where it is
a chore to write out the full type, such as having to namespace-qualify
it. Using "auto" instead of "int" or such is a bit of a stretch, though.

Obligatory rude snide remark #2: Luckily, having boost::auto has been
outlawed by The Committee.

Note, however, that the proposal to use range-based for is orthogonal to
the one of full namespace qualification, and I'd even argue it goes into
he opposite direction "in spirit".

Obligatory rude snide remark #3: Omitted, for personal reasons.

Andre'

Re: [PATCH 5/5] src/lyxfind.cpp: use local typedef to simplify

[André Pönitz]

On Tue, Oct 23, 2012 at 11:14:42PM +0200, lar...@gullik.org wrote:
> From: Lars Gullik Bjønnes 
> 
> Use a local typedef pair P to avoid having to repeat
> that multiple times.
> ---
>  src/lyxfind.cpp | 72 
> -
>  1 file changed, 40 insertions(+), 32 deletions(-)
> 
> diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
> index a19724b..33dbd8a 100644
> --- a/src/lyxfind.cpp
> +++ b/src/lyxfind.cpp
> @@ -495,54 +495,62 @@ typedef vector > Escapes;
>  /// @note Beware of order
>  Escapes const & get_regexp_escapes()
>  {
> + typedef std::pair P;
> +

Conveniently adding a std:: or three, so next time the discussion
comes up we can reasonably claim that it is used "inconsistently"
and the 'using' on top could go...

Andre'

Re: Ad. using namespace std - ref prob in c9b9748c

[André Pönitz]

On Mon, Oct 22, 2012 at 12:41:08AM +0200, Lars Gullik Bjønnes wrote:
 
 It is mentioned in c9b9748c that using namespace std on msvc10 also
 drags in std::tr1 stuff.
 
 IMHO the soltion is not to use boost::shared_ptr etc. But to stop
 using using namespace std. I look briefly as to what was discussed in
 2007 when the using namespace std was introduced all over, and afaikr
 this was done to get rid of the using std::stuff lines? Agree with
 the move to get rid of all the using lines, but not with the solution.
 
 IMHO a much better solution is to just use std:: prefix where
 required.

Precisely. Where required. Fortunately, it's not very often _required_.

Namespaces exist for a reason, and the reason is not to spell them
fully out all the time. If that had been the intention, all the
namespace wording could have just been left out of the Standard,
greatly simplifying it.  Instead of 'std::vector' we would simply be
using 'std_vector'.  Or use colons as part of identifiers. 
It isn't like that - luckily.

namespaces exist for a reason, and the reason is to keep things
apart when needed, not when possible.
 
 I am willing to do the work to remove using namespace std and put
 std:: where required. This will also make declaration signatures
 cosistent with signatures on definitions, and without haveing a
 mixture of std:: and non-std:: in source files.

I hope this crusade stops before it begins. This kind of work
adds no value to the source, just introduces an additional chore
for people when writing and reading code.

LyX source is currently in a pretty good shape. Keep it like that.
There's no need for yet another Lost Decade of Overengineering.

ANdre'

Re: Ad. "using namespace std" - ref prob in c9b9748c

[André Pönitz]

On Mon, Oct 22, 2012 at 12:41:08AM +0200, Lars Gullik Bjønnes wrote:
> 
> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
> drags in std::tr1 stuff.
> 
> IMHO the soltion is not to use boost::shared_ptr etc. But to stop
> using "using namespace std". I look briefly as to what was discussed in
> 2007 when the "using namespace std" was introduced all over, and afaikr
> this was done to get rid of the "using std::" lines? Agree with
> the move to get rid of all the "using" lines, but not with the solution.
> 
> IMHO a much better solution is to just use "std::" prefix where
> required.

Precisely. Where required. Fortunately, it's not very often _required_.

Namespaces exist for a reason, and the reason is not to spell them
fully out all the time. If that had been the intention, all the
namespace wording could have just been left out of the Standard,
greatly simplifying it.  Instead of 'std::vector' we would simply be
using 'std_vector'.  Or use colons as part of identifiers. 
It isn't like that - luckily.

namespaces exist for a reason, and the reason is to keep things
apart when needed, not when possible.
 
> I am willing to do the work to remove "using namespace std" and put
> std:: where required. This will also make declaration signatures
> cosistent with signatures on definitions, and without haveing a
> mixture of std:: and non-std:: in source files.

I hope this crusade stops before it begins. This kind of "work"
adds no value to the source, just introduces an additional chore
for people when writing and reading code.

LyX source is currently in a pretty good shape. Keep it like that.
There's no need for yet another Lost Decade of Overengineering.

ANdre'

Re: [PATCH 03/13] src/Lyx: use boost::scoped_ptr to hold the pimpl

[André Pönitz]

On Sun, Oct 21, 2012 at 08:49:06PM +0200, Lars Gullik Bjønnes wrote:
 diff --git a/src/LyX.h b/src/LyX.h
 index 70b8b7e..97c9b4a 100644
 --- a/src/LyX.h
 +++ b/src/LyX.h
 @@ -16,6 +16,7 @@
  
  #include support/strfwd.h
  
 +#include boost/scoped_ptr.hpp
  #include vector
  
  namespace lyx {
 @@ -126,7 +127,7 @@ private:
   /// Use the Pimpl idiom to hide the internals.
   // Mostly used for singletons.
   struct Impl;
 - Impl * pimpl_;
 + boost::scoped_ptrstruct Impl pimpl_;
  

The Empire strikes back.

Bald-pointer-phobia accompanied by swift C style
use of struct. What a deadly combination!

Andre'



PS: 1/2 ;-) for those who are missing one...

Re: [PATCH 03/13] src/Lyx: use boost::scoped_ptr to hold the pimpl

[André Pönitz]

On Sun, Oct 21, 2012 at 08:49:06PM +0200, Lars Gullik Bjønnes wrote:
> diff --git a/src/LyX.h b/src/LyX.h
> index 70b8b7e..97c9b4a 100644
> --- a/src/LyX.h
> +++ b/src/LyX.h
> @@ -16,6 +16,7 @@
>  
>  #include "support/strfwd.h"
>  
> +#include 
>  #include 
>  
>  namespace lyx {
> @@ -126,7 +127,7 @@ private:
>   /// Use the Pimpl idiom to hide the internals.
>   // Mostly used for singletons.
>   struct Impl;
> - Impl * pimpl_;
> + boost::scoped_ptr pimpl_;
>  

The Empire strikes back.

Bald-pointer-phobia accompanied by swift C style
use of "struct". What a deadly combination!

Andre'



PS: 1/2 ;-) for those who are missing one...

Re: lyx.pro [was: Re: Re: [LyX master] Proper naming for tab-group-close.]

[André Pönitz]

On Mon, Oct 01, 2012 at 09:44:55AM -0400, Richard Heck wrote:
 On 10/01/2012 06:42 AM, Pavel Sanda wrote:
 Kornel Benko wrote:
 What's the point of maintaining such beast if it can be (re)created? P
 Kill it.
 In a similar fashion I see there lyx.pro file.
 This is actively used by anyone (qt-creator people)?
 I use Qt Creator, but have never used this pro file. I didn't even
 know it was there!
 
 I think the qmake stuff may be a leftover from when Andre was trying
 to create a fourth build system.

Well, the reasoning was a bit different, but sure, the file can go now.

Andre'

Re: lyx.pro [was: Re: Re: [LyX master] Proper naming for tab-group-close.]

[André Pönitz]

On Mon, Oct 01, 2012 at 09:44:55AM -0400, Richard Heck wrote:
> On 10/01/2012 06:42 AM, Pavel Sanda wrote:
> >Kornel Benko wrote:
> >>>What's the point of maintaining such beast if it can be (re)created? P
> >>Kill it.
> >In a similar fashion I see there lyx.pro file.
> >This is actively used by anyone (qt-creator people)?
> I use Qt Creator, but have never used this pro file. I didn't even
> know it was there!
> 
> I think the qmake stuff may be a leftover from when Andre was trying
> to create a fourth build system.

Well, the reasoning was a bit different, but sure, the file can go now.

Andre'

Re: [PATCH (?)] add -Werror to autotools and cmake ?

[André Pönitz]

On Sat, Sep 29, 2012 at 04:53:00AM -0400, Scott Kostyshak wrote:
 I have been thinking about compiler warnings because of the recent
 discussion here:
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg175099.html
 
 From that thread, I have the understanding that some developers think
 it's important to fix warnings, although not if it is risky. I don't
 have much experience programming so I wouldn't be surprised if there's
 something wrong with the following logic:
 
 It seems to me that warnings should either be fixed when they occur or
 just ignored. That is, if a warning is viewed to be a problem, it
 should be fixed right when it's introduced. Or, if it is not viewed as
 a problem, it should just be permanently ignored. I don't see any
 advantage to having warnings sit around.
 
 Thus, I wonder if it would be useful to specify -Werror in the
 development build, which would turn all warnings into errors and would
 alert the author to fix them right away.

And as soon as the next version of a compiler decides to spit out
more warnings (and we know that not all warnings are warranted)
the code base suddenly does not compile anymore, for no good reason,
and people will have to spend time to reconfigure or patch around
the problem, when all they want is just to get a fresh build.

There's nothing wrong with keeping a -Werror enabling patch locally,
git makes this extremely easy. But it's nothing that should be on
by default.

Andre'

Re: [PATCH (?)] add -Werror to autotools and cmake ?

[André Pönitz]

On Sat, Sep 29, 2012 at 04:53:00AM -0400, Scott Kostyshak wrote:
> I have been thinking about compiler warnings because of the recent
> discussion here:
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg175099.html
> 
> >From that thread, I have the understanding that some developers think
> it's important to fix warnings, although not if it is risky. I don't
> have much experience programming so I wouldn't be surprised if there's
> something wrong with the following logic:
> 
> It seems to me that warnings should either be fixed when they occur or
> just ignored. That is, if a warning is viewed to be a problem, it
> should be fixed right when it's introduced. Or, if it is not viewed as
> a problem, it should just be permanently ignored. I don't see any
> advantage to having warnings sit around.
> 
> Thus, I wonder if it would be useful to specify "-Werror" in the
> development build, which would turn all warnings into errors and would
> alert the author to fix them right away.

And as soon as the next version of a compiler decides to spit out
more warnings (and we know that not all warnings are warranted)
the code base suddenly does not compile anymore, for no good reason,
and people will have to spend time to reconfigure or patch around
the problem, when all they want is just to get a fresh build.

There's nothing wrong with keeping a -Werror enabling patch locally,
git makes this extremely easy. But it's nothing that should be on
by default.

Andre'

Re: [patch] LyX scrolling issue

[André Pönitz]

On Fri, Sep 21, 2012 at 12:51:43AM +0200, Pavel Sanda wrote:
 Scott Kostyshak wrote:
   void GuiWorkArea::update(int x, int y, int w, int h)
   {
  -   viewport()-update(x, y, w, h);
  +   viewport()-repaint(x, y, w, h);
 
 
 IIRC it was Andre's claim that we should use update instead of repaint.
 Maybe he would know why this slow downs LyX so much.

From the docs:

We suggest only using repaint() if you need an immediate repaint, for
example during animation. In almost all circumstances update() is
better, as it permits Qt to optimize for speed and minimize flicker.

Warning: If you call repaint() in a function which may itself be called
from paintEvent(), you may get infinite recursion. The update() function
never causes recursion.

Andre'

Re: [patch] LyX scrolling issue

[André Pönitz]

On Fri, Sep 21, 2012 at 12:51:43AM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> >  void GuiWorkArea::update(int x, int y, int w, int h)
> >  {
> > -   viewport()->update(x, y, w, h);
> > +   viewport()->repaint(x, y, w, h);
> 
> 
> IIRC it was Andre's claim that we should use update instead of repaint.
> Maybe he would know why this slow downs LyX so much.

>From the docs:

We suggest only using repaint() if you need an immediate repaint, for
example during animation. In almost all circumstances update() is
better, as it permits Qt to optimize for speed and minimize flicker.

Warning: If you call repaint() in a function which may itself be called
from paintEvent(), you may get infinite recursion. The update() function
never causes recursion.

Andre'

Re: plan for the next LyX developer meeting

[André Pönitz]

On Sat, Jun 02, 2012 at 05:52:47PM +0200, Uwe Stöhr wrote:
 André, sad to hear that but why not having a weekend break
 at another nice location?

I haven't said I wouldn't try to come. Switzerland sounds fine.

 When have you e.g. been the last time in Switzerland?

1991 if I remember correctly.

Andre'

Re: plan for the next LyX developer meeting

[André Pönitz]

On Sat, Jun 02, 2012 at 05:52:47PM +0200, Uwe Stöhr wrote:
> André, sad to hear that but why not having a weekend break
> at another nice location?

I haven't said I wouldn't try to come. Switzerland sounds fine.

> When have you e.g. been the last time in Switzerland?

1991 if I remember correctly.

Andre'

Re: plan for the next LyX developer meeting

[André Pönitz]

On Thu, May 31, 2012 at 01:06:38AM +0200, Uwe Stöhr wrote:
 Am 27.05.2012 08:25, schrieb Abdelrazak Younes:
 
 For me Berlin, Amsterdam, Paris, London, Barcelona, Porto, etc
 are fine. Depending on the dates, I would come.
 
 Good to hear that we are now at least 2 persons. Is nobody else
 interested? If we are more I will book a room at the
 university.  Please tell me soon if you would come. if nobody
 else is interested, it is no problem, I only want to know how
 to proceed or to stop.

Unless the criteria is did commit during the last years:

If it's in Berlin I could most likely attend. And of course
there would some place for _some_ sleeping bag folk...

If it's outside, chances are still above zero.

Andre'

Re: plan for the next LyX developer meeting

[André Pönitz]

On Thu, May 31, 2012 at 01:06:38AM +0200, Uwe Stöhr wrote:
> Am 27.05.2012 08:25, schrieb Abdelrazak Younes:
> 
> >For me Berlin, Amsterdam, Paris, London, Barcelona, Porto, etc
> >are fine. Depending on the dates, I would come.
> 
> Good to hear that we are now at least 2 persons. Is nobody else
> interested? If we are more I will book a room at the
> university.  Please tell me soon if you would come. if nobody
> else is interested, it is no problem, I only want to know how
> to proceed or to stop.

Unless the criteria is "did commit during the last years":

If it's in Berlin I could most likely attend. And of course
there would some place for _some_ sleeping bag folk...

If it's outside, chances are still above zero.

Andre'

Re: Current git workflow

[André Pönitz]

On Wed, Mar 21, 2012 at 05:04:56PM +0100, Pavel Sanda wrote:
 Georg Baum wrote:
  commit yet)? I guess it would look like
  
  git checkout -b fixfileformat
  git commit
  git checkout master
  git merge fixfileformat
  git commit
  git branch -d fixfileformat
 
 The simplistic SVN-like scenario is just:
 
 git pull (update from public repo)
 git commit (just local commit in your tree)
 git push (push the commit to public repo)

Methinks

  git commit (just local commit in your tree)
  git pull --rebase (update from public repo and put local changes on top)
  git push (push the - possibly adjusted - commit to public repo)

is closer to the SVN way.

Andre'

Re: Current git workflow

[André Pönitz]

On Wed, Mar 21, 2012 at 05:04:56PM +0100, Pavel Sanda wrote:
> Georg Baum wrote:
> > commit yet)? I guess it would look like
> > 
> > git checkout -b fixfileformat
> > git commit
> > git checkout master
> > git merge fixfileformat
> > git commit
> > git branch -d fixfileformat
> 
> The simplistic SVN-like scenario is just:
> 
> git pull (update from public repo)
> git commit (just local commit in your tree)
> git push (push the commit to public repo)

Methinks

  git commit (just local commit in your tree)
  git pull --rebase (update from public repo and put local changes on top)
  git push (push the - possibly adjusted - commit to public repo)

is closer to the SVN way.

Andre'

Re: [lyx/refs/heads/2.0.x] Merge branch '2.0.x' of git.lyx.org:lyx into 2.0.x

[André Pönitz]

On Thu, Mar 15, 2012 at 02:43:58PM +0100, Vincent van Ravesteijn wrote:
 It's easier to have  a separate branch in case the repo has new
 commits. If you do 'git pull' with local commits in your tree and
 with new commits in the repo, you will get an unnecessary merge.

git pull --rebase  to the rescue.

 If you keep the master branch clean, you can always safely 'git
 pull'. Whenever you want to push a feature to the repo, you rebase
 it onto, merge it into master and push.

If you keep rebasing every now and then (like, always when you pull,
see above) your local work and the main repo don't diverge too much
and the chance of getting conflicts is smaller then with a big
merge in the end. For the normal case of working on a single feature 
at a time that's already completely sufficient.

Andre'

Re: [lyx/refs/heads/2.0.x] Merge branch '2.0.x' of git.lyx.org:lyx into 2.0.x

[André Pönitz]

On Thu, Mar 15, 2012 at 02:43:58PM +0100, Vincent van Ravesteijn wrote:
> It's easier to have  a separate branch in case the repo has new
> commits. If you do 'git pull' with local commits in your tree and
> with new commits in the repo, you will get an unnecessary merge.

"git pull --rebase"  to the rescue.

> If you keep the master branch clean, you can always safely 'git
> pull'. Whenever you want to push a feature to the repo, you rebase
> it onto, merge it into master and push.

If you keep rebasing every now and then (like, always when you pull,
see above) your local work and the main repo don't diverge too much
and the chance of getting conflicts is smaller then with a big
merge in the end. For the "normal" case of working on a single feature 
at a time that's already completely sufficient.

Andre'

Re: Git workflow #2

[André Pönitz]

On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote:
 On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
 But why?
 
 This is the perfect case for a separate repo.
 
  [...]
 
 | Assuming that the pristinity of the lyx repo as a whole is so
 | important that we cannot allow trusted developers to create branches,
 | then maybe such branches can be allowed in the lyx-staging repo? Can
 | we have branches in this one, please?
 
 That would be better, but I do not understand why you couldn't have this
 in your own repo.
 
 
 And I don't understand why we couldn't have branches in our repo.
 I want it simple, and I want it centralized. It's nice to allow
 private new repos to developers, thank you for that, but it seems
 overkill to require their use.

Additional repos are really easy to handle with git remotes.
I'd even argue you won't really notice it. 

 I honestly cannot be bothered at the moment to setup remote
 repositories to fetch someone else's latest feature branch, let alone
 setup my own copy of the repo on the server.

You are ready to write a 20-line-mail because you can't be bothered
to write a single 'git remote add name git://...' line when you
need it? This does not make much sense to me. 

 I'm looking for a central place to have access and contribute to the
 latest LyX development. (I'm also looking for a tool that is stupid
 easy to use.) I hope that if it's not lyx.git, then please let
 lyx-staging.git be this central place. Then it would be the main LyX
 repo in my mind.
 
 Anyway, that's just me. I'm curious to hear what others have to say.

There is no need to clutter The LyX Sources with work-in-progress
branches and lots of needless merges. It's not only ugly, but also
impacts stuff like 'git bisect'. Some things are simply better kept
linear...

You want to keep it simple. Using git remotes _is_ simple.

Andre'

Re: Git workflow #2

[André Pönitz]

On Wed, Mar 14, 2012 at 08:33:05PM +0100, Vincent van Ravesteijn wrote:
 Op 14-3-2012 14:11, Pavel Sanda schreef:
 Vincent van Ravesteijn wrote:
 I see that in some cases of 2. additional commit are applied but we
 shouldn't value clean commit history at such high rates.
 These additional commits are the number 1 reason for me to propose what I
 proposed. To my liking, there are way too many commits that fix a typo, fix
 a warning on a different platform, fix a commit error, fix whitespace, fix
 monolithic build, commit a forgotten file, etc.
 Yes, that's where we disagree. I don't see these additional commits as
 good enough reason to drown people in branching mania. Unless someone
 develops new nifty feature or particularly tough bug, he shouldn't
 recognize there is some difference between svn and git.
 
 You seem to have an aversion to branches, while I can't work without
 them anymore.

There is a difference between (a) using branches for work (implementing
stuff, checking out other people's work etc) and (b) having branches in
the main repo. (a) does not imply (b).

Andre'

Re: Git workflow #2

[André Pönitz]

On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote:
 
 Yes, that's where we disagree. I don't see these additional commits as
 good enough reason to drown people in branching mania. Unless someone
 develops new nifty feature or particularly tough bug, he shouldn't
 recognize there is some difference between svn and git.
 You seem to have an aversion to branches, while I can't work without
 them anymore.
 There is a difference between (a) using branches for work (implementing
 stuff, checking out other people's work etc) and (b) having branches in
 the main repo. (a) does not imply (b).
 
 (a) does not imply (b), but both (a) and (b) imply branching
 mania. So, given (a), branching mania can't be a reason to refuse
 (b).

(a) is everybody own's business. Nobody will ever know how many
local branches you have used to end up with that single patch or
two that finally go to the main repo. Same for branches in any
private repos you might have used to share previews of your work.
As long as it's not in the main repo, nobody should really care,
and you can use whatever make you feel happy. 

Branching mania is only a problem when this kind of structure
gets set in stone in the main repo by merging, instead of, say,
squashing stuff to palatable chunks and cherry-picking the result
to a mostly linear main repo.

Andre'

Re: Git workflow #2

[André Pönitz]

On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote:
> On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
> >But why?
> >
> >This is the perfect case for a separate repo.
> >
> > [...]
> >
> >| Assuming that the pristinity of the lyx repo as a whole is so
> >| important that we cannot allow trusted developers to create branches,
> >| then maybe such branches can be allowed in the lyx-staging repo? Can
> >| we have branches in this one, please?
> >
> >That would be better, but I do not understand why you couldn't have this
> >in your own repo.
> >
> 
> And I don't understand why we couldn't have branches in our repo.
> I want it simple, and I want it centralized. It's nice to allow
> private new repos to developers, thank you for that, but it seems
> overkill to require their use.

Additional repos are really easy to handle with git remotes.
I'd even argue you won't really notice it. 

> I honestly cannot be bothered at the moment to setup remote
> repositories to fetch someone else's latest feature branch, let alone
> setup my own copy of the repo on the server.

You are ready to write a 20-line-mail because you can't be bothered
to write a single 'git remote add  git://...' line when you
need it? This does not make much sense to me. 

> I'm looking for a central place to have access and contribute to the
> latest LyX development. (I'm also looking for a tool that is stupid
> easy to use.) I hope that if it's not lyx.git, then please let
> lyx-staging.git be this central place. Then it would be the main LyX
> repo in my mind.
> 
> Anyway, that's just me. I'm curious to hear what others have to say.

There is no need to clutter The LyX Sources with work-in-progress
branches and lots of needless merges. It's not only ugly, but also
impacts stuff like 'git bisect'. Some things are simply better kept
linear...

You want to keep it simple. Using git remotes _is_ simple.

Andre'

Re: Git workflow #2

[André Pönitz]

On Wed, Mar 14, 2012 at 08:33:05PM +0100, Vincent van Ravesteijn wrote:
> Op 14-3-2012 14:11, Pavel Sanda schreef:
> >Vincent van Ravesteijn wrote:
> >>>I see that in some cases of 2. additional commit are applied but we
> >>>shouldn't value clean commit history at such high rates.
> >>These additional commits are the number 1 reason for me to propose what I
> >>proposed. To my liking, there are way too many commits that fix a typo, fix
> >>a warning on a different platform, fix a commit error, fix whitespace, fix
> >>monolithic build, commit a forgotten file, etc.
> >Yes, that's where we disagree. I don't see these additional commits as
> >good enough reason to drown people in branching mania. Unless someone
> >develops new nifty feature or particularly tough bug, he shouldn't
> >recognize there is some difference between svn and git.
> 
> You seem to have an aversion to branches, while I can't work without
> them anymore.

There is a difference between (a) using branches for work (implementing
stuff, checking out other people's work etc) and (b) having branches in
the main repo. (a) does not imply (b).

Andre'

Re: Git workflow #2

[André Pönitz]

On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote:
> 
> >>>Yes, that's where we disagree. I don't see these additional commits as
> >>>good enough reason to drown people in branching mania. Unless someone
> >>>develops new nifty feature or particularly tough bug, he shouldn't
> >>>recognize there is some difference between svn and git.
> >>You seem to have an aversion to branches, while I can't work without
> >>them anymore.
> >There is a difference between (a) using branches for work (implementing
> >stuff, checking out other people's work etc) and (b) having branches in
> >the main repo. (a) does not imply (b).
> 
> (a) does not imply (b), but both (a) and (b) imply "branching
> mania". So, given (a), "branching mania" can't be a reason to refuse
> (b).

(a) is everybody own's business. Nobody will ever know how many
local branches you have used to end up with that single patch or
two that finally go to the main repo. Same for branches in any
private repos you might have used to share previews of your work.
As long as it's not in the main repo, nobody should really care,
and you can use whatever make you feel happy. 

"Branching mania" is only a problem when this kind of structure
gets set in stone in the main repo by merging, instead of, say,
squashing stuff to palatable chunks and cherry-picking the result
to a mostly linear main repo.

Andre'

Re: 2 trunk compilation errors with CMake in release mode

[André Pönitz]

On Thu, Feb 16, 2012 at 12:13:18AM +0100, Uwe Stöhr wrote:
 Am 15.02.2012 12:02, schrieb Vincent van Ravesteijn:
 
 I still don't understand why you insist on using the build scripts. Why not 
 just using an IDE ?
 
 Because I have to compile both, branch and trunk quite frequently.
 Using the IDE took ages and one had to reset everything when
 switching from trunk to branch and back.

Maybe you can save some time by using different checkouts
for trunk and branch

Andre'

Re: 2 trunk compilation errors with CMake in release mode

[André Pönitz]

On Thu, Feb 16, 2012 at 12:13:18AM +0100, Uwe Stöhr wrote:
> Am 15.02.2012 12:02, schrieb Vincent van Ravesteijn:
> 
> >I still don't understand why you insist on using the build scripts. Why not 
> >just using an IDE ?
> 
> Because I have to compile both, branch and trunk quite frequently.
> Using the IDE took ages and one had to reset everything when
> switching from trunk to branch and back.

Maybe you can save some time by using different checkouts
for trunk and branch

Andre'

Re: Report (was: Qt: was Slow scrolling)

[André Pönitz]

On Thu, Jan 05, 2012 at 02:17:29PM +0100, Pavel Sanda wrote:
 Jean-Marc Lasgouttes wrote:
  Le 05/01/2012 02:40, André Pönitz a écrit :
  The main performance problems I have seesn so far are due to an abuse of
  the toolkit, not caused _by_ the toolkit (except for the remote raster
 
 please... there were many cases we have no clue where the problem is.
 it can be lyx, qt, X, card drivers. to summarize the whole thing by saying
 that all is abuse of qt smells like problem with your affiliation ;)

[Sure, we can go ad hominem if you think that helps...]

LyX is the _only_ application I know that e.g. still pretends to be able
to draw outside of paint events by adding another level of buffering
(GuiWorkArea::Private::screen_). And note, that's not a problem
originating from Qt, but imposed by some platforms, most notably
MacOS_X_.  This approach causes otherwise completely unnessary copies of
all screen data when scrolling.

Also, the core text drawing functionality is abstracted, i.e. LyX does
it (deteminining positioning, spacing etc), spoon-feeds the results to
Qt's drawText() which does the same again. Similar for the handling of
fonts, colors etc.

I just stepped a bit through the code and there were tons of instances
where single characters were passed to drawText, each setting up the
text drawing machinery mostly from scratch. I do understand that this
might be needed for math, but it should not happen often for regular
test.

Andre'

Re: Report

[André Pönitz]

On Sun, Jan 08, 2012 at 09:26:28PM +0100, Abdelrazak Younes wrote:
 On 08/01/2012 20:44, André Pönitz wrote:
 On Thu, Jan 05, 2012 at 02:17:29PM +0100, Pavel Sanda wrote:
 Jean-Marc Lasgouttes wrote:
 Le 05/01/2012 02:40, André Pönitz a écrit :
 The main performance problems I have seesn so far are due to
 an abuse of
 the toolkit, not caused _by_ the toolkit (except for the remote raster
 
 please... there were many cases we have no clue where the problem is.
 it can be lyx, qt, X, card drivers. to summarize the whole thing
 by saying
 that all is abuse of qt smells like problem with your affiliation
 
 [Sure, we can go ad hominem if you think that helps...]
 
 LyX is the _only_ application I know that e.g. still pretends to be able
 to draw outside of paint events by adding another level of buffering
 (GuiWorkArea::Private::screen_).
 
 Are you sure? What about paint or picture programs? Except going the
 QGraphisView or the QTextEdit ways, what are the options without a
 backing QPixmap or QPicture?

Call update(), and do the drawing in the paint event, with an
painter opened on the widget, not to the QImage/QPixmap buffer.

 Also, the core text drawing functionality is abstracted, i.e. LyX does
 it (deteminining positioning, spacing etc), spoon-feeds the results to
 Qt's drawText() which does the same again. Similar for the handling of
 fonts, colors etc.
 
 That's the price to pay for toolkit independence

[Partially. The other part is the price for LyX's peculiar approach
core/gui separation, where the core tells the gui when and what to
draw. But I did not want to discuss _that_ issue again.]
 
 I just stepped a bit through the code and there were tons of
 instances where single characters were passed to drawText, each
 setting up the text drawing machinery mostly from scratch. I do
 understand that this might be needed for math, but it should not
 happen often for regular test.
 
 It is needed for RTL text and for MacOS correct font rendering.

It certainly _was_ needed. Whether it still is I don't know. What
happens when someone puts some arabic text in a simple QTextEdit
on Mac? Are you saying that does not just work?

Andre'
 

Re: Report (was: Qt: was Slow scrolling)

[André Pönitz]

On Thu, Jan 05, 2012 at 02:17:29PM +0100, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Le 05/01/2012 02:40, André Pönitz a écrit :
> >> The main performance problems I have seesn so far are due to an abuse of
> >> the toolkit, not caused _by_ the toolkit (except for the remote raster
> 
> please... there were many cases we have no clue where the problem is.
> it can be lyx, qt, X, card drivers. to summarize the whole thing by saying
> that all is abuse of qt smells like problem with your affiliation ;)

[Sure, we can go ad hominem if you think that helps...]

LyX is the _only_ application I know that e.g. still pretends to be able
to draw outside of paint events by adding another level of buffering
(GuiWorkArea::Private::screen_). And note, that's not a "problem
originating from Qt", but imposed by some platforms, most notably
MacOS_X_.  This approach causes otherwise completely unnessary copies of
all screen data when scrolling.

Also, the core text drawing functionality is "abstracted", i.e. LyX does
it (deteminining positioning, spacing etc), spoon-feeds the results to
Qt's drawText() which does the same again. Similar for the handling of
fonts, colors etc.

I just stepped a bit through the code and there were tons of instances
where single characters were passed to drawText, each setting up the
text drawing machinery mostly from scratch. I do understand that this
might be needed for math, but it should not happen often for regular
test.

Andre'

Re: Report

[André Pönitz]

On Sun, Jan 08, 2012 at 09:26:28PM +0100, Abdelrazak Younes wrote:
> On 08/01/2012 20:44, André Pönitz wrote:
> >On Thu, Jan 05, 2012 at 02:17:29PM +0100, Pavel Sanda wrote:
> >>Jean-Marc Lasgouttes wrote:
> >>>Le 05/01/2012 02:40, André Pönitz a écrit :
> >>>>The main performance problems I have seesn so far are due to
> >>>>an abuse of
> >>>>the toolkit, not caused _by_ the toolkit (except for the remote raster
> >>
> >>please... there were many cases we have no clue where the problem is.
> >>it can be lyx, qt, X, card drivers. to summarize the whole thing
> >>by saying
> >>that all is abuse of qt smells like problem with your affiliation
> >
> >[Sure, we can go ad hominem if you think that helps...]
> >
> >LyX is the _only_ application I know that e.g. still pretends to be able
> >to draw outside of paint events by adding another level of buffering
> >(GuiWorkArea::Private::screen_).
> 
> Are you sure? What about paint or picture programs? Except going the
> QGraphisView or the QTextEdit ways, what are the options without a
> backing QPixmap or QPicture?

Call update(), and do the drawing in the paint event, with an
painter opened on the widget, not to the QImage/QPixmap buffer.

> >Also, the core text drawing functionality is "abstracted", i.e. LyX does
> >it (deteminining positioning, spacing etc), spoon-feeds the results to
> >Qt's drawText() which does the same again. Similar for the handling of
> >fonts, colors etc.
> 
> That's the price to pay for toolkit independence

[Partially. The other part is the price for LyX's peculiar approach
core/gui separation, where the core tells the gui when and what to
draw. But I did not want to discuss _that_ issue again.]
 
> >I just stepped a bit through the code and there were tons of
> >instances where single characters were passed to drawText, each
> >setting up the text drawing machinery mostly from scratch. I do
> >understand that this might be needed for math, but it should not
> >happen often for regular test.
> 
> It is needed for RTL text and for MacOS correct font rendering.

It certainly _was_ needed. Whether it still is I don't know. What
happens when someone puts some arabic text in a simple QTextEdit
on Mac? Are you saying that does not "just work"?

Andre'
> 

Re: Releasing and testing questions

[André Pönitz]

On Mon, Dec 26, 2011 at 09:32:17AM +0100, marcus...@index.hu wrote:
 I've used LyX for a while in the past and I've been keeping track of
 it's progress. Two questions arose that concern development: the first
 is, why don't you release more often?

Making a release is a lot of effort. It does not happen because it
would be nice, but because someone does that work. 

 You have a bugzilla list of automated testing bugs, why
 don't you fix those

Counterquestion: Why didn't you fix those bugs?

 (Mind you, I'm trying to be constructive. LyX is an awesome thing,
 I'll definitely help with development once I get some free time
 between work and university.)

You seem to know the answer to your questions already.

Andre'

Re: Releasing and testing questions

[André Pönitz]

On Mon, Dec 26, 2011 at 09:32:17AM +0100, marcus...@index.hu wrote:
> I've used LyX for a while in the past and I've been keeping track of
> it's progress. Two questions arose that concern development: the first
> is, why don't you release more often?

Making a release is a lot of effort. It does not happen because "it
would be nice", but because someone does that work. 

> You have a bugzilla list of automated testing bugs, why
> don't you fix those

Counterquestion: Why didn't you fix those bugs?

> (Mind you, I'm trying to be constructive. LyX is an awesome thing,
> I'll definitely help with development once I get some free time
> between work and university.)

You seem to know the answer to your questions already.

Andre'

Re: Potential fix for slowness on X11 (Re: r39932 - lyx-devel/trunk/src/frontends/qt4

[André Pönitz]

On Wed, Dec 14, 2011 at 01:46:30PM +0100, Helge Hafting wrote:
 On 21. nov. 2011 21:01, Abdelrazak Younes wrote:
 On 21/11/2011 11:28, Helge Hafting wrote:
  I failed to test the patch. It does not apply to the 2.1 sources, and
  not 2.0.2 either.
 
 There is nothing to apply, you just have to uncomment the definition of
 USE_QIMAGE at the top of
 
 GuiWorkArea_Private.h
 
 
 Ok, I misunderstood. I have now tested, by loading the User Guide
 in a large window, and scroll it to the bottom by holding
 down the page down key. The results:
 
 Fast machine, no USE_QIMAGE: 20s
 Slow machine, no USE_QIMAGE: 200s
 Slow machine, with USE_QIMAGE: 33s

Is that the same version of Qt?

Andre'

Re: Potential fix for slowness on X11 (Re: r39932 - lyx-devel/trunk/src/frontends/qt4

[André Pönitz]

On Wed, Dec 14, 2011 at 01:46:30PM +0100, Helge Hafting wrote:
> On 21. nov. 2011 21:01, Abdelrazak Younes wrote:
> >On 21/11/2011 11:28, Helge Hafting wrote:
> >> I failed to test the patch. It does not apply to the 2.1 sources, and
> >> not 2.0.2 either.
> >
> >There is nothing to apply, you just have to uncomment the definition of
> >USE_QIMAGE at the top of
> >
> >GuiWorkArea_Private.h
> 
> 
> Ok, I misunderstood. I have now tested, by loading the User Guide
> in a large window, and scroll it to the bottom by holding
> down the "page down" key. The results:
> 
> Fast machine, no USE_QIMAGE: 20s
> Slow machine, no USE_QIMAGE: 200s
> Slow machine, with USE_QIMAGE: 33s

Is that the same version of Qt?

Andre'

Re: LyX trunk builded with Qt creator on Ubuntu 11.10

[André Pönitz]

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
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...)]

Andre'

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

Re: LyX trunk builded with Qt creator on Ubuntu 11.10

[André Pönitz]

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
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...)]

Andre'

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

Re: LyX trunk builded with Qt creator on Ubuntu 11.10

[André Pönitz]

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.

Andre'

Re: LyX trunk builded with Qt creator on Ubuntu 11.10

[André Pönitz]

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.

Andre'

Re: Some warnings with gcc 4.7

[André Pönitz]

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.

Andre

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

[André Pönitz]

On Mon, Nov 21, 2011 at 12:02:15AM +0100, Lars Gullik Bjønnes wrote:
 Systemcall.cpp:337:65: error: inconsistent user-defined literal suffixes 
 ‘__FILE__’ and ‘QTOSTRING’ in string literal
 Systemcall.cpp:337:65: error: unable to find user-defined string literal 
 operator ‘operator __FILE__’
 
 This seems to be our own problem.
 Unless it is something we inherit from Qt.
 Ahh nice... it is Qt.

Indeed. The error istriggered by

  #define QTOSTRING_HELPER(s) #s
  #define QTOSTRING(s) QTOSTRING_HELPER(s)
  #define QLOCATION \0__FILE__:QTOSTRING(__LINE__)

 And the wonderfull non-c++ parts of Qt.

The preprocessor is part of C++ (both 98/03 and 11), how that can be
dubbed non-c++ is beyond me.

The first two lines represent the canonical way to stringify expanded
values using the C++ preprocessor.  The third line is valid C++ in the
1998 and 2003 versions of the Standard.

Unfortunately, the 2011 version of the Standard introduces user
defined literals which are - as shown by this example - source
incompatible, i.e. previously valid code is now invalid.

Blaming library code that has been around for a quite a while for not
anticipating such changes seems odd, especially if previous versions
of gcc happily accepted that code in C++0x mode.

Andre'

Re: Some warnings with gcc 4.7

[André Pönitz]

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.

Andre"

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

[André Pönitz]

On Mon, Nov 21, 2011 at 12:02:15AM +0100, Lars Gullik Bjønnes wrote:
> Systemcall.cpp:337:65: error: inconsistent user-defined literal suffixes 
> ‘__FILE__’ and ‘QTOSTRING’ in string literal
> Systemcall.cpp:337:65: error: unable to find user-defined string literal 
> operator ‘operator"" __FILE__’
> 
> This seems to be our own problem.
> Unless it is something we inherit from Qt.
> Ahh nice... it is Qt.

Indeed. The error istriggered by

  #define QTOSTRING_HELPER(s) #s
  #define QTOSTRING(s) QTOSTRING_HELPER(s)
  #define QLOCATION "\0"__FILE__":"QTOSTRING(__LINE__)

> And the wonderfull non-c++ parts of Qt.

The preprocessor is part of C++ (both 98/03 and 11), how that can be
dubbed "non-c++" is beyond me.

The first two lines represent the canonical way to stringify expanded
values using the C++ preprocessor.  The third line is valid C++ in the
1998 and 2003 versions of the Standard.

Unfortunately, the 2011 version of the Standard introduces "user
defined literals" which are - as shown by this example - source
incompatible, i.e. previously valid code is now invalid.

Blaming library code that has been around for a quite a while for not
anticipating such changes seems odd, especially if previous versions
of gcc happily accepted that code in "C++0x" mode.

Andre'

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

[André Pönitz]

On Mon, Nov 21, 2011 at 10:11:11AM +0100, Lars Gullik Bjønnes wrote:
 Peter Kümmel syntheti...@gmx.net 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.

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

Andre'

Re: Some warnings with gcc 4.7

[André Pönitz]

On Mon, Nov 21, 2011 at 10:07:51AM +0100, Lars Gullik Bjønnes wrote:
 André Pönitz andre.poen...@mathematik.tu-chemnitz.de writes:
 
 | On Sun, Nov 20, 2011 at 11:46:10PM +0100, Lars Gullik Bjønnes wrote:
  
  Even if gcc 4.7 has not been released (quite far from), it might be
  nice to test compile with it anyway.
 
 | Sure.
 |  
  Here are the results:
   
  GuiWorkArea.cpp: In destructor ‘virtual
  lyx::frontend::GuiWorkArea::~GuiWorkArea()’: GuiWorkArea.cpp:327:9:
  warning: deleting object of polymorphic class type
  ‘lyx::frontend::GuiWorkArea::Private’ which has non-virtual destructor
  might cause undefined behaviour [-Wdelete-non-virtual-dtor]
 
 | I see  : d(new Private) and delete d;.  Where is the problem?
 
 The (potential) problem is a destructor in a parent class that is not
 marked virtual. If anything is allocated in the that class it will not
 be destroyed through the polymorfic pointer.
 
 It might very well be that gcc is a tad mistaken, but if
 EmbeddedWorkArea, then GuiWorkArea should
 have a virtual destructor.
 
 (I cannot see how GuiWorkArea::Private plays into this.)

First guess: gcc sees 'virtual' on two member functions but no virtual
destructor, cannot prove that delete operates only on static type ==
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

[André Pönitz]

On Mon, Nov 21, 2011 at 10:44:04PM +0100, Peter Kümmel wrote:
 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ümmelsyntheti...@gmx.net  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.

And won't have, as long as the core steers the gui [ 1/2 ;-) ]

Andre'

Re: Some warnings with gcc 4.7

[André Pönitz]

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 

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: Compiling LyX with -std=gnu++1

[André Pönitz]

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.

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

Andre'

Re: Some warnings with gcc 4.7

[André Pönitz]

On Mon, Nov 21, 2011 at 10:07:51AM +0100, Lars Gullik Bjønnes wrote:
> André Pönitz <andre.poen...@mathematik.tu-chemnitz.de> writes:
> 
> | On Sun, Nov 20, 2011 at 11:46:10PM +0100, Lars Gullik Bjønnes wrote:
> >> 
> >> Even if gcc 4.7 has not been released (quite far from), it might be
> >> nice to test compile with it anyway.
> >
> | Sure.
> |  
> >> Here are the results:
> >>  
> >> GuiWorkArea.cpp: In destructor ‘virtual
> >> lyx::frontend::GuiWorkArea::~GuiWorkArea()’: GuiWorkArea.cpp:327:9:
> >> warning: deleting object of polymorphic class type
> >> ‘lyx::frontend::GuiWorkArea::Private’ which has non-virtual destructor
> >> might cause undefined behaviour [-Wdelete-non-virtual-dtor]
> >
> | I see " : d(new Private)" and "delete d;".  Where is the problem?
> 
> The (potential) problem is a destructor in a parent class that is not
> marked virtual. If anything is allocated in the that class it will not
> be destroyed through the polymorfic pointer.
> 
> It might very well be that gcc is a tad mistaken, but if
> EmbeddedWorkArea, then GuiWorkArea should
> have a virtual destructor.
> 
> (I cannot see how GuiWorkArea::Private plays into this.)

First guess: gcc sees 'virtual' on two member functions but no virtual
destructor, cannot prove that delete operates only on static type ==
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

[André Pönitz]

On Mon, Nov 21, 2011 at 10:44:04PM +0100, Peter Kümmel wrote:
> 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<syntheti...@gmx.net>  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.

And won't have, as long as the core steers the gui [ 1/2 ;-) ]

Andre'

Re: Some warnings with gcc 4.7

[André Pönitz]

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 "

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: Qt creator?

[André Pönitz]

On Sat, Nov 19, 2011 at 12:36:19PM +0100, Peter Kümmel 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.
 
 Wasn't he (Is still?) a vi-guy ;)

There's FakeVim, you know...

Btw, as the 'vi keystrokes for LyX' issue came up on the users list:
I don't think it's impossible. The core of the FakeVim plugin is
(intentionally) not tied to the IDE. It can operate on any QTextEdit or
QPlainTextEdit derived class, and currently requires such, so it would
not be a drop in, but the ties are rather weak, and it should be
fairly straightforward to replace accesses the QTextDocument model by
something else. The main challenge is probably to find a painless way to
handle Cursor Up/Down, as the FakeVim model assumes fixed width fonts.

Andre'

Re: tar'ed boost headers

[André Pönitz]

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'

Re: Some warnings with gcc 4.7

[André Pönitz]

On Sun, Nov 20, 2011 at 11:46:10PM +0100, Lars Gullik Bjønnes wrote:
 
 Even if gcc 4.7 has not been released (quite far from), it might be
 nice to test compile with it anyway.

Sure.
 
 Here are the results:
  
 GuiWorkArea.cpp: In destructor ‘virtual
 lyx::frontend::GuiWorkArea::~GuiWorkArea()’: GuiWorkArea.cpp:327:9:
 warning: deleting object of polymorphic class type
 ‘lyx::frontend::GuiWorkArea::Private’ which has non-virtual destructor
 might cause undefined behaviour [-Wdelete-non-virtual-dtor]

I see  : d(new Private) and delete d;.  Where is the problem?

Arguably, the two 'virtual' in showCursor and removeCursor are not
needed, but legal and harmless. Is that what the compiler is helpfully
trying to hint at? If so, why doesn't it say so?

 [...]
 insets/InsetListingsParams.cpp: In constructor 
 ‘lyx::{anonymous}::ParValidator::ParValidator()’:
 insets/InsetListingsParams.cpp:280:1: note: variable tracking size limit 
 exceeded with -fvar-tracking-assignments, retrying without

Looks rather like a problem of the compiler, not of the code.

Andre'

Re: Qt creator?

[André Pönitz]

On Sat, Nov 19, 2011 at 12:36:19PM +0100, Peter Kümmel 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.
> 
> Wasn't he (Is still?) a vi-guy ;)

There's FakeVim, you know...

Btw, as the 'vi keystrokes for LyX' issue came up on the users list:
I don't think it's impossible. The core of the FakeVim plugin is
(intentionally) not tied to the IDE. It can operate on any QTextEdit or
QPlainTextEdit derived class, and currently requires such, so it would
not be a "drop in", but the ties are rather weak, and it should be
fairly straightforward to replace accesses the QTextDocument model by
something else. The main challenge is probably to find a painless way to
handle Cursor Up/Down, as the FakeVim model assumes fixed width fonts.

Andre'

Re: tar'ed boost headers

[André Pönitz]

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'

Re: Some warnings with gcc 4.7

[André Pönitz]

On Sun, Nov 20, 2011 at 11:46:10PM +0100, Lars Gullik Bjønnes wrote:
> 
> Even if gcc 4.7 has not been released (quite far from), it might be
> nice to test compile with it anyway.

Sure.
 
> Here are the results:
>  
> GuiWorkArea.cpp: In destructor ‘virtual
> lyx::frontend::GuiWorkArea::~GuiWorkArea()’: GuiWorkArea.cpp:327:9:
> warning: deleting object of polymorphic class type
> ‘lyx::frontend::GuiWorkArea::Private’ which has non-virtual destructor
> might cause undefined behaviour [-Wdelete-non-virtual-dtor]

I see " : d(new Private)" and "delete d;".  Where is the problem?

Arguably, the two 'virtual' in showCursor and removeCursor are not
needed, but legal and harmless. Is that what the compiler is helpfully
trying to hint at? If so, why doesn't it say so?

> [...]
> insets/InsetListingsParams.cpp: In constructor 
> ‘lyx::{anonymous}::ParValidator::ParValidator()’:
> insets/InsetListingsParams.cpp:280:1: note: variable tracking size limit 
> exceeded with -fvar-tracking-assignments, retrying without

Looks rather like a problem of the compiler, not of the code.

Andre'