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 a
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.
>>
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, update the strings on ma
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 f
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 shou
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 t
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.
>
>
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 an
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 en-dashes
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.
>> Alter
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.
>> Alter
Richard, OK for branch?
Georg
Georg Baum wrote:
> commit a6be519a815893765a257bec5a456d7f6eecf8f6
> Author: Georg Baum
> Date: Thu Sep 8 22:38:33 2016 +0200
>
> Fix data loss with [ in first cell of aligned
>
> If the first character in the first ce
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
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
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
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 from
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 ascii_num_get
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 facets (
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 synt
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
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
\de
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 fa
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 to
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 configura
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 f
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 us
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 know
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>CYGW
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. This is to a high de
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
Kornel Benko wrote:
> Am Sonntag, 10. Juli 2016 um 18:51:55, schrieb Georg Baum
>> - 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
> Imagemagick is needed by so
Kornel Benko wrote:
> Am Sonntag, 10. Juli 2016 um 18:51:55, schrieb Georg Baum
>
>> 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.
>
> Gettext
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
>
> C:\LyX\lyx-23-bu
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"
> -DLYX_DEPENDENCIES_DOWNLOAD:BOOL="
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 gc
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
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 d
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 n
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
>>
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 the
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 o
Georg Baum wrote:
> commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0
> Author: Georg Baum
> 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 keeps
> the cre
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
mos
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 attachment). I gues
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 distinguis
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 after
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 cred
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 on
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.
>>
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
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 remaini
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 see t
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 be
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)
-
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 com
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 part
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
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 t
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,
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
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
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
>>
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
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
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 = /hom
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 19.00
Kornel Benko wrote:
> Am Sonntag, 19. Juni 2016 um 19:23:14, schrieb racoon
>> On 19.06.2016 18:20, Georg Baum wrote:
>> > racoon wrote:
>
> ...
>
>> >
>> > The most important question now is why cmake does not find your C
>> > compiler
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
i
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
Kornel Benko wrote:
> Am Sonntag, 19. Juni 2016 um 13:52:02, schrieb Georg Baum
>
>>
>> OK, then we need to document that instead of QT_QMAKE_EXECUTABLE. What I
>> did not understand yet is how cmake finds Qt5CoreConfig.cmake. If I only
>> have $QTDIR/bin in $PA
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 cmake kno
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
> q
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 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 then?
Georg
Georg Baum wrote:
> commit 48fd76d4bfb99ee9dff20740c6b46683e36f043e
> Author: Georg Baum
> 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 not
> provided an
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
Kornel Benko wrote:
> Am Samstag, 18. Juni 2016 um 12:56:23, schrieb Georg Baum
>
>> 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)
>>
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 rece
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 in
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
> targ
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
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. Eve
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 o
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}
> 3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.c
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
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 the attached?
On
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 wa
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
Georg Baum wrote:
> commit 166420d02ccb073dc32ab5cd0bc466de54aa36bb
> Author: Georg Baum
> 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 conversions
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 unicode
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:
> /home/scott/lyxbuilds/master/repo/src/support/convert.cpp
Liviu Andronic wrote:
> Following JMarc's and Richard's furious hunting, we're now down to 22
> outstanding defects, down from about 200 we had originally during the
> first scan in 2015. At least as far as Coverity's checks go, we're
> starting to look pretty --- though I understand there are a c
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, if
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 develop
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
>
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 h
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: "platex.exe
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 u
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: *** [
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 optio
1 - 100 of 6177 matches
Mail list logo
