Re: Ubuntu Trusty testers needed

[Benedict Holland]

Right. I deeply question that logic though. The fact that a corrupted save
bug was fixed is sort of a game changer from a usability perspective. I
mean, if it wasn't well known, well documented, or fixed, I might say that
it makes sense but as it stands, releasing code that has a known
catastrophic or critical or severe bug that was later fixed seems like it
will just cause far more problems in the future, especially on systems that
don't take updates.

Again, I wouldn't find this a problem except in this fairly rare case
particularly when the first thing to do is make sure that the software used
is up to date when it comes to fixing problems.

I suppose, that said, I don't mind testing lyx on various systems but the
2.0.8 branch is old and is in release for what, at least a year? What
additional testing, apart from that, is required? Is there a spec sheet for
various usability tests that should be performed or is it just ad-hoc
testing and report bugs to the channel?

~Ben

On Thu, Jul 2, 2015 at 6:28 PM, Richard Heck rgh...@lyx.org wrote:

 On 07/02/2015 03:24 PM, Benedict Holland wrote:

 Just curious, why are we testing old versions of an application with
 known catastrophic bugs? Wasn't the uncorrupted save feature implemented in
 the 2.1 branch? Also, I have been using the 2.1.3 exclusively for a long
 time and I admit that I am a power user. It is stable as anything I use and
 when combined with LuaTex, it produces beamer presentations and pdf
 documents that are absolutely stunning. This includes images. XeLatex had
 problems for me when importing PDF images but LuaTex does it far better.
 None of this has to do with Lyx though. Lyx is performing beautifully and I
 am using it to the fullest extent possible.

 The ONLY thing I have a gripe about is the lack of biblatex and biber
 support. I get it, but I wish that it was there.


 The testing here, I take it, is just to make sure that 2.0.8.1 works as
 expected on Ubuntu 14.04, which is still live (and widely used) and whose
 policies prohibit an upgrade to 2.1.x. Despite all the bugfixes.

 Richard

Re: [Patch] Two lyxpak bugs

[Guy Rutenberg]

Hi,

On Fri, Jul 3, 2015 at 3:53 PM, Enrico Forestieri for...@lyx.org wrote:

 Your patch still does not work on Windows. It may work when files have
 names encodable in the current code page, otherwise it fails.
 Note that NTFS uses UTF-16 even if python returns msbc as the filesystem
 encoding. Instead, the attached patch works for me on any platform I have
 access to. I think it also solves your problem even if in a different way.


This works great on Linux.

Thanks,

Guy

Re: Ubuntu Trusty testers needed

[Richard Heck]

On 07/04/2015 04:09 PM, Benedict Holland wrote:
Right. I deeply question that logic though. The fact that a corrupted 
save bug was fixed is sort of a game changer from a usability 
perspective. I mean, if it wasn't well known, well documented, or 
fixed, I might say that it makes sense but as it stands, releasing 
code that has a known catastrophic or critical or severe bug that was 
later fixed seems like it will just cause far more problems in the 
future, especially on systems that don't take updates.


Yes, but this is not our decision. It's an Ubuntu policy. It makes a lot 
more sense with libraries, really, but it's part of why I personally 
don't use Ubuntu LTS.


Note that the problem that triggered the corrupted save bug has been 
fixed in 2.0.8.1.


I suppose, that said, I don't mind testing lyx on various systems but 
the 2.0.8 branch is old and is in release for what, at least a year? 
What additional testing, apart from that, is required? Is there a spec 
sheet for various usability tests that should be performed or is it 
just ad-hoc testing and report bugs to the channel?


I'm not the best person to answer this, but I think all that's needed is 
to try it out pretty quickly. Since other packages haven't been 
seriously updated on Trusty either (e.g., Qt), one wouldn't expect there 
to be any issue.


Richard

Re: assert in CursorSlice.cpp

[Guillaume M-M]

Le 30/06/2015 19:20, Enrico Forestieri a écrit :

On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote:

Dear list,


I got an assertion in stable (1b596e92) for the second time today. It
happened while selecting text (first time with Shift+Arrows and second time
with the mouse).

I don't remember seeing it before: if it wasn't introduced recently then
maybe it was hidden by the fact that I did not use instant preview before. I
cannot think of anything particular in my settings apart from instant
preview on, only one document displayed.

I opened gdb after the first crash just in case. I don't know how to
reproduce it, the second crash happened when I was no longer paying
attention. I am keeping my gdb session open for a while if you would like me
to extract more relevant informations than the trace below, just ask.


Messages:

CursorSlice.cpp (207): can't compare cursor and anchor in different insets
p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558
q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079
lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check false in file lassert.cpp:44


The interesting thread seems to be Thread 4 but it was truncated too early.


Thread 4 (Thread 0x7fffde979700 (LWP 27221)):
#0  0x759e6267 in __GI_raise (sig=sig@entry=6)
 at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x759e7eca in __GI_abort () at abort.c:89
#2  0x0059418d in ?? ()
#3  0x04df8db0 in ?? ()
#4  0x005139a1 in ?? ()
#5  0x0a007fffde977c68 in ?? ()
#6  0x2ede86bc847dcc00 in ?? ()
#7  0x01d3b608 in ?? ()
#8  0x in ?? ()


Try running under gdb after setting a breakpoint at CursorSlice.cpp:206
(before the LASSERT line) and take a backtrace when it triggers.

I have no idea why it happens and wonder how many bugs are still lurking
there when instant preview for math is on...

In any case, it would greatly help if you can provide a reproducer.
However, note that this does not seem to be a fatal bug and LyX would
simply continue running when compiled in release mode.




I found that this behaviour could be associated to segfault with data loss.

Here are two reproducers with instructions included. Occurs with stable 
at 5a550d0a.


The files have sigsegv in their names but they actually trigger the 
above assertion in CursorSlice.cpp. This is because my non-minimal 
original example produced a segfault instead of asserting. I did not 
notice that the error message changed while minimizing the file, but if 
it's really important I can try again and this time preserve the 
segfault, although I predict that it is going to be complicated because 
the behaviour is very volatile. (or I could send it privately)


The data loss can be as follows:
- in 100% of the cases, the emergency save is corrupted
- it is possible that both the emergency save and the save file end up 
corrupted (if the user saves while LyX is in an incoherent state, as 
demonstrated in lyx-preview-sigsegv5.lyx)


lyx-preview-sigsegv5.lyx seems a bit complicated, this is because if I 
removed anything it would crash right at step 3, which is not what I 
wanted to demonstrate.


lyx-sigsegv-dataloss.lyx
Description: application/lyx


lyx-preview-sigsegv5.lyx
Description: application/lyx


lyx-sigsegv-dataloss-subfile.lyx
Description: application/lyx

logical cursor movement

[Scott Kostyshak]

I have no experience with how this is supposed to work, but I would like
to confirm that this behavior is expected:

1. In Tools  Preferences  Language Settings, set Cursor movement to
Logical (by the way, a tooltip here might be useful).
2. Open the attached file.
3. In Arabic, when I press Right, the cursor moves right. In English
(the text ddsss), when I press Right, the cursor moves left.

The behavior in (3) is the opposite of what I expected. I expected
Right to be interpretted as forward and thus move left in Arabic,
and right in English.

Which part of the above logic did I get wrong?

Scott
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 495
\begin_document
\begin_header
\origin unavailable
\textclass scrbook
\begin_preamble
\marginparsep=0.8 cm
\marginparwidth=105pt
%\reversemarginpar
%\normalmarginpar
\usepackage{sidenotes}
\usepackage{blindtext}
\usepackage{pst-optic,pst-text}
\usepackage{capt-of}
\AtBeginDocument{\setdefaultlanguage[numerals=maghrib]{arabic}}
\renewcommand{\nomname}{المصطلحات}% 
\usepackage{varwidth}
%\usepackage{bidi}
%\usepackage{xltxtra}
%\usepackage{tabularx}
%\usepackage{fmultico}
%\usepackage{etex}
\usepackage{hyperref}%لتلوين الاشارات المرجعية وجعل الفهارس قابلة للنقر
\hypersetup{
colorlinks=true,
linkcolor=blue,
citecolor=black,
filecolor=black,
urlcolor=black,
}
\usepackage{tikz}
\usetikzlibrary{shadows}
\usepackage{fancyhdr}

\pagestyle{fancy}

\renewcommand{\chaptermark}[1]%
{\markboth{\textbf{\thechapter\ #1}}{}}
\renewcommand{\sectionmark}[1]%
{\markright{\textbf{\thesection\ #1}}}
%\renewcommand{\headrulewidth}{0.4pt}
%\renewcommand{\footrulewidth}{0pt}
\fancyhf{}
\fancyhead[LE,RO]{\rightmark}
\fancyhead[LO,LE]{\leftmark} %chapter
\fancyfoot[LE,RO]{\textbf\thepage}
\end_preamble
\use_default_options true
\begin_modules
multicol
\end_modules
\maintain_unincluded_children false
\language arabic_arabi
\language_package default
\inputencoding auto
\fontencoding global
\font_roman Scheherazade
\font_sans Scheherazade
\font_typewriter Scheherazade
\font_math auto
\font_default_family default
\use_non_tex_fonts true
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize 12
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered true
\pdf_bookmarksopen true
\pdf_bookmarksopenlevel 4
\pdf_breaklinks false
\pdf_pdfborder false
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date true
\justification true
\use_refstyle 1
\boxbgcolor #af
\branch branchtest
\selected 1
\filename_suffix 0
\color #faf0e6
\end_branch
\index Index
\shortcut idx
\color #008000
\end_index
\leftmargin 6cm
\topmargin 2cm
\rightmargin 1.5cm
\bottommargin 1.5cm
\headheight 1cm
\headsep 1cm
\footskip 0.5cm
\columnsep 1cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation 0.5cm
\quotes_language french
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Chapter
الجزء الاول
\end_layout

\begin_layout Chapter
شرح برنامج ليك
\end_layout

\begin_layout Section
إضافة المراجع الخاصة بالاستشهادات
\end_layout

\begin_layout Standard
نقوم بإنشاء قاعدة بيانات للمراجع وتسمى bib ، ويمكن
\lang american
ddsss
\lang arabic_arabi
 إنشاءها بعدة برامج اشهرها 
\end_layout

\end_body
\end_document

logical cursor movement

[Scott Kostyshak]

I have no experience with how this is supposed to work, but I would like
to confirm that this behavior is expected:

1. In Tools > Preferences > Language Settings, set "Cursor movement" to
"Logical" (by the way, a tooltip here might be useful).
2. Open the attached file.
3. In Arabic, when I press , the cursor moves right. In English
(the text "ddsss"), when I press , the cursor moves left.

The behavior in (3) is the opposite of what I expected. I expected
 to be interpretted as "forward" and thus move left in Arabic,
and right in English.

Which part of the above logic did I get wrong?

Scott
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 495
\begin_document
\begin_header
\origin unavailable
\textclass scrbook
\begin_preamble
\marginparsep=0.8 cm
\marginparwidth=105pt
%\reversemarginpar
%\normalmarginpar
\usepackage{sidenotes}
\usepackage{blindtext}
\usepackage{pst-optic,pst-text}
\usepackage{capt-of}
\AtBeginDocument{\setdefaultlanguage[numerals=maghrib]{arabic}}
\renewcommand{\nomname}{المصطلحات}% 
\usepackage{varwidth}
%\usepackage{bidi}
%\usepackage{xltxtra}
%\usepackage{tabularx}
%\usepackage{fmultico}
%\usepackage{etex}
\usepackage{hyperref}%لتلوين الاشارات المرجعية وجعل الفهارس قابلة للنقر
\hypersetup{
colorlinks=true,
linkcolor=blue,
citecolor=black,
filecolor=black,
urlcolor=black,
}
\usepackage{tikz}
\usetikzlibrary{shadows}
\usepackage{fancyhdr}

\pagestyle{fancy}

\renewcommand{\chaptermark}[1]%
{\markboth{\textbf{\thechapter\ #1}}{}}
\renewcommand{\sectionmark}[1]%
{\markright{\textbf{\thesection\ #1}}}
%\renewcommand{\headrulewidth}{0.4pt}
%\renewcommand{\footrulewidth}{0pt}
\fancyhf{}
\fancyhead[LE,RO]{\rightmark}
\fancyhead[LO,LE]{\leftmark} %chapter
\fancyfoot[LE,RO]{\textbf\thepage}
\end_preamble
\use_default_options true
\begin_modules
multicol
\end_modules
\maintain_unincluded_children false
\language arabic_arabi
\language_package default
\inputencoding auto
\fontencoding global
\font_roman Scheherazade
\font_sans Scheherazade
\font_typewriter Scheherazade
\font_math auto
\font_default_family default
\use_non_tex_fonts true
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize 12
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered true
\pdf_bookmarksopen true
\pdf_bookmarksopenlevel 4
\pdf_breaklinks false
\pdf_pdfborder false
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date true
\justification true
\use_refstyle 1
\boxbgcolor #af
\branch branchtest
\selected 1
\filename_suffix 0
\color #faf0e6
\end_branch
\index Index
\shortcut idx
\color #008000
\end_index
\leftmargin 6cm
\topmargin 2cm
\rightmargin 1.5cm
\bottommargin 1.5cm
\headheight 1cm
\headsep 1cm
\footskip 0.5cm
\columnsep 1cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation 0.5cm
\quotes_language french
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Chapter
الجزء الاول
\end_layout

\begin_layout Chapter
شرح برنامج ليك
\end_layout

\begin_layout Section
إضافة المراجع الخاصة بالاستشهادات
\end_layout

\begin_layout Standard
نقوم بإنشاء قاعدة بيانات للمراجع وتسمى bib ، ويمكن
\lang american
ddsss
\lang arabic_arabi
 إنشاءها بعدة برامج اشهرها 
\end_layout

\end_body
\end_document

Re: [Patch] Two lyxpak bugs

[Guy Rutenberg]

Hi,

On Fri, Jul 3, 2015 at 3:53 PM, Enrico Forestieri  wrote:

> Your patch still does not work on Windows. It may work when files have
> names encodable in the current code page, otherwise it fails.
> Note that NTFS uses UTF-16 even if python returns "msbc" as the filesystem
> encoding. Instead, the attached patch works for me on any platform I have
> access to. I think it also solves your problem even if in a different way.
>

This works great on Linux.

Thanks,

Guy

Re: Ubuntu Trusty testers needed

[Benedict Holland]

Right. I deeply question that logic though. The fact that a corrupted save
bug was fixed is sort of a game changer from a usability perspective. I
mean, if it wasn't well known, well documented, or fixed, I might say that
it makes sense but as it stands, releasing code that has a known
catastrophic or critical or severe bug that was later fixed seems like it
will just cause far more problems in the future, especially on systems that
don't take updates.

Again, I wouldn't find this a problem except in this fairly rare case
particularly when the first thing to do is make sure that the software used
is up to date when it comes to fixing problems.

I suppose, that said, I don't mind testing lyx on various systems but the
2.0.8 branch is old and is in release for what, at least a year? What
additional testing, apart from that, is required? Is there a spec sheet for
various usability tests that should be performed or is it just ad-hoc
testing and report bugs to the channel?

~Ben

On Thu, Jul 2, 2015 at 6:28 PM, Richard Heck  wrote:

> On 07/02/2015 03:24 PM, Benedict Holland wrote:
>
>> Just curious, why are we testing old versions of an application with
>> known catastrophic bugs? Wasn't the uncorrupted save feature implemented in
>> the 2.1 branch? Also, I have been using the 2.1.3 exclusively for a long
>> time and I admit that I am a power user. It is stable as anything I use and
>> when combined with LuaTex, it produces beamer presentations and pdf
>> documents that are absolutely stunning. This includes images. XeLatex had
>> problems for me when importing PDF images but LuaTex does it far better.
>> None of this has to do with Lyx though. Lyx is performing beautifully and I
>> am using it to the fullest extent possible.
>>
>> The ONLY thing I have a gripe about is the lack of biblatex and biber
>> support. I get it, but I wish that it was there.
>>
>
> The testing here, I take it, is just to make sure that 2.0.8.1 works as
> expected on Ubuntu 14.04, which is still live (and widely used) and whose
> policies prohibit an upgrade to 2.1.x. Despite all the bugfixes.
>
> Richard
>
>

Re: Ubuntu Trusty testers needed

[Richard Heck]

On 07/04/2015 04:09 PM, Benedict Holland wrote:
Right. I deeply question that logic though. The fact that a corrupted 
save bug was fixed is sort of a game changer from a usability 
perspective. I mean, if it wasn't well known, well documented, or 
fixed, I might say that it makes sense but as it stands, releasing 
code that has a known catastrophic or critical or severe bug that was 
later fixed seems like it will just cause far more problems in the 
future, especially on systems that don't take updates.


Yes, but this is not our decision. It's an Ubuntu policy. It makes a lot 
more sense with libraries, really, but it's part of why I personally 
don't use Ubuntu LTS.


Note that the problem that triggered the corrupted save bug has been 
fixed in 2.0.8.1.


I suppose, that said, I don't mind testing lyx on various systems but 
the 2.0.8 branch is old and is in release for what, at least a year? 
What additional testing, apart from that, is required? Is there a spec 
sheet for various usability tests that should be performed or is it 
just ad-hoc testing and report bugs to the channel?


I'm not the best person to answer this, but I think all that's needed is 
to try it out pretty quickly. Since other packages haven't been 
seriously updated on Trusty either (e.g., Qt), one wouldn't expect there 
to be any issue.


Richard

Re: assert in CursorSlice.cpp

[Guillaume M-M]

Le 30/06/2015 19:20, Enrico Forestieri a écrit :

On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote:

Dear list,


I got an assertion in stable (1b596e92) for the second time today. It
happened while selecting text (first time with Shift+Arrows and second time
with the mouse).

I don't remember seeing it before: if it wasn't introduced recently then
maybe it was hidden by the fact that I did not use instant preview before. I
cannot think of anything particular in my settings apart from instant
preview on, only one document displayed.

I opened gdb after the first crash just in case. I don't know how to
reproduce it, the second crash happened when I was no longer paying
attention. I am keeping my gdb session open for a while if you would like me
to extract more relevant informations than the trace below, just ask.


Messages:

CursorSlice.cpp (207): can't compare cursor and anchor in different insets
p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558
q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079
lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:44


The interesting thread seems to be Thread 4 but it was truncated too early.


Thread 4 (Thread 0x7fffde979700 (LWP 27221)):
#0  0x759e6267 in __GI_raise (sig=sig@entry=6)
 at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x759e7eca in __GI_abort () at abort.c:89
#2  0x0059418d in ?? ()
#3  0x04df8db0 in ?? ()
#4  0x005139a1 in ?? ()
#5  0x0a007fffde977c68 in ?? ()
#6  0x2ede86bc847dcc00 in ?? ()
#7  0x01d3b608 in ?? ()
#8  0x in ?? ()


Try running under gdb after setting a breakpoint at CursorSlice.cpp:206
(before the LASSERT line) and take a backtrace when it triggers.

I have no idea why it happens and wonder how many bugs are still lurking
there when instant preview for math is on...

In any case, it would greatly help if you can provide a reproducer.
However, note that this does not seem to be a fatal bug and LyX would
simply continue running when compiled in release mode.




I found that this behaviour could be associated to segfault with data loss.

Here are two reproducers with instructions included. Occurs with stable 
at 5a550d0a.


The files have "sigsegv" in their names but they actually trigger the 
above assertion in CursorSlice.cpp. This is because my non-minimal 
original example produced a segfault instead of asserting. I did not 
notice that the error message changed while minimizing the file, but if 
it's really important I can try again and this time preserve the 
segfault, although I predict that it is going to be complicated because 
the behaviour is very volatile. (or I could send it privately)


The data loss can be as follows:
- in 100% of the cases, the emergency save is corrupted
- it is possible that both the emergency save and the save file end up 
corrupted (if the user saves while LyX is in an incoherent state, as 
demonstrated in lyx-preview-sigsegv5.lyx)


lyx-preview-sigsegv5.lyx seems a bit complicated, this is because if I 
removed anything it would crash right at step 3, which is not what I 
wanted to demonstrate.


lyx-sigsegv-dataloss.lyx
Description: application/lyx


lyx-preview-sigsegv5.lyx
Description: application/lyx


lyx-sigsegv-dataloss-subfile.lyx
Description: application/lyx