Am 17.01.2011 um 08:38 schrieb Stephan Witt:
> I claim that 1) and 2) are fixed with my patch and should help the installer
> a lot. The environment variables of the other preference path items are
> replaced
> already on read of the lyxrc files. To make use of it the installer has to
> make
> s
Am 17.01.2011 um 03:01 schrieb Enrico Forestieri:
> On Mon, Jan 17, 2011 at 08:45:45AM +0800, hzluo wrote:
>
>> In addition to this exact path_prefix problem, it causes another
>> problem on Windows:
>> If the external uitility is a .bat/.cmd wrapper, it will fail. For
>> example, ps2pdf13 is a w
On 17.01.2011 03:01, Enrico Forestieri wrote:
On Mon, Jan 17, 2011 at 08:45:45AM +0800, hzluo wrote:
In addition to this exact path_prefix problem, it causes another
problem on Windows:
If the external uitility is a .bat/.cmd wrapper, it will fail. For
example, ps2pdf13 is a wrapper in gs/lib d
On 2011-01-16, Liviu Andronic wrote:
> On Sat, Jan 15, 2011 at 10:06 PM, Pavel Sanda wrote:
> But I have a feeling that XeTeX and LuaTeX are both broken on my
> system in beta3. I get the same errors even with very simple
> documents.
There has been rapid development especially with LuaTeX in re
On Mon, Jan 17, 2011 at 08:45:45AM +0800, hzluo wrote:
> In addition to this exact path_prefix problem, it causes another
> problem on Windows:
> If the external uitility is a .bat/.cmd wrapper, it will fail. For
> example, ps2pdf13 is a wrapper in gs/lib dir on Windows Ghostscript.
> I have to fi
Friends, I also find the problem of not using system() calls to start
processes. And the path_prefix is not the only configure variable affected
by this problem. All path variables in the preference dialog will be
affected, for example \thesaurusdir_path. So, If I use some environment
variables
On 1/16/2011 10:16 PM, Stephan Witt wrote:
Now I think effectively it's a bug. In the past the external utilities where
started with system() calls.
Then the shell interpreted the environment variables. This was replaced by
QProcess::start. I'm almost
sure since then the environment variables h
On Sat, Jan 15, 2011 at 10:06 PM, Pavel Sanda wrote:
>> The configure script adds two converters: sweave to latex (DVI chain) and
>> sweave to pdflatex, so pdflatex should actually work.
>>
>> To include XeTeX and LuaTeX, you would only need to add two more formats,
>> given that Sweave really wor
Am 16.01.2011 um 21:25 schrieb Joost Verburg:
> On 1/16/2011 8:41 PM, Stephan Witt wrote:
>> LyX uses QProcess to create child processes.
>> I cannot tell for sure if the PATH environment with %LyXDir% included works.
>> I could not find it when reading the Qt docs here:
>> http://doc.qt.nokia.com
Am 16.01.2011 um 21:25 schrieb Joost Verburg:
> On 1/16/2011 8:41 PM, Stephan Witt wrote:
>> LyX uses QProcess to create child processes.
>> I cannot tell for sure if the PATH environment with %LyXDir% included works.
>> I could not find it when reading the Qt docs here:
>> http://doc.qt.nokia.com
On 1/16/2011 8:41 PM, Stephan Witt wrote:
LyX uses QProcess to create child processes.
I cannot tell for sure if the PATH environment with %LyXDir% included works.
I could not find it when reading the Qt docs here:
http://doc.qt.nokia.com/latest/qprocess.html
Can you give it a try please? I don'
> Just for information:
> LyX document 350 pages A4 opened by
> thinkpad201(i3)+squeeze+lyx-1.6 in 55 seconds,
> eeepc1005(atom450)+lenny+lyx-1.5 in 10 seconds.
> Five times slowly by i3 than by atom450!
> Terrible :(
> What do lyx-1.6 do while opening document -- it's parsing internal li
Peter Kümmel wrote:
> threads should be no problem. And making Graph const correct could
> be done by simply cache all results.
still you need write access for the first run.
pavel
Am 16.01.2011 um 17:41 schrieb Joost Verburg:
> On 1/16/2011 5:11 PM, Stephan Witt wrote:
>>> In addition a call to expandPath should be added for path_prefix.
>>
>> ... I wonder why that is of any use.
>>
>> If I change my path_prefix in the preferences I don't expect it gets
>> replaced immedi
On 16.01.2011 20:01, Richard Heck wrote:
On 01/16/2011 06:08 AM, Peter Kümmel wrote:
HEAD without the locks in Graph.cpp
It's a typical race condition, see output with attached patch:
I'm no expert on this stuff, but it looks to me as if the locks are
needed, unless we start copying the Grap
On 16.01.2011 20:06, Richard Heck wrote:
On 01/16/2011 07:40 AM, Peter Kümmel wrote:
Attached a patch which introduces a value semantic for the Converter
list.
theConverters now doesn't return a reference any more but a copy of
the list.
This way we could remove the locks in Graph.cpp.
The retu
Pavel Sanda lyx.org> writes:
> this bug has been fixed yesterday.
> pavel
Okay, I have updated my svn copy and will report if the bug persists. Thanks!
On 01/16/2011 07:40 AM, Peter Kümmel wrote:
Attached a patch which introduces a value semantic for the Converter
list.
theConverters now doesn't return a reference any more but a copy of
the list.
This way we could remove the locks in Graph.cpp.
The returned Converters is const, so the compile
On 01/16/2011 06:08 AM, Peter Kümmel wrote:
HEAD without the locks in Graph.cpp
It's a typical race condition, see output with attached patch:
I'm no expert on this stuff, but it looks to me as if the locks are
needed, unless we start copying the Graph object every time we use it.
That could
Pavel Sanda wrote:
> btw are aware of #6682 ?
I was not. After reading the report I know that it is completely unrelated
to the tex2lyx problem I fixed: Per-document colors are needed (see also
http://www.lyx.org/trac/ticket/6626#comment:6) IMHO, fixing this correctly
is too risky at this deve
Ben Goodrich wrote:
> Error returned from iconv
> E2BIG There is not sufficient room at *outbuf.
> Qt Concurrent has caught an exception thrown from a worker thread.
> This is not supported, exceptions thrown in worker threads must be
> caught before control returns to Qt Concurrent.
> terminate c
Hi,
I have hit been hitting a bug for a while, but I still don't have a recipe to
reliably reproduce it. But if I am working on a paper, this bug or a similar bug
will happen maybe once an hour on average. It can be triggered just by typing
but more often by deleting, cutting, pasting, etc. a chun
Enrico Forestieri wrote:
> On Sun, Jan 16, 2011 at 02:19:57PM +0100, Pavel Sanda wrote:
>
> > i like it more than having mutexes on 10 different places. on the
> > other hand i'm little bit afraid about unintended side effects of this
> > patch :) lets wait what other say.
>
> What about the simp
On Sun, Jan 16, 2011 at 02:19:57PM +0100, Pavel Sanda wrote:
> i like it more than having mutexes on 10 different places. on the
> other hand i'm little bit afraid about unintended side effects of this
> patch :) lets wait what other say.
What about the simple and effective attached patch?
SCNR
On 1/16/2011 5:11 PM, Stephan Witt wrote:
In addition a call to expandPath should be added for path_prefix.
... I wonder why that is of any use.
If I change my path_prefix in the preferences I don't expect it gets
replaced immediately. Instead of this I expect it to be replaced at runtime.
Y
Am 16.01.2011 um 16:58 schrieb Joost Verburg:
> On 1/16/2011 4:12 PM, Pavel Sanda wrote:
>> so it depends whether the guys are satisfied with this.
>> pavel
>
> Stephan's patch looks fine to me.
Indeed it fixes the single replace issue. But...
> In addition a call to expandPath should be added
On 1/16/2011 4:12 PM, Pavel Sanda wrote:
so it depends whether the guys are satisfied with this.
pavel
Stephan's patch looks fine to me. In addition a call to expandPath
should be added for path_prefix.
Joost
Stephan Witt wrote:
> Am 16.01.2011 um 14:25 schrieb Peter Kümmel:
>
> > On 15.01.2011 20:31, Joost Verburg wrote:
> >> On 1/14/2011 11:23 PM, Pavel Sanda wrote:
> >>> unless somebody is going to make detail review, this is too late for 2.0.
> >>> it can bring regressions since the code touches co
Pavel Sanda wrote:
> key question: the document you open in 1.6 was already saved in 1.6?
Yes it was, i've check it back
Andrei
Am 16.01.2011 um 14:25 schrieb Peter Kümmel:
> On 15.01.2011 20:31, Joost Verburg wrote:
>> On 1/14/2011 11:23 PM, Pavel Sanda wrote:
>>> unless somebody is going to make detail review, this is too late for 2.0.
>>> it can bring regressions since the code touches common routine...
>>
>> Some time
On 15.01.2011 20:31, Joost Verburg wrote:
On 1/14/2011 11:23 PM, Pavel Sanda wrote:
unless somebody is going to make detail review, this is too late for 2.0.
it can bring regressions since the code touches common routine...
Some time ago I mentioned this exact same issue on the devel list. It
Peter Kümmel wrote:
> Attached a patch which introduces a value semantic for the Converter list.
> theConverters now doesn't return a reference any more but a copy of the
> list.
> This way we could remove the locks in Graph.cpp.
>
> The returned Converters is const, so the compiler shows up the p
On 16.01.2011 13:40, Peter Kümmel wrote:
Attached a patch which introduces a value semantic for the Converter list.
theConverters now doesn't return a reference any more but a copy of the list.
This way we could remove the locks in Graph.cpp.
The returned Converters is const, so the compiler sho
Attached a patch which introduces a value semantic for the Converter list.
theConverters now doesn't return a reference any more but a copy of the list.
This way we could remove the locks in Graph.cpp.
The returned Converters is const, so the compiler shows up the places where
we touch the conver
HEAD without the locks in Graph.cpp
It's a typical race condition, see output with attached patch:
184 74127768 size 1 , thread:
186 74127768 size 1 , thread:
36 19714232 size 0 , thread:
This means
line 184: thread 74127768 checks if Q is not empty > enter the while loop
line 186: Q is st
Peter Kümmel wrote:
> On 16.01.2011 11:39, Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>> Found another way to crash lyx:
>>>
>>> Call utf8_to_ucs4 via getStatus and getPath,
>>> but it is not obvious why it crashes here.
>>> See attechments.
>>
>> what was the scenario, which revision of the tree?
On 16.01.2011 11:39, Pavel Sanda wrote:
Peter Kümmel wrote:
Found another way to crash lyx:
Call utf8_to_ucs4 via getStatus and getPath,
but it is not obvious why it crashes here.
See attechments.
what was the scenario, which revision of the tree?
pavel
HEAD without the locks in Graph.cpp
Peter Kümmel wrote:
> Found another way to crash lyx:
>
> Call utf8_to_ucs4 via getStatus and getPath,
> but it is not obvious why it crashes here.
> See attechments.
what was the scenario, which revision of the tree?
pavel
Found another way to crash lyx:
Call utf8_to_ucs4 via getStatus and getPath,
but it is not obvious why it crashes here.
See attechments.
Peter
LyX.exe!std::basic_string,std::allocator >::_Eos(unsigned int _Newsize) Zeile 1954
C++
LyX.exe!std::basic_string,std::allocator >::ap
On 16.01.2011 00:01, Peter Kümmel wrote:
Graph has a container with pointers (vertices_) but now copy constructor,
this could not work.
Checked this again and I was wrong, the pointers must be to internal objects
which are copied by value (there's nor "new" in Graph.cpp, not API with a
pointe
Richard Heck wrote:
> On 01/15/2011 04:54 PM, Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>> When a thread enters a function which another thread is busy on it hangs
>>> in the lock, if it wouldn't wait the the chaos would become even worse.
>>> The mutex only guaranties that one operation is finish
Tommaso Cucinotta wrote:
> Anything against it ?
>> lets try it...
>
> what happened ? thx.
i meant lets try to commit it and have some testing for sideeffects...
the bug you described is fixed for me as well.
pavel
42 matches
Mail list logo
