Re: Copying translations from 2.2.x to master?

Kornel Benko wrote: > So what is Uwe doing when he is re-merging? Probably calling > development/tools/mergepo.py. No. The workhose for remerging translations from the source code is po/lyx_pot.py. mergepo.py is only for merging between two branches without ptoducing huge nonsense diffs. > I

Re: Copying translations from 2.2.x to master?

Kornel Benko wrote: > Am Samstag, 10. Juni 2017 um 10:41:43, schrieb Georg Baum >> >> I would suggest to use git correctly instead of fixing broken line ends >> again and again, producing huge nonsense diffs. We had this discussion >> several times in the past. >>

Re: Copying translations from 2.2.x to master?

Kornel Benko wrote: > Am Sonntag, 4. Juni 2017 um 10:33:02, schrieb Scott Kostyshak > >> On Sun, Jun 04, 2017 at 12:17:27PM +0200, Kornel Benko wrote: >> >> > > Unless someone has a different idea, I will replace the Windows >> > > linebreaks with non-Windows linebreaks,

Re: Copying translations from 2.2.x to master?

Scott Kostyshak wrote: > On Sat, Jun 03, 2017 at 08:07:39PM -0400, Scott Kostyshak wrote: > >> Unless someone has a different idea, I will replace the Windows >> linebreaks with non-Windows linebreaks, update the strings on master, >> and try the mergepo.py call above again. > > After Kornel's

Re: dashes and line-breaks (#10543)

Am 26.05.2017 um 21:54 schrieb Scott Kostyshak: On Fri, May 19, 2017 at 09:12:27AM -0400, Scott Kostyshak wrote: Günter has written a lot about what to do regarding em- and en-dashes. For more information, see: http://www.lyx.org/trac/ticket/10543 Does anyone else have feedback on what

Re: LyX 2.2 cannot read a document from LyX 2.1?

José Abílio Matos wrote: > On Tuesday, 7 March 2017 12.39.19 WET Enrico Forestieri wrote: >> > Is this a valid process that we should support? >> >> Given that lyx2lyx processes text files, taking into account that they >> may have a BOM is safer. I agree. Some text editors decide to add a BOM

Re: Regular expression search

Guillaume Munch wrote: > AFAIR, the ECMAScript regexes are a proper subset of PCRE whereas there > are incompatibilities between POSIX and PCRE. Moreover ECMAScript is the > default for , so maybe it is better supported across compilers. > This makes ECMAScript the simplest for a transition. > >

Re: EmDash Problems (patch)

Guenter Milde wrote: > Not "perfect" (but maybe "satisfactory"): There may be issues with > documents containing literal Unicode dashes: these may now have different > line breaks. If this is an issue then it was already an issue when format 481 was introduced (because we changed -- to U+2013

Re: EmDash Problems (patch)

Enrico Forestieri wrote: > This seems to have been done on purpose. But I don't understand why. > The attached patch corrects this glitch and I am going to commit it > because I really don't see any rationale behind this behavior. This is part of the code that tried to make the input of

Re: EmDash Problems (patch)

Jean-Marc Lasgouttes wrote: > Le 24/01/2017 à 23:57, Richard Heck a écrit : >> I agree with Enrico that we should revert to the previous behavior. What >> we could also do, though, is provide SOME easy way (a shortcut?) for >> people to insert \textemdash, if that is what they want to do. >>

Re: EmDash Problems (patch)

Jean-Marc Lasgouttes wrote: > Le 24/01/2017 à 23:57, Richard Heck a écrit : >> I agree with Enrico that we should revert to the previous behavior. What >> we could also do, though, is provide SOME easy way (a shortcut?) for >> people to insert \textemdash, if that is what they want to do. >>

Re: [LyX/master] Fix data loss with [ in first cell of aligned

Richard, OK for branch? Georg Georg Baum wrote: > commit a6be519a815893765a257bec5a456d7f6eecf8f6 > Author: Georg Baum <b...@lyx.org> > Date: Thu Sep 8 22:38:33 2016 +0200 > > Fix data loss with [ in first cell of aligned > > If the first

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

Richard Heck wrote: > On 09/06/2016 06:10 PM, Georg Baum wrote: >> Richard Heck wrote: >> >>> On 09/05/2016 04:56 PM, Georg Baum wrote: >>>> I think he meant the missing .xlsx extension in the external material >>>> file dialog. I added this in mas

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

Richard Heck wrote: > On 09/05/2016 04:56 PM, Georg Baum wrote: >> I think he meant the missing .xlsx extension in the external material >> file dialog. I added this in master at df8e0ed9e0c37ab7. > > Fine for stable too. I need 646d47ae9393bc for stable too, otherwise

Re: [patch] Experiment with c++11 unicode strings

Guillaume Munch wrote: > Le 30/08/2016 à 21:12, Georg Baum a écrit : >> Guillaume Munch wrote: >> >>> >>> * Why ascii_num_get_facet::do_get uses from_local8bit at some >>> point. >> >> The encoding does not matter here: Our own numpunct_fac

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

Helge Hafting wrote: > Den 05. sep. 2016 00:53, skrev Jannick: >> Currently lyx deals with *.xls files only, while the Excel world rather >> turns around .xlsx files. It would be great if lyx could be extended >> including the file handler where ssconvert appears to faithfully extract >> data

Re: [patch] Experiment with c++11 unicode strings

Guillaume Munch wrote: > I made it work with libc++ too, which was not straightforward. In this > case, the template is undefined and cannot be inherited from. > > Could you or somebody else please double-check the following, which I am > not sure to understand correctly: > > * Why

Re: [patch] Experiment with c++11 unicode strings

Guillaume Munch wrote: > Le 22/08/2016 à 20:56, Georg Baum a écrit : >> Guillaume Munch wrote: >> >>> This is not the final version >>> of the patch however because there is one big disappointment: the C++11 >>> standard does not require several facet

Re: [patch] Experiment with c++11 unicode strings

Guillaume Munch wrote: > Dear all, > > Here's a few patches proposing to improve the definitions in > support/strfwd.h, results of my experiments. > > 1. Define docstring using the Unicode strings from C++11 (with > char_type=char32_t). This allows us to write docstrings directly with > the

Re: lib/symbols issue

Georg Baum wrote: > Am 05.08.2016 um 21:11 schrieb Richard Heck: > >> So far as I can see, the fourth of these, in whichever version, is never >> used in the existing code. > > This was added because the macro machinery did support it already. small correction: it i

Re: lib/symbols issue

Am 05.08.2016 um 21:11 schrieb Richard Heck: When Georg added the ability to assign HTML entities to global math macros, as cc87f810, a comment in the code said: syntax: Either \def\macroname{definition} or \def\macroname{definition} requires or \def\macroname{definition} requires xmlname or

Re: master is no longer compilable because of required polib library

Pavel Sanda wrote: > Kornel Benko wrote: >> This is a consequence of your previous mail stating >> 1> ImportError: No module named polib >> >> Surprisingly I get this error also in the 2.2.x branch. (I will open a >> bug report for this.) >> The wrong part was that cmake didn't care about the

Re: master is no longer compilable because of required polib library

Uwe Stöhr wrote: > I don't think that one needs to have polib installed to be able to > compile LyX. It is not required for compiling LyX. It is only required if you remerge translation strings. > Moreover, I still don't know from where I can install this > library. This info should be added

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 11.07.2016 17:43, racoon wrote: >> >> If I provide just those CMake gives me an error: >> >> --- >> >> Make Error at CMakeLists.txt:601 (find_package): >> By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project >> has >> asked CMake to find a package

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 11.07.2016 16:05, racoon wrote: >> >> Did click on "Build" (is that the same as compile?) from the context >> menu of "LyX" in the Solution Explorer. And it compiled with no errors. Yes I meant build (this is the MSVc terminology). >> Pressed F5, got a message about outdated

Re: Compiling with Microsoft Visual C++

Richard Heck wrote: > If you're running LyX from a terminal, you should get some output > explaining why reconfiguration is failing. Unfortunately this is more complicated on windows than on other operating systems. An application is either a console application (with stdin/stdout/stderr and

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 12.07.2016 16:48, Richard Heck wrote: >> >> The python executable is not being found. Is it in your path? I would >> guess that this is something the installer usually takes care of. > > Thanks. The python path was actually not in my path variable. Now it > works. I don't

Re: Compiling with Microsoft Visual C++

racoon wrote: > Final warnings I get are of the following form: > > 3> Generating LyX2.3.pot > 3>CUSTOMBUILD : cygwin warning : > 3>MS-DOS style path detected: C:/LyX/lyx-23-build/po/POTFILES.in > 3>Preferred POSIX equivalent is: > /cygdrive/c/LyX/lyx-23-build/po/POTFILES.in > 3>

Re: How to create a patch with git gui

racoon wrote: > On 12.07.2016 14:58, Stephan Witt wrote: >> >>> Am 12.07.2016 um 14:20 schrieb racoon : >>> >>> I really don't like the windows command line. The native cmd.exe is indeed too limited. IMHO it does not matter whether you use git via a gui or from command line.

Re: [LyX/master] Fix windows dependencies download

PS: I have not forgotten you Guillaume (and other messages in my list), but I am running out of time again, I hope I'll can do it tomorrow or tuesday. Georg

Re: [LyX/master] Fix windows dependencies download

Kornel Benko wrote: > Am Sonntag, 10. Juli 2016 um 18:51:55, schrieb Georg Baum <b...@lyx.org> >> - perl, python, imagemagick etc are only needed to build the installer. > > Perl is needed by TL too (Probably provided by MikTeX?) > Python is needed by lyx2lyx > Im

Re: [LyX/master] Fix windows dependencies download

Kornel Benko wrote: > Am Sonntag, 10. Juli 2016 um 18:51:55, schrieb Georg Baum <b...@lyx.org> > >> If we could change the setup the installation of >> gettext would become an optional step that only those need to do who >> wnat to work on the translations.

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 09.07.2016 17:33, racoon wrote: > > Next, I copy the dependencies. The culprit is, however, that there is > > no lyx.exe in > > C:\LyX\lyx-23-build\msvc2015-deps\lyx-windows-deps-msvc2015\bin... so I > > can't execute it. > > There are LyX.exe files in > >

Re: Compiling with Microsoft Visual C++

racoon wrote: > Okay, next step taken, I think. > > I set a couple of paths in CMAKE. Here is the "Show My Changes" output: > > --- > > Commandline options: > -DLYX_USE_QT:STRING="QT5" > -DQt5Widgets_DIR:PATH="C:\Qt\Qt5.6.1\5.6\msvc2015\lib\cmake\Qt5Widgets" >

Re: [LyX/master] Ensure that iconv and zlib are always found

Kornel Benko wrote: > Did it at a51847f. > > By the way, I get these linkage error independently if I select both (z + > iconv) as local or only one of them. Tested each time on empty build build > tree. Thank you very much. I am sorry for the trouble and might have a look with a more recent

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 04.07.2016 09:11, racoon wrote: >> "Compile the INSTALL project to get a LyX installation in >> C:\LyX\lyx-23-install" >> >> I guess it means opening "INSTALL.vcxproj" and STRG-F5. Getting >> >> "Build: 14 succeeded, 12 failed, 0 up-to-date, 0 skipped" Congratulations! You are

Re: Anonymous functions: replace bind with lambdas

Guillaume Munch wrote: > I have split the patch in two for you, and already committed the part > that does not introduce lambda expressions. Attached is the remainder of > the patch that replaces all remaining std::bind with lambda expressions. Thanks. I am currently swamped with work, and this

Re: make distcheck: cannot remove '../../po/lyx.pot'

Pavel Sanda wrote: > This was a tough one. distcheck was broken for a while (while showing it's > famous lyx.pot message) and bisecting nowadays master is like walking > through the minefield where bunch of commits do not compile at all or git > gets crazy due to cr-lf mismanagement. I still do

Re: [LyX/master] Move duplicated symbols to the macro section

Enrico Forestieri wrote: > On Sun, Jul 03, 2016 at 08:07:46PM +0200, Enrico Forestieri wrote: > >> On Sun, Jun 26, 2016 at 08:36:48PM +0200, Georg Baum wrote: >> >> > commit 343a379b88e35778f358742e134c61b552bcabb3 >> > Author: Georg Baum <b...@lyx.org

Re: [LyX/master] Ensure that iconv and zlib are always found

Kornel Benko wrote: > No, sorry. Looks like the same quadrillion error messages. I do not understand how these errors could be related to my commit. Do they go away if you call cmake without LYX_3RDPARTY_BUILD? > Trying now with clean build tree: > ... > Same result. As an example, this is

Re: [LyX/master] Ensure that iconv and zlib are always found

Kornel Benko wrote: > I cannot compile anymore with this change with cmake. > Previously selecting LYX_3RDPARTY_BUILD, I was able to compile and bind > with our hunspell sources. > Now the compilation is OK too, but if it comes to bind I have many > unsatisfied references. > > Will try to find

Re: [LyX/master] Fix CAS input on windows (bug 10262)

Georg Baum wrote: > commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0 > Author: Georg Baum <b...@lyx.org> > Date: Sat Jul 2 18:58:30 2016 +0200 > > Fix CAS input on windows (bug 10262) > > This is the well known file locking problem: The TempFile class k

Re: compilation error in branch and master

Uwe Stöhr wrote: > Am 02.07.2016 um 17:34 schrieb Uwe Stöhr: > >> I still get the same compilation error: > > Very, very weird: I just recompiled it without changing anything. it is > incredible but now it compile. Did you recompile at least once after the compiler upgrade? If not this was

Re: [LyX/master] By default, charstyles should not permit layout changes internally.

Richard Heck wrote: > commit 152817576adaefaa1be8f124b9feecd5c2bfd7c2 > Author: Richard Heck > Date: Mon Jun 20 11:30:32 2016 -0400 > > By default, charstyles should not permit layout changes internally. > > Fixes #10237. This makes the tex2lyx tests fail (see

Re: compilation error in branch and master

Am 02.07.2016 um 03:19 schrieb Uwe Stöhr: No, I created separate folders for every git branch to be able to use different CMake configs for every branch. Very good. Please send CMakeError.log There is no such file. and CMakeOutput.log This one is attached. Here we need to

Re: Do we want to keep any temporary files after a compilation error?

Scott Kostyshak wrote: > If not, it seems we can just have a fresh start when compiling again > after an error. That is, instead of using the hard-coded list, we just > remove all temporary files. +1 The temporary files can be useful for error analysis, so they should not be deleted right

Re: Reintroduce Windows Vista compatibility for 2.2.0+

Richard Heck wrote: > On 07/01/2016 04:13 PM, Georg Baum wrote: >> >> Richard, OK for branch as well? > > Yes, that's fine. OK, it is in. > Did anyone add Dima to the credits? I did forget that originally, but now it is done. Someone just needs to update the credi

Re: Reintroduce Windows Vista compatibility for 2.2.0+

Dima Ruinskiy wrote: > As of version 2.2.0, LyX no longer works out of the box on Windows Vista, > probably because of some default settings in MSVC2015. > > > This patch fixes that by forcing a PSAPI version that is compatible with > Vista as well as later versions of Windows. > > > Tested

Re: compilation error in branch and master

Richard Heck wrote: > On 06/30/2016 07:36 PM, Uwe Stöhr wrote: >> compiling today's 2.2.x branch and master I get this compilation error: >> >> environment.cpp >> D:\LyXGit\Master\src\support\environment.cpp(73): fatal error C1189: >> #error: No environment-setting function has been defined.

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 25.06.2016 20:41, Georg Baum wrote: >> >> This is strange. This file created the error in the CMakeError.log you >> sent some days ago. Maybe this directory does not exist anymore after you >> reinstalled the SDK? If the current CMakeError.log look

Re: Anonymous functions: replace bind with lambdas

Guillaume Munch wrote: > Dear list, > > > Here is a patch that removes all uses of std::bind and boost::bind in > src/. I think this is something that we want in the long term, because > it makes the changed code much more readable and maintainable. You mean std::bind, or did I miss any

Re: workaround to 'git reset --hard' not working because of .gitattributes

Scott Kostyshak wrote: > On Sun, Jun 26, 2016 at 07:46:21PM +0100, Guillaume Munch wrote: >> Le 26/06/2016 18:08, Georg Baum a écrit : > >> > Funnily I never saw that >> > myself, but it should be fixed at 933bc7f0ddf. PLease tell me if you >> > ever

Re: workaround to 'git reset --hard' not working because of .gitattributes

Scott Kostyshak wrote: > I think this is due to the recent fixes in .gitattributes. In any case, > git reset --hard does not fix anything. But the following does work for > me: Yes, this was caused by the introduction of .gitattributes, since these files were checked in with windows line ends

Re: new LyX 2.2.0 installer for Windows Vista is available

Richard Heck wrote: > I'll ask again: What is the status of the mingw build? Last I heard, it > built our executables fine and the only issue was with building the > installer. The mingw build works fine in several flavours: -natively on windows as described in INSTALL.Win32 (uses autotools) -

Re: using directives in headers

Guillaume Munch wrote: > Agreed. While the only advices to avoid "using" in headers I could find > are about "using namespace", I do not see a reason either not to have as > a rule what you wrote. IMHO the only difference between using complete namespaces or single symbols is statistics: For

using directives in headers

I recently stumbled upon using std::shared_ptr; or lyx::support::FileName; in header files (e.g. TocBackend.h). The shared_ptr was introduced as part of the lyx::shared_ptr removal (which did either point to boost or std), but there are other hits as well. While I understand that in this

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 25.06.2016 18:16, Georg Baum wrote: >> >> You could also send me (privately please) the file C:\Program Files >> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140\Toolset.targets, >> maybe I have then an idea about po

Re: new LyX 2.2.0 installer for Windows Vista is available

Uwe Stöhr wrote: > Richard, could you please put it on ftp.lyx.org? Could you please also > write a news message that we now have a Vista installer but that this > installer should not be used for other Windows versions than Vista. This is not possible for legal reasons. Our own license forbids

Re: Joining LyX development team

Hi Dima, welcome from me as well! We can always need some helping hands, and as you might have found out already especially windows build procedure needs help. Dima Ruinskiy wrote: > Richard Heck lyx.org> writes: > >> Is there something specific you'd like to work on? >> > Nothing specific,

Re: new LyX 2.2.0 installer for Windows Vista is available

Jean-Marc Lasgouttes wrote: > I am not completely sure why we are having this surreal discussion. Uwe, > what is wrong with the following? > 1/ Dima provides a patch that makes a Vista compatible build > 2/ Kornel checks that the cmake part good enough for inclusion > 3/ Uwe does his usual builds

Re: Compiling with Microsoft Visual C++

racoon wrote: > Thanks for the sustained support! You are welcome! I do it because building LyX on windows should be as easy as it is on unix. Unfortunately this is not yet the case, and your help in trying out different tests is appreciated as well. > On 21.06.2016 22:02, Georg Baum

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 20.06.2016 22:10, Georg Baum wrote: >> >> Good, that brings us a step further. I assume you have the Windows >> Platform SDK installed? If not, please install it from >> https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk >>

Re: LyX 2.2.0 Linux Compilation Error

Joel Kulesza wrote: > Still the same error as before. :-( However, I appreciate your time > considering this! OK, then I have no idea anymore. Hopefully the new install will fix it. Georg

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 20.06.2016 10:14, racoon wrote: >> On 19.06.2016 20:02, Georg Baum wrote: >>> >>> Yes. Does cmake still not recognize the compiler if you call it from >>> that command window? In that case please send the CMakeError.log and >>> CMake

Re: LyX 2.2.0 Linux Compilation Error

Joel Kulesza wrote: > All the gore and carnage for the failing source file from the configure > with "--disable-silent-rules" below my signature. > > I did try compiling with CMake and see the error(s) below: > > 1026 jkulesza@machine[~/SRC/lyx220/build_cmake]> cmake ../. > -- TOP_SRC_DIR =

Re: Compiling with Microsoft Visual C++

racoon wrote: > In a common command window cl is not found. This is actually good. It means your PATH is not poisoned by specific MSVC tools. > But if I start > > 1) Open Developer Command Prompt for VS2015 > 2) call 'cl -v' > > I get > > Microsoft (R) C/C++ Optimizing Compiler Version

Re: Compiling with Microsoft Visual C++

Kornel Benko wrote: > Am Sonntag, 19. Juni 2016 um 19:23:14, schrieb racoon <xraco...@gmx.de> >> On 19.06.2016 18:20, Georg Baum wrote: >> > racoon wrote: > > ... > >> > >> > The most important question now is why cmake does n

Re: LyX 2.2.0 Linux Compilation Error

Sorry, I overlooked this (please post always to the list, then others can help as well). Am 12.06.2016 um 23:47 schrieb Joel Kulesza: For the sake of complete communication: I've seen failures with 4.6.1, 4.9.2, and 5.3.0. At this point, I'm not sure of a way to proceed without a deep dive

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 19.06.2016 16:09, Georg Baum wrote: >> >> If you use the paths listed in INSTASLL.Win32, then you would need to >> unpack it in the folder C:\LyX\lyx-23-build\msvc2015-deps. This would >> create a folder C:\LyX\lyx-23-build\lyx-windows-deps-ms

Re: Compiling with Microsoft Visual C++

Kornel Benko wrote: > Am Sonntag, 19. Juni 2016 um 13:52:02, schrieb Georg Baum > <georg.b...@post.rwth-aachen.de> >> >> OK, then we need to document that instead of QT_QMAKE_EXECUTABLE. What I >> did not understand yet is how cmake finds Qt5CoreConfig.cmake

Re: Compiling with Microsoft Visual C++

racoon wrote: > On 19.06.2016 14:41, Georg Baum wrote: >> >> Please try Visual Studio 14 instead (or however MSVC2015 is called in >> cmake, 14 is the internal MSVC version corresponding to the 2015 >> release). MSVC 2015 can load MSVC 2010 solutions, but if cma

Re: Compiling with Microsoft Visual C++

Kornel Benko wrote: > He claimed to have installed QT5.7. > We are using find_package(Qt5Core REQUIRED) > The module (not part of cmake but part of qt) is named > /Qt5CoreConfig.cmake. So it depends of where he installed his > QT and if he has the correct path set. It may be sufficient to know >

Re: Compiling with Microsoft Visual C++

racoon wrote: > Hi, > > I'd like to compile LyX on my Win7 machine. However, I get errors when I > try to compile LyX even though I tried to follow the instruction step by > step. Maybe someone can help: Unfortunately the instructions are outdated (details below). It would be very nice if you

Re: Compiling with Microsoft Visual C++

Kornel Benko wrote: > Am Samstag, 18. Juni 2016 um 18:15:51, schrieb racoon >> >> > - Set QT_QMAKE_EXECUTABLE to e.g. >> > C:\Qt\qt-everywhere-opensource-src-4.8.4\bin\qmake.exe >> > and Configure again. > > I think, this is important only if you use QT4 How is qt5 found

Re: [LyX/master] Fix windows dependencies download

Georg Baum wrote: > commit 48fd76d4bfb99ee9dff20740c6b46683e36f043e > Author: Georg Baum <b...@lyx.org> > Date: Sun Jun 19 12:47:30 2016 +0200 > > Fix windows dependencies download > > The paths and servers have changed, and a MSVC 2013 version is

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

Scott Kostyshak wrote: > On Tue, Jun 14, 2016 at 08:45:28PM -0400, Scott Kostyshak wrote: >> On Tue, Jun 14, 2016 at 10:24:18PM +0200, Georg Baum wrote: >> >> > The xmingw script works fine for me BTW with the monolithic build. >> >> What is your version? K

Re: Interpreting file names for use with lyx2lyx

Kornel Benko wrote: > Am Samstag, 18. Juni 2016 um 12:56:23, schrieb Georg Baum > <georg.b...@post.rwth-aachen.de> >> Kornel Benko wrote: >> >> > Thanks for clarification. Nonetheless, we have a mess here. >> > 1.) Reading .lyx without need to conve

Re: Interpreting file names for use with lyx2lyx

Kornel Benko wrote: > Thanks for clarification. Nonetheless, we have a mess here. > 1.) Reading .lyx without need to convert (e.g. in current lyx-format) > works regardless of environment (This is done by lyx directly, without > interpreting the file-name) Probably because you loaded it from

Re: Interpreting file names for use with lyx2lyx

Kornel Benko wrote: > Setting 'wrong' lang environment causes lyx to use different encoding for > filenames. > > Setting > export LANG="en_IE@euro" > > Now, reading the file "Testoübernahme.lyx" which needs conversion leads to > this log snippet: > > support/TempFile.cpp (35): Temporary file

Re: One official build system?

Georg Baum wrote: > Kornel Benko wrote: > >> So it is a built and removed source. Should it be ditributed? > > I don't think so. But I do not understand how to implement that. It seems > that automake evalutes all if-branches when adding file to the *_DIST > targets.

Re: One official build system?

Kornel Benko wrote: > I see, but this one is from automake, not from cmake (where one would > expect it). I don't have it local. The question mark is there, because I > didn't knew, where it came from). Searching now... A sorry, I was confused. This file is for the monolithic build, and we have

Re: One official build system?

Kornel Benko wrote: > Am Dienstag, 14. Juni 2016 um 22:37:58, schrieb Georg Baum > >> The icons and the regex files are indeed a serious problem. The icons >> should be fixed now, this was simply a wrong style of using variables. > > It does not look like that.

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > What error is it? ../../src/MetricsInfo.cpp:61:4: error: type ‘lyx::MetricsBase’ is not a direct base of ‘lyx::MetricsBase’ BTW, if it is possible to keep gcc 4.6 supported for a while with little effort I am in favour of this as well, and I can do also some testing

Re: One official build system?

Kornel Benko wrote: > The result is that cmake part misses > Makefile.in > automake misses > lib/fonts/*.sfd (11 files) > lib/images/ipa/*.svgz (30 files) > lib/images/oxygen/*.svgz (88 files) > src/mathed/InsetMathXYArrow.{cpp,h} >

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

Scott Kostyshak wrote: > Thanks to your comment, I realized that when I copy the master directory > to e.g. master-mingw, the lyx-dependencies folder came with the copy. I > removed that directory, and then removed the monolithic build option, > and now it works for me. To me it does rather look

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Le 14/06/2016 16:38, Jean-Marc Lasgouttes a écrit : > >> but of course RefChange >> proved more difficult. I tried to define it as a subclass of >> unique_ptr, but then my C++11 default skills showed >> their weakness. > > What errors does it give with

Re: #10214: Fail to Compile LyX with Visual C++ 2015

Kornel Benko wrote: > I'd like to remove the file development/cmake/configCompiler.h.msvc. It > was meant as a cache-like set for compiler settings for msvc. +1 > As a first step I want to disable the possibility to select this bypass > (see attached) I expect this works for windows, but will

Re: Why is the filesystemencoding needed for \origin lyx2lyx?

Enrico Forestieri wrote: > On Sun, Jun 12, 2016 at 07:21:48PM +0200, Georg Baum wrote: > >> Hi Enrico, >> >> you added an encoding conversion in lyx2lyx here: >> http://www.lyx.org/trac/changeset/a0afd345/lyxgit >> >> Can you please expl

Re: [LyX/master] Make lyx2lyx infrastructure python3 ready

Georg Baum wrote: > commit 166420d02ccb073dc32ab5cd0bc466de54aa36bb > Author: Georg Baum <b...@lyx.org> > Date: Sun Jun 12 21:21:15 2016 +0200 > > Make lyx2lyx infrastructure python3 ready > > The LyX class works now with python 3. Certain file format

Why is the filesystemencoding needed for \origin lyx2lyx?

Hi Enrico, you added an encoding conversion in lyx2lyx here: http://www.lyx.org/trac/changeset/a0afd345/lyxgit Can you please explain why this is needed, but not on windows? I ask because this conversion does not work with python 3: All strings, also the ones returned by os.path, are

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

Scott Kostyshak wrote: > I tried xmingw-script on current master but it does not succeed for me. > > I get the following: > > error: > In file included from > /home/scott/lyxbuilds/master/CMakeBuild/src/support/_allinone_const.C:118:0: >

Re: "Reconfigure" gives an error

Andrew Parsloe wrote: > What puzzled (& puzzles) me is that the warning doesn't arise with > 2.1.4, nor when 2.2.0 is installed. This is strange. If you want you could try out whether the error happens as well if you start platex.exe manually. If yes, then it is definitely a MikTeX problwem,

Re: [LyX/master] Add missing includes after change to boost signals2

Jean-Marc Lasgouttes wrote: > Le 12/06/2016 12:14, Stephan Witt a écrit : >>> Different structure of headers, just switching between different gcc >>> versions and their accompanied libs is enough to trigger such errors on >>> the same system. >> >> I’m not used to this behavior with other

Re: Errors in lib/lyx2lyx/LyX.py with python3

Kornel Benko wrote: > All tests with lyx2lyx fail with: > -- Executing /usr/bin/python3 /usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx -e > qwbwf -o 8dqNDg /usr2/src/lyx/lyx-git/lib/doc/Math.lyx Traceback (most > recent call last): > File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx", line 88, in >

Re: CMake + clang failure

Kornel Benko wrote: > I have a check for regex, what about the attached? > 1.) Determine if 'regex-source' compiles in FindCXX11Compiler.cmake > 2.) Use the value in case of 'clang' in CMakeLists.txt Perfect, thanks a lot! > Maybe we should use this value unconditionally? This would depend on

Re: "Reconfigure" gives an error

Andrew Parsloe wrote: > On 11/06/2016 5:32 p.m., CarLaTeX wrote: >> Hi LyX developers, >> >> I've installed LyX 2.2.0 on Windows 10 (distribution for LaTeX: MiKTeX >> 2.9). >> When I use "Tools > Reconfigure" I get this error: >> Immagine incorporata 2 >> I try to translate in English:

Re: CMake + clang failure

Kornel Benko wrote: > OK, but my second question is not answered. To what value should > LYX_USE_STD_REGEX be set? It should be autodetected. The algorithm of autotools is: detect presence of . If available and compiler is clang, use std::regex. This is however not 100% correct: If clang is

Re: [LyX/master] Autotools: restore deprecation warning

Stephan Witt wrote: > Now we have a linker problem: > > CXXLDlyx > clang: error: no such file or directory: '../3rdparty/boost/liblyxboost.a' > make[4]: *** [lyx] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: ***

Re: LyX 2.2.0 Linux Compilation Error

Joel Kulesza wrote: > I have gcc 4.6.1, 4.7.0, 4.7.2, 4.8.2, 4.9.2, and 5.3.0 available. Are > any > of those known to be particularly successful with this vintage of Qt? If > not, I'm afraid I'll be without 2.2.0 on this system (I am not the admin > so simply installing a package isn't an

Re: CMake + clang failure

Kornel Benko wrote: > Should we really ignore output of '${CMAKE_CXX_COMPILER} -dumpversion'? In case of clang yes, since clang outputs an arbitrary number which has nothing to do with the clang version. Sooner or later we will need clang version tests as well (and then we will need to figure

  1   2   3   4   5   6   7   8   9   10   >