Small conversion issue with beamer

[Pietro Cortese]

Hello,

I have found a small conversion issue from lyx 2.0 to 2.1.
In 2.0 one could define blocks and, for what I could tell, the block 
title was to be specified with ERT.


In 2.1 one can insert the block title and the ERT text is now 
interpreted as part of the block.


You can find in attachment the same document compiled with lyx 2.0 and 
lyx 2.1.


I wrote a small awk script to correct the problem.

Best regards,
Pietro


beamer-test.lyx
Description: application/lyx


beamer-test-2.0.pdf
Description: Adobe PDF document


beamer-test-2.1.pdf
Description: Adobe PDF document


convert.awk
Description: application/awk

Re: Clear RELEASE-NOTES on master?

[Stephan Witt]

Am 21.11.2014 um 23:37 schrieb Scott Kostyshak skost...@lyx.org:

 On Fri, Nov 21, 2014 at 12:28 PM, Stephan Witt st.w...@gmx.net wrote:
 Am 20.11.2014 um 09:10 schrieb Scott Kostyshak skost...@lyx.org:
 
 On Tue, Nov 18, 2014 at 3:05 AM, Jean-Marc Lasgouttes
 lasgout...@lyx.org wrote:
 Le 18/11/14 02:14, Scott Kostyshak a écrit :
 
 The RELEASE-NOTES on master is for 2.1.0. Should it be cleaned so we
 can add 2.2.0 stuff or is this done somewhere else that I forgot? I
 can do the work but I wanted to check in first.
 
 
 Sure.
 
 Done at ef71f667.
 
 Scott, the comment about Qt5 should be changed, at least for Mac OS X.
 
 I've attached a proposal.
 
 I'm not sure what the state for Linux is.
 
 Thanks, Stephan.
 
 We should put a link to the Qt 5 mega bug issue in RELEASE-NOTES (as
 long as there is at least one open bug at the time of release):
 http://www.lyx.org/trac/ticket/9215
 Feel free to do that in your patch. Otherwise I will do it.
 
 Do you see the following issue with Qt 5 on Mac OS X?
 http://www.lyx.org/trac/ticket/9223
 I would not be surprised if that is specific to Linux but I would
 appreciate it if you could check. To check, download the document
 attached there and select character-by-character (either on keyboard
 or slowly with mouse) from left to right and then also try right to
 left. Do you see a blank part anywhere? Often for me it appears _not_
 in the part I am selecting.

Hmm… probably the issue is on Mac too. 
But I cannot tell what the expected behavior is.
I've attached two snapshots how it looks here.
The second one demonstrates a bad clipping effect of the
selected text (the lower dots are not drawn completely).

 Does the following bug affect Mac?
 http://www.lyx.org/trac/ticket/9218
 To test, in LyX start an ERT and press Tab and then press Backspace.
 Are you left with an empty ERT? If you are left with a empty ERT then
 you do not have the bug. I am left with an ERT containing a tab
 (because the tab was duplicated).

This bug is present on Mac too. One Tab press results in three Tabs here.

I went to https://bugreports.qt-project.org/browse/QTBUG-38986 and there
the three Tab effect is mentioned too. The state of the bug is FIXED for 
Qt 5.5.0. That's really late :(

Stephan

 For Windows, do we still see the bug that showed up for shortcuts with
 4.8.5 or was it fixed in 4.8.6? If it was fixed, should we recommend
 4.8.6 instead of 4.8.4?
 
 As for Linux, I've been using Qt 5 for a long time with only very
 minor issues (like selecting with Urdu).
 
 Scott

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 22/11/2014 23:01, Richard Heck wrote:

On 11/22/2014 03:19 AM, Abdelrazak Younes wrote:

On 20/11/2014 21:04, Georg Baum wrote:

I don't think so in this case. The crash happens because internal
std::basic_string members are corrupt, and it is almost always a string
created from Language::babel_. Furthermore, I was not able to 
reproduce the

crash after changing

std::string const  babel() const { return babel_; }

to

std::string const babel() const { return babel_.c_str(); }

in Language.h (which circumvents copy-on-write).


Hum, well, maybe Language object is shared between the buffer clones? 


In BufferParams.h:
///
Language const * language;


Ahah...



That could well explain the issue... babel_ is accessed at the same 
time between 2 threads which creates a race condition.


So my solution would be to protect the Language object through a mutex.

If I am right then this crash is due to a flow in our design, not in 
the STL string.


I'm not as well informed as you and others about these sorts of 
issues. Why would
simply having two threads reading the babel_ string at the same time 
cause this sort
of problem? We shouldn't have write access to the language object from 
the Buffer.


This string might be modified by some class in main thread while being 
read at the same time by a buffer clone in the export thread. If the 
memory reserved by basic-string is big enough we should be fine but if 
not basic_string will allocate another chunk of memory and delete 
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor 
(basic_string::reserve() should exist).

2) protect babel_ with a mutex.

In any case, one should audit this Language class for thread safety. 
Same thing for BufferParams if this is shared between buffers.


Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Jean-Marc Lasgouttes]

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const as 
can be.


JMarc

Re: Clear RELEASE-NOTES on master?

[Scott Kostyshak]

On Sun, Nov 23, 2014 at 11:28 AM, Stephan Witt st.w...@gmx.net wrote:


 Do you see the following issue with Qt 5 on Mac OS X?
 http://www.lyx.org/trac/ticket/9223
 I would not be surprised if that is specific to Linux but I would
 appreciate it if you could check. To check, download the document
 attached there and select character-by-character (either on keyboard
 or slowly with mouse) from left to right and then also try right to
 left. Do you see a blank part anywhere? Often for me it appears _not_
 in the part I am selecting.


 Hmm… probably the issue is on Mac too. But I cannot tell what the expected
 behavior is.
 I've attached two snapshots how it looks here.
 The second one demonstrates a bad clipping effect of the
 selected text (the lower dots are not drawn completely).


Yes I see what you mean. I put that you can reproduce on the ticket.



 Does the following bug affect Mac?
 http://www.lyx.org/trac/ticket/9218
 To test, in LyX start an ERT and press Tab and then press Backspace.
 Are you left with an empty ERT? If you are left with a empty ERT then
 you do not have the bug. I am left with an ERT containing a tab
 (because the tab was duplicated).


 This bug is present on Mac too. One Tab press results in three Tabs here.

 I went to https://bugreports.qt-project.org/browse/QTBUG-38986 and there
 the three Tab effect is mentioned too. The state of the bug is FIXED for
 Qt 5.5.0. That's really late :(


That is indeed late. Thanks for testing. I put your comments on the ticket.

Scott

Re: Thread problems with std::basic_string and GNU libstdc++

[Richard Heck]

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.

rh

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 23/11/2014 22:21, Richard Heck wrote:

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.


Then there is a good chance that Georg is fully right... But I still 
feel there's some other reason...


Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Richard Heck]

On 11/23/2014 05:57 PM, Abdelrazak Younes wrote:

On 23/11/2014 22:21, Richard Heck wrote:

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.


Then there is a good chance that Georg is fully right... But I still 
feel there's some other reason...


Can you explain in language I can understand why simply /reading/ this 
variable

in separate threads could cause this kind of problem? I'm very confused.

Richard

Small conversion issue with beamer

[Pietro Cortese]

Hello,

I have found a small conversion issue from lyx 2.0 to 2.1.
In 2.0 one could define blocks and, for what I could tell, the block 
title was to be specified with ERT.


In 2.1 one can insert the block title and the ERT text is now 
interpreted as part of the block.


You can find in attachment the same document compiled with lyx 2.0 and 
lyx 2.1.


I wrote a small awk script to correct the problem.

Best regards,
Pietro


beamer-test.lyx
Description: application/lyx


beamer-test-2.0.pdf
Description: Adobe PDF document


beamer-test-2.1.pdf
Description: Adobe PDF document


convert.awk
Description: application/awk

Re: Clear RELEASE-NOTES on master?

[Stephan Witt]

Am 21.11.2014 um 23:37 schrieb Scott Kostyshak :

> On Fri, Nov 21, 2014 at 12:28 PM, Stephan Witt  wrote:
>> Am 20.11.2014 um 09:10 schrieb Scott Kostyshak :
>> 
>>> On Tue, Nov 18, 2014 at 3:05 AM, Jean-Marc Lasgouttes
>>>  wrote:
 Le 18/11/14 02:14, Scott Kostyshak a écrit :
> 
> The RELEASE-NOTES on master is for 2.1.0. Should it be cleaned so we
> can add 2.2.0 stuff or is this done somewhere else that I forgot? I
> can do the work but I wanted to check in first.
 
 
 Sure.
>>> 
>>> Done at ef71f667.
>> 
>> Scott, the comment about Qt5 should be changed, at least for Mac OS X.
>> 
>> I've attached a proposal.
>> 
>> I'm not sure what the state for Linux is.
> 
> Thanks, Stephan.
> 
> We should put a link to the Qt 5 mega bug issue in RELEASE-NOTES (as
> long as there is at least one open bug at the time of release):
> http://www.lyx.org/trac/ticket/9215
> Feel free to do that in your patch. Otherwise I will do it.
> 
> Do you see the following issue with Qt 5 on Mac OS X?
> http://www.lyx.org/trac/ticket/9223
> I would not be surprised if that is specific to Linux but I would
> appreciate it if you could check. To check, download the document
> attached there and select character-by-character (either on keyboard
> or slowly with mouse) from left to right and then also try right to
> left. Do you see a blank part anywhere? Often for me it appears _not_
> in the part I am selecting.

Hmm… probably the issue is on Mac too. 
But I cannot tell what the expected behavior is.
I've attached two snapshots how it looks here.
The second one demonstrates a bad clipping effect of the
selected text (the lower "dots" are not drawn completely).

> Does the following bug affect Mac?
> http://www.lyx.org/trac/ticket/9218
> To test, in LyX start an ERT and press Tab and then press Backspace.
> Are you left with an empty ERT? If you are left with a empty ERT then
> you do not have the bug. I am left with an ERT containing a tab
> (because the tab was duplicated).

This bug is present on Mac too. One Tab press results in three Tabs here.

I went to https://bugreports.qt-project.org/browse/QTBUG-38986 and there
the three Tab effect is mentioned too. The state of the bug is FIXED for 
Qt 5.5.0. That's really late :(

Stephan

> For Windows, do we still see the bug that showed up for shortcuts with
> 4.8.5 or was it fixed in 4.8.6? If it was fixed, should we recommend
> 4.8.6 instead of 4.8.4?
> 
> As for Linux, I've been using Qt 5 for a long time with only very
> minor issues (like selecting with Urdu).
> 
> Scott

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 22/11/2014 23:01, Richard Heck wrote:

On 11/22/2014 03:19 AM, Abdelrazak Younes wrote:

On 20/11/2014 21:04, Georg Baum wrote:

I don't think so in this case. The crash happens because internal
std::basic_string members are corrupt, and it is almost always a string
created from Language::babel_. Furthermore, I was not able to 
reproduce the

crash after changing

std::string const & babel() const { return babel_; }

to

std::string const babel() const { return babel_.c_str(); }

in Language.h (which circumvents copy-on-write).


Hum, well, maybe Language object is shared between the buffer clones? 


In BufferParams.h:
///
Language const * language;


Ahah...



That could well explain the issue... babel_ is accessed at the same 
time between 2 threads which creates a race condition.


So my solution would be to protect the Language object through a mutex.

If I am right then this crash is due to a flow in our design, not in 
the STL string.


I'm not as well informed as you and others about these sorts of 
issues. Why would
simply having two threads reading the babel_ string at the same time 
cause this sort
of problem? We shouldn't have write access to the language object from 
the Buffer.


This string might be modified by some class in main thread while being 
read at the same time by a buffer clone in the export thread. If the 
memory reserved by basic-string is big enough we should be fine but if 
not basic_string will allocate another chunk of memory and delete 
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor 
(basic_string::reserve() should exist).

2) protect babel_ with a mutex.

In any case, one should audit this Language class for thread safety. 
Same thing for BufferParams if this is shared between buffers.


Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Jean-Marc Lasgouttes]

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const as 
can be.


JMarc

Re: Clear RELEASE-NOTES on master?

[Scott Kostyshak]

On Sun, Nov 23, 2014 at 11:28 AM, Stephan Witt  wrote:


> Do you see the following issue with Qt 5 on Mac OS X?
> http://www.lyx.org/trac/ticket/9223
> I would not be surprised if that is specific to Linux but I would
> appreciate it if you could check. To check, download the document
> attached there and select character-by-character (either on keyboard
> or slowly with mouse) from left to right and then also try right to
> left. Do you see a blank part anywhere? Often for me it appears _not_
> in the part I am selecting.
>
>
> Hmm… probably the issue is on Mac too. But I cannot tell what the expected
> behavior is.
> I've attached two snapshots how it looks here.
> The second one demonstrates a bad clipping effect of the
> selected text (the lower "dots" are not drawn completely).
>

Yes I see what you mean. I put that you can reproduce on the ticket.


>
> Does the following bug affect Mac?
> http://www.lyx.org/trac/ticket/9218
> To test, in LyX start an ERT and press Tab and then press Backspace.
> Are you left with an empty ERT? If you are left with a empty ERT then
> you do not have the bug. I am left with an ERT containing a tab
> (because the tab was duplicated).
>
>
> This bug is present on Mac too. One Tab press results in three Tabs here.
>
> I went to https://bugreports.qt-project.org/browse/QTBUG-38986 and there
> the three Tab effect is mentioned too. The state of the bug is FIXED for
> Qt 5.5.0. That's really late :(
>

That is indeed late. Thanks for testing. I put your comments on the ticket.

Scott

Re: Thread problems with std::basic_string and GNU libstdc++

[Richard Heck]

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.

rh

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 23/11/2014 22:21, Richard Heck wrote:

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.


Then there is a good chance that Georg is fully right... But I still 
feel there's some other reason...


Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Richard Heck]

On 11/23/2014 05:57 PM, Abdelrazak Younes wrote:

On 23/11/2014 22:21, Richard Heck wrote:

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.


Then there is a good chance that Georg is fully right... But I still 
feel there's some other reason...


Can you explain in language I can understand why simply /reading/ this 
variable

in separate threads could cause this kind of problem? I'm very confused.

Richard