On 12. okt. 2013 20:43, Enrico Forestieri wrote:
I still simply wait for a latex run to finish before doing anything
else, so multithreading is of no help to me.
Latex sometimes takes a long time, due to a big document or
costly features (tikz, or external insets that runs export
functions in
Vincent van Ravesteijn wrote:
> First of all it is a misunderstanding that the bug manifests itself as a
> difference between GUI and non-GUI export: "It's just another joy of
> multithreading".
Both is true, since GUI export uses a second thread, and command line export
does not.
> As I wrote
On 10/12/2013 02:43 PM, Enrico Forestieri wrote:
I still simply wait for a latex run to finish before doing anything
else, so multithreading is of no help to me. Morever, I was being
almost riduculed when I was manifesting my contrariety to this feature.
Oh, well...
I agree with you that some
On Sat, Oct 12, 2013 at 01:15:58PM +0200, Vincent van Ravesteijn wrote:
> First of all it is a misunderstanding that the bug manifests itself
> as a difference between GUI and non-GUI export: "It's just another
> joy of multithreading".
>
> As I wrote somewhere else, it was a problem of
> MathMac
Georg Baum schreef op 10-10-2013 23:41:
OK, I believe I understand what happens, but I can't test, since I do not
see the \newcommand differences: The MacroData which is constructed from a
DocIterator is a lazy version, which does not have data initially, but
queries it when needed. This is not b
Enrico Forestieri schreef op 7-10-2013 21:05:
On Mon, Oct 07, 2013 at 02:28:18PM -0400, Richard Heck wrote:
It is very strange that I can't reproduce, if this is the cause,
and, indeed, that people haven't been seeing this bug all along.
Actually, all my files are converted correctly. But using
On 10/10/2013 23:12, Georg Baum wrote:
Vincent van Ravesteijn wrote:
The other difference I noticed is that on Cygwin and Solaris I get
\renewcommand instead of \newcommand. That is, applying your patch,
on Debian exporting from the GUI or from command line, produces the
same result, but lyx s
Jean-Marc Lasgouttes wrote:
> 11/10/2013 12:14, Jürgen Spitzmüller:
>>
>> I suppose the rationale is that the menu strings etc. displayed by this
>> inset should conform the actual language of the GUI.
>
> The use case is indeed when a user opens the Help files in LyX. The menu
> and shortcuts ar
Richard Heck wrote:
> Just a question: Is there any reason not just to use the lazy version
> everywhere? The only place the non-lazy constructor is used is in
> MacroTable::insert. We don't have a DocIterator there, but perhaps
> we could pass one from upstream?
I don't know. Maybe in that case
11/10/2013 12:14, Jürgen Spitzmüller:
Georg Baum wrote:
Is that on purpose? If yes, why? This looks wrong to me.
I suppose the rationale is that the menu strings etc. displayed by this inset
should conform the actual language of the GUI.
The use case is indeed when a user opens the Help file
On Thu, Oct 10, 2013 at 11:41:28PM +0200, Georg Baum wrote:
>
> Does this patch fix the problem for you?
Yes! Now the export on all three platforms (either from command line
or GUI) is the same as that originally obtained on Linux.
Great work, really!
--
Enrico
On Fri, Oct 11, 2013 at 11:38:29AM +0200, Jean-Marc Lasgouttes wrote:
> 10/10/2013 10:51, Enrico Forestieri:
> >>Please send to me a gmo file built on your machine. I have not
> >>implemented endianness support because I do not have at hand a gmo
> >>file build on anything else but intel architectu
Georg Baum wrote:
> Is that on purpose? If yes, why? This looks wrong to me.
I suppose the rationale is that the menu strings etc. displayed by this inset
should conform the actual language of the GUI.
Jürgen
10/10/2013 10:51, Enrico Forestieri:
Please send to me a gmo file built on your machine. I have not
implemented endianness support because I do not have at hand a gmo
file build on anything else but intel architecture.
Here is an archive with a couple of them corresponding to current trunk.
T
On 10/10/2013 05:41 PM, Georg Baum wrote:
Enrico Forestieri wrote:
On Wed, Oct 09, 2013 at 10:22:20PM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
The other difference I noticed is that on Cygwin and Solaris I get
\renewcommand instead of \newcommand. That is, applying your patch,
on De
Enrico Forestieri wrote:
> On Wed, Oct 09, 2013 at 10:22:20PM +0200, Georg Baum wrote:
>> Enrico Forestieri wrote:
>>
>> > The other difference I noticed is that on Cygwin and Solaris I get
>> > \renewcommand instead of \newcommand. That is, applying your patch,
>> > on Debian exporting from the
Vincent van Ravesteijn wrote:
> The other difference I noticed is that on Cygwin and Solaris I get
>> \renewcommand instead of \newcommand. That is, applying your patch,
>> on Debian exporting from the GUI or from command line, produces the
>> same result, but lyx segafaults on exit.
>> On Cygwin
Pavel Sanda wrote:
> Georg Baum wrote:
>> but if I use the Czech GUI I see that \shortcut{undefined} is translated
>> if exported from the GUI, and untranslated if exported from the command
>> line. This should not happen.
>
> This is because InsetInfo produces output in UI language instead of
>
The other difference I noticed is that on Cygwin and Solaris I get
> \renewcommand instead of \newcommand. That is, applying your patch,
> on Debian exporting from the GUI or from command line, produces the
> same result, but lyx segafaults on exit.
> On Cygwin and Solaris, exporting from the GUI c
On Wed, Oct 9, 2013 at 10:22 PM, Georg Baum
wrote:
> Enrico Forestieri wrote:
>
> > On Tue, Oct 08, 2013 at 09:49:44PM +0200, Vincent van Ravesteijn wrote:
> >>
> >> I tried to use QThreadStorage, which works on Windows, but on Linux
> >> I keep getting segmentation faults.
>
> Vincent, I extended
Am Donnerstag, 10. Oktober 2013 um 00:22:29, schrieb Enrico Forestieri
> On Wed, Oct 09, 2013 at 11:44:22PM +0200, Jean-Marc Lasgouttes wrote:
>
> > This could be to my gettext-removal patch... I am not sure that gui
> > language is set when exporting fron command-line.
>
> You mean the transla
Le 10/10/13 00:22, Enrico Forestieri a écrit :
However, now that you talk about it, I noticed that the .gmo files
are tracked in git. Why that? On Solaris I always get the messages
support/Messages.cpp (245): Wrong magic number for file
/export/src/lyx/lyx-devel/po/it.gmo.
Expected 0x950412de,
Georg Baum wrote:
> but if I use the Czech GUI I see that \shortcut{undefined} is translated if
> exported from the GUI, and untranslated if exported from the command line.
> This should not happen.
This is because InsetInfo produces output in UI language instead of document
language.
Pavel
Enrico Forestieri wrote:
> However, now that you talk about it, I noticed that the .gmo files
> are tracked in git. Why that? On Solaris I always get the messages
Kornel pushed this because of CMake. Look for "Gettext removed from master"
thread or around.
Pavel
On Wed, Oct 09, 2013 at 11:44:22PM +0200, Jean-Marc Lasgouttes wrote:
> This could be to my gettext-removal patch... I am not sure that gui
> language is set when exporting fron command-line.
You mean the translation, I suppose, as I don't see how that could
affect the fact that lyx thinks that a
This could be to my gettext-removal patch... I am not sure that gui language is
set when exporting fron command-line.
JMarc
Enrico Forestieri a écrit :
>On Wed, Oct 09, 2013 at 10:22:20PM +0200, Georg Baum wrote:
>> Enrico Forestieri wrote:
>>
>> > I tried your patch on Cygwin, Solaris, and D
On Wed, Oct 09, 2013 at 10:22:20PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > I tried your patch on Cygwin, Solaris, and Debian Linux. It worked fine
> > in all cases. However, and this occurs *only* on Debian, on quitting lyx
> > I get:
> >
> > lyx: QObject::startTimer: QTimer can
On Wed, Oct 09, 2013 at 11:28:53AM -0400, Scott Kostyshak wrote:
> On Wed, Oct 9, 2013 at 7:18 AM, Enrico Forestieri wrote:
> > On Tue, Oct 08, 2013 at 09:49:44PM +0200, Vincent van Ravesteijn wrote:
> >>
> > The other difference I noticed is that on Cygwin and Solaris I get
> > \renewcommand inst
Enrico Forestieri wrote:
> On Tue, Oct 08, 2013 at 09:49:44PM +0200, Vincent van Ravesteijn wrote:
>>
>> I tried to use QThreadStorage, which works on Windows, but on Linux
>> I keep getting segmentation faults.
Vincent, I extended your patch to protect all IconvProcessor instances.
Thanks to E
Scott Kostyshak wrote:
> I saw this too. For me the difference was that one of them (I forget
> which) was showing when I exported from the command line and one of
> them when I exported from the GUI. I think (in my case) it was
> explained by the following:
> When I exported from the command line
On Wed, Oct 9, 2013 at 7:18 AM, Enrico Forestieri wrote:
> On Tue, Oct 08, 2013 at 09:49:44PM +0200, Vincent van Ravesteijn wrote:
>>
> The other difference I noticed is that on Cygwin and Solaris I get
> \renewcommand instead of \newcommand. That is, applying your patch,
> on Debian exporting fro
On Tue, Oct 08, 2013 at 09:49:44PM +0200, Vincent van Ravesteijn wrote:
>
> I tried to use QThreadStorage, which works on Windows, but on Linux
> I keep getting segmentation faults.
I tried your patch on Cygwin, Solaris, and Debian Linux. It worked fine
in all cases. However, and this occurs *onl
On Tue, Oct 08, 2013 at 10:43:30PM +0200, Georg Baum wrote:
>
> However, I investigated the problem a bit more, and found out that there are
> more problems than the static buffer in iconv_convert(). My main question is
> this: Is the iconv() function really not thread safe, as the fix for bug
Jean-Marc Lasgouttes wrote:
> 08/10/2013 14:24, Jean-Marc Lasgouttes:
>> 07/10/2013 23:24, Georg Baum:
>>
>> Is there something like per-thread static storage? We do not really need
>> mutexes, since it is not concurrent access to the same information.
thread-local storage does unfortunately stil
Op 8-10-2013 14:30, Jean-Marc Lasgouttes schreef:
08/10/2013 14:24, Jean-Marc Lasgouttes:
07/10/2013 23:24, Georg Baum:
I don't remember the mutex story, however the problem is surely due to
the static output buffer in iconv_convert. The question is: why was it
made static?
For performance re
08/10/2013 14:24, Jean-Marc Lasgouttes:
07/10/2013 23:24, Georg Baum:
I don't remember the mutex story, however the problem is surely due to
the static output buffer in iconv_convert. The question is: why was it
made static?
For performance reasons (see r14854), and I believe that removing the
07/10/2013 23:24, Georg Baum:
I don't remember the mutex story, however the problem is surely due to
the static output buffer in iconv_convert. The question is: why was it
made static?
For performance reasons (see r14854), and I believe that removing the static
keyword would be quite visible in
Richard Heck wrote:
> The things that are turning up in the corrupt file look to me like UI
> strings. So I'm guessing that what happens is that, while the file is
> being exported, we are calling the iconv stuff to deal with UI strings,
> and we end up with a mess. Perhaps this is more likely to
On Mon, Oct 07, 2013 at 09:18:38PM +0200, Vincent van Ravesteijn wrote:
> When I open the document in a plain text editor, it complains about
> characters that cannot be represented in the current codeset (or
> something like that).
Maybe your editor is not configured for reading utf8 encoded tex
Enrico Forestieri wrote:
> On Mon, Oct 07, 2013 at 11:39:57AM -0700, Pavel Sanda wrote:
>
>> Enrico Forestieri wrote:
>> > The problem here is that to_utf8() (and most probably all other
>> > conversion routines) is not thread safe, maybe due to the static
>> > output buffer in iconv_convert().
>
Richard Heck wrote:
> Great work, Enrico. I've posted the patch to the bug report. We'll see
> what the reporter has to say.
Great work indeed!
> It is very strange that I can't reproduce, if this is the cause, and,
> indeed, that people haven't been seeing this bug all along.
This is not stran
On 10/07/2013 04:16 PM, Vincent van Ravesteijn wrote:
Op 7-10-2013 21:18, Vincent van Ravesteijn schreef:
Op 7-10-2013 21:05, Enrico Forestieri schreef:
On Mon, Oct 07, 2013 at 02:28:18PM -0400, Richard Heck wrote:
It is very strange that I can't reproduce, if this is the cause,
and, indeed, t
On Mon, Oct 7, 2013 at 4:16 PM, Vincent van Ravesteijn wrote:
> Op 7-10-2013 21:18, Vincent van Ravesteijn schreef:
> Something else I notice: Sometime the macros are exported as "\newcommand"
> and sometimes as "\renewcommand". This seems to be rather random.
>
I saw this too. For me the differe
Op 7-10-2013 21:18, Vincent van Ravesteijn schreef:
Op 7-10-2013 21:05, Enrico Forestieri schreef:
On Mon, Oct 07, 2013 at 02:28:18PM -0400, Richard Heck wrote:
It is very strange that I can't reproduce, if this is the cause,
and, indeed, that people haven't been seeing this bug all along.
Act
Op 7-10-2013 21:05, Enrico Forestieri schreef:
So, the bug also depends on the structure of the document, somehow.
Is the registered trademark symbol on line 460 and 480 of the lyx file
the problem maybe ?
Vincent
Op 7-10-2013 21:05, Enrico Forestieri schreef:
On Mon, Oct 07, 2013 at 02:28:18PM -0400, Richard Heck wrote:
It is very strange that I can't reproduce, if this is the cause,
and, indeed, that people haven't been seeing this bug all along.
Actually, all my files are converted correctly. But usin
On Mon, Oct 07, 2013 at 02:28:18PM -0400, Richard Heck wrote:
>
> It is very strange that I can't reproduce, if this is the cause,
> and, indeed, that people haven't been seeing this bug all along.
Actually, all my files are converted correctly. But using the one
attached to the bug report trigge
On Mon, Oct 07, 2013 at 11:39:57AM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > The problem here is that to_utf8() (and most probably all other
> > conversion routines) is not thread safe, maybe due to the static
> > output buffer in iconv_convert().
>
> Huh, iconv strikes back. We al
Enrico Forestieri wrote:
> The problem here is that to_utf8() (and most probably all other
> conversion routines) is not thread safe, maybe due to the static
> output buffer in iconv_convert().
Huh, iconv strikes back. We already knew that iconv is not thread safe
and I remember we already mutexed
On 10/07/2013 02:10 PM, Enrico Forestieri wrote:
On Sun, Oct 06, 2013 at 12:09:50PM -0400, Richard Heck wrote:
I just wanted to call everyone's attention to this bug:
http://www.lyx.org/trac/ticket/8854
It appears to be a very nasty dataloss bug in 2.1-beta1. What seems
to be happening is that,
On Mon, Oct 07, 2013 at 08:10:33PM +0200, Enrico Forestieri wrote:
>
> The problem here is that to_utf8() (and most probably all other
> conversion routines) is not thread safe, maybe due to the static
> output buffer in iconv_convert().
Yes, this seems to be the case. The attached alternative pa
On Sun, Oct 06, 2013 at 12:09:50PM -0400, Richard Heck wrote:
>
> I just wanted to call everyone's attention to this bug:
> http://www.lyx.org/trac/ticket/8854
> It appears to be a very nasty dataloss bug in 2.1-beta1. What seems
> to be happening is that, on save, the LyX file is corrupted in ver
Op 6-10-2013 18:09, Richard Heck schreef:
I just wanted to call everyone's attention to this bug:
http://www.lyx.org/trac/ticket/8854
It appears to be a very nasty dataloss bug in 2.1-beta1. What seems to
be happening is that, on save, the LyX file is corrupted in very weird
ways, with random
I tried to export user guide under valgrind, but got no interesting warnibg.
JMarc
Richard Heck a écrit :
>On 10/06/2013 01:38 PM, Jean-Marc Lasgouttes wrote:
>> Le 06/10/2013 18:09, Richard Heck a écrit :
>>>
>>> I just wanted to call everyone's attention to this bug:
>>> http://www.lyx.org/tr
On 10/06/2013 01:38 PM, Jean-Marc Lasgouttes wrote:
Le 06/10/2013 18:09, Richard Heck a écrit :
I just wanted to call everyone's attention to this bug:
http://www.lyx.org/trac/ticket/8854
It appears to be a very nasty dataloss bug in 2.1-beta1. What seems to
be happening is that, on save, the L
Jean-Marc Lasgouttes wrote:
> If it is in 2.0.6, it is not really a 2.1 blocker, is it?
No.
Jürgen
Vincent van Ravesteijn wrote:
> Is it really a blocking bug if it is only seen by one person who only can
> see this bug when running in a multi-processor virtual machine ?
This is not what the bug states. The bug happened on a normal machine and the
reporter was bold enough to create image on vi
Le 06/10/2013 18:09, Richard Heck a écrit :
I just wanted to call everyone's attention to this bug:
http://www.lyx.org/trac/ticket/8854
It appears to be a very nasty dataloss bug in 2.1-beta1. What seems to
be happening is that, on save, the LyX file is corrupted in very weird
ways, with random
Op 6-10-2013 18:09, Richard Heck schreef:
I just wanted to call everyone's attention to this bug:
http://www.lyx.org/trac/ticket/8854
It appears to be a very nasty dataloss bug in 2.1-beta1. What seems to
be happening is that, on save, the LyX file is corrupted in very weird
ways, with random
I just wanted to call everyone's attention to this bug:
http://www.lyx.org/trac/ticket/8854
It appears to be a very nasty dataloss bug in 2.1-beta1. What seems to
be happening is that, on save, the LyX file is corrupted in very weird
ways, with random parts of the file being replaced by things
60 matches
Mail list logo
