On Sun, Jul 15, 2007 at 02:48:08PM +0200, Sven Hoexter wrote:
> On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
>
> Hi,
>
> > Yes, this could be. We should simply NOT use the static solution.
> > Does attached patch work on Debian? If yes we could remove BugfixSignal, and
> > create
Sven Hoexter wrote:
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correc
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
> Yes, this could be. We should simply NOT use the static solution.
> Does attached patch work on Debian? If yes we could remove BugfixSignal, and
> create the signal at runtime. But we then have to clean up correctly.
Ok I tried y
Roger Mc Murtrie wrote:
Is there any relationship between this problem and Bug 4014, Comment 16
due to some changes in boost?
I don't think so.
Abdel.
Abdelrazak Younes wrote:
Hum, maybe the problem is in our side and not boost. This comment and
code in frontends/Dialogs.cpp seems suspicious to me:
// Note that static boost signals break some compilers, so this wrapper
// initialises the signal dynamically when it is first invoked.
templa
Abdelrazak Younes wrote:
The only solution is just to get rid of this BugfixSignal. Actually,
this hideSignal is not needed at all!
Something like the attached. I guess this signal was needed at some
point but not anymore.
Updated patch attached.
Abdel.
Index: frontends/Dialogs.cpp
===
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create th
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But w
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up co
Peter Kümmel wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Abdelrazak Younes wrote:
Peter Kümmel wrote:
> Yes, this could be. We should simply NOT use the static solution.
> Does attached patch work on Debian? If yes we could remove
> BugfixSignal, and
> create t
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution wi
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>>
>> Yes, this could be. We should simply NOT use the static solution.
>> Does attached patch work on Debian? If yes we could remove
>> BugfixSignal, and
>> create the signal at runtime. But we then have to clean up correctly.
>
> Your solution will
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>>
>> Yes, this could be. We should simply NOT use the static solution.
>> Does attached patch work on Debian? If yes we could remove
>> BugfixSignal, and
>> create the signal at runtime. But we then have to clean up correctly.
>
> Your solution will
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution will only work with the first instance...
Abde
Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal dy
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Maybe someone has an idea:
>>>
>>> 74 LyXView::LyXView(int id)
>>> 75 : work_area_(0),
>>> 76 toolbars_(new Toolbars(*this)),
>>> 77 autosave_timeout_(new Timeout(5000)),
>>> 7
Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal dyna
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76 toolbars_(new Toolbars(*this)),
77 autosave_timeout_(new Timeout(5000)),
78 dialogs_(new Dialogs(*this)),
79
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76toolbars_(new Toolbars(*this)),
77autosave_timeout_(new Timeout(5000)),
78dialogs_(new Dialogs(*this)),
79controlcomm
Sven Hoexter wrote:
> On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
>> Sven Hoexter wrote:
>>> Hi,
>>> while preparing a Debian package for the upcoming 1.5 release I've
>>> experienced a huge performance problem with 1.5rc1. Now I tried to find a
>>> reason and had to find out that
On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
> Sven Hoexter wrote:
> > Hi,
> > while preparing a Debian package for the upcoming 1.5 release I've
> > experienced a huge performance problem with 1.5rc1. Now I tried to find a
> > reason and had to find out that the current trunk will
Sven Hoexter wrote:
> Hi,
> while preparing a Debian package for the upcoming 1.5 release I've
> experienced a huge performance problem with 1.5rc1. Now I tried to find a
> reason and had to find out that the current trunk will segfault when I build
> it with the boost libs provided in the Debian a
Hi,
while preparing a Debian package for the upcoming 1.5 release I've
experienced a huge performance problem with 1.5rc1. Now I tried to find a
reason and had to find out that the current trunk will segfault when I build
it with the boost libs provided in the Debian archive.
I don't know if someo
24 matches
Mail list logo
