Andre Poenitz <[EMAIL PROTECTED]> writes:
> Right now it looks like it. However, there's no guarantee that the
> boost zip code that we currently blame for the corruption and that's
> essentially the same on Windows and Linux does not cause corruption
> on non-Windows machines.
That's the point. L
Martin Vermeer wrote:
On Wed, Aug 01, 2007 at 09:39:03AM +0200, Jean-Marc Lasgouttes wrote:
No, we should make sure that the size of the figure float does not
change. Why does that happen?
That is a very good question. If this did not happen, we also
wouldn't need the wide() thing.
I
Andre Poenitz wrote:
On Tue, Jul 31, 2007 at 12:28:31PM +0200, Helge Hafting wrote:
Martin Vermeer wrote:
...and more importantly, you just confirmed my diagnosis of
the problem. There is something in qt, or LyX's use of qt,
that responds very badly to DRI both being turned on and
pract
Andreas Karlsson wrote:
Dear LyX developers,
Under the Edit > Math menu in LyX there is an entry Use Computer Algebra System.
Does this menu entry works? I have tried it but not got it to work. Is there any plans to develop this feature?
It works to some extent if you have one of the so
Bennett Helm <[EMAIL PROTECTED]> writes:
> On Aug 1, 2007, at 11:26 AM, Jean-Marc Lasgouttes wrote:
>
>> "Bo Peng" <[EMAIL PROTECTED]> writes:
>>> OK. Please apply to trunk and branch. Frankly, I am too tired to
>>> debug
>>> boost::iostreams.
>>
>> Agreed. I would have liked to upgrade to boost 1.
I hereby grant permission to licence my contributions to LyX under the
GNU General Public Licence, version 2 or later.
Darren Freeman
On Aug 2, 2007, at 6:07 AM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
On Aug 1, 2007, at 11:26 AM, Jean-Marc Lasgouttes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
OK. Please apply to trunk and branch. Frankly, I am too tired to
debug
boost::iostreams.
Agreed. I
Andreas Karlsson <[EMAIL PROTECTED]> writes:
> Dear LyX developers,
>
> Under the Edit > Math menu in LyX there is an entry Use Computer
> Algebra System.
...
There is a way to use yacas from R via R package Ryacas [1] so it could
be possible to use this in LyX via Sweave (noweb like system u
Bennett Helm <[EMAIL PROTECTED]> writes:
>> Looks like gzstream.* did not get compiled and/or linked. Does running
>> 'make clean && make ' in src/support improve the situation?
>
> Nope -- same problem.
Did the makefile get recreated automatically? (it did for me)
Does running ./autogen.sh help
> That's the point. Let's try to make 1.5.1 happen fast. Could even be
> today.
Did you test middle-button paste in trunk? It works perfect for me and
if you find no other problem, please patch 1.5.x.
I also have a one-liner for a critical bug that I am testing...
Bo
Richard Heck wrote:
Bo Peng wrote:
Still tracing...
The problem is found:
Here's how I see it, and I actually do get a crash on Linux when doing
the following: Open test.lyx, then open the TOC, then click on child 2
and load it. The problem is caused by the fact that child1 is being
As I have analyzed in another email, the crash is caused by
1. load child doc 2 ==> child doc 2 loaded, switch to child doc 2,
setBuffer(child doc 2), which disconnect the master buffer.
2. load child doc 1 ==> child doc 1 loaded, fire structureChanged()
from its master buffer. However, the maste
> Here's how I see it,
Your analysis is the same as mine...
> And I actually get the crash in this vicinity.
Great. I was not able to reproduce it under linux.
> I'm trying this:
> Index: src/frontends/LyXView.cpp
> ===
> --- src/f
Bo Peng wrote:
Here's how I see it,
Your analysis is the same as mine...
And I actually get the crash in this vicinity.
Great. I was not able to reproduce it under linux.
I'm trying this:
Index: src/frontends/LyXView.cpp
Bo Peng wrote:
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
This fixes the crash, but I think it hides the real problem. I'm sending
a patch in a moment that I think deals with the underlying issue.
So my understanding of the 'real problem' is different from yours. :-)
I think th
1.5 current svn crashes on launch for me on Mac. (The first time I
launched it, it worked; every subsequent time crashes.)
Here's the backtrace.
Bennett
CGSResolveShmemReference : offset exceeds bounds
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_F
This fixes the crash, but I think it hides the real problem. I'm sending
a patch in a moment that I think deals with the underlying issue.
Richard
Bo Peng wrote:
As I have analyzed in another email, the crash is caused by
1. load child doc 2 ==> child doc 2 loaded, switch to child doc 2,
se
Try this patch. It seems to me we shouldn't disconnect until we're ready
to connect. It's possible that the connectBuffer() call should go
earlier, but I think this is right. It's where it was before, anyway.
Richard
--
==
Richa
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>
> This fixes the crash, but I think it hides the real problem. I'm sending
> a patch in a moment that I think deals with the underlying issue.
>
So my understanding of the 'real problem' is different from yours. :-)
I think the real problem is
> I think structureChanged() could possibly be used for other stuff, too,
> though it's not at present. The call in ControlToc::updateBackend() goes
> to the current buffer, though, which may have its own TOC, right?
void ControlToc::updateBackend()
{
kernel().buffer().getMasterBuffer()->t
> As long as something's connected, the master buffer will get this
> signal, it turns out:
> bufferStructureChangedConnection_ =
> buf.getMasterBuffer()->structureChanged.connect(
> boost::bind(&LyXView::updateToc, this));
> So structureChanged() is always connected to the
Pavel Sanda <[EMAIL PROTECTED]> writes:
[...]
>
> it starts to import, however i'm not sure whether this is the correct
> solution because intermediate .tex file remain in the current directory.
>
> did the previous parameter worked for you or is this bug ?
Here on Solaris w2l 0.5b2 works like
Bo Peng wrote:
As long as something's connected, the master buffer will get this
signal, it turns out:
bufferStructureChangedConnection_ =
buf.getMasterBuffer()->structureChanged.connect(
boost::bind(&LyXView::updateToc, this));
So structureChanged() is always connected to
Here's a slightly improved patch, that does a little cleanup along the way.
Richard
Richard Heck wrote:
Bo Peng wrote:
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
This fixes the crash, but I think it hides the real problem. I'm
sending
a patch in a moment that I think deals with th
Bo Peng wrote:
I think structureChanged() could possibly be used for other stuff, too,
though it's not at present. The call in ControlToc::updateBackend() goes
to the current buffer, though, which may have its own TOC, right?
void ControlToc::updateBackend()
{
kernel().buffer().getM
Bo Peng wrote:
Yes. This bothered me back when Abdel and I were sorting out a
different, but similar, crash. It just seemed wrong. I should have
followed my gut.
This part looks fragile. Could you add a few lines of comments in your
patch? Something like: we can not disconnect oldBuffer now
Here is the most up-to-date version of the patch, with all comments and
such. Bo and I agree it should go into both trunk and branch, as it
solves the problem. ;-) We need one more OK.
Richard
--
==
Richard G Heck, Jr
Professor
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>
> Here is the most up-to-date version of the patch, with all comments and
> such. Bo and I agree it should go into both trunk and branch, as it
> solves the problem. ;-) We need one more OK.
+ //Now that all the updating of the old
> Yes. This bothered me back when Abdel and I were sorting out a
> different, but similar, crash. It just seemed wrong. I should have
> followed my gut.
This part looks fragile. Could you add a few lines of comments in your
patch? Something like: we can not disconnect oldBuffer now because
B
On Aug 2, 2007, at 11:24 AM, Bennett Helm wrote:
1.5 current svn crashes on launch for me on Mac. (The first time I
launched it, it worked; every subsequent time crashes.)
Here's the backtrace.
Might this be a false alarm? ... Some other applications on my
computer started behaving badly,
Bo Peng wrote:
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
Here is the most up-to-date version of the patch, with all comments and
such. Bo and I agree it should go into both trunk and branch, as it
solves the problem. ;-) We need one more OK.
+ //Now that all the
> Might this be a false alarm?
Maybe, because there is no change to 1.5.0svn that might contribute to this.
Bo
Hello,
I just add a new mirror. The server is located at US (Dallas, 100mb
connection). I am doing daily upate on this mirror. Here is the url:
http://lyx.site2nd.org/lyx/
It's a little thing that I can do to contribute to the community.
If you have any question, just let me know. Thanks.
Max
33 matches
Mail list logo
