Re: cmake Error
Am Dienstag, 15. Mai 2018 22:02:06 CEST schrieb Richard Kimberly Heck : > Could NOT find LYX_PY_polib (missing: LYX_PY_POLIB) > > Is that something I need to worry about? > > Riki > You will not be able to use po/lyx_pot.py to re-create the translation files. Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0 Regression Inquiry
2018-05-15 20:44 GMT+02:00 Richard Kimberly Heck : > I take it that your patch essentially reverts the one I mentioned above. > I'm happy for it to be reverted at this point. > Done at e077255aea9d8. 2.3.2? Jürgen > > As far as the larger issues you mentioned are concerned, let's ponder > those. > > Riki > >
Re: Windows Installers: TESTING ONLY
On 16/05/2018 3:33 p.m., Richard Kimberly Heck wrote: I have finally managed to build Windows installers for 2.3.0. They can be found here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Let me emphasize again that THESE ARE FOR TESTING ONLY I have tested them a little bit myself, but not a whole lot. They seem to work, basically---I compiled the tutorial---but that's as far as I'm going to go in vouching for them. My understanding of the installer code is pretty basic at this point. The executables were cross-compiled using MinGW on Linux. So these are not at all the same binaries that we have previously been distributing. The installers themselves, however, are pretty much the same, though without the "Update MiKTeX" code, which has just been commented out. If we want to include it, but issue some kind of warning, then I think that will need to be translated. I know where to put the translated strings, but I'm not entirely sure how to get them from the translators, and that will of course take time. Longer term, I have some thoughts about how to improve our situation on Windows, and there's been vigorous discussion over on the user list. But I'll save that for after we get an installer for 2.3.x. Riki PS Certainly one thing I've learned is that installing LyX with MikTeX takes *forever*, and I've got a fast internet connection. It would be nice to know what packages we need to install to compile the User Guide, etc, and just install those, rather than every single package LyX could possibly need. This is not trivial, since some of those are font definitions. I uninstalled my current 2.3.0 (from Uwe's very first 2.3.0 installer, which has worked perfectly for me) and tried the link above (not the bundle). LyX installed, but there are problems on my windows 7 machine. 1. When starting LyX, a command window is presented and retained. Closing the command window closes LyX. 2. LyX does not create a personal LyX2.3 directory. (It should be at C:\Users\Andrew\AppData\Roaming\LyX2.3 in my case.) When I made my previous LyX2.3 directory available (from Uwe's installation), LyX didn't recognize it and reconfiguring was no help. 3. The Uninstall-LyX.exe program did not terminate. I had to close it with the windows task manager. Andrew PS Re your PS and *forever*, that's one more reason for treating MiKTeX and LyX as distinct programs and not bundling them together. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: SIGSEGV when copy/pasting a child doc
On Wed, May 02, 2018 at 04:00:12PM +, Scott Kostyshak wrote: > On Wed, May 02, 2018 at 01:06:04PM +, Jean-Marc Lasgouttes wrote: > > Le 28/04/2018 à 00:06, Scott Kostyshak a écrit : > > > On Wed, Apr 25, 2018 at 06:41:36PM +, Scott Kostyshak wrote: > > > > > > > it is not 100% reproducible for me. I wonder if valgrind might be useful > > > > to try in this situation. > > > > > > Attached is a valgrind log. Do the invalid reads provide any clues? > > > > Does this patch help? I have a more complicated approach, but this should be > > good enough for now. > > With the patch I still get a SIGSEGV. I think the dialog shows and then > the SIGSEGV immediately occurs. In the attached screenshot, I move the > SIGSEGV to show that behind it is the dialog. I think I am the only one who can reproduce this, right? For those who cannot reproduce, do you have a clean Valgrind log? Scott signature.asc Description: PGP signature
Re: Lyx on Mac bug: document tabs disappearing in fullscreen mode
On Wed, May 16, 2018 at 04:03:44AM +, Zhexuan Gong wrote: > Yes, it's still there in 2.3.0 and perfectly reproducible. Thanks for checking. Scott signature.asc Description: PGP signature
Re: Lyx on Mac bug: document tabs disappearing in fullscreen mode
Yes, it's still there in 2.3.0 and perfectly reproducible. On Tue, May 15, 2018 at 8:47 PM, Scott Kostyshak wrote: > On Fri, Feb 02, 2018 at 06:25:25PM +, Scott Kostyshak wrote: > > On Sat, Oct 28, 2017 at 12:47:29AM +, Zhexuan Gong wrote: > > > Dear Lyx developers, > > > > > > I'm not sure if any of you are aware of this bug. I'm using the latest > > > 2.2.3 Lyx on Mac. And whenever Lyx is in macOS' native full screen mode > > > (using the green button on the title bar, not the View->Full Screen), > the > > > document tab row will disappear mysteriously whenever a new document is > > > created or the current tab is closed. This is annoying since one cannot > > > switch between tabs any more. The problem will persist even if one > exit the > > > full screen mode. The only way to make the tab row reappear is to first > > > exit the full screen mode, then enter the full screen mode using > View->Full > > > Screen, and then do View->Full Screen again (uncheck). > > > > > > To me, this bug has to do with the fact that there are two full screen > > > modes. The native one by clicking the full screen icon at the title bar > > > will not hide the toolbars nor the tab bar, but the full screen mode > via > > > the View menu will hide everything except the document itself. The bug > > > yields a messed-up situation where all the tool bars are showing, but > the > > > document tab bar is hidden, which belongs to neither of the two full > screen > > > modes. > > > > > > P. S. I'm not talking about the Tab Bar under the View menu that is > > > introduced by macOS Sierra. I'm talking about the tabs enabled in > > > Preferences->Document Handling. > > > > > > Can anyone look into this? > > > > Do you still see this with 2.3.0rc2? If please file a bug report at > > > > https://www.lyx.org/trac > > > > and put the keyword "os=macosx". This way we will not forget about it. > > Dear Zhexuan Gong, do you still see the above issue with 2.3.0? > > Scott >
Windows Installers: TESTING ONLY
I have finally managed to build Windows installers for 2.3.0. They can be found here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Let me emphasize again that THESE ARE FOR TESTING ONLY I have tested them a little bit myself, but not a whole lot. They seem to work, basically---I compiled the tutorial---but that's as far as I'm going to go in vouching for them. My understanding of the installer code is pretty basic at this point. The executables were cross-compiled using MinGW on Linux. So these are not at all the same binaries that we have previously been distributing. The installers themselves, however, are pretty much the same, though without the "Update MiKTeX" code, which has just been commented out. If we want to include it, but issue some kind of warning, then I think that will need to be translated. I know where to put the translated strings, but I'm not entirely sure how to get them from the translators, and that will of course take time. Longer term, I have some thoughts about how to improve our situation on Windows, and there's been vigorous discussion over on the user list. But I'll save that for after we get an installer for 2.3.x. Riki PS Certainly one thing I've learned is that installing LyX with MikTeX takes *forever*, and I've got a fast internet connection. It would be nice to know what packages we need to install to compile the User Guide, etc, and just install those, rather than every single package LyX could possibly need. This is not trivial, since some of those are font definitions.
Re: Lyx on Mac bug: document tabs disappearing in fullscreen mode
On Fri, Feb 02, 2018 at 06:25:25PM +, Scott Kostyshak wrote: > On Sat, Oct 28, 2017 at 12:47:29AM +, Zhexuan Gong wrote: > > Dear Lyx developers, > > > > I'm not sure if any of you are aware of this bug. I'm using the latest > > 2.2.3 Lyx on Mac. And whenever Lyx is in macOS' native full screen mode > > (using the green button on the title bar, not the View->Full Screen), the > > document tab row will disappear mysteriously whenever a new document is > > created or the current tab is closed. This is annoying since one cannot > > switch between tabs any more. The problem will persist even if one exit the > > full screen mode. The only way to make the tab row reappear is to first > > exit the full screen mode, then enter the full screen mode using View->Full > > Screen, and then do View->Full Screen again (uncheck). > > > > To me, this bug has to do with the fact that there are two full screen > > modes. The native one by clicking the full screen icon at the title bar > > will not hide the toolbars nor the tab bar, but the full screen mode via > > the View menu will hide everything except the document itself. The bug > > yields a messed-up situation where all the tool bars are showing, but the > > document tab bar is hidden, which belongs to neither of the two full screen > > modes. > > > > P. S. I'm not talking about the Tab Bar under the View menu that is > > introduced by macOS Sierra. I'm talking about the tabs enabled in > > Preferences->Document Handling. > > > > Can anyone look into this? > > Do you still see this with 2.3.0rc2? If please file a bug report at > > https://www.lyx.org/trac > > and put the keyword "os=macosx". This way we will not forget about it. Dear Zhexuan Gong, do you still see the above issue with 2.3.0? Scott signature.asc Description: PGP signature
cmake Error
Could NOT find LYX_PY_polib (missing: LYX_PY_POLIB) Is that something I need to worry about? Riki
Re: LyX 2.3.1
On 05/15/2018 01:14 PM, Scott Kostyshak wrote: > On Tue, May 15, 2018 at 09:30:09AM +, Pavel Sanda wrote: >> Richard Kimberly Heck wrote: >>> I am working on this. I've managed to compile for Windows using mingw on >>> Linux (amazingly easy, actually) but have not dealt with the packaging >>> issues yet. Fortunately, someone who reported a bug to us seems as if >>> they may have done so and is giving me some help. >> Given latest developments we should at least take down bundle installer >> from web download section and advice users to install either texlive or >> miktex on their own because my understanding is that miktex contained >> in the bundle is broken so at least we stop spreading the buggy version. >> >> Any disagreement? > That sounds reasonable, but I don't recall many reports from users who > have installed the 2.2.3 bundle and reported problems. I guess the > problem comes if they try to update MiKTeX after installing the 2.2.3 > bundle? The answer is back in that thread somewhere I managed today to build a Windows installer, though for 2.4.dev. The not "bundled" one. I've got to backport the various changes I had to make to the build scripts, etc, and then I should be able to build an installer for 2.3.0. I guess I'll do the bundled one, too, if I can. The only difference is the installation of MikTeX. Riki
Re: [LyX/master] #11142 correct list of previous version to check for user directory contents
On 05/15/2018 04:03 PM, Stephan Witt wrote: > Am 13.05.2018 um 20:16 schrieb Stephan Witt : >> commit 17c3617c49487977e5c46de20cb450952c68b03d >> Author: Stephan Witt >> Date: Sun May 13 20:15:35 2018 +0200 >> >>#11142 correct list of previous version to check for user directory >> contents >> >>LyX on Mac uses a user directory with version suffix. On change of the >> version suffix the existence of the directories with previous versions is >> checked and the latest one is used for a copy on first configure run. For >> 2.4 the candidate list starts with 2.3 now as it should. > Riki, I’d like to fix it in branch too. Is the attached patch ok? Yes, please go ahead. Riki
Re: [LyX/master] Removed unused private variable
Le 15/05/2018 à 21:58, Richard Kimberly Heck a écrit : Removed unused private variable Spotted by clang++ 6. Riki, I guess this is OK for branch? Sure. Done. JMarc
Re: [LyX/master] #11142 correct list of previous version to check for user directory contents
Am 13.05.2018 um 20:16 schrieb Stephan Witt :
>
> commit 17c3617c49487977e5c46de20cb450952c68b03d
> Author: Stephan Witt
> Date: Sun May 13 20:15:35 2018 +0200
>
>#11142 correct list of previous version to check for user directory
> contents
>
>LyX on Mac uses a user directory with version suffix. On change of the
> version suffix the existence of the directories with previous versions is
> checked and the latest one is used for a copy on first configure run. For 2.4
> the candidate list starts with 2.3 now as it should.
> ---
> lib/configure.py |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/configure.py b/lib/configure.py
> index a46ae23..ba4c004 100644
> --- a/lib/configure.py
> +++ b/lib/configure.py
> @@ -168,14 +168,14 @@ def checkUpgrade():
> logger.info('Checking for upgrade from previous version.')
> parent = os.path.dirname(cwd)
> appname = basename[:(-len(version_suffix))]
> -for version in ['-2.1', '-2.0', '-1.6' ]:
> +for version in ['-2.3', '-2.2', '-2.1', '-2.0', '-1.6' ]:
> logger.debug('Checking for upgrade from previous version ' +
> version)
> previous = os.path.join(parent, appname + version)
> logger.debug('previous = ' + previous)
> if os.path.isdir( previous ):
> logger.info('Found directory "%s".', previous)
> copy_tree( previous, cwd, True )
> -logger.info('Content copied to directory "%s".', cwd)
> +logger.info('Content copied from directory "%s".', previous)
> return
Riki, I’d like to fix it in branch too. Is the attached patch ok?
bug-11142-branch.patch
Description: Binary data
Re: [LyX/master] Removed unused private variable
On 05/15/2018 04:54 AM, Jean-Marc Lasgouttes wrote: > Le 15/05/2018 à 00:04, Jean-Marc Lasgouttes a écrit : >> commit c4075367fa6330cac075e94b61f8522fcd54f630 >> Author: Jean-Marc Lasgouttes >> Date: Mon May 14 23:03:50 2018 +0200 >> >> Removed unused private variable >> Spotted by clang++ 6. > > Riki, I guess this is OK for branch? Sure. Riki
Re: LyX 2.3.0 Regression Inquiry
On 05/15/2018 03:42 AM, Jürgen Spitzmüller wrote: > Am Montag, den 14.05.2018, 13:51 -0400 schrieb Richard Kimberly Heck: >> So probably 2d6173d8103 was a mistake: We should just have said that >> you >> can't do that. But that was before the includeonly support, I >> believe, >> so maybe it made sense then? I'm not sure. > Note that it does not work anyway. Since we do what we can do dis- > couple such a non-output parent in the latex output routine (via > ignore_parent), the math macros are in fact _not_ inherited in > standalone situations! Since nobody complained about that during the > last years, I wonder whether this is really such a widespread usage. > > Anyway, currently our code contradicts itself: clone tries to include > non-relevant parents, and the latex routine does everything it possibly > can to revert that -- with a mixed result. > > This is a betwixt-and-between situation that does not help anybody, and > leads to bugs that are hard to identify (such as this one). > > So can we please, please, cleanly separate those buffer from the start? I take it that your patch essentially reverts the one I mentioned above. I'm happy for it to be reverted at this point. As far as the larger issues you mentioned are concerned, let's ponder those. Riki
Re: Error messages with lyx2.3
Le 15/05/2018 à 19:51, Enrico Forestieri a écrit : The problem seems to be in the calling code. This seems to happen for svgz files (compressed svg files). Actually, it seems to happen when the same image is included multiple times, irrespective of the type. See attached example. Bisect leads to a31d3dc6 as the commit that introduced this issue. Thanks Enrico. I will investigate whether something direct can be done and otherwise I will revert the patch. I still do not understand the exact relation between the patch and the convert code, but I will eventually find out. JMarc
Re: Error messages with lyx2.3
On Fri, May 11, 2018 at 06:13:31PM +0100, José Abílio Matos wrote: > On Thursday, 10 May 2018 18.32.00 WEST Scott Kostyshak wrote: > > Should I still do the above? I'm not sure if it would still be useful > > after reading the messages that came after this. > > > > Thanks for helping debug, > > > > Scott > > There is no need to. > > The problem seems to be in the calling code. This seems to happen for svgz > files (compressed svg files). Actually, it seems to happen when the same image is included multiple times, irrespective of the type. See attached example. Bisect leads to a31d3dc6 as the commit that introduced this issue. -- Enrico #LyX 2.2 created this file. For more info see http://www.lyx.org/ \lyxformat 508 \begin_document \begin_header \save_transient_properties true \origin unavailable \textclass article \use_default_options true \maintain_unincluded_children false \language english \language_package default \inputencoding auto \fontencoding global \font_roman "default" "default" \font_sans "default" "default" \font_typewriter "default" "default" \font_math "auto" "auto" \font_default_family default \use_non_tex_fonts false \font_sc false \font_osf false \font_sf_scale 100 100 \font_tt_scale 100 100 \graphics default \default_output_format default \output_sync 0 \bibtex_command default \index_command default \paperfontsize default \use_hyperref false \papersize default \use_geometry false \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 false \justification true \use_refstyle 1 \index Index \shortcut idx \color #008000 \end_index \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \paragraph_indentation default \quotes_language english \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 Standard \begin_inset Graphics filename placeholder.eps \end_inset \begin_inset Graphics filename placeholder.eps \end_inset \end_layout \end_body \end_document placeholder.eps Description: PostScript document
Re: LyX 2.3.1
On Tue, May 15, 2018 at 09:30:09AM +, Pavel Sanda wrote: > Richard Kimberly Heck wrote: > > I am working on this. I've managed to compile for Windows using mingw on > > Linux (amazingly easy, actually) but have not dealt with the packaging > > issues yet. Fortunately, someone who reported a bug to us seems as if > > they may have done so and is giving me some help. > > Given latest developments we should at least take down bundle installer > from web download section and advice users to install either texlive or > miktex on their own because my understanding is that miktex contained > in the bundle is broken so at least we stop spreading the buggy version. > > Any disagreement? That sounds reasonable, but I don't recall many reports from users who have installed the 2.2.3 bundle and reported problems. I guess the problem comes if they try to update MiKTeX after installing the 2.2.3 bundle? Scott signature.asc Description: PGP signature
Re: Musings from configure
On Tuesday, 15 May 2018 11.03.01 WEST Jean-Marc Lasgouttes wrote: > This has been fixed by Enrico at 6253cc4c51e4e3, right? > > JMarc After running again autogen.sh the problem went away. So I suspect that the answer is yes to your question. :-) -- José Abílio
Re: Musings from configure
Le 08/05/2018 à 16:08, José Abílio Matos a écrit : === The following minor problems have been detected by configure. === Please check the messages below before running 'make'. === (see the section 'Problems' in the INSTALL file) == The found moc compiler is for Qt moc-qt5 5.10.1 but the Qt library version is 5.10.1. This has been fixed by Enrico at 6253cc4c51e4e3, right? JMarc
Re: LyX 2.3.1
Richard Kimberly Heck wrote: > I am working on this. I've managed to compile for Windows using mingw on > Linux (amazingly easy, actually) but have not dealt with the packaging > issues yet. Fortunately, someone who reported a bug to us seems as if > they may have done so and is giving me some help. Given latest developments we should at least take down bundle installer from web download section and advice users to install either texlive or miktex on their own because my understanding is that miktex contained in the bundle is broken so at least we stop spreading the buggy version. Any disagreement? Pavel
Re: LyX master Work Area Disappears on Initial Save (Redraw issue?)
Le 15/05/2018 à 06:08, Richard Kimberly Heck a écrit : + // Do not trigger the painting machinery if we are not ready (see + // bug #10989). However, since macOS has turned the screen back at "black", I take it. Indeed. I pushed the patch to master. JMarc
Re: LyX 2.3.0 Regression Inquiry
Am Montag, den 14.05.2018, 13:51 -0400 schrieb Richard Kimberly Heck: > So probably 2d6173d8103 was a mistake: We should just have said that > you > can't do that. But that was before the includeonly support, I > believe, > so maybe it made sense then? I'm not sure. Note that it does not work anyway. Since we do what we can do dis- couple such a non-output parent in the latex output routine (via ignore_parent), the math macros are in fact _not_ inherited in standalone situations! Since nobody complained about that during the last years, I wonder whether this is really such a widespread usage. Anyway, currently our code contradicts itself: clone tries to include non-relevant parents, and the latex routine does everything it possibly can to revert that -- with a mixed result. This is a betwixt-and-between situation that does not help anybody, and leads to bugs that are hard to identify (such as this one). So can we please, please, cleanly separate those buffer from the start? > I wonder if it would help people here to have some LFUN that would > allow > one to "view only the child" in the way people want. What it would > do, > basically, is includeonly the current Buffer and its descendants, > then > view that. I.e., you wouldn't have to go to the master, fiddle with > those settings, and then view. So it would work kind of like > master-buffer-view, but take care of the includeonly stuff for you. > Then > again, that might not work in a lot of cases. E.g., you might need to > include the bibliography always---which is why Joel has that complex > ERT. (But then maybe there could be a setting for that? But maybe > that > gets too complicated) Sure, we can try and improve the includeonly UI. As for the math macros, though, I think the problem is a fundamental design flaw of math macros UI: they need to be defined in the main workarea currently, rather than in a sort of preamble that could be inherited by children _at wish_. I think implementing that would not be that hard now that we have the embedded workarea widget. A workaround for the moment is to define math macros in a separate file and input that at each buffer that needs them. I think people should do that. UI wise, I think something to ponder would be a kind of "common settings" (math macros, branches, and other things) that could be shared by a family of documents, notwithstanding whether they have a parent-child relationship or not. Something like Pavel's graphics group on a more abstract level. Jürgen > > Riki > signature.asc Description: This is a digitally signed message part
