On 6/07/2016 2:16 a.m., José Abílio Matos wrote:
Could you, please, test the following (independent) tests:
1) take the compressed ".21.lyx" created with 2.2 use an
external program to decompress that file and see if lyx 2.1 opens that file?
2) use lyx 2.1 to create a compressed file, save i
Am Dienstag, 5. Juli 2016 um 21:53:49, schrieb Georg Baum
> 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
Le 02/07/2016 23:43, Guillaume Munch a écrit :
On the other hand, it is possible to prioritise LyX shortcuts by using
the shortcut override mechanism. This would solve both bugs
http://www.lyx.org/trac/ticket/10261 and
http://www.lyx.org/trac/ticket/10119 (probably),
and alleviate the occasiona
On 07/05/2016 03:36 PM, Daniel wrote:
> On 05.07.2016 16:22, Richard Heck wrote:
>> On 07/04/2016 02:42 PM, racoon wrote:
>>> On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
Le 04/07/2016 à 15:38, racoon a écrit :
> Thanks. Still I am wondering a bit why anything special at all is
> n
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
>> > Date: Sun Jun 26 20:23:46 2016 +0200
>> >
>> >
Am Dienstag, 5. Juli 2016 um 18:17:40, schrieb Jean-Marc Lasgouttes
> Le 05/07/2016 à 17:47, Kornel Benko a écrit :
> > Cmake tries to use -std=c++14 first, then c++11, gnu++11, gnu++0x
> >
> > See development/cmake/modules/FindCXX11Compiler.cmake:50
>
> Very interesting code, thanks. Concernin
Guillaume Munch wrote:
> Le 05/07/2016 18:37, Pavel Sanda a écrit :
>>
>> I figured out that the linking problem disappears when building from clean
>> tree.
>> unistd.h is still needed (configure --enable-build-type=rel , automake
>> 1.15, autoconf 2.69).
>>
>
> This unistd.h problem is very str
Le 05/07/2016 18:37, Pavel Sanda a écrit :
I figured out that the linking problem disappears when building from clean tree.
unistd.h is still needed (configure --enable-build-type=rel , automake 1.15,
autoconf 2.69).
This unistd.h problem is very strange. I could compile without errors or
w
Le 05/07/2016 18:40, Pavel Sanda a écrit :
wrote in the other mail, but to be clear i don't expect you to test
all possible gcc or auttools variants before commiting stuff, we have
to live with bugs like that. p
Thank you for your patience.
Guillaume Munch wrote:
> I am really curious to know Pavel's configure line given that he uses
> gcc. If I could reproduce the problems then I would be able to test
> beforehand more thoroughly when useful.
wrote in the other mail, but to be clear i don't expect you to test
all possible gcc or aut
Pavel Sanda wrote:
> Pavel Sanda wrote:
> > Guillaume Munch wrote:
> > > Le 04/07/2016 02:20, Pavel Sanda a écrit :
> > >> anyone can reproduce this (gcc 4.9.3):
> > >
> > > Not with 4.6 nor with 5.3 but there are probably configure switches
> > > involved.
> >
> > Indeed, the bug s triggered when
Jean-Marc Lasgouttes wrote:
> Comments welcome. My plan is to use that for both Qt4 and Qt5 (for
> simplicity). Seeing the different behavior of Qt 4.8.1 and 4.8.7 (albeit
> different machines), I suspect that the problem is elsewhere in the
> configuration.
>
> I would be glad to have numbers f
Le 05/07/2016 à 17:52, Guillaume Munch a écrit :
Le 05/07/2016 17:23, Jean-Marc Lasgouttes a écrit :
We have compiled for ages in gnu++98 mode forever when not using C++11.
And currently gcc 6 uses gnu++14 by default. Do you want me to force
c++14 instead?
If this brings the behaviour of gcc
Le 05/07/2016 à 17:47, Kornel Benko a écrit :
Cmake tries to use -std=c++14 first, then c++11, gnu++11, gnu++0x
See development/cmake/modules/FindCXX11Compiler.cmake:50
Very interesting code, thanks. Concerning the regex code, I saw the
stackexchange question already, but it did not occur to
Le 05/07/2016 17:23, Jean-Marc Lasgouttes a écrit :
We have compiled for ages in gnu++98 mode forever when not using C++11.
And currently gcc 6 uses gnu++14 by default. Do you want me to force
c++14 instead?
If this brings the behaviour of gcc closer to that of other compilers,
then why not?
Am Dienstag, 5. Juli 2016 um 17:23:40, schrieb Jean-Marc Lasgouttes
> Le 05/07/2016 à 12:23, Guillaume Munch a écrit :
> >> I figured that the difference were minimal, but if I am wrong I can
> >> revert this part of course. Only cygwin requires gnu++11.
> >
> > As far as I understand, the differ
Le 05/07/2016 à 12:23, Guillaume Munch a écrit :
I figured that the difference were minimal, but if I am wrong I can
revert this part of course. Only cygwin requires gnu++11.
As far as I understand, the difference is precisely to enable
non-standard extensions. I do see the point of disabling n
Developers:
By way of update:
- I was able to compile against Qt 5.3 and Qt 5.5 using configure but
with neither using cmake
- With both configure and cmake, my PATH and LD_LIBRARY_PATHs were
identical. Cmake would begin compiling, but a series of errors
would occur
in the Q
On 07/05/2016 06:00 PM, Uwe Stöhr wrote:
> Am 04.07.2016 um 12:05 schrieb Jean-Marc Lasgouttes:
>
>> I'd say that only regressions could be important. Other than that, it is
>> always better to let a good release out than to wait for a perfect one.
>
> +1
>
> it seems that only http://www.lyx.org/t
Le 05/07/2016 à 16:28, Richard Heck a écrit :
Can you give a receipe for producing them? I'm ignorant about profiling.
(In my case, this would be on Linux.)
Actually, the patch is already instrumented (see below). So all you need
to do is produce a build without run-time debugging. A good way
Le 04/07/2016 à 20:42, racoon a écrit :
On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
Le 04/07/2016 à 15:38, racoon a écrit :
Thanks. Still I am wondering a bit why anything special at all is
necessary.
Well, I am glad I do not have dangling list items like Word gladly
creates.
Thanks. N
On 07/05/2016 10:06 AM, Jean-Marc Lasgouttes wrote:
> The attached patch implements a cache around the function
> GuiFontMetrics::breakAt, which has been identified as very slow by
> Guillaume. To this end, I use a plain QCache object.
>
> This patch is also instrumented using pmprof.h. When I load
Le 05/07/2016 à 16:26, Richard Heck a écrit :
If this proves to work correctly (i.e. if --enable-qt5 is all it takes
to switch from Qt4 to Qt5), then this should eventually go to 2.2.x
(no hurry).
Can you plan to commit it right after 2.2.1 is released?
Sure, I will.
JMarc
On 07/05/2016 06:12 AM, Jean-Marc Lasgouttes wrote:
> Le 05/07/2016 à 12:02, Jean-Marc Lasgouttes a écrit :
>> commit d044986724e98921510c95adecb61d2688b1f598
>> Author: Jean-Marc Lasgouttes
>> Date: Mon Jul 4 16:22:57 2016 +0200
>>
>> Autoconf : Try to select the correct Qt tools by using t
On 07/04/2016 02:42 PM, racoon wrote:
> On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
>> Le 04/07/2016 à 15:38, racoon a écrit :
>>> Thanks. Still I am wondering a bit why anything special at all is
>>> necessary.
>>
>> Well, I am glad I do not have dangling list items like Word gladly
>> create
On 07/04/2016 06:47 PM, Steve Litt wrote:
> Hi all,
>
> I have a specific paragraph style (environment) that has TeX "Large"
> print and is used only on single sentences. I'd like to incorporate
> something in this environment's LaTeX code to prevent it breaking in
> the middle. Anyone know how to
On Tuesday, July 5, 2016 10:36:51 PM WEST Andrew Parsloe wrote:
> The problem is just with compressed files. Uncompressed they export
> fine, and can be read in 2.1.5. With the compressed file when I try to
> open it in 2.1.5 I get the message: ".21.lyx is not a
> readable LyX document." Perhaps
Am Sonntag, 3. Juli 2016 um 19:00:15, schrieb Georg Baum
> 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
The attached patch implements a cache around the function
GuiFontMetrics::breakAt, which has been identified as very slow by
Guillaume. To this end, I use a plain QCache object.
This patch is also instrumented using pmprof.h. When I load the
UserGuide, and move along the document using Cursor-
Le 05/07/2016 00:31, Stephan Witt a écrit :
Am 04.07.2016 um 23:55 schrieb Guillaume Munch :
What errors do you get with the attached?
Guillaume
That works too.
Thanks for testing.
Guillaume
On 5/07/2016 8:40 p.m., José Abílio Matos wrote:
On Saturday, May 28, 2016 3:00:09 PM WEST Andrew Parsloe wrote:
I inadvertently tried exporting a compressed 2.2 file to 2.1.4. It was
not recognised by 2.1.4. When I try exporting an empty 2.2 compressed
file, it too isn't recognized by 2.1.4,
Le 05/07/2016 12:11, Jean-Marc Lasgouttes a écrit :
Le 04/07/2016 à 23:34, Guillaume Munch a écrit :
Le 04/07/2016 12:25, Jean-Marc Lasgouttes a écrit :
commit 67ac031a33b1621fdadb903422de598595cc08d2
Also, use gnu++11 unconditionnally with gcc as we used to do
before 67385e69.
Does th
Le 05/07/2016 à 12:02, Jean-Marc Lasgouttes a écrit :
commit d044986724e98921510c95adecb61d2688b1f598
Author: Jean-Marc Lasgouttes
Date: Mon Jul 4 16:22:57 2016 +0200
Autoconf : Try to select the correct Qt tools by using the -qt option
With this change, it is now possible to configu
Le 04/07/2016 à 23:34, Guillaume Munch a écrit :
Le 04/07/2016 12:25, Jean-Marc Lasgouttes a écrit :
commit 67ac031a33b1621fdadb903422de598595cc08d2
Also, use gnu++11 unconditionnally with gcc as we used to do
before 67385e69.
Does this mean more problems that go unnoticed until people
Le 04/07/2016 à 23:47, Guillaume Munch a écrit :
But doing so I noticed the following warning with clang, in case someone
fancies fixing it:
In file included from ../../src/EnchantChecker.cpp:14:
/usr/include/enchant/enchant++.h:55:25: warning:
'enchant::Exception::what' hides
overloaded v
Le 05/07/2016 00:33, Stephan Witt a écrit :
Am 05.07.2016 um 00:24 schrieb Guillaume Munch :
Le 04/07/2016 12:06, Stephan Witt a écrit :
Hi Guillaume,
now I’m getting: …
Where are we after Pavel's and your changes?
I’m able to build LyX again.
But as Pavel said already: a git bisect wa
Le 05/07/2016 00:55, Stephan Witt a écrit :
The enchant C++ header has more serious errors than this one.
Look at the method is_added …
I’m really surprised it’s so common on Linux.
Sorry, I missed the fact that it is not in the LyX source tree.
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"
Can't run because of errors.
... And here are the erro
On Saturday, May 28, 2016 3:00:09 PM WEST Andrew Parsloe wrote:
> I inadvertently tried exporting a compressed 2.2 file to 2.1.4. It was
> not recognised by 2.1.4. When I try exporting an empty 2.2 compressed
> file, it too isn't recognized by 2.1.4, so clearly this is not an
> allowed mode of e
43 matches
Mail list logo
