Re: [LyX/master] Return an error if file-open is called with a non-absolute path

2013-12-02 Thread Scott Kostyshak
On Tue, Dec 3, 2013 at 2:38 AM, Vincent van Ravesteijn  wrote:
>
>
> On Tue, Dec 3, 2013 at 2:14 AM, Scott Kostyshak  wrote:
>>
>> On Mon, Dec 2, 2013 at 3:05 PM, Vincent van Ravesteijn 
>> wrote:
>> > commit 9c4461deea8eabb5bc025a08fa6ce11cb1c9e6fd
>> > Author: Vincent van Ravesteijn 
>> > Date:   Mon Dec 2 21:04:46 2013 +0100
>> >
>> > Return an error if file-open is called with a non-absolute path
>>
>> Kornel and I (both on Ubuntu) cannot open files after this patch. File
>> > Open gives no output (no dialog, no message, no STDERR). File > New
>> From Template works as expected.
>>
>> Scott
>
>
> Yes, sorry. It is fixed now.

Thanks, it works well now.

Scott


Re: [LyX/master] Return an error if file-open is called with a non-absolute path

2013-12-02 Thread Vincent van Ravesteijn
On Tue, Dec 3, 2013 at 2:14 AM, Scott Kostyshak  wrote:

> On Mon, Dec 2, 2013 at 3:05 PM, Vincent van Ravesteijn 
> wrote:
> > commit 9c4461deea8eabb5bc025a08fa6ce11cb1c9e6fd
> > Author: Vincent van Ravesteijn 
> > Date:   Mon Dec 2 21:04:46 2013 +0100
> >
> > Return an error if file-open is called with a non-absolute path
>
> Kornel and I (both on Ubuntu) cannot open files after this patch. File
> > Open gives no output (no dialog, no message, no STDERR). File > New
> From Template works as expected.
>
> Scott
>

Yes, sorry. It is fixed now.

Vincent


Re: examples/es/europeCV.lyx: can't export with luatex

2013-12-02 Thread Scott Kostyshak
On Sat, Nov 30, 2013 at 2:01 AM, Scott Kostyshak  wrote:
> On Fri, May 17, 2013 at 8:49 PM, Scott Kostyshak  wrote:
>> On Sun, Apr 14, 2013 at 3:39 AM, Scott Kostyshak  wrote:
>>> I get utf-8 and utf8x errors.
>>>
>>> Is there a fix for this while preserving export with pdflatex and latex?
>>
>> Any ideas?
>
> It is still failing for me with LuaTeX and XeTeX.
> Adding the option "latin2" fixes it for me. Is that the right thing to do?
> The following seems relevant:
> (from http://mirrors.ctan.org/macros/latex/contrib/europecv/europecv.pdf)
> The default input encoding for the europecv class is UTF-8. If you have
> a Unicode capable text editor, you should be able to directly type text
> with accents, diacritics and so on (i.e., no need to use LATEX commands for
> special characters). In order for this to work, you must ensure that your
> document is saved using the UTF-8 text encoding. As an alternative, you
> may specify a different input encoding for your document (see options
> below). Please note that the ucs and inputenc packages are needed no
> matter which encoding you use (see Section 5).

I will change the encoding to "latin2" unless someone objects.

Scott


Re: trunk: Style Chunk

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 8:13 PM, Scott Kostyshak  wrote:
> On Mon, Dec 2, 2013 at 8:07 PM, Richard Heck  wrote:
>> On 12/02/2013 06:39 PM, Scott Kostyshak wrote:
>>>
>>> Attached is a patch that fixes Literate.lyx manually. I just replace
>>> the problematic chunks with ERT. Is this OK for a fix for 2.1? It
>>> seems it might save some time to just do this manual fix (and also for
>>> noweb2lyx and listerrors) for 2.1 and if a lyx2lyx fix is desired that
>>> can be worked on later. Any thoughts?
>>>
>>> Also note that the following thread is related:
>>> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179740.html
>>
>>
>> Manual fix is probably good, anyway. I will work on the lyx2lyx stuff once
>> the semester is over.
>
> Sounds good. I will try to do this later tonight.

Done at fb034884.

Scott


Re: Cannot clone non-devel version of LyX

2013-12-02 Thread Scott Kostyshak
On Tue, Dec 3, 2013 at 1:07 AM, Keld Lundgaard  wrote:
> I am experiencing a large improvement in the scrolling speed and fluidity.
>
> Thanks a lot, Keld

Great, glad it's working better. Thanks for the feedback.

Best,

Scott

>
>
> On Mon, Dec 2, 2013 at 9:35 PM, Scott Kostyshak  wrote:
>>
>> On Tue, Dec 3, 2013 at 12:12 AM, Keld Lundgaard
>>  wrote:
>> > Hi Scott
>> >
>> > Thanks a lot for the fast response. It was a firewall setting on my site
>> > that was the problem. Your link is very welcome - downloading now.
>>
>> Glad that you got it working. Please let us know if the slow scrolling
>> is fixed (or at least better) for you.
>>
>> Best,
>>
>> Scott
>
>


Re: Cannot clone non-devel version of LyX

2013-12-02 Thread Keld Lundgaard
I am experiencing a large improvement in the scrolling speed and fluidity.

Thanks a lot, Keld


On Mon, Dec 2, 2013 at 9:35 PM, Scott Kostyshak  wrote:

> On Tue, Dec 3, 2013 at 12:12 AM, Keld Lundgaard
>  wrote:
> > Hi Scott
> >
> > Thanks a lot for the fast response. It was a firewall setting on my site
> > that was the problem. Your link is very welcome - downloading now.
>
> Glad that you got it working. Please let us know if the slow scrolling
> is fixed (or at least better) for you.
>
> Best,
>
> Scott
>


Re: Cannot clone non-devel version of LyX

2013-12-02 Thread Scott Kostyshak
On Tue, Dec 3, 2013 at 12:12 AM, Keld Lundgaard
 wrote:
> Hi Scott
>
> Thanks a lot for the fast response. It was a firewall setting on my site
> that was the problem. Your link is very welcome - downloading now.

Glad that you got it working. Please let us know if the slow scrolling
is fixed (or at least better) for you.

Best,

Scott


Re: Cannot clone non-devel version of LyX

2013-12-02 Thread Keld Lundgaard
Hi Scott

Thanks a lot for the fast response. It was a firewall setting on my site
that was the problem. Your link is very welcome - downloading now.

Cheers, Keld


On Mon, Dec 2, 2013 at 8:47 PM, Scott Kostyshak  wrote:

> On Mon, Dec 2, 2013 at 10:24 PM, Keld Lundgaard
>  wrote:
> > Dear LyX Developers
> >
> > Thank you for dedicating yourself to making this amazing program.
> >
> > I cannot clone the non-devel version of lyX. The server simply doesn’t
> respond! Could you provide some guidance please. I am using LyX on mac 10.9
> and experience the slow scroll that has been reported widely on the
> internet.
> >
> > Cheers, Keld
>
> Hi Keld,
>
> Thanks for reporting this. When reporting problems it's always helpful
> if you show what you tried. Which command did you run?
>
> What do you mean by non-devel version of LyX? Did you mean devel? If
> you are interested in trying LyX 2.1 beta2 (it is only a week behind
> the current devel version), you can download the Mac binary here:
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/lyx-2.1.0beta2
>
> Scott
>


Re: Cannot clone non-devel version of LyX

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 10:24 PM, Keld Lundgaard
 wrote:
> Dear LyX Developers
>
> Thank you for dedicating yourself to making this amazing program.
>
> I cannot clone the non-devel version of lyX. The server simply doesn’t 
> respond! Could you provide some guidance please. I am using LyX on mac 10.9 
> and experience the slow scroll that has been reported widely on the internet.
>
> Cheers, Keld

Hi Keld,

Thanks for reporting this. When reporting problems it's always helpful
if you show what you tried. Which command did you run?

What do you mean by non-devel version of LyX? Did you mean devel? If
you are interested in trying LyX 2.1 beta2 (it is only a week behind
the current devel version), you can download the Mac binary here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/lyx-2.1.0beta2

Scott


Cannot clone non-devel version of LyX

2013-12-02 Thread Keld Lundgaard
Dear LyX Developers

Thank you for dedicating yourself to making this amazing program. 

I cannot clone the non-devel version of lyX. The server simply doesn’t respond! 
Could you provide some guidance please. I am using LyX on mac 10.9 and 
experience the slow scroll that has been reported widely on the internet. 

Cheers, Keld 

Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 8:04 PM, Richard Heck  wrote:
> On 12/02/2013 07:19 PM, Scott Kostyshak wrote:
>>
>> On Mon, Dec 2, 2013 at 6:44 PM, Kornel Benko  wrote:
>>>
>>> Am Montag, 2. Dezember 2013 um 23:56:42, schrieb Kornel Benko
>>> 
>>>
 Am Montag, 2. Dezember 2013 um 17:21:13, schrieb Richard Heck
 
>
> On 12/02/2013 03:45 PM, Kornel Benko wrote:
>>>
>>> THIS IS SEVERE:
>>>
>>> With the newest lyx, I am unable to open a new file (There is _no_
>>> dialog)
>>>
>>> (New from template dialog is still OK)
>>>
>>> Using the previous version, that is before 'Return an error if file-open
>>> is
>>> called with a non-absolute path'
>>>
>>> is OK.
>>
>> I can reproduce on Ubuntu. File > Open does not work (nothing seems to
>> happen, no dialog, no STDERR output). File > New From Template does
>> work.
>
>
> This should be posted separately, not in this thread, and cc'd to Vincent.

Indeed, I responded to Vincent's commit because I'm guessing that
Kornel (but probably Vincent also) is in bed.

Scott


Re: [LyX/master] Return an error if file-open is called with a non-absolute path

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 3:05 PM, Vincent van Ravesteijn  wrote:
> commit 9c4461deea8eabb5bc025a08fa6ce11cb1c9e6fd
> Author: Vincent van Ravesteijn 
> Date:   Mon Dec 2 21:04:46 2013 +0100
>
> Return an error if file-open is called with a non-absolute path

Kornel and I (both on Ubuntu) cannot open files after this patch. File
> Open gives no output (no dialog, no message, no STDERR). File > New
>From Template works as expected.

Scott


Re: trunk: Style Chunk

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 8:07 PM, Richard Heck  wrote:
> On 12/02/2013 06:39 PM, Scott Kostyshak wrote:
>>
>> Attached is a patch that fixes Literate.lyx manually. I just replace
>> the problematic chunks with ERT. Is this OK for a fix for 2.1? It
>> seems it might save some time to just do this manual fix (and also for
>> noweb2lyx and listerrors) for 2.1 and if a lyx2lyx fix is desired that
>> can be worked on later. Any thoughts?
>>
>> Also note that the following thread is related:
>> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179740.html
>
>
> Manual fix is probably good, anyway. I will work on the lyx2lyx stuff once
> the semester is over.

Sounds good. I will try to do this later tonight.

Scott


Re: [LyX/master] CMake: allow compile-time C++ flags to be set

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 8:07 AM, Kornel Benko  wrote:

> BTW, we do not come very far compiling with -Werror.

True. But there are not too many of these. And I think the auto_ptr
warnings (now errors) only occur with -DLYX_ENABLE_CXX11

There are many more warnings using Clang.

It would be nice to someday have warnings-free code for Clang and GCC
so that we can easily detect when an important warning occurs.

Scott


Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Richard Heck

On 12/02/2013 05:56 PM, Kornel Benko wrote:


Am Montag, 2. Dezember 2013 um 17:21:13, schrieb Richard Heck 



> On 12/02/2013 03:45 PM, Kornel Benko wrote:

> >

> >

> > The first click in the float (inside 1.1.1) caused the crash.

> >

> > This file starts with chapter 1, so we are not at document start.

> >

>

> OK, so you can see what you're getting here: The contents displayed of

> the outliner, in reverse. What should have been next? 1.1?

Yes, should be "1.1 some text" and then "1 some other text".



OK.


> And yes, as you said in the other message, this shows that the

> TocIterator is invalid for some reason.

>

> Can you send me this document? I may be able to reproduce.

I don't dare. Besides that it has 9 lyx-files, about 30 images, it also is

the work of my son, not published yet.

But I can try to make a testcase.



OK. See what you can do.

You can send me the whole mess privately, if you wish. I won't care 
about the contents.



> If you close one of the open outliners, do you still get the crash?

I am unable to get the crash in this case.



OK, that suggests some kind of conflict. This is reminscent, in a way, 
of the static variable stuff previously.



> I wonder if there's not some kind of conflict between them. I.e., maybe

> the other one is trying to update itself, too.

With the _same_ iterator?



The vector itself could be over-written, in which case --it becomes 
invalid. How many "tableofcontents" TOCs do we have, is my question. 
I'll try to look into this tomorrow.


rh



Re: trunk: Style Chunk

2013-12-02 Thread Richard Heck

On 12/02/2013 06:39 PM, Scott Kostyshak wrote:

Attached is a patch that fixes Literate.lyx manually. I just replace
the problematic chunks with ERT. Is this OK for a fix for 2.1? It
seems it might save some time to just do this manual fix (and also for
noweb2lyx and listerrors) for 2.1 and if a lyx2lyx fix is desired that
can be worked on later. Any thoughts?

Also note that the following thread is related:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179740.html


Manual fix is probably good, anyway. I will work on the lyx2lyx stuff 
once the semester is over.


rh



Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Richard Heck

On 12/02/2013 07:19 PM, Scott Kostyshak wrote:

On Mon, Dec 2, 2013 at 6:44 PM, Kornel Benko  wrote:

Am Montag, 2. Dezember 2013 um 23:56:42, schrieb Kornel Benko



Am Montag, 2. Dezember 2013 um 17:21:13, schrieb Richard Heck


On 12/02/2013 03:45 PM, Kornel Benko wrote:

THIS IS SEVERE:

With the newest lyx, I am unable to open a new file (There is _no_ dialog)

(New from template dialog is still OK)

Using the previous version, that is before 'Return an error if file-open is
called with a non-absolute path'

is OK.

I can reproduce on Ubuntu. File > Open does not work (nothing seems to
happen, no dialog, no STDERR output). File > New From Template does
work.


This should be posted separately, not in this thread, and cc'd to Vincent.

rh



Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Scott Kostyshak
On Mon, Dec 2, 2013 at 6:44 PM, Kornel Benko  wrote:
> Am Montag, 2. Dezember 2013 um 23:56:42, schrieb Kornel Benko
> 
>
>> Am Montag, 2. Dezember 2013 um 17:21:13, schrieb Richard Heck
>> 
>
>> > On 12/02/2013 03:45 PM, Kornel Benko wrote:

> THIS IS SEVERE:
>
> With the newest lyx, I am unable to open a new file (There is _no_ dialog)
>
> (New from template dialog is still OK)
>
> Using the previous version, that is before 'Return an error if file-open is
> called with a non-absolute path'
>
> is OK.

I can reproduce on Ubuntu. File > Open does not work (nothing seems to
happen, no dialog, no STDERR output). File > New From Template does
work.

Scott


Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Kornel Benko
Am Montag, 2. Dezember 2013 um 23:56:42, schrieb Kornel Benko 
> Am Montag, 2. Dezember 2013 um 17:21:13, schrieb Richard Heck 
> > On 12/02/2013 03:45 PM, Kornel Benko wrote:
> > >
> 
> > >
> > > The first click in the float (inside 1.1.1) caused the crash.
> > >
> > > This file starts with chapter 1, so we are not at document start.
> > >
> > 
> > OK, so you can see what you're getting here: The contents displayed of 
> > the outliner, in reverse. What should have been next? 1.1?
> 
> Yes, should be "1.1 some text" and then "1 some other text".
> 
> > And yes, as you said in the other message, this shows that the 
> > TocIterator is invalid for some reason.
> > 
> > Can you send me this document? I may be able to reproduce.
> 
> I don't dare. Besides that it has 9 lyx-files, about 30 images, it also is
> the work of my son, not published yet.
> 
> But I can try to make a testcase.

This is not so easy. Looks, like the TOC should be bigger than in the testcase.

(I get the crash, but I have to click several times on the image,
 and the crash was 'Exception: std::bad_alloc')

> > If you close one of the open outliners, do you still get the crash?
> 
> I am unable to get the crash in this case.
> 
> > I 
> > wonder if there's not some kind of conflict between them. I.e., maybe 
> > the other one is trying to update itself, too.
> 
> With the _same_ iterator?
> 
> > Richard


THIS IS SEVERE:
With the newest lyx, I am unable to open a new file (There is _no_ dialog)
(New from template dialog is still OK)
Using the previous version, that is before 'Return an error if file-open is 
called with a non-absolute path'
is OK.


Kornel

signature.asc
Description: This is a digitally signed message part.


Re: trunk: Style Chunk

2013-12-02 Thread Scott Kostyshak
Attached is a patch that fixes Literate.lyx manually. I just replace
the problematic chunks with ERT. Is this OK for a fix for 2.1? It
seems it might save some time to just do this manual fix (and also for
noweb2lyx and listerrors) for 2.1 and if a lyx2lyx fix is desired that
can be worked on later. Any thoughts?

Also note that the following thread is related:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179740.html

Scott
From 2478e0d6f8e3bf471707f8c42b5739d1acbc9b5a Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Mon, 2 Dec 2013 18:30:00 -0500
Subject: [PATCH] Fix Literate.lyx

Some of the problematic chunks are not converted with lyx2lyx
so this commit manually converts them to ERT.
---
 lib/examples/Literate.lyx | 1285 +++--
 1 file changed, 773 insertions(+), 512 deletions(-)

diff --git a/lib/examples/Literate.lyx b/lib/examples/Literate.lyx
index bcf37a3..2d9bc3b 100644
--- a/lib/examples/Literate.lyx
+++ b/lib/examples/Literate.lyx
@@ -1,5 +1,5 @@
 #LyX 2.1 created this file. For more info see http://www.lyx.org/
-\lyxformat 448
+\lyxformat 474
 \begin_document
 \begin_header
 \textclass article
@@ -34,13 +34,16 @@ noweb
 \use_geometry false
 \use_package amsmath 0
 \use_package amssymb 0
+\use_package cancel 0
 \use_package esint 0
 \use_package mathdots 1
 \use_package mathtools 0
 \use_package mhchem 1
+\use_package stackrel 0
+\use_package stmaryrd 0
 \use_package undertilde 0
 \cite_engine basic
-\cite_engine_type numerical
+\cite_engine_type default
 \biblio_style plain
 \use_bibtopic false
 \use_indices false
@@ -172,132 +175,180 @@ The filter is required to read from standard input, 
parse for error messages
 Algorithm
 \end_layout
 
-\begin_layout Chunk
-<>=
+\begin_layout Standard
+\begin_inset Flex Chunk
+status open
+
+\begin_layout Plain Layout
+
+\begin_inset Argument 1
+status open
+
+\begin_layout Plain Layout
+Function bodies
 \end_layout
 
-\begin_layout Chunk
+\end_inset
+
 int
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 main (int argc, char **argv)
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 {
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   if (argc == 2) {
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 switch (argv[1][0]) {
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 case 'n':
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   <>
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   break;
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 case 'x':
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   <>
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   break;
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 case 'a':
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   <>
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   break;
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 case 's':
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 case 'b':
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   <>
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   break;
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 case 'g':
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 default:
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   <>
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   break;
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 }
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   } else {
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 <>
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
   }
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 }
 \end_layout
 
-\begin_layout Chunk
-@
+\end_inset
+
+
 \end_layout
 
-\begin_layout Chunk
-<>=
+\begin_layout Standard
+\begin_inset Flex Chunk
+status open
+
+\begin_layout Plain Layout
+
+\begin_inset Argument 1
+status open
+
+\begin_layout Plain Layout
+Function prototypes
 \end_layout
 
-\begin_layout Chunk
+\end_inset
+
 int main (int argc, char **argv);
 \end_layout
 
-\begin_layout Chunk
-@
+\end_inset
+
+
 \end_layout
 
 \begin_layout Section
@@ -311,28 +362,38 @@ We resort to some global variables to allow access from 
several different
  input.
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Standard
+\begin_inset ERT
+status open
+
+\begin_layout Plain Layout
+
 <>=
 \end_layout
 
-\begin_layout Chunk
+\begin_layout Plain Layout
+
 charbuffer[200][200];
-\begin_inset Newline newline
-\end_inset
+\end_layout
+
+\begin_layout Plain Layout
 
 int last_buf_line;
-\begin_inset Newline newline
-\end_inset
+\end_layou

Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Kornel Benko
Am Montag, 2. Dezember 2013 um 17:21:13, schrieb Richard Heck 
> On 12/02/2013 03:45 PM, Kornel Benko wrote:
> >

> >
> > The first click in the float (inside 1.1.1) caused the crash.
> >
> > This file starts with chapter 1, so we are not at document start.
> >
> 
> OK, so you can see what you're getting here: The contents displayed of 
> the outliner, in reverse. What should have been next? 1.1?

Yes, should be "1.1 some text" and then "1 some other text".

> And yes, as you said in the other message, this shows that the 
> TocIterator is invalid for some reason.
> 
> Can you send me this document? I may be able to reproduce.

I don't dare. Besides that it has 9 lyx-files, about 30 images, it also is
the work of my son, not published yet.

But I can try to make a testcase.

> If you close one of the open outliners, do you still get the crash?

I am unable to get the crash in this case.

> I 
> wonder if there's not some kind of conflict between them. I.e., maybe 
> the other one is trying to update itself, too.

With the _same_ iterator?

> Richard

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Richard Heck

On 12/02/2013 03:45 PM, Kornel Benko wrote:


> > Interesting may be also this:

> >

> > (gdb) p dit_text[0]

> >

> > $1 = (const lyx::CursorSlice &) @0x4395580: {

> >

> > inset_ = 0x2646fb0,

> >

> > idx_ = 0,

> >

> > pit_ = 9,

> >

> > pos_ = 0

> >

> > }

> >

> > (gdb) p it->dit_[0]

> >

> > Program received signal SIGSEGV, Segmentation fault.

> >

> > 0x00972a2a in std::vector > std::allocator >::operator[] (

> >

> > this=0x69001e, __n=0) at 
/usr/include/c++/4.6/bits/stl_vector.h:711


> >

> > 711 { return *(this->_M_impl._M_start + __n); }

> >

>

> OK, so it's it->dit_ that is problematic. Now "it" here is supposed to

> point at a TocItem listed in the currently visible Toc, and dit is

> supposed to be the location in the document at which that item points.

> So it really ought to have at least one CursorSlice. (We're in the

> process of looking for first TocItem that points at a location earlier

> in the document than the cursor currently is.)

>

> It might help to put a little debugging code right before the crash 
line


> and see how many times we are going through the loop before the crash,

> and thus which TocItem we're crashing on, e.g.:

Will do.

> + LYXERR0(it->str_);

> if (&it->dit_[0].inset() != &dit_text[0].inset())

> continue;

>

> Richard

This is the last part of the output (I changed the titles):

...

TocBackend.cpp (211): 1.2.1 

TocBackend.cpp (211): 1.2 xxxy

TocBackend.cpp (211): 1.1.4 xxxz

TocBackend.cpp (211): 1.1.3 xxyx

TocBackend.cpp (211): 1.1.2 xxyy

TocBackend.cpp (211): 1.1.1 xxyz bla bla

TocBackend.cpp (211):

Program received signal SIGSEGV, Segmentation fault.

0x7615cf80 in std::basic_stringstd::char_traits, std::allocator >::size() const


() from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

(gdb)

The first click in the float (inside 1.1.1) caused the crash.

This file starts with chapter 1, so we are not at document start.



OK, so you can see what you're getting here: The contents displayed of 
the outliner, in reverse. What should have been next? 1.1?


And yes, as you said in the other message, this shows that the 
TocIterator is invalid for some reason.


Can you send me this document? I may be able to reproduce.

If you close one of the open outliners, do you still get the crash? I 
wonder if there's not some kind of conflict between them. I.e., maybe 
the other one is trying to update itself, too.


Richard



Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Kornel Benko
Am Montag, 2. Dezember 2013 um 21:45:09, schrieb Kornel Benko 
> The first click in the float (inside 1.1.1) caused the crash.
> This file starts with chapter 1, so we are not at document start.
> 
> The backtrace is identical.

'it' seems to be totaly wrong.

(gdb) up
#1  0x0102fbcc in lyx::to_utf8 (ucs4=...) at 
/usr/src/lyx/lyx-git/src/support/docstring.cpp:102
102 vector const utf8 = ucs4_to_utf8(ucs4.data(), 
ucs4.size());
(gdb) up
#2  0x01017a12 in lyx::operator<< (l=..., t=...) at 
/usr/src/lyx/lyx-git/src/support/debug.cpp:251
251 { return toStream(l, to_utf8(t)); }
(gdb) up
#3  0x00a49110 in lyx::Toc::item (this=0x349e1b8, dit=...) at 
/usr/src/lyx/lyx-git/src/TocBackend.cpp:211
211 LYXERR0(it->str_);
(gdb) p it
$1 = {
  _M_current = 0xffde
}

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Kornel Benko
Am Montag, 2. Dezember 2013 um 15:16:45, schrieb Richard Heck 
> On 12/01/2013 08:49 AM, Kornel Benko wrote:
> >
> > Hi,
> >
> > ATM I get often crashes.
> >
> > Lyx editing in two windows (but different files).
> >
> > I try to position the cursor to the start of document.
> >
> > The first element there is floating image.
> >
> 
> A few questions: Do you have the outliner open in both documents?

Yes. TOC in both, from the main doc of both childs in the two windows.

> Are 
> you switching from one window to the other when you get the crash?

No, mouse movement (+ click) inside one window

> What 
> is the outliner displaying at the time you get the crash?

What do you mean? I did not see any update in the outliner.
Both outliner are visible.

> I'm thinking this could happen if the code got confused about which 
> outliner it was trying to refresh. Or maybe the outliner isn't properly 
> initialized.
> 
> > Interesting may be also this:
> >
> > (gdb) p dit_text[0]
> >
> > $1 = (const lyx::CursorSlice &) @0x4395580: {
> >
> > inset_ = 0x2646fb0,
> >
> > idx_ = 0,
> >
> > pit_ = 9,
> >
> > pos_ = 0
> >
> > }
> >
> > (gdb) p it->dit_[0]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> >
> > 0x00972a2a in std::vector > std::allocator >::operator[] (
> >
> > this=0x69001e, __n=0) at /usr/include/c++/4.6/bits/stl_vector.h:711
> >
> > 711 { return *(this->_M_impl._M_start + __n); }
> >
> 
> OK, so it's it->dit_ that is problematic. Now "it" here is supposed to 
> point at a TocItem listed in the currently visible Toc, and dit is 
> supposed to be the location in the document at which that item points. 
> So it really ought to have at least one CursorSlice. (We're in the 
> process of looking for first TocItem that points at a location earlier 
> in the document than the cursor currently is.)
> 
> It might help to put a little debugging code right before the crash line 
> and see how many times we are going through the loop before the crash, 
> and thus which TocItem we're crashing on, e.g.:

Will do.

> +   LYXERR0(it->str_);
>  if (&it->dit_[0].inset() != &dit_text[0].inset())
>  continue;
> 
> Richard

This is the last part of the output (I changed the titles):
...
TocBackend.cpp (211): 1.2.1 
TocBackend.cpp (211): 1.2 xxxy
TocBackend.cpp (211): 1.1.4 xxxz
TocBackend.cpp (211): 1.1.3 xxyx
TocBackend.cpp (211): 1.1.2 xxyy
TocBackend.cpp (211): 1.1.1 xxyz bla bla
TocBackend.cpp (211): 
Program received signal SIGSEGV, Segmentation fault.
0x7615cf80 in std::basic_string, 
std::allocator >::size() const
() from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) 

The first click in the float (inside 1.1.1) caused the crash.
This file starts with chapter 1, so we are not at document start.

The backtrace is identical.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Richard Heck

On 12/01/2013 08:49 AM, Kornel Benko wrote:


Hi,

ATM I get often crashes.

Lyx editing in two windows (but different files).

I try to position the cursor to the start of document.

The first element there is floating image.



A few questions: Do you have the outliner open in both documents? Are 
you switching from one window to the other when you get the crash? What 
is the outliner displaying at the time you get the crash?


I'm thinking this could happen if the code got confused about which 
outliner it was trying to refresh. Or maybe the outliner isn't properly 
initialized.



Interesting may be also this:

(gdb) p dit_text[0]

$1 = (const lyx::CursorSlice &) @0x4395580: {

inset_ = 0x2646fb0,

idx_ = 0,

pit_ = 9,

pos_ = 0

}

(gdb) p it->dit_[0]

Program received signal SIGSEGV, Segmentation fault.

0x00972a2a in std::vectorstd::allocator >::operator[] (


this=0x69001e, __n=0) at /usr/include/c++/4.6/bits/stl_vector.h:711

711 { return *(this->_M_impl._M_start + __n); }



OK, so it's it->dit_ that is problematic. Now "it" here is supposed to 
point at a TocItem listed in the currently visible Toc, and dit is 
supposed to be the location in the document at which that item points. 
So it really ought to have at least one CursorSlice. (We're in the 
process of looking for first TocItem that points at a location earlier 
in the document than the cursor currently is.)


It might help to put a little debugging code right before the crash line 
and see how many times we are going through the loop before the crash, 
and thus which TocItem we're crashing on, e.g.:


+   LYXERR0(it->str_);
if (&it->dit_[0].inset() != &dit_text[0].inset())
continue;

Richard



Re: Adv. f & r bugs in 2.1 beta2

2013-12-02 Thread Andrew Parsloe



On 3/12/2013 1:09 a.m., Liviu Andronic wrote:

On Sun, Dec 1, 2013 at 10:45 AM, Liviu Andronic  wrote:

On Sun, Dec 1, 2013 at 9:56 AM, Andrew Parsloe  wrote:

2.0.1 beta2, windows 7.

1. When an adv. f & r search reaches the end of the document & I respond
'yes' to searching from the beginning, all the toolbars etc vanish from
view. (See the attachment (but ignore the physics.) Clicking outside LyX
itself restores things. This doesn't happen in 2.0.6 on windows 7.


BTW, I can easily reproduce this on Linux with beta2 using the above
recipe. Could you file a bug report for this issue?

Liviu



#8909

Andrew


Re: [LyX/master] CMake: allow compile-time C++ flags to be set

2013-12-02 Thread Kornel Benko
Am Montag, 2. Dezember 2013 um 13:16:33, schrieb Vincent van Ravesteijn 

> On Mon, Dec 2, 2013 at 11:50 AM, Kornel Benko  wrote:
> 
> >  Am Montag, 2. Dezember 2013 um 09:00:30, schrieb Vincent van Ravesteijn <
> > v...@lyx.org>
> >
> > > On Sat, Nov 30, 2013 at 7:08 PM, Scott Kostyshak 
> > wrote:
> >
> > >
> >
> > > > commit 374cf6a39f321c7843b36aab242e0852b01887b8
> >
> > > > Author: Scott Kostyshak 
> >
> > > > Date: Fri Nov 29 21:08:48 2013 -0500
> >
> > > >
> >
> > > > CMake: allow compile-time C++ flags to be set
> >
> > > >
> >
> > > > For example, one could run CMake as follows:
> >
> > > > cmake -DLYX_CXX_FLAGS_EXTRA="-Werror"
> >
> > > >
> >
> > > > Thanks to Kornel.
> >
> > > >
> >
> > > > diff --git a/CMakeLists.txt b/CMakeLists.txt
> >
> > > > index c285dc0..c0fd673 100644
> >
> > > > --- a/CMakeLists.txt
> >
> > > > +++ b/CMakeLists.txt
> >
> > > > @@ -468,6 +468,10 @@ if(NOT MSVC)
> >
> > > > endif()
> >
> > > > endif()
> >
> > > >
> >
> > > > +if(LYX_CXX_FLAGS_EXTRA)
> >
> > > > + add_definitions(${LYX_CXX_FLAGS_EXTRA})
> >
> > > > +endif()
> >
> > > > +
> >
> > > > find_package(Qt5Core QUIET)
> >
> > > > if (Qt5Core_FOUND)
> >
> > > > find_package(Qt5Widgets REQUIRED)
> >
> > > >
> >
> > >
> >
> > > Does this work well in the CMake gui as well ?
> >
> >
> >
> > No, and it should not do. It is not a cache variable.
> >
> >
> >
> > > I would expect some line like set(LYX_CXX_FLAGS_EXTRA "" CACHE STRING
> >
> > > "Extra compiler flags")
> >
> >
> >
> > Please no. Why do you want it in the cache? In my understanding it is for
> > developer only,
> >
> > searching for some warnings.
> >
> >
> >
> > > Vincent
> >
> >
> >
> > Kornel
> >
> 
> Well, I'm using the CMake GUI, and I'm a developer. I wouldn't want to
> switch to the command line cmake just because of this one option.

Hmm, makes sense for me ...

> You can mark the option as advanced if you want... (IIRC).

We can mark the variable as advanced, yes. (It is not option (on/off) in cmake 
sense)

The attached patch works as you like.
To see the variable in the cmake-gui, you have to reconfigure twice.

BTW, we do not come very far compiling with -Werror.
...
cd /usr/BUILD/BuildLyxGit/boost/libs/signals && /usr/bin/c++-Wall 
-Wunused-parameter -std=gnu++0x -fno-strict-aliasing  -Wall -Wunused-parameter 
-std=gnu++0x -fno-strict-aliasing -O0 -g3 -D_DEBUG -I/usr/BUILD/BuildLyxGit 
-I/usr/src/lyx/lyx-git/src -I/usr/include/enchant -I/usr/src/lyx/lyx-git/boost  
  -Werror -DBOOST_USER_CONFIG="" -o 
CMakeFiles/boost_signals.dir/src/signal_base.cpp.o -c 
/usr/src/lyx/lyx-git/boost/libs/signals/src/signal_base.cpp
/usr/src/lyx/lyx-git/boost/libs/signals/src/signal_base.cpp: In static member 
function ‘static void 
boost::signals::detail::signal_base_impl::slot_disconnected(void*, void*)’:
/usr/src/lyx/lyx-git/boost/libs/signals/src/signal_base.cpp:136:37: error: 
‘auto_ptr’ is deprecated (declared at 
/usr/include/c++/4.6/backward/auto_ptr.h:87) [-Werror=deprecated-declarations]
cc1plus: all warnings being treated as errors
make[2]: *** 
[boost/libs/signals/CMakeFiles/boost_signals.dir/src/signal_base.cpp.o] Error 1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGit'
make[1]: *** [boost/libs/signals/CMakeFiles/boost_signals.dir/all] Error 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGit'
make: *** [all] Error 2
...

> Vincent

Korneldiff --git a/CMakeLists.txt b/CMakeLists.txt
index ccb4a6c..034c864 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -279,7 +279,8 @@ if (LYX_LOCALVERSIONING)
 	FIND_PROGRAM(LYX_GITVERSION git)
 	#message(STATUS "gitversion = ${LYX_GITVERSION}")
 	if(LYX_GITVERSION)
-		EXECUTE_PROCESS(COMMAND ${LYX_GITVERSION} "describe" WORKING_DIRECTORY "${TOP_SRC_DIR}" OUTPUT_VARIABLE LYX_PACKAGE_RELEASE OUTPUT_STRIP_TRAILING_WHITESPACE)
+		EXECUTE_PROCESS(COMMAND ${LYX_GITVERSION} describe --match 2.0.0 HEAD
+WORKING_DIRECTORY "${TOP_SRC_DIR}" OUTPUT_VARIABLE LYX_PACKAGE_RELEASE OUTPUT_STRIP_TRAILING_WHITESPACE)
 		if (LYX_PACKAGE_RELEASE MATCHES "^2\\.0\\.0\\-\([0-9]+\)\\-.*$")
 		  # We will add offset of 4 to get appropriate value to
 		  # previous svn.


signature.asc
Description: This is a digitally signed message part.


Re: [LyX/master] CMake: allow compile-time C++ flags to be set

2013-12-02 Thread Vincent van Ravesteijn
On Mon, Dec 2, 2013 at 11:50 AM, Kornel Benko  wrote:

>  Am Montag, 2. Dezember 2013 um 09:00:30, schrieb Vincent van Ravesteijn <
> v...@lyx.org>
>
> > On Sat, Nov 30, 2013 at 7:08 PM, Scott Kostyshak 
> wrote:
>
> >
>
> > > commit 374cf6a39f321c7843b36aab242e0852b01887b8
>
> > > Author: Scott Kostyshak 
>
> > > Date: Fri Nov 29 21:08:48 2013 -0500
>
> > >
>
> > > CMake: allow compile-time C++ flags to be set
>
> > >
>
> > > For example, one could run CMake as follows:
>
> > > cmake -DLYX_CXX_FLAGS_EXTRA="-Werror"
>
> > >
>
> > > Thanks to Kornel.
>
> > >
>
> > > diff --git a/CMakeLists.txt b/CMakeLists.txt
>
> > > index c285dc0..c0fd673 100644
>
> > > --- a/CMakeLists.txt
>
> > > +++ b/CMakeLists.txt
>
> > > @@ -468,6 +468,10 @@ if(NOT MSVC)
>
> > > endif()
>
> > > endif()
>
> > >
>
> > > +if(LYX_CXX_FLAGS_EXTRA)
>
> > > + add_definitions(${LYX_CXX_FLAGS_EXTRA})
>
> > > +endif()
>
> > > +
>
> > > find_package(Qt5Core QUIET)
>
> > > if (Qt5Core_FOUND)
>
> > > find_package(Qt5Widgets REQUIRED)
>
> > >
>
> >
>
> > Does this work well in the CMake gui as well ?
>
>
>
> No, and it should not do. It is not a cache variable.
>
>
>
> > I would expect some line like set(LYX_CXX_FLAGS_EXTRA "" CACHE STRING
>
> > "Extra compiler flags")
>
>
>
> Please no. Why do you want it in the cache? In my understanding it is for
> developer only,
>
> searching for some warnings.
>
>
>
> > Vincent
>
>
>
> Kornel
>

Well, I'm using the CMake GUI, and I'm a developer. I wouldn't want to
switch to the command line cmake just because of this one option.

You can mark the option as advanced if you want... (IIRC).

Vincent


Re: Adv. f & r bugs in 2.1 beta2

2013-12-02 Thread Liviu Andronic
On Sun, Dec 1, 2013 at 10:45 AM, Liviu Andronic  wrote:
> On Sun, Dec 1, 2013 at 9:56 AM, Andrew Parsloe  wrote:
>> 2.0.1 beta2, windows 7.
>>
>> 1. When an adv. f & r search reaches the end of the document & I respond
>> 'yes' to searching from the beginning, all the toolbars etc vanish from
>> view. (See the attachment (but ignore the physics.) Clicking outside LyX
>> itself restores things. This doesn't happen in 2.0.6 on windows 7.
>>
BTW, I can easily reproduce this on Linux with beta2 using the above
recipe. Could you file a bug report for this issue?

Liviu


> I'm wondering if this isn't a symptom, as on Linux I often encountered
> such UI artifacts in different usage contexts (with 2.0.x). Here I had
> a _visual_ disappearance of the toolbar buttons; I say visual since if
> I hovered the mouse on top of the buttons then they would re-appear,
> and hitting any button would work. It's a bit different from what
> Andrew is reporting, but this behaviour is eerily familiar to me.
>
> Liviu
>
>
>> 2. If the Source Pane is detached from the main LyX gui, then the same
>> recipe causes its content to freeze. Clicking in different paragraphs in the
>> main LyX work area doesn't change the content of the Source Pane. If the
>> Source Pane is docked at the bottom of the main LyX window, this doesn't
>> happen (nor in 2.0.6).
>>
>> Andrew
>>
>
>
>
> --
> Do you know how to read?
> http://www.alienetworks.com/srtest.cfm
> http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
> Do you know how to write?
> http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail


Re: Closing LyX Version 2.1.0beta2,(10 November 2013)

2013-12-02 Thread Liviu Andronic
On Mon, Dec 2, 2013 at 12:20 PM, Mike  wrote:
> However, trying out the find/replace advanced settings now causes Lyx to 
> stall, resulting in a blank work-area in Lyx, then choosing 'force quit',
>
Isn't this related to Andrew's recent report on UI freezes coming from
Advanced F&R (on Windows)?

Liviu



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail


Re: Closing LyX Version 2.1.0beta2,(10 November 2013)

2013-12-02 Thread Mike
Using the menu 
system I close all, then quit Lyx.
Using command+q Lyx has not crashed once through 3 attempts to reproduce
 the crash.
Loaded two files (master + child); tried a further 3 times to reproduce 
the crash; there was no crash this morning.
However, trying out the find/replace advanced settings now causes Lyx to
 stall, resulting in a blank work-area in Lyx, then choosing 'force 
quit', on close Lyx throws up a dialog box asking me if I want to create
 a new document! Then, choosing no, it closes normally with no crash 
report.
Mike 


   	   
   	Stephan Witt  
  2 December 2013 
11:02
  I'm not aware 
of any changes, except the unicode/iconv handling.There are two 
bugs on LyX trac filed: http://www.lyx.org/trac/ticket/8637http://www.lyx.org/trac/ticket/8287These
 issues are not consistently reproducible. Therefor I'm not sure if 
the crash is not happen with beta1.@Mike: What are you 
referring to with "using the menu system to close it down" exactly?Does
 this mean it doesn't crash when exiting with Command-q?Stephan
   	   
   	Vincent van Ravesteijn  
  2 December 2013 
08:26
  Mike responded privately to say that this 
didn't happen with beta1.  Stephan ? Any idea ? 
Does this involve mime types ? Did something change in this area 
lately ? Vincent

  
   	   
   	Vincent van Ravesteijn  
  2 December 2013 
07:42
  
I am using LyX Version 2.1.0beta2 (10 November 2013) on an Apple Macbook
 Pro: Processor  2.4 GHz Intel Core 2 Duo; Memory  4 GB 1067 MHz DDR3. 
On closing the programme using the menu system to close it down, the 
following dialog window appears: 

SIGSEGV
 signal caught! A problem report generated by the Macbook Pro is 
attached.
Regards,
Mike Does this happen with
 beta1 as well ? Vincent 

  
   	   
   	Mike  
  1 December 2013 
19:23
  

I am using LyX Version 2.1.0beta2 (10 November 2013) on an Apple Macbook
 Pro: Processor  2.4 GHz Intel Core 2 Duo; Memory  4 GB 1067 MHz DDR3. 
On closing the programme using the menu system to close it down, the 
following dialog window appears: 

SIGSEGV

 signal caught! A problem report generated by the Macbook Pro is 
attached.
Regards,
Mike

 


 
  




Re: Closing LyX Version 2.1.0beta2,(10 November 2013)

2013-12-02 Thread Stephan Witt

Am 02.12.2013 um 09:26 schrieb Vincent van Ravesteijn :

> 
> 
> On Sun, Dec 1, 2013 at 8:23 PM, Mike  wrote:
> I am using LyX Version 2.1.0beta2 (10 November 2013) on an Apple Macbook Pro: 
> Processor  2.4 GHz Intel Core 2 Duo; Memory  4 GB 1067 MHz DDR3. On closing 
> the programme using the menu system to close it down, the following dialog 
> window appears: 
> SIGSEGV signal caught! A problem report generated by the Macbook Pro is 
> attached.
> Regards,
> Mike
>  
> Does this happen with beta1 as well ?
>  
> Vincent 
> 
> Mike responded privately to say that this didn't happen with beta1.
>  
> Stephan ? Any idea ?
>  
> Does this involve mime types ? Did something change in this area lately ?

I'm not aware of any changes, except the unicode/iconv handling.

There are two bugs on LyX trac filed:
 
http://www.lyx.org/trac/ticket/8637
http://www.lyx.org/trac/ticket/8287

These issues are not consistently reproducible. 
Therefor I'm not sure if the crash is not happen with beta1.

@Mike: 
What are you referring to with "using the menu system to close it down" exactly?
Does this mean it doesn't crash when exiting with Command-q?

Stephan

Re: [LyX/master] CMake: allow compile-time C++ flags to be set

2013-12-02 Thread Kornel Benko
Am Montag, 2. Dezember 2013 um 09:00:30, schrieb Vincent van Ravesteijn 

> On Sat, Nov 30, 2013 at 7:08 PM, Scott Kostyshak  wrote:
> 
> > commit 374cf6a39f321c7843b36aab242e0852b01887b8
> > Author: Scott Kostyshak 
> > Date:   Fri Nov 29 21:08:48 2013 -0500
> >
> > CMake: allow compile-time C++ flags to be set
> >
> > For example, one could run CMake as follows:
> >   cmake -DLYX_CXX_FLAGS_EXTRA="-Werror"
> >
> > Thanks to Kornel.
> >
> > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > index c285dc0..c0fd673 100644
> > --- a/CMakeLists.txt
> > +++ b/CMakeLists.txt
> > @@ -468,6 +468,10 @@ if(NOT MSVC)
> > endif()
> >  endif()
> >
> > +if(LYX_CXX_FLAGS_EXTRA)
> > +   add_definitions(${LYX_CXX_FLAGS_EXTRA})
> > +endif()
> > +
> >  find_package(Qt5Core QUIET)
> >  if (Qt5Core_FOUND)
> > find_package(Qt5Widgets REQUIRED)
> >
> 
> Does this work well in the CMake gui as well ?

No, and it should not do. It is not a cache variable.

> I would expect some line like set(LYX_CXX_FLAGS_EXTRA "" CACHE STRING
> "Extra compiler flags")

Please no. Why do you want it in the cache? In my understanding it is for 
developer only,
searching for some warnings.

> Vincent

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: trunk: Crash on cursor positioning with mouse

2013-12-02 Thread Kornel Benko
Am Sonntag, 1. Dezember 2013 um 22:36:17, schrieb Scott Kostyshak 

> On Sun, Dec 1, 2013 at 8:49 AM, Kornel Benko  wrote:
> > Hi,
> >
> > ATM I get often crashes.
> >
> >
> >
> > Lyx editing in two windows (but different files).
> 
> Different instances of LyX or same instance? If same instance, how do
> you get the other window? From File > New Window or do you have Tools
> > preferences > Look & Feel > Document Handling > "Open documents in
> tabs" unchecked?

Same instance. File > New Window.
And it looks like it happens if the cpu's are busy otherwise.
At least I did not see it, if lyx is running alone.

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: Closing LyX Version 2.1.0beta2,(10 November 2013)

2013-12-02 Thread Vincent van Ravesteijn
>
> On Sun, Dec 1, 2013 at 8:23 PM, Mike  wrote:
>
>>  I am using LyX Version 2.1.0beta2 (10 November 2013) on an Apple Macbook
>> Pro: Processor  2.4 GHz Intel Core 2 Duo; Memory  4 GB 1067 MHz DDR3. On
>> closing the programme using the menu system to close it down, the following
>> dialog window appears:
>>
>> SIGSEGV signal caught! A problem report generated by the Macbook Pro is
>> attached.
>> Regards,
>> Mike
>>
>
> Does this happen with beta1 as well ?
>
> Vincent
>

Mike responded privately to say that this didn't happen with beta1.

Stephan ? Any idea ?

Does this involve mime types ? Did something change in this area lately ?

Vincent


Re: [LyX/master] Also when not using tabs, do not open a file twice if already opened (part of #8787)

2013-12-02 Thread Vincent van Ravesteijn
On Tue, Nov 26, 2013 at 4:16 PM, Juergen Spitzmueller  wrote:

> commit 766e8b1e3319c75bebb9811af6dc3df97d9a0119
> Author: Juergen Spitzmueller 
> Date:   Tue Nov 26 16:12:52 2013 +0100
>
> Also when not using tabs, do not open a file twice if already opened
> (part of #8787)
>
> diff --git a/src/frontends/qt4/GuiApplication.cpp
> b/src/frontends/qt4/GuiApplication.cpp
> index 53fb170..6fd3eb4 100644
> --- a/src/frontends/qt4/GuiApplication.cpp
> +++ b/src/frontends/qt4/GuiApplication.cpp
> @@ -1572,8 +1572,10 @@ void GuiApplication::dispatch(FuncRequest const &
> cmd, DispatchResult & dr)
> validateCurrentView();
> // FIXME: create a new method shared with LFUN_HELP_OPEN.
> string const fname = to_utf8(cmd.argument());
> -   if (d->views_.empty() || (!lyxrc.open_buffers_in_tabs
> - && current_view_->documentBufferView() != 0)) {
> +   if (d->views_.empty()
> +   || (!lyxrc.open_buffers_in_tabs
> +   && current_view_->documentBufferView() != 0
> +   && !theBufferList().getBuffer(FileName(fname {
> // We want the ui session to be saved per document
> and not per
> // window number. The filename crc is a good
> enough identifier.
> boost::crc_32_type crc;
>

We shouldn't use FileName(fname), when fname is given by the user.

By design, FileName should only take absolute paths and it should assert if
the given path isn't absolute. See the assert in
FileName::FileName(string)  Unfortunately, I happen to commit something a
long time ago that somehow prepended the current_dir instead of asserting
(see FileName::Private::Private(string)).

If we revert this behaviour back to asserting, this code will likely to
assert when the user uses this code.

Vincent


Re: [LyX/master] CMake: allow compile-time C++ flags to be set

2013-12-02 Thread Vincent van Ravesteijn
On Sat, Nov 30, 2013 at 7:08 PM, Scott Kostyshak  wrote:

> commit 374cf6a39f321c7843b36aab242e0852b01887b8
> Author: Scott Kostyshak 
> Date:   Fri Nov 29 21:08:48 2013 -0500
>
> CMake: allow compile-time C++ flags to be set
>
> For example, one could run CMake as follows:
>   cmake -DLYX_CXX_FLAGS_EXTRA="-Werror"
>
> Thanks to Kornel.
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index c285dc0..c0fd673 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -468,6 +468,10 @@ if(NOT MSVC)
> endif()
>  endif()
>
> +if(LYX_CXX_FLAGS_EXTRA)
> +   add_definitions(${LYX_CXX_FLAGS_EXTRA})
> +endif()
> +
>  find_package(Qt5Core QUIET)
>  if (Qt5Core_FOUND)
> find_package(Qt5Widgets REQUIRED)
>

Does this work well in the CMake gui as well ?

I would expect some line like set(LYX_CXX_FLAGS_EXTRA "" CACHE STRING
"Extra compiler flags")

Vincent