Re: design patterns used in LyX

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 09:01:09AM +0200, Tommaso Cucinotta wrote:
> On 21/04/2017 05:51, Scott Kostyshak wrote:
> >   (1) studying design patterns is a reasonable way to achieve that goal
> >   (2) what the best way to do that would be
> 
> I have good memories of Bruce Eckel's Thinking in C++
> 
>   http://www.mindviewinc.com/Books/downloads.html
> 
> there's a whole chapter about design patterns, plus plenty of good hints on 
> C++ software design.
> 
> >   (3) which design patterns we use in LyX
> 
> those that you can see "all over the place" (I show some of these LyX 
> examples in my lecture on DP :-) ):
> -) singleton (e.g., LyX.cpp)
> -) factory (e.g., MathFactory.cpp)
> -) MVC / MV (the whole src/frontends/qt4/*.cpp vs src/*.cpp code separation 
> structure
> -) observer: see how GuiView(s) track changes in Text/Buffer/Inset(s)
> -) private implementation (just grep for impl_)
> -) template pattern: grep 'do[A-Z]' src/*.cpp
> -) visitor & double-dispatching: serialization/deserialization to/from file, 
> e.g., grep 'write' src/insets/*.h
> -) composition: the whole Buffer, Paragraph, Inset, etc...
> -) iterator: well, quite a lot of stc++, but also e.g. the very DocIterator, 
> as well as e.g.: Inset::idxNext() / ::idxPrev(); basically, grep -r 
> 'prev\|next' *
> -) I can barely remember the moment boost::signal<> was dropoped, years ago, 
> that was enlightning...
> 
> Not that all of the above cases are completely & fully adhering to a DP full 
> spec, however, there's quite many bits here & there...
> 
> My2c,

This is all very useful. This gives me a good start for studying. Thanks, 
Tommaso!

Scott


signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 09:08:36AM +0200, Kornel Benko wrote:
> Am Donnerstag, 20. April 2017 um 23:48:12, schrieb Scott Kostyshak 
> 
> > On Thu, Apr 20, 2017 at 07:59:05PM +0200, Kornel Benko wrote:
> > > Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 
> > > 
> > > > On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > > > > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > > > > A 2nd SIGSEGV, involving similar actions, but the crash happens 
> > > > > > earlier, so
> > > > > > I guess it's a different bug:
> > > > > > 1. clear your ~/.lyx-trunk/cache/*
> > > > > > 2. start LyX, new doc
> > > > > > 3. type "info-insert icon whatevernonsense"
> > > > > > 
> > > > > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > > > > 
> > > > > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a 
> > > > > git
> > > > > bisect tomorrow if no one beats me to it:
> > > > > 
> > > > >   git bisect start
> > > > >   git bisect good 15fd7920
> > > > >   git bisect bad dbcbf305
> > > > 
> > > > My bisect lead to 244de5d2
> > > 
> > > This makes sense, because I came to the same commit while investigating 
> > > the crash.
> > 
> > I'm curious (to improve my debugging skills), how did you think through
> > this and how did the above lead you to 244de5d2?
> 
> From the dbg backtraces I have seen that
>   src/support/FileName.cpp
>   src/graphics/GraphicsConverter.cpp
>   src/graphics/GraphicsCacheItem.cpp
>   src/graphics/GraphicsCacheItem.cpp
> were involved. So I checked with 'git log' for these files if they fit into 
> the interval (15fd7920,dbcbf305)

Nice.

> > > Backtrace gives src/support/FileName.cpp:188
> > >   return d->name
> > > (gdb) p d->name
> > > Cannot access memory at address 0x0
> > 
> > I get to here OK. I think the though process is "why do we crash when
> > reading d->name? Let's print it out". We cannot access the memory, so
> > that means something is wrong with "d->name". Let's go higher up to see
> > where d->name becomes invalid.
> 
> Not only 'd->name' is invalid. The pointer 'd' itself is invalid (zero)

Ah now I see.

> 
> > > (gdb) up
> > >   src/graphics/GraphicsConverter.cpp:146
> > > (gdb) p doc_fname_
> > 
> > Here I am already a little lost. How did you know to print doc_fname_?
> > I see in the gdb output that it is an argument of the function that we
> > are in. But did you just make the connection between the "name" in
> > "d->name" and the "name" in "doc_fname_" ?
> 
> The routine FileName::absFileName() in src/support/FileName.cpp:188 is called 
> without parameter.
> The only call to absFileName() in src/graphics/GraphicsConverter.cpp:146 was
>   doc_fname_.absFileName()
> 
> > > $1 = (const lyx::support::FileName &) @0x3559560: {
> > >   _vptr.FileName = 0x38ca7d0, 
> > >   d = 0x0
> > > }
> > 
> > What information does this tell you? I guess that 0x38ca7d0 is a memory
> > address of the pointer?
> 
> The info is, that the 'd'-value is already here wrong.

Thank you for taking the time to explain all that. I find it very
helpful.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Mover.h: let move be defined

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 10:45:02PM +0200, Jean-Marc Lasgouttes wrote:
> Yes plzase, so that we have time to understand fully the problem. Although I 
> am 90% sure it is a gcc4.6 issue.

Reverted at ee7d78d1.

Scott


signature.asc
Description: PGP signature

Re: #10469: patch for putting LyX window on top on Windows

[Scott Kostyshak]

On Sat, Apr 22, 2017 at 03:04:11AM +0200, Enrico Forestieri wrote:

> I tried the patch but it does not work for me. I started lyx and then,
> from another terminal, I issued "lyx --remote file.lyx". The file was
> loaded in the already running instance but it was not brought to top.

Thanks for taking a look, Enrico. Let's hold off on the patch for now
then.

Scott


signature.asc
Description: PGP signature

Re: #10469: patch for putting LyX window on top on Windows

[Enrico Forestieri]

On Thu, Apr 20, 2017 at 11:50:03PM -0400, Scott Kostyshak wrote:

> Dear all,
> 
> I am wondering if we should include racoon's patch at #10469. It can be
> seen here:
> 
>   http://www.lyx.org/trac/attachment/ticket/10469/0001-Fix-for-10469.patch
> 
> I would propose that we include it with an OS guard for Windows only for
> the setWindowState line.
> 
> I'm not sure anyone understands why the patch works, but racoon has
> tested it, and it is simple.
> 
> Any thoughts?

I tried the patch but it does not work for me. I started lyx and then,
from another terminal, I issued "lyx --remote file.lyx". The file was
loaded in the already running instance but it was not brought to top.

-- 
Enrico

keytest.py

[Kornel Benko]

With this patch all findadv tests pass now.

This is result of collaboration with Tommaso. Not important for alpha,
but also no side effects to the rest.

Kornel



signature.asc
Description: This is a digitally signed message part.
diff --git a/development/autotests/bug-export-latex-in.txt b/development/autotests/bug-export-latex-in.txt
index b45c815..9b6ae27 100644
--- a/development/autotests/bug-export-latex-in.txt
+++ b/development/autotests/bug-export-latex-in.txt
@@ -7,6 +7,8 @@ TestBegin -dbg files test.lyx > lyx-log.txt 2>&1
 KK: \Axinfo-insert icon math-mode\[Return]
 KK: \Axbuffer-export luatex\[Return]
 KK: \[Tab]\[Return]
+KK: \Axbuffer-write\[Return]
+KK: \[Tab]\[Return]
 TestEnd
 Lang C
 Assert ! pcregrep -M "support/FileName.cpp .* creating path '/.*/lib/images'" lyx-log.txt
diff --git a/development/autotests/keytest.py b/development/autotests/keytest.py
index 3a60927..f6551e9 100755
--- a/development/autotests/keytest.py
+++ b/development/autotests/keytest.py
@@ -169,12 +169,39 @@ def intr_system(cmd, ignore_err = False):
 raise BaseException("command failed:" + cmd)
 return ret
 
+statreg = re.compile(r'^State:.*\(([a-z]+)\)')
+
+def lyx_status(pid):
+  if lyx_pid is None:
+return "dead"
+  fname = '/proc/' + pid + '/status'
+  try:
+f = open(fname)
+for line in f:
+  m = statreg.match(line)
+  if m:
+status = m.group(1)
+f.close()
+return status
+f.close()
+  except IOError as e:
+ print "I/O error({0}): {1}".format(e.errno, e.strerror)
+ return "dead"
+  except:
+print "Unexpected error:", sys.exc_info()[0]
+  return "dead"
 
 # Return true if LyX (identified via lyx_pid) is sleeping
 def lyx_sleeping():
-fname = '/proc/' + lyx_pid + '/status'
-return intr_system("grep 'State.*sleeping' " + fname, True)
+return lyx_status(lyx_pid) == "sleeping"
+
+# Return true if LyX (identified via lyx_pid) is zombie
+def lyx_zombie():
+return lyx_status(lyx_pid) == "zombie"
 
+def lyx_dead():
+status = lyx_status(lyx_pid)
+return (status == "dead") or (status == "zombie")
 
 def sendKeystring(keystr, LYX_PID):
 
@@ -365,6 +392,7 @@ while not failed:
 failed = True
 print 'lyx_pid: ' + lyx_pid + '\n'
 print 'lyx_win: ' + lyx_window_name + '\n'
+sendKeystring("\C\[Home]", lyx_pid)
 elif c[0:5] == 'Sleep':
 print "Sleeping for " + c[6:] + " seconds\n"
 time.sleep(float(c[6:]))
@@ -400,15 +428,20 @@ while not failed:
 failed = failed or (result != 0)
 print "result=" + str(result) + ", failed=" + str(failed)
 elif c[0:7] == 'TestEnd':
-time.sleep(0.5)
+#time.sleep(0.5)
 if not lyx_exists():
 print "LyX instance not found because of crash or assert !\n"
 failed = True
 else:
-print "Terminating lyx instance: " + str(lyx_pid) + "\n"
-intr_system("kill -9 " + str(lyx_pid), True);
-while lyx_exists():
-print "Waiting for lyx to die...\n"
+print "Forcing quit of lyx instance: " + str(lyx_pid) + "...\n"
+# intr_system("kill -9 " + str(lyx_pid), True);
+sendKeystring("\Cq", lyx_pid)
+lcount = 0
+while not lyx_dead():
+lcount = lcount + 1
+if lcount > 20:
+print "LyX still up, killing process and waiting for it to die...\n"
+intr_system("kill -9 " + str(lyx_pid), True);
 time.sleep(0.5)
 cmd = c[8:].rstrip()
 print "Executing " + cmd

Re: [LyX/master] Mover.h: let move be defined

[Jean-Marc Lasgouttes]

Yes plzase, so that we have time to understand fully the problem. Although I am 
90% sure it is a gcc4.6 issue.

Jmarc

Le 21 avril 2017 21:34:59 GMT+02:00, Scott Kostyshak  a écrit 
:
>
>I think Guillaume is away until May. JMarc, do you recommend we revert
>this commit for alpha?
>
>Scott

Re: #10400: keyboard shortcut for document settings?

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 10:48:05AM +0200, Jean-Marc Lasgouttes wrote:
> Le 21/04/2017 à 05:50, Scott Kostyshak a écrit :
> > Should we have a keyboard shortcut for document settings, as proposed at
> > 
> >   http://www.lyx.org/trac/ticket/10400
> > 
> > ?
> > 
> > There is a proposal to use ctrl + p, which is now free because we got
> > rid of print.
> > 
> > I agree a shortcut would be nice. I have mixed feelings about the
> > particular shortcut ctrl + p, but I don't have another suggestion.
> 
> Ctrl+P is assigned to Print in most applications. I would rather re-use it
> for View (default), which would become some print preview. However, I would
> not say that Cttrl+R is a good shortcut for document settings, but Ctrl+P is
> not either (unless we thin of settings as properties).

We should figure out which reasonable shortcuts are free.

As for using Ctrl + P for View (default), what is the smoothest way we
should make that transition?

idea 1.
unbind Ctrl + R and bind Ctrl + P and expect user complaints of broken
LyX.

idea 2.
For 2.3.0, bind both Ctrl + R and ctrl + P to View (default) and put a note 
that Ctrl +
R will be deprecated in favor of Ctrl + P in 2.4.0?
We could put the note in the release notes and the messages pane, each
time a user tries to do Ctrl + R. Of course, few will read the release
notes and few will have the messages pane open, but at least in 2.4.0 we
can say "we warned you this would happen".

idea 3.
For 2.3.x we can bind Ctrl + R to a warning that pops up that says the new key 
binding for View (default) is Ctrl + P.

Am I thinking too much about this?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] special character "allowbreak" (ZWSP), fileformat change

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 12:06:46PM +, Guenter Milde wrote:

> Fixed at f5ac0580ff8f4f1fd3.

Thanks for the quick fix. All tex2lyx tests pass on current master.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Mover.h: let move be defined

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 03:47:21PM +0200, Jean-Marc Lasgouttes wrote:
> Le 20/04/2017 à 23:49, Guillaume MM a écrit :
> > commit d4ea07705a88089519b80db3307a7d940fbae40d
> > Author: Guillaume MM 
> > Date:   Mon Apr 3 00:31:37 2017 +0200
> > 
> > Mover.h: let move be defined
> 
> This commit leads to a compile error with gcc 4.6. I guess it is due to this
> compiler's weak C++11 support.

I think Guillaume is away until May. JMarc, do you recommend we revert
this commit for alpha?

Scott


signature.asc
Description: PGP signature

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 01:59:30PM -0400, Scott Kostyshak wrote:
> On Apr 21, 2017 1:45 PM, "Guenter Milde"  wrote:
> >
> > On 2017-04-21, Scott Kostyshak wrote:
> >
> > > Is there consensus that this is the right approach?
> >
> > There is no consensus about the right approach to the "dash problem".
> > Therefore, this is only a minimal, "stop gap" proposal.
> >
> 
> I see. Would you guess there is any opposition from those who participated
> in the "great dash debate" to this temporary proposal?

To be clear, if you do not think anyone would oppose, please go ahead
and make the changes you suggest.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Scott Kostyshak]

On Apr 21, 2017 1:45 PM, "Guenter Milde"  wrote:
>
> On 2017-04-21, Scott Kostyshak wrote:
>
> > Is there consensus that this is the right approach?
>
> There is no consensus about the right approach to the "dash problem".
> Therefore, this is only a minimal, "stop gap" proposal.
>

I see. Would you guess there is any opposition from those who participated
in the "great dash debate" to this temporary proposal?

Scott

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Scott Kostyshak]

On Apr 21, 2017 12:45 PM, "Guenter Milde"  wrote:
>
> On 2017-04-21, Jean-Marc Lasgouttes wrote:
> > Le 21/04/2017 à 14:20, Guenter Milde a écrit :
> >> I propose a simple change to the lyx2lyx conversions for now:
>
> >> User a closed ERT inset for ligature dashes in pre-2.2 documents:
>
> >> 2.1  <->  2.2
> >> --   <->  ERT --
> >> ---  <->  ERT ---
>
> > Would that mean that all 2.1 documents that use long hyphens will now be
> > littered with ERT? Is that supposed to be temporary?
>
> Yes and yes.
>
> In 2.2, ERT is the only way to ensure no info is lost, because there is no
> internal construct for "ligature dashes".
>
> Actually, pre-2.2 documents used "raw LaTeX" for the ligature dashes, too.
> So when converting them to ERT,
> * the content "--" or "---" is the same,
> * the GUI shows the same symbolsm, just in different colour.
>
> In 2.3.alpha, we can alternatively use literal dashes with the "use
> ligature dashes" setting instead of ERT, if the document does not contain
> literal dashes.  (2.3.0 should use special chars for ligature dashes.)
>
> When converting older documents to 2.3 with lyx2lyx, set
> \use-ligature-dashes false, if the document contains literal dashes
> (instead of depending on the document's fileformat version).

If you are confident there are no disagreements from others (I remember
some disagreement with how to handle dashes but I think that was resolved)
and you want this in alpha to prevent data loss and for testing, then
please go ahead and do what you think is best.

Scott
>
> Günter
>

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Guenter Milde]

On 2017-04-21, Scott Kostyshak wrote:
> On Fri, Apr 21, 2017 at 12:20:47PM +, Guenter Milde wrote:

>> Dear Scott,

>> > As discussed [1], the current plan is to release alpha1 on Saturday.

>> > Please do not make any commits to master today after 22h00 UTC until
>> > master is open again. Between now and 22h00 UTC, please only make
>> > commits that:

>> >   (1) are very safe
>> > and
>> >   (2) you are confident do not break any of the ctests

>> > If there is a strong reason to break one of those two criteria, please
>> > start a discussion on the list explaining why an exception should be
>> > made.

>> there is a risk of further information loss in the em-dash conversion
>> workaround. I wrote an analysis and suggestion on 31 Mar 2017
...

>> I propose a simple change to the lyx2lyx conversions for now:

>> User a closed ERT inset for ligature dashes in pre-2.2 documents:

>> 2.1  <->  2.2
>> --   <->  ERT --
>> ---  <->  ERT ---


> Is the risk of information loss only on documents created before 2.2.x
> format?

No.

The problems with the current state are:

1. Pre-2.2 documents using literal dashes were not affected by the change
   in 2.2 but now they require user-interaction (unchecking
   use-ligature-dashes) to work as before.
  
2. Opening pre 2.2 documents in 2.2 or 2.3 destroys information whether
   a dash was a literal dash or a "ligature" dash.

3. Back-conversion of 2.3 documents destroys information whether dashes
   shall be exported as literal characters or ligatures.

4. Different behaviour for documents with non-TeX fonts when compiled with
   LuaTeX.


>> This would require a change to lyx2lyx/lyx_2_2.py (functions
>> convert/revert_dashes) and lyx2lyx/lyx_2_3.py 
>> (convert/revert_dashligatures).

> Is there consensus that this is the right approach?

There is no consensus about the right approach to the "dash problem".
Therefore, this is only a minimal, "stop gap" proposal.

Günter

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Guenter Milde]

On 2017-04-21, Jean-Marc Lasgouttes wrote:
> Le 21/04/2017 à 14:20, Guenter Milde a écrit :
>> I propose a simple change to the lyx2lyx conversions for now:

>> User a closed ERT inset for ligature dashes in pre-2.2 documents:

>> 2.1  <->  2.2
>> --   <->  ERT --
>> ---  <->  ERT ---

> Would that mean that all 2.1 documents that use long hyphens will now be
> littered with ERT? Is that supposed to be temporary?

Yes and yes.

In 2.2, ERT is the only way to ensure no info is lost, because there is no
internal construct for "ligature dashes".

Actually, pre-2.2 documents used "raw LaTeX" for the ligature dashes, too.
So when converting them to ERT,
* the content "--" or "---" is the same,
* the GUI shows the same symbolsm, just in different colour.

In 2.3.alpha, we can alternatively use literal dashes with the "use
ligature dashes" setting instead of ERT, if the document does not contain
literal dashes.  (2.3.0 should use special chars for ligature dashes.)

When converting older documents to 2.3 with lyx2lyx, set
\use-ligature-dashes false, if the document contains literal dashes
(instead of depending on the document's fileformat version).

Günter

Re: New warnings in master

[Jean-Marc Lasgouttes]

Le 21/04/2017 à 18:12, Guenter Milde a écrit :

This is a result of the addition of tooltips for some special chars (where
the symbol in the GUI is a bit ambiguous...).
No tooltips for the values above is the intended behaviour.

What would be the correct way to silence the warnings?


The lazy solution is to add a
  default:
break;
statement at the end of the switch.

The better solution is to add cases to enumerate all the cases that do 
not need a tooltip. This way you get a warning when adding a new element 
if you did not decide whether a tooltip was needed.


JMarc

Re: New warnings in master

[Guenter Milde]

On 2017-04-20, Guillaume MM wrote:
> ../../src/insets/InsetSpecialChar.cpp: In member function ‘virtual 
> lyx::docstring lyx::InsetSpecialChar::toolTip(const lyx::BufferView&, 
> int, int) const’:
> ../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
> ‘LDOTS’ not handled in switch [-Wswitch]
>switch (kind_) {
>   ^
> ../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
> ‘MENU_SEPARATOR’ not handled in switch [-Wswitch]
> ../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
> ‘PHRASE_LYX’ not handled in switch [-Wswitch]
> ../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
> ‘PHRASE_TEX’ not handled in switch [-Wswitch]
> ../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
> ‘PHRASE_LATEX2E’ not handled in switch [-Wswitch]
> ../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
> ‘PHRASE_LATEX’ not handled in switch [-Wswitch]

This is a result of the addition of tooltips for some special chars (where
the symbol in the GUI is a bit ambiguous...).
No tooltips for the values above is the intended behaviour.

What would be the correct way to silence the warnings?

Günter

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Jean-Marc Lasgouttes]

Le 21/04/2017 à 14:20, Guenter Milde a écrit :

I propose a simple change to the lyx2lyx conversions for now:

User a closed ERT inset for ligature dashes in pre-2.2 documents:

2.1  <->  2.2
--   <->  ERT --
---  <->  ERT ---


Would that mean that all 2.1 documents that use long hyphens will now be 
littered with ERT? Is that supposed to be temporary?


JMarc

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 12:20:47PM +, Guenter Milde wrote:
> Dear Scott,
> 
> > As discussed [1], the current plan is to release alpha1 on Saturday.
> 
> > Please do not make any commits to master today after 22h00 UTC until
> > master is open again. Between now and 22h00 UTC, please only make
> > commits that:
> 
> >   (1) are very safe
> 
> > and
> 
> >   (2) you are confident do not break any of the ctests
> 
> > If there is a strong reason to break one of those two criteria, please
> > start a discussion on the list explaining why an exception should be
> > made.
> 
> there is a risk of further information loss in the em-dash conversion
> workaround. I wrote an analysis and suggestion on 31 Mar 2017 but waited
> with action becaus of missing feedback and because I wanted the "allowbreak"
> special char to be present first.
> 
> I propose a simple change to the lyx2lyx conversions for now:
> 
> User a closed ERT inset for ligature dashes in pre-2.2 documents:
> 
> 2.1  <->  2.2
> --   <->  ERT --
> ---  <->  ERT ---
>   

Is the risk of information loss only on documents created before 2.2.x
format?

> This would require a change to lyx2lyx/lyx_2_2.py (functions
> convert/revert_dashes) and lyx2lyx/lyx_2_3.py 
> (convert/revert_dashligatures).

Is there consensus that this is the right approach?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Mover.h: let move be defined

[Jean-Marc Lasgouttes]

Le 20/04/2017 à 23:49, Guillaume MM a écrit :

commit d4ea07705a88089519b80db3307a7d940fbae40d
Author: Guillaume MM 
Date:   Mon Apr 3 00:31:37 2017 +0200

Mover.h: let move be defined


This commit leads to a compile error with gcc 4.6. I guess it is due to 
this compiler's weak C++11 support.


JMarc


---
 src/Mover.h |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/Mover.h b/src/Mover.h
index 4d1c1c7..e432a3d 100644
--- a/src/Mover.h
+++ b/src/Mover.h
@@ -27,7 +27,13 @@ namespace support { class FileName; }
 class Mover
 {
 public:
-   virtual ~Mover() {}
+   virtual ~Mover() = default;
+   Mover(Mover &&) = default;
+   Mover & operator=(Mover &&) = default;
+   Mover(Mover const &) = default;
+   Mover & operator=(Mover const &) = default;
+
+   Mover() = default;

/** Copy file @c from to @c to.
 *  This version should be used to copy files from the original
@@ -109,9 +115,7 @@ protected:
 class SpecialisedMover : public Mover
 {
 public:
-   SpecialisedMover() {}
-
-   virtual ~SpecialisedMover() {}
+   SpecialisedMover() = default;

/** @c command should be of the form
 *  

Re: master closed today at 22h00 UTC for 2.3.0alpha1

[Guenter Milde]

Dear Scott,

> As discussed [1], the current plan is to release alpha1 on Saturday.

> Please do not make any commits to master today after 22h00 UTC until
> master is open again. Between now and 22h00 UTC, please only make
> commits that:

>   (1) are very safe

> and

>   (2) you are confident do not break any of the ctests

> If there is a strong reason to break one of those two criteria, please
> start a discussion on the list explaining why an exception should be
> made.

there is a risk of further information loss in the em-dash conversion
workaround. I wrote an analysis and suggestion on 31 Mar 2017 but waited
with action becaus of missing feedback and because I wanted the "allowbreak"
special char to be present first.

I propose a simple change to the lyx2lyx conversions for now:

User a closed ERT inset for ligature dashes in pre-2.2 documents:

2.1  <->  2.2
--   <->  ERT --
---  <->  ERT ---

This would require a change to lyx2lyx/lyx_2_2.py (functions
convert/revert_dashes) and lyx2lyx/lyx_2_3.py 
(convert/revert_dashligatures).

I may be able to do the changes but I am not sure whether I would manage to
fix the tests.

Günter

Re: [LyX/master] special character "allowbreak" (ZWSP), fileformat change

[Guenter Milde]

On 2017-04-21, Scott Kostyshak wrote:
> On Thu, Apr 20, 2017 at 11:29:55PM +0200, Günter Milde wrote:

>> commit f5ac0580ff8f4f1fd34d792f7952fb05d182e162
>> Author: Günter Milde 
>> Date:   Mon Mar 6 14:49:30 2017 +0100

>> special character "allowbreak" (ZWSP), fileformat change

...

> A bisect suggests that this commit broke the following test:

>   tex2lyx/roundtrip/box-color-size-space-align.tex (Failed)

> I'm guessing that the following test was also broken by this commit (but
> I only bisected based on the above test):

>   tex2lyx/cmplyx/box-color-size-space-align.tex (Failed)

> Günter will you have time to look into this today?

A sample files was saved with the wrong encoding after editing the
fileformat number.

Fixed at f5ac0580ff8f4f1fd3.

Sorry for the invonvenience,

Günter

Re: [LyX/master] use examples folder setting from preferences

[Kornel Benko]

Am Freitag, 21. April 2017 um 11:28:12, schrieb Stephan Witt 
> commit a91402dc64cb6c73b355465ec11868cf1d0a443d
> Author: Stephan Witt 
> Date:   Tue Apr 18 09:32:22 2017 +0200
> 
> use examples folder setting from preferences
> ---
>  src/frontends/qt4/GuiView.cpp |   10 +++---
>  1 files changed, 3 insertions(+), 7 deletions(-)

Thanks,

Kornel

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

Re: design patterns used in LyX

[Jean-Marc Lasgouttes]

Le 21/04/2017 à 05:51, Scott Kostyshak a écrit :

  (1) studying design patterns is a reasonable way to achieve that goal
  (2) what the best way to do that would be
  (3) which design patterns we use in LyX


I am not much of a C++ programmer in this  respect.


I also found JMarc's commit at 91b38516 which referenced

  https://www.ics.com/designpatterns/book/

but perhaps he just came across that URL when searching.


Indeed AFAIR I found it on the relevant stackexchange thread google 
pointed me to.


JMarc

Re: #10400: keyboard shortcut for document settings?

[Jean-Marc Lasgouttes]

Le 21/04/2017 à 05:50, Scott Kostyshak a écrit :

Should we have a keyboard shortcut for document settings, as proposed at

  http://www.lyx.org/trac/ticket/10400

?

There is a proposal to use ctrl + p, which is now free because we got
rid of print.

I agree a shortcut would be nice. I have mixed feelings about the
particular shortcut ctrl + p, but I don't have another suggestion.


Ctrl+P is assigned to Print in most applications. I would rather re-use 
it for View (default), which would become some print preview. However, I 
would not say that Cttrl+R is a good shortcut for document settings, but 
Ctrl+P is not either (unless we thin of settings as properties).


Reading about windows settings, I found that Alt+Enter is for object 
properties:

https://support.microsoft.com/en-us/help/12445/windows-keyboard-shortcuts

It might be nice to implement that for inset settings.

JMarc

focus-handling

[mn]

With 2.3-dev (and before that) there are inconsistencies or bugs
regarding focus-management.

Open LyX, create new document.
Open document-settings.
Switch to preamble.

There is no focus in the preamble-editing area.
It should be active immediately.

Activate preamble editing area.

Now close the settings window.
Reopen document settings window.

The editing area now shows a blinking cursor, pretending to be active.
But there is no keyboard entry possible.

The blinking cursor should always indicate where keyboard action would
have consequences.
This seems to be a general issue since similar behavior also impedes
working with other panels, like find and spell checking.

Is this now working as designed, i.e. intended?

greetings
Mike

Re: SIGSEGV on luatex export #2

[Kornel Benko]

Am Freitag, 21. April 2017 um 00:47:38, schrieb Scott Kostyshak 

> On Thu, Apr 20, 2017 at 11:48:12PM -0400, Scott Kostyshak wrote:
> 
> > > $1 = (const lyx::support::FileName &) @0x3559560: {
> > >   _vptr.FileName = 0x38ca7d0, 
> > >   d = 0x0
> > > }
> > 
> > What information does this tell you? I guess that 0x38ca7d0 is a memory
> > address of the pointer?
> 
> Ah so the idea is that at this point I should realize that it should be
> an actual file name, not a pointer to a file name?

The idea is that d should be a pointer to something 'not zero'.
(According to the class FileName it is
private:
Private * const d;
while Private is declared in FileName.cpp:88

but apparently 'd' was never set. (I did not understand why though)
)

> Scott

Kornel

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

Re: SIGSEGV on luatex export #2

[Kornel Benko]

Am Donnerstag, 20. April 2017 um 23:48:12, schrieb Scott Kostyshak 

> On Thu, Apr 20, 2017 at 07:59:05PM +0200, Kornel Benko wrote:
> > Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 
> > 
> > > On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > > > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > > > A 2nd SIGSEGV, involving similar actions, but the crash happens 
> > > > > earlier, so
> > > > > I guess it's a different bug:
> > > > > 1. clear your ~/.lyx-trunk/cache/*
> > > > > 2. start LyX, new doc
> > > > > 3. type "info-insert icon whatevernonsense"
> > > > > 
> > > > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > > > 
> > > > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> > > > bisect tomorrow if no one beats me to it:
> > > > 
> > > >   git bisect start
> > > >   git bisect good 15fd7920
> > > >   git bisect bad dbcbf305
> > > 
> > > My bisect lead to 244de5d2
> > 
> > This makes sense, because I came to the same commit while investigating the 
> > crash.
> 
> I'm curious (to improve my debugging skills), how did you think through
> this and how did the above lead you to 244de5d2?

From the dbg backtraces I have seen that
src/support/FileName.cpp
src/graphics/GraphicsConverter.cpp
src/graphics/GraphicsCacheItem.cpp
src/graphics/GraphicsCacheItem.cpp
were involved. So I checked with 'git log' for these files if they fit into the 
interval (15fd7920,dbcbf305)

> > Backtrace gives src/support/FileName.cpp:188
> > return d->name
> > (gdb) p d->name
> > Cannot access memory at address 0x0
> 
> I get to here OK. I think the though process is "why do we crash when
> reading d->name? Let's print it out". We cannot access the memory, so
> that means something is wrong with "d->name". Let's go higher up to see
> where d->name becomes invalid.

Not only 'd->name' is invalid. The pointer 'd' itself is invalid (zero)

> > (gdb) up
> > src/graphics/GraphicsConverter.cpp:146
> > (gdb) p doc_fname_
> 
> Here I am already a little lost. How did you know to print doc_fname_?
> I see in the gdb output that it is an argument of the function that we
> are in. But did you just make the connection between the "name" in
> "d->name" and the "name" in "doc_fname_" ?

The routine FileName::absFileName() in src/support/FileName.cpp:188 is called 
without parameter.
The only call to absFileName() in src/graphics/GraphicsConverter.cpp:146 was
doc_fname_.absFileName()

> > $1 = (const lyx::support::FileName &) @0x3559560: {
> >   _vptr.FileName = 0x38ca7d0, 
> >   d = 0x0
> > }
> 
> What information does this tell you? I guess that 0x38ca7d0 is a memory
> address of the pointer?

The info is, that the 'd'-value is already here wrong.

> Scott

Kornel

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

Re: design patterns used in LyX

[Tommaso Cucinotta]

On 21/04/2017 05:51, Scott Kostyshak wrote:

  (1) studying design patterns is a reasonable way to achieve that goal
  (2) what the best way to do that would be


I have good memories of Bruce Eckel's Thinking in C++

  http://www.mindviewinc.com/Books/downloads.html

there's a whole chapter about design patterns, plus plenty of good hints on C++ 
software design.


  (3) which design patterns we use in LyX


those that you can see "all over the place" (I show some of these LyX examples 
in my lecture on DP :-) ):
-) singleton (e.g., LyX.cpp)
-) factory (e.g., MathFactory.cpp)
-) MVC / MV (the whole src/frontends/qt4/*.cpp vs src/*.cpp code separation 
structure
-) observer: see how GuiView(s) track changes in Text/Buffer/Inset(s)
-) private implementation (just grep for impl_)
-) template pattern: grep 'do[A-Z]' src/*.cpp
-) visitor & double-dispatching: serialization/deserialization to/from file, 
e.g., grep 'write' src/insets/*.h
-) composition: the whole Buffer, Paragraph, Inset, etc...
-) iterator: well, quite a lot of stc++, but also e.g. the very DocIterator, as 
well as e.g.: Inset::idxNext() / ::idxPrev(); basically, grep -r 'prev\|next' *
-) I can barely remember the moment boost::signal<> was dropoped, years ago, 
that was enlightning...

Not that all of the above cases are completely & fully adhering to a DP full spec, 
however, there's quite many bits here & there...

My2c,

T.

Re: #10400: keyboard shortcut for document settings?

[Kornel Benko]

Am Donnerstag, 20. April 2017 um 23:50:45, schrieb Scott Kostyshak 

> Should we have a keyboard shortcut for document settings, as proposed at
> 
>   http://www.lyx.org/trac/ticket/10400
> 
> ?
> 
> There is a proposal to use ctrl + p, which is now free because we got
> rid of print.

In emacs.bind and xemacs.bin  it is 
\bind "C-p""up"

> I agree a shortcut would be nice. I have mixed feelings about the
> particular shortcut ctrl + p, but I don't have another suggestion.
> 
> Scott

Kornel

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

Re: beamer editing

[Jürgen Spitzmüller]

Am Donnerstag, den 20.04.2017, 22:30 +0200 schrieb Edwin Leuven:
> feel free to apply the patch ;-)

I'll let others comment and test first. Alas, I do not have time for
testing myself ATM.

Jürgen

> 
> ed.
> 

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