Am Mittwoch, den 12.04.2017, 20:25 +0200 schrieb Enrico Forestieri:
> On Wed, Apr 12, 2017 at 07:28:49PM +0200, Enrico Forestieri wrote:
> > On Wed, Apr 12, 2017 at 06:09:00PM +0200, Jürgen Spitzmüller wrote:
> > >
> > > FWIW the patch fixes my case (although reconfiguring seems
> > > significantl
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/154/--
[...truncated 1122 lines...]
CXX insets/InsetGraphicsParams.o
CXX insets/InsetGraphics.o
CXX insets/InsetHyperlink.o
CXX insets/InsetIncl
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/138/--
[...truncated 1929 lines...]
[ 89%] Linking CXX executable ../../../bin/check_filetools
cd /build/lyx/build/src/support/tests && /usr/bin/cmake -E cmake_link_script
CMakeFiles/c
Am 12.04.2017 um 22:18 schrieb Stephan Witt :
>
> Hi Scott,
>
> it looks like your change c659fd4f742763331a5d1e1d3220fb1a615ef845
> removed the tilde expansion of path names from preference files.
>
> Isn’t this a problem on Linux too?
Sorry, I meant the change before: 9b64d7bd24d606490c344a5
邮件已收到，谢谢。保持联系！
Hi Scott,
it looks like your change c659fd4f742763331a5d1e1d3220fb1a615ef845
removed the tilde expansion of path names from preference files.
Isn’t this a problem on Linux too?
Stephan
Le 08/04/2017 à 15:10, Jean-Marc Lasgouttes a écrit :
Le 07/04/2017 à 23:55, Guillaume MM a écrit :
commit b382b246b62b66100733449b2bf75a01fd1d263f
Author: Guillaume MM
Date: Sun Apr 2 21:04:06 2017 +0200
MathAtom is a unique_ptr
Fix coverity suggestion of defining a move constructo
Le 11/04/2017 à 10:04, Jean-Marc Lasgouttes a écrit :
Le 11/04/2017 à 09:45, Guenter Milde a écrit :
The Python convention is to leave out "== true" while in C++ this may be
required. (Python auto-converts any value to a Boolean if required in an
"if" clause.)
I do not see any reason to keep =
On 12.04.17 18:52, Stephan Witt wrote:
> What are some of the present bugs / missing features you're
> referring to? I wonder if some workarounds are available...
>> - that apparently almost nobody was interested in reducing the filesize
>> of the shipped images.
PNG
On Wed, Apr 12, 2017 at 05:03:24PM +0100, José Abílio Matos wrote:
> On Wednesday, 12 April 2017 16.49.54 WEST Enrico Forestieri wrote:
> > And how would you perform regex matches when dealing with bytes-like
> > objects in python3? Don't you get a TypeError?
>
> http://stackoverflow.com/questions
On 04/12/2017 06:10 AM, Guenter Milde wrote:
> On 2017-04-11, Richard Heck wrote:
>> On 04/11/2017 04:20 PM, Guenter Milde wrote:
>>> On 2017-04-11, PhilipPirrip wrote:
On 04/11/2017 11:23 AM, Stephan Witt wrote:
My proposal of having "a general sheet where one could send options to
On Wed, Apr 12, 2017 at 07:28:49PM +0200, Enrico Forestieri wrote:
> On Wed, Apr 12, 2017 at 06:09:00PM +0200, Jürgen Spitzmüller wrote:
> >
> > FWIW the patch fixes my case (although reconfiguring seems
> > significantly slower).
>
> Let's see whether José comes up with something, then.
Maybe I
On Wed, Apr 12, 2017 at 06:09:00PM +0200, Jürgen Spitzmüller wrote:
>
> FWIW the patch fixes my case (although reconfiguring seems
> significantly slower).
Let's see whether José comes up with something, then.
--
Enrico
Am 12.04.2017 um 17:51 schrieb mn :
>
> On 12.04.17 16:13, Stephan Witt wrote:
What are some of the present bugs / missing features you're
referring to? I wonder if some workarounds are available...
> - that apparently almost nobody was interested in reducing the filesize
>>>
Am Mittwoch, den 12.04.2017, 16:42 +0200 schrieb Enrico Forestieri:
> If we agree on this, with the attached patch no re-encoding is
> necessary.
> Please, try it. The python chardet module is required.
FWIW the patch fixes my case (although reconfiguring seems
significantly slower).
Jürgen
sig
On Wednesday, 12 April 2017 16.49.54 WEST Enrico Forestieri wrote:
> And how would you perform regex matches when dealing with bytes-like
> objects in python3? Don't you get a TypeError?
http://stackoverflow.com/questions/5618988/regular-expression-parsing-a-binary-file
tldr; defining the regex e
On 12.04.17 16:13, Stephan Witt wrote:
>>> What are some of the present bugs / missing features you're
>>> referring to? I wonder if some workarounds are available...
- that apparently almost nobody was interested in reducing the filesize
of the shipped images.
>>> That’s not tru
On Wed, Apr 12, 2017 at 04:21:33PM +0100, José Abílio Matos wrote:
>
> The other option would be to open the file in binary mode and then we have to
> make sure to use the b"" strings when there are file manipulations.
And how would you perform regex matches when dealing with bytes-like
objects
On 2017-04-12, Jean-Pierre Chrétien wrote:
> Le 12/04/2017 à 12:05, Guenter Milde a écrit :
...
>>> I applied this, and I am now down to 33 failures :
>>> The following tests FAILED:
>>> 1777 - export/doc/cs/Tutorial_pdf (Failed)
>>> 1778 - DEFAULTOUTPUT_export/doc/cs/Tutorial_pdf2 (Failed
On Wednesday, 12 April 2017 15.42.42 WEST Enrico Forestieri wrote:
> On Wed, Apr 12, 2017 at 03:36:10PM +0200, Jürgen Spitzmüller wrote:
> > I understand that there is no perfect method. However, if we can catch
> > a significant set of cases without too much effort, we should probably
> > do that.
On Wed, Apr 12, 2017 at 03:36:10PM +0200, Jürgen Spitzmüller wrote:
>
> I understand that there is no perfect method. However, if we can catch
> a significant set of cases without too much effort, we should probably
> do that.
If we agree on this, with the attached patch no re-encoding is necessa
Am 12.04.2017 um 14:34 schrieb mn :
>
> On 12.04.17 12:59, Stephan Witt wrote:
>> What are some of the present bugs / missing features you're
>> referring to? I wonder if some workarounds are available...
>
The part below I don’t understand. What exactly is the message?
>
>>>
On Wed, Apr 12, 2017 at 03:36:10PM +0200, Jürgen Spitzmüller wrote:
>
> Could you tell me again why it is now necessary to open the files with
> a specific encoding, while we did not do that until now? (I admit that
> I skipped most of those "Python 3" threads)
Because of this commit:
http://www.
Am Mittwoch, den 12.04.2017, 15:22 +0200 schrieb Enrico Forestieri:
> I find that the chardet library is the least reliable. I get better
> results with python-magic. However, all methods are unreliable to
> some extent. Try the attached patch to see in how many encodings
> you can read a file. Try
On Wed, Apr 12, 2017 at 03:22:58PM +0200, Enrico Forestieri wrote:
> some extent. Try the attached patch to see in how many encodings
^
Sorry, I meant script, of course.
--
Enrico
On Wed, Apr 12, 2017 at 02:28:48PM +0200, Jürgen Spitzmüller wrote:
>
> There seem to be some ways to detect the file encoding in python:
> http://stackoverflow.com/questions/436220/determine-the-encoding-of-tex
> t-in-python
I find that the chardet library is the least reliable. I get better
res
Am Mittwoch, 12. April 2017 um 14:31:23, schrieb Jean-Pierre Chrétien
...
> - I had not installed knitr and dependencies in R, knitr.lyx and
> Rjournal.lyx
>
> work OK now by hand (I documented the installation in the wiki);
You may want to configure converters for ctest-lyx too, e.g
On 12.04.17 12:59, Stephan Witt wrote:
> What are some of the present bugs / missing features you're
> referring to? I wonder if some workarounds are available...
>>> The part below I don’t understand. What exactly is the message?
>>>
>> - that apparently almost nobody was interested in r
Le 12/04/2017 à 12:05, Guenter Milde a écrit :
On 2017-04-11, Jean-Pierre Chrétien wrote:
Le 11/04/2017 à 10:13, Kornel Benko a écrit :
Am Dienstag, 11. April 2017 um 09:33:15, schrieb Jean-Pierre Chrétien
I applied this, and I am now down to 33 failures :
The following tests FAILED:
Am Mittwoch, den 12.04.2017, 14:13 +0200 schrieb Enrico Forestieri:
> I highlighted this issue here:
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg199359.html
> I don't know what will happen.
I see. So the patch you have posted (which has been applied by JMarc)
helps in JMarc's own case
On Wed, Apr 12, 2017 at 01:38:57PM +0200, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 12.04.2017, 13:05 +0200 schrieb Enrico Forestieri:
>
> > I think that this deserves a comment
> > in release notes.
>
> At least. If there's a way to do the recoding via layout2layout, I
> would very much prefe
Am Mittwoch, den 12.04.2017, 13:05 +0200 schrieb Enrico Forestieri:
> Check that all your layout files are utf8 encoded:
>
> file ~/.lyx/layout/*
Indeed, some weren't.
> If not, use iconv to convert them.
Did that (using recode). That helped.
> I think that this deserves a comment
> in releas
On Wed, Apr 12, 2017 at 12:24:20PM +0200, Jürgen Spitzmüller wrote:
> I am currently getting the following error while doing reconfigure:
>
> checking LaTeX configuration... auto
> Traceback (most recent call last):
> File "/home/juergen/lyx/lyx-devel2/lib/configure.py", line 1825, in
>
>
Am 12.04.2017 um 12:31 schrieb mn :
>
> On 12.04.17 11:43, Stephan Witt wrote:
>
What are some of the present bugs / missing features you're
referring to? I wonder if some workarounds are available...
>>>
>>> The biggest bug imho is the slowness, worst on OS X.
>>> That's supposed to g
On 12.04.17 11:43, Stephan Witt wrote:
>>> What are some of the present bugs / missing features you're
>>> referring to? I wonder if some workarounds are available...
>>
>> The biggest bug imho is the slowness, worst on OS X.
>> That's supposed to get a little bit better.
>
> In case you have con
I am currently getting the following error while doing reconfigure:
checking LaTeX configuration... auto
Traceback (most recent call last):
File "/home/juergen/lyx/lyx-devel2/lib/configure.py", line 1825, in
ret = checkLatexConfig(lyx_check_config and LATEX != '',
bool_docbook)
Fi
On 2017-04-11, Richard Heck wrote:
> On 04/11/2017 04:20 PM, Guenter Milde wrote:
>> On 2017-04-11, PhilipPirrip wrote:
>>> On 04/11/2017 11:23 AM, Stephan Witt wrote:
>>> My proposal of having "a general sheet where one could send options to
>>> (the calls of) this and that package would be a go
On 2017-04-11, Jean-Pierre Chrétien wrote:
> Le 11/04/2017 à 10:13, Kornel Benko a écrit :
>> Am Dienstag, 11. April 2017 um 09:33:15, schrieb Jean-Pierre Chrétien
>>
> I applied this, and I am now down to 33 failures :
> The following tests FAILED:
> 1777 - export/doc/cs/Tutorial_pdf (Fa
On 2017-04-11, Uwe Stöhr wrote:
> El 06.04.2017 a las 10:39, Jean-Marc Lasgouttes escribió:
...
>> The question is not whether the equation is indented, it is whether it
>> is flushed left.
>> The paramter (and all it incarantion in the code) should be \fleqn or
>> \flush_equation or \flush_mat
Am 11.04.2017 um 18:46 schrieb mn :
>
> On 11.04.17 14:58, Joel Kulesza wrote:
>> On Tue, Apr 11, 2017 at 3:38 AM, mn >
>>> Right now, I am struggling with bugs and also features lacking in
>>> the latest stable LyX. And for some at least I know they are supposed
>>> to be fixed or added in the n
Am Dienstag, 11. April 2017 um 23:53:56, schrieb Pavel Sanda
> Scott Kostyshak wrote:
> > I hope others join this conversation. To alpha or not to alpha?
>
> If I was manager I would do aplha, do it quickly with very low
> reuirements for bugs solved or fetures yet-to-be-delivered
> and clearly
On 2017-04-11, Uwe Stöhr wrote:
> El 11.04.2017 a las 10:15, Jean-Marc Lasgouttes escribió:
> Why are the 30pt a problem? This is by design. 30pt is the default size.
30 pt is not always the default size:
fleqn is a standard LaTeX option defined in `fleqn.clo' with
\newdimen\mathindent
\AtE
On Tuesday, 11 April 2017 09.04.59 WEST Jean-Marc Lasgouttes wrote:
> I do not see any reason to keep == true in C++ either.
>
> JMarc
I agree that the " == true" is a non-idiomatic expression both for c++ and for
python.
PS: I am aware that the literal is True in python but the idea is precise
On Wednesday, 12 April 2017 00.16.01 WEST Uwe Stöhr wrote:
> Well, this is a matter of taste. For me math is everything, inline and
> formulas. Since the indentation is only something for formulas I chose
> "formula". Personally, I find LyX's term "displayed equations"
> meaningless. What is "displ
44 matches
Mail list logo
