Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #140

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/140/--
Started by an SCM change
Building remotely on lyx-linux3 (linux) in workspace 
<https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/ws/>
[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
Cloning the remote Git repository
Using shallow clone
Avoid fetching tags
Honoring refspec on initial clone
Cloning repository git://git.lyx.org/lyx.git
 > git init 
 > <https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/ws/>
 >  # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git --version # timeout=10
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/master^{commit} # timeout=10
Checking out Revision 74bcd5d26c558e5d540b2e3370d869a3f0469aff 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 74bcd5d26c558e5d540b2e3370d869a3f0469aff
 > git rev-list 8769c0fb750a8c46e6f053c5f73b3991393dcd73 # timeout=10
First time build. Skipping changelog.
[ubuntu-xenial-qt4-autotools-extended] $ /bin/sh -xe 
/tmp/hudson2495833187698955466.sh
+ patch -p1
patching file INSTALL
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file INSTALL.rej
patching file autogen.sh
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file autogen.sh.rej
patching file configure.ac
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file configure.ac.rej
patching file src/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file src/Makefile.am.rej
The next patch would create the file src/tests/dummy_functions.cpp,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file src/tex2lyx/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file src/tex2lyx/Makefile.am.rej
Build step 'Execute shell' marked build as failure

Re: LyX-140 Crash on Quit

[Bennett Helm]

This bug has gotten lost in the shuffle, so I thought I'd repost it.  
(Others are now reporting the same problem when using LyX/Mac-140pre3.)


Bennett

On Oct 4, 2005, at 1:40 PM, Bennett Helm wrote:

I've occasionally been having lyx-140 crash on quitting. It doesn't  
happen often enough that I've seen a pattern, and I can't reliably  
reproduce it.


Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00050a9b
0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252

252 {
(gdb) bt
#0  0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252
#1  0x0069cb88 in boost::signal2void, std::string const,  
InsetBase*, boost::last_valuevoid, int, std::lessint,  
boost::functionvoid ()(std::string const, InsetBase*),  
std::allocatorvoid  ::operator() (this=0xb4460f0, [EMAIL PROTECTED],  
a2=0x1184f2d0) at ../../boost/boost/signals/signal_template.hpp:335
#2  0x000e46b0 in Dialogs::hide ([EMAIL PROTECTED], inset=0x1184f2d0)  
at Dialogs.C:32
#3  0x0016085c in InsetERT::~InsetERT (this=0x1184f2d0,  
__in_chrg=3) at insetert.C:107
#4  0x0001451c in InsetList::~InsetList (this=0xcb192d0,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_iterator.h:602
#5  0x0009f380 in Paragraph::~Paragraph (this=0xcb192cc,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_alloc.h:242
#6  0x00627d7c in __static_initialization_and_destruction_0  
(__initialize_p=0, __priority=65535) at /usr/include/gcc/darwin/3.3/ 
c++/bits/stl_construct.h:125
#7  0x8fe109dc in  
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkCont 
extE ()

#8  0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#9  0x90013a5c in __cxa_finalize ()
#10 0x90013904 in exit ()
#11 0x00171b08 in lyx_gui::exit () at lyx_gui.C:285
#12 0x00062de4 in QuitLyX (noask=8210760) at lyx_cb.C:219
#13 0x000760a8 in LyXFunc::dispatch (this=0xb44fbf0,  
[EMAIL PROTECTED]) at /usr/include/gcc/darwin/3.3/c++/bits/ 
basic_string.h:1136
#14 0x004562a0 in lyx::frontend::QLPopupMenu::fire (this=0xb4577a0,  
index=5002) at ../../../src/MenuBackend.h:97
#15 0x00506418 in lyx::frontend::QLPopupMenu::qt_invoke  
(this=0xb4577a0, _id=57, _o=0xbfffe560) at /Users/bennett/lyx/ 
gcc-3.3/qt-mac-free-3.3.5/include/private/qucom_p.h:388
#16 0x001e0920 in QObject::activate_signal () at  
ControlCommandBuffer.C:137
#17 0x001e0bb0 in QObject::activate_signal () at  
ControlCommandBuffer.C:137

#18 0x002a6878 in QPopupMenu::actSig () at GraphicsCacheItem.C:443
#19 0x002acd30 in QPopupMenu::activateItemAt () at  
GraphicsCacheItem.C:443

#20 0x0038b44c in QMenuBar::activateCommand () at command_inset.C:80
#21 0x00232384 in QApplication::globalEventProcessor () at  
lcolorcache.C:40

#22 0x931288d4 in DispatchEventToHandlers ()
#23 0x9312802c in SendEventToEventTargetInternal ()
#24 0x9312edb0 in SendEventToEventTarget ()
#25 0x931a7cb0 in SendHICommandEvent ()
#26 0x931d7cf4 in SendMenuItemSelectedEvent ()
#27 0x931f3258 in HandleKeyboardEvent ()
#28 0x931288d4 in DispatchEventToHandlers ()
#29 0x9312802c in SendEventToEventTargetInternal ()
#30 0x93127ea8 in SendEventToEventTargetWithOptions ()
#31 0x931f2568 in HandleKeyboardEvent ()
#32 0x9312f12c in ToolboxEventDispatcherHandler ()
#33 0x93128b24 in DispatchEventToHandlers ()
#34 0x9312802c in SendEventToEventTargetInternal ()
#35 0x9312edb0 in SendEventToEventTarget ()
#36 0x0022ec08 in qt_mac_send_event () at lcolorcache.C:40
#37 0x00369e24 in QEventLoop::processEvents () at fileiter.cpp:875
#38 0x003476cc in QEventLoop::enterLoop () at GraphicsCacheItem.C:443
#39 0x003475b8 in QEventLoop::exec () at GraphicsCacheItem.C:443
#40 0x001719b0 in lyx_gui::start ([EMAIL PROTECTED],  
[EMAIL PROTECTED]) at lyx_gui.C:253
#41 0x00065f64 in LyX::priv_exec (this=0xb406e60, [EMAIL PROTECTED],  
argv=0xb850) at lyx_main.C:282
#42 0x00065198 in LyX::exec ([EMAIL PROTECTED], argv=0xb850)  
at ../boost/boost/scoped_ptr.hpp:93

#43 0x2b58 in main (argc=1, argv=0xb850) at main.C:47

Bennett


--
Bennett W. Helm
Department of Philosophy
Franklin  Marshall College
Lancaster, PA 17604-3003
Voice: 717-291-4392
FAX: 717-291-4369
Homepage: http://www.fandm.edu/Departments/Philosophy/staticpages/ 
index.php?page=helm

Re: LyX-140 Crash on Quit

[Bennett Helm]

This bug has gotten lost in the shuffle, so I thought I'd repost it.  
(Others are now reporting the same problem when using LyX/Mac-140pre3.)


Bennett

On Oct 4, 2005, at 1:40 PM, Bennett Helm wrote:

I've occasionally been having lyx-140 crash on quitting. It doesn't  
happen often enough that I've seen a pattern, and I can't reliably  
reproduce it.


Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00050a9b
0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252

252 {
(gdb) bt
#0  0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252
#1  0x0069cb88 in boost::signal2<void, std::string const&,  
InsetBase*, boost::last_value, int, std::less,  
boost::functionstd::allocator > >::operator() (this=0xb4460f0, [EMAIL PROTECTED],  
a2=0x1184f2d0) at ../../boost/boost/signals/signal_template.hpp:335
#2  0x000e46b0 in Dialogs::hide ([EMAIL PROTECTED], inset=0x1184f2d0)  
at Dialogs.C:32
#3  0x0016085c in InsetERT::~InsetERT (this=0x1184f2d0,  
__in_chrg=3) at insetert.C:107
#4  0x0001451c in InsetList::~InsetList (this=0xcb192d0,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_iterator.h:602
#5  0x0009f380 in Paragraph::~Paragraph (this=0xcb192cc,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_alloc.h:242
#6  0x00627d7c in __static_initialization_and_destruction_0  
(__initialize_p=0, __priority=65535) at /usr/include/gcc/darwin/3.3/ 
c++/bits/stl_construct.h:125
#7  0x8fe109dc in  
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkCont 
extE ()

#8  0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#9  0x90013a5c in __cxa_finalize ()
#10 0x90013904 in exit ()
#11 0x00171b08 in lyx_gui::exit () at lyx_gui.C:285
#12 0x00062de4 in QuitLyX (noask=8210760) at lyx_cb.C:219
#13 0x000760a8 in LyXFunc::dispatch (this=0xb44fbf0,  
[EMAIL PROTECTED]) at /usr/include/gcc/darwin/3.3/c++/bits/ 
basic_string.h:1136
#14 0x004562a0 in lyx::frontend::QLPopupMenu::fire (this=0xb4577a0,  
index=5002) at ../../../src/MenuBackend.h:97
#15 0x00506418 in lyx::frontend::QLPopupMenu::qt_invoke  
(this=0xb4577a0, _id=57, _o=0xbfffe560) at /Users/bennett/lyx/ 
gcc-3.3/qt-mac-free-3.3.5/include/private/qucom_p.h:388
#16 0x001e0920 in QObject::activate_signal () at  
ControlCommandBuffer.C:137
#17 0x001e0bb0 in QObject::activate_signal () at  
ControlCommandBuffer.C:137

#18 0x002a6878 in QPopupMenu::actSig () at GraphicsCacheItem.C:443
#19 0x002acd30 in QPopupMenu::activateItemAt () at  
GraphicsCacheItem.C:443

#20 0x0038b44c in QMenuBar::activateCommand () at command_inset.C:80
#21 0x00232384 in QApplication::globalEventProcessor () at  
lcolorcache.C:40

#22 0x931288d4 in DispatchEventToHandlers ()
#23 0x9312802c in SendEventToEventTargetInternal ()
#24 0x9312edb0 in SendEventToEventTarget ()
#25 0x931a7cb0 in SendHICommandEvent ()
#26 0x931d7cf4 in SendMenuItemSelectedEvent ()
#27 0x931f3258 in HandleKeyboardEvent ()
#28 0x931288d4 in DispatchEventToHandlers ()
#29 0x9312802c in SendEventToEventTargetInternal ()
#30 0x93127ea8 in SendEventToEventTargetWithOptions ()
#31 0x931f2568 in HandleKeyboardEvent ()
#32 0x9312f12c in ToolboxEventDispatcherHandler ()
#33 0x93128b24 in DispatchEventToHandlers ()
#34 0x9312802c in SendEventToEventTargetInternal ()
#35 0x9312edb0 in SendEventToEventTarget ()
#36 0x0022ec08 in qt_mac_send_event () at lcolorcache.C:40
#37 0x00369e24 in QEventLoop::processEvents () at fileiter.cpp:875
#38 0x003476cc in QEventLoop::enterLoop () at GraphicsCacheItem.C:443
#39 0x003475b8 in QEventLoop::exec () at GraphicsCacheItem.C:443
#40 0x001719b0 in lyx_gui::start ([EMAIL PROTECTED],  
[EMAIL PROTECTED]) at lyx_gui.C:253
#41 0x00065f64 in LyX::priv_exec (this=0xb406e60, [EMAIL PROTECTED],  
argv=0xb850) at lyx_main.C:282
#42 0x00065198 in LyX::exec ([EMAIL PROTECTED], argv=0xb850)  
at ../boost/boost/scoped_ptr.hpp:93

#43 0x2b58 in main (argc=1, argv=0xb850) at main.C:47

Bennett


--
Bennett W. Helm
Department of Philosophy
Franklin & Marshall College
Lancaster, PA 17604-3003
Voice: 717-291-4392
FAX: 717-291-4369
Homepage: <http://www.fandm.edu/Departments/Philosophy/staticpages/ 
index.php?page=helm>

Re: de_UserGuide-140.lyx + de_Extended-140.lyx

[Jean-Marc Lasgouttes]

 Hartmut == Hartmut Haase [EMAIL PROTECTED] writes:

Hartmut  Hi Jean-Marc, here are two updates according to name changes
Hartmut I agreed with Michael. 

Thanks Hartmut. There are committed now.

JMarc

Re: de_UserGuide-140.lyx + de_Extended-140.lyx

[Jean-Marc Lasgouttes]

> "Hartmut" == Hartmut Haase <[EMAIL PROTECTED]> writes:

Hartmut>  Hi Jean-Marc, here are two updates according to name changes
Hartmut> I agreed with Michael. 

Thanks Hartmut. There are committed now.

JMarc

LyX-140 Crash on Quit

[Bennett Helm]

I've occasionally been having lyx-140 crash on quitting. It doesn't  
happen often enough that I've seen a pattern, and I can't reliably  
reproduce it.


Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00050a9b
0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252

252 {
(gdb) bt
#0  0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252
#1  0x0069cb88 in boost::signal2void, std::string const,  
InsetBase*, boost::last_valuevoid, int, std::lessint,  
boost::functionvoid ()(std::string const, InsetBase*),  
std::allocatorvoid  ::operator() (this=0xb4460f0, [EMAIL PROTECTED],  
a2=0x1184f2d0) at ../../boost/boost/signals/signal_template.hpp:335
#2  0x000e46b0 in Dialogs::hide ([EMAIL PROTECTED], inset=0x1184f2d0) at  
Dialogs.C:32
#3  0x0016085c in InsetERT::~InsetERT (this=0x1184f2d0, __in_chrg=3)  
at insetert.C:107
#4  0x0001451c in InsetList::~InsetList (this=0xcb192d0,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_iterator.h:602
#5  0x0009f380 in Paragraph::~Paragraph (this=0xcb192cc,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_alloc.h:242
#6  0x00627d7c in __static_initialization_and_destruction_0  
(__initialize_p=0, __priority=65535) at /usr/include/gcc/darwin/3.3/c+ 
+/bits/stl_construct.h:125
#7  0x8fe109dc in  
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContex 
tE ()

#8  0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#9  0x90013a5c in __cxa_finalize ()
#10 0x90013904 in exit ()
#11 0x00171b08 in lyx_gui::exit () at lyx_gui.C:285
#12 0x00062de4 in QuitLyX (noask=8210760) at lyx_cb.C:219
#13 0x000760a8 in LyXFunc::dispatch (this=0xb44fbf0, [EMAIL PROTECTED])  
at /usr/include/gcc/darwin/3.3/c++/bits/basic_string.h:1136
#14 0x004562a0 in lyx::frontend::QLPopupMenu::fire (this=0xb4577a0,  
index=5002) at ../../../src/MenuBackend.h:97
#15 0x00506418 in lyx::frontend::QLPopupMenu::qt_invoke  
(this=0xb4577a0, _id=57, _o=0xbfffe560) at /Users/bennett/lyx/gcc-3.3/ 
qt-mac-free-3.3.5/include/private/qucom_p.h:388
#16 0x001e0920 in QObject::activate_signal () at  
ControlCommandBuffer.C:137
#17 0x001e0bb0 in QObject::activate_signal () at  
ControlCommandBuffer.C:137

#18 0x002a6878 in QPopupMenu::actSig () at GraphicsCacheItem.C:443
#19 0x002acd30 in QPopupMenu::activateItemAt () at  
GraphicsCacheItem.C:443

#20 0x0038b44c in QMenuBar::activateCommand () at command_inset.C:80
#21 0x00232384 in QApplication::globalEventProcessor () at  
lcolorcache.C:40

#22 0x931288d4 in DispatchEventToHandlers ()
#23 0x9312802c in SendEventToEventTargetInternal ()
#24 0x9312edb0 in SendEventToEventTarget ()
#25 0x931a7cb0 in SendHICommandEvent ()
#26 0x931d7cf4 in SendMenuItemSelectedEvent ()
#27 0x931f3258 in HandleKeyboardEvent ()
#28 0x931288d4 in DispatchEventToHandlers ()
#29 0x9312802c in SendEventToEventTargetInternal ()
#30 0x93127ea8 in SendEventToEventTargetWithOptions ()
#31 0x931f2568 in HandleKeyboardEvent ()
#32 0x9312f12c in ToolboxEventDispatcherHandler ()
#33 0x93128b24 in DispatchEventToHandlers ()
#34 0x9312802c in SendEventToEventTargetInternal ()
#35 0x9312edb0 in SendEventToEventTarget ()
#36 0x0022ec08 in qt_mac_send_event () at lcolorcache.C:40
#37 0x00369e24 in QEventLoop::processEvents () at fileiter.cpp:875
#38 0x003476cc in QEventLoop::enterLoop () at GraphicsCacheItem.C:443
#39 0x003475b8 in QEventLoop::exec () at GraphicsCacheItem.C:443
#40 0x001719b0 in lyx_gui::start ([EMAIL PROTECTED],  
[EMAIL PROTECTED]) at lyx_gui.C:253
#41 0x00065f64 in LyX::priv_exec (this=0xb406e60, [EMAIL PROTECTED],  
argv=0xb850) at lyx_main.C:282
#42 0x00065198 in LyX::exec ([EMAIL PROTECTED], argv=0xb850) at ../ 
boost/boost/scoped_ptr.hpp:93

#43 0x2b58 in main (argc=1, argv=0xb850) at main.C:47

Bennett

LyX-140 Crash on Quit

[Bennett Helm]

I've occasionally been having lyx-140 crash on quitting. It doesn't  
happen often enough that I've seen a pattern, and I can't reliably  
reproduce it.


Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00050a9b
0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252

252 {
(gdb) bt
#0  0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252
#1  0x0069cb88 in boost::signal2<void, std::string const&,  
InsetBase*, boost::last_value, int, std::less,  
boost::functionstd::allocator > >::operator() (this=0xb4460f0, [EMAIL PROTECTED],  
a2=0x1184f2d0) at ../../boost/boost/signals/signal_template.hpp:335
#2  0x000e46b0 in Dialogs::hide ([EMAIL PROTECTED], inset=0x1184f2d0) at  
Dialogs.C:32
#3  0x0016085c in InsetERT::~InsetERT (this=0x1184f2d0, __in_chrg=3)  
at insetert.C:107
#4  0x0001451c in InsetList::~InsetList (this=0xcb192d0,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_iterator.h:602
#5  0x0009f380 in Paragraph::~Paragraph (this=0xcb192cc,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_alloc.h:242
#6  0x00627d7c in __static_initialization_and_destruction_0  
(__initialize_p=0, __priority=65535) at /usr/include/gcc/darwin/3.3/c+ 
+/bits/stl_construct.h:125
#7  0x8fe109dc in  
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContex 
tE ()

#8  0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#9  0x90013a5c in __cxa_finalize ()
#10 0x90013904 in exit ()
#11 0x00171b08 in lyx_gui::exit () at lyx_gui.C:285
#12 0x00062de4 in QuitLyX (noask=8210760) at lyx_cb.C:219
#13 0x000760a8 in LyXFunc::dispatch (this=0xb44fbf0, [EMAIL PROTECTED])  
at /usr/include/gcc/darwin/3.3/c++/bits/basic_string.h:1136
#14 0x004562a0 in lyx::frontend::QLPopupMenu::fire (this=0xb4577a0,  
index=5002) at ../../../src/MenuBackend.h:97
#15 0x00506418 in lyx::frontend::QLPopupMenu::qt_invoke  
(this=0xb4577a0, _id=57, _o=0xbfffe560) at /Users/bennett/lyx/gcc-3.3/ 
qt-mac-free-3.3.5/include/private/qucom_p.h:388
#16 0x001e0920 in QObject::activate_signal () at  
ControlCommandBuffer.C:137
#17 0x001e0bb0 in QObject::activate_signal () at  
ControlCommandBuffer.C:137

#18 0x002a6878 in QPopupMenu::actSig () at GraphicsCacheItem.C:443
#19 0x002acd30 in QPopupMenu::activateItemAt () at  
GraphicsCacheItem.C:443

#20 0x0038b44c in QMenuBar::activateCommand () at command_inset.C:80
#21 0x00232384 in QApplication::globalEventProcessor () at  
lcolorcache.C:40

#22 0x931288d4 in DispatchEventToHandlers ()
#23 0x9312802c in SendEventToEventTargetInternal ()
#24 0x9312edb0 in SendEventToEventTarget ()
#25 0x931a7cb0 in SendHICommandEvent ()
#26 0x931d7cf4 in SendMenuItemSelectedEvent ()
#27 0x931f3258 in HandleKeyboardEvent ()
#28 0x931288d4 in DispatchEventToHandlers ()
#29 0x9312802c in SendEventToEventTargetInternal ()
#30 0x93127ea8 in SendEventToEventTargetWithOptions ()
#31 0x931f2568 in HandleKeyboardEvent ()
#32 0x9312f12c in ToolboxEventDispatcherHandler ()
#33 0x93128b24 in DispatchEventToHandlers ()
#34 0x9312802c in SendEventToEventTargetInternal ()
#35 0x9312edb0 in SendEventToEventTarget ()
#36 0x0022ec08 in qt_mac_send_event () at lcolorcache.C:40
#37 0x00369e24 in QEventLoop::processEvents () at fileiter.cpp:875
#38 0x003476cc in QEventLoop::enterLoop () at GraphicsCacheItem.C:443
#39 0x003475b8 in QEventLoop::exec () at GraphicsCacheItem.C:443
#40 0x001719b0 in lyx_gui::start ([EMAIL PROTECTED],  
[EMAIL PROTECTED]) at lyx_gui.C:253
#41 0x00065f64 in LyX::priv_exec (this=0xb406e60, [EMAIL PROTECTED],  
argv=0xb850) at lyx_main.C:282
#42 0x00065198 in LyX::exec ([EMAIL PROTECTED], argv=0xb850) at ../ 
boost/boost/scoped_ptr.hpp:93

#43 0x2b58 in main (argc=1, argv=0xb850) at main.C:47

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett That seems to work for me.

The important question is whether the information in lyx.pot is
reasonable. You should see entries like:

msgid \\arabic{enumi}.
msgstr 

(what is important here is the double backslash).

JMarc

Re: LyX 140 configure problem with awk

[Bennett Helm]

On Sep 13, 2005, at 5:16 AM, Jean-Marc Lasgouttes wrote:


The important question is whether the information in lyx.pot is
reasonable. You should see entries like:

msgid \\arabic{enumi}.
msgstr 

(what is important here is the double backslash).


I don't get \\arabic{enumi} in particular. I do get double  
backslashes in the following cases, all of which look reasonable:


\\begin_header
\\begin_document
\\,
\\:
\\;
\\quad
\\qquad
... etc. in QMathDialog.C
\\input
\\include
\\verbatiminput
\\usepackage
\\documentclass
\\selectlanguage

There aren't cases of single backslashes where it looks like doubles  
should be used instead.


Is that what you need to know?

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett On Sep 13, 2005, at 5:16 AM, Jean-Marc Lasgouttes wrote:
 The important question is whether the information in lyx.pot is
 reasonable. You should see entries like:
 
 msgid \\arabic{enumi}. msgstr 
 
 (what is important here is the double backslash).

Bennett I don't get \\arabic{enumi} in particular. I do get double
Bennett backslashes in the following cases, all of which look
Bennett reasonable:

Bennett There aren't cases of single backslashes where it looks like
Bennett doubles should be used instead.

Bennett Is that what you need to know?

What I am interested in are entries related to LabelString in layout
files, so my enumi example was not very well chosen.

For example, numarticle.inc says

Style Section
LabelType Counter
LabelCounter  section
LabelString   \arabic{section}
LabelStringAppendix   \Alph{section}
TocLevel  1
End

so you should find the strings \\arabic{section} and
\\Alph{section} in the .pot file.

JMarc

Re: LyX 140 configure problem with awk

[Bennett Helm]

On Sep 13, 2005, at 8:56 AM, Jean-Marc Lasgouttes wrote:


What I am interested in are entries related to LabelString in layout
files, so my enumi example was not very well chosen.


Actually, it was my fault: I was stupidly looking at lyx.pot from the  
wrong build.



For example, numarticle.inc says

Style Section
LabelType Counter
LabelCounter  section
LabelString   \arabic{section}
LabelStringAppendix   \Alph{section}
TocLevel  1
End

so you should find the strings \\arabic{section} and
\\Alph{section} in the .pot file.


Yes -- they're all there (at least every one I checked!).

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

 so you should find the strings \\arabic{section} and
 \\Alph{section} in the .pot file.

Bennett Yes -- they're all there (at least every one I checked!).

Very good. I'll apply the patch.

JMarc

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> That seems to work for me.

The important question is whether the information in lyx.pot is
reasonable. You should see entries like:

msgid "\\arabic{enumi}."
msgstr ""

(what is important here is the double backslash).

JMarc

Re: LyX 140 configure problem with awk

[Bennett Helm]

On Sep 13, 2005, at 5:16 AM, Jean-Marc Lasgouttes wrote:


The important question is whether the information in lyx.pot is
reasonable. You should see entries like:

msgid "\\arabic{enumi}."
msgstr ""

(what is important here is the double backslash).


I don't get \\arabic{enumi} in particular. I do get double  
backslashes in the following cases, all of which look reasonable:


\\begin_header
\\begin_document
\\,
\\:
\\;
\\quad
\\qquad
... etc. in QMathDialog.C
\\input
\\include
\\verbatiminput
\\usepackage
\\documentclass
\\selectlanguage

There aren't cases of single backslashes where it looks like doubles  
should be used instead.


Is that what you need to know?

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> On Sep 13, 2005, at 5:16 AM, Jean-Marc Lasgouttes wrote:
>> The important question is whether the information in lyx.pot is
>> reasonable. You should see entries like:
>> 
>> msgid "\\arabic{enumi}." msgstr ""
>> 
>> (what is important here is the double backslash).

Bennett> I don't get \\arabic{enumi} in particular. I do get double
Bennett> backslashes in the following cases, all of which look
Bennett> reasonable:

Bennett> There aren't cases of single backslashes where it looks like
Bennett> doubles should be used instead.

Bennett> Is that what you need to know?

What I am interested in are entries related to LabelString in layout
files, so my enumi example was not very well chosen.

For example, numarticle.inc says

Style Section
LabelType Counter
LabelCounter  section
LabelString   "\arabic{section}"
LabelStringAppendix   "\Alph{section}"
TocLevel  1
End

so you should find the strings "\\arabic{section}" and
"\\Alph{section}" in the .pot file.

JMarc

Re: LyX 140 configure problem with awk

[Bennett Helm]

On Sep 13, 2005, at 8:56 AM, Jean-Marc Lasgouttes wrote:


What I am interested in are entries related to LabelString in layout
files, so my enumi example was not very well chosen.


Actually, it was my fault: I was stupidly looking at lyx.pot from the  
wrong build.



For example, numarticle.inc says

Style Section
LabelType Counter
LabelCounter  section
LabelString   "\arabic{section}"
LabelStringAppendix   "\Alph{section}"
TocLevel  1
End

so you should find the strings "\\arabic{section}" and
"\\Alph{section}" in the .pot file.


Yes -- they're all there (at least every one I checked!).

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

>> so you should find the strings "\\arabic{section}" and
>> "\\Alph{section}" in the .pot file.

Bennett> Yes -- they're all there (at least every one I checked!).

Very good. I'll apply the patch.

JMarc

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Jean-Marc Lasgouttes wrote:
 To fix 2/ properly, I see two radically different solutions:

 a) set POSIXLY_CORRECT before invoking awk, so that gawk is in
 POSIX mode and we can use the second gsub flavour.

Angus I think that an app that conforms to POSIX has at least some
Angus chance of working in a multi-platform world. How much work
Angus would it be to ensure that we use POSIX regexes?

OK, people who have problems with gawk, could you try the following
patch?

JMarc

Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.1023
diff -u -p -r1.1023 ChangeLog
--- ChangeLog	18 Jul 2005 15:49:56 -	1.1023
+++ ChangeLog	12 Sep 2005 14:38:06 -
@@ -1,3 +1,8 @@
+2005-09-12  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+
+	* configure.ac: check for AWK and use --posix option if we found
+	gawk.
+
 2005-07-18  Lars Gullik Bjønnes  [EMAIL PROTECTED]
 
 	* configure.ac: version back to 1.4.0cvs 
Index: configure.ac
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/configure.ac,v
retrieving revision 1.58
diff -u -p -r1.58 configure.ac
--- configure.ac	18 Jul 2005 15:49:57 -	1.58
+++ configure.ac	12 Sep 2005 14:38:06 -
@@ -31,7 +31,8 @@ done
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 
-AC_SUBST(AWK,[gawk])
+AC_PROG_AWK
+test $AWK = gawk  AWK=gawk --posix
 
 #AC_PROG_RANLIB
 AC_CHECK_PROG(KPSEWHICH, kpsewhich, kpsewhich, :)
Index: po/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/ChangeLog,v
retrieving revision 1.229
diff -u -p -r1.229 ChangeLog
--- po/ChangeLog	8 Sep 2005 16:57:13 -	1.229
+++ po/ChangeLog	12 Sep 2005 14:38:06 -
@@ -1,3 +1,7 @@
+2005-09-12  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+
+	* Makefile.in.in: when invoking awk, use POSIX regexps only.
+
 2005-09-08  Martin Vermeer  [EMAIL PROTECTED]
 
 	* he.po: move enum, appendix counter functionality here
Index: po/Makefile.in.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/Makefile.in.in,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile.in.in
--- po/Makefile.in.in	15 Jul 2005 18:58:17 -	1.51
+++ po/Makefile.in.in	12 Sep 2005 14:38:06 -
@@ -446,8 +446,8 @@ layouts_l10n.pot: $(top_srcdir)/lib/layo
 		/LabelString[A-Za-z]*/ { \
 			line=$$0; \
 			sub(/[[:space:]]*LabelString[A-Za-z]*[[:space:]]*/, , line); \
-			gsub(//, , line); \
-			gsub(/\\/, , line); \
+			gsub(/\/, , line); \
+			gsub(/\/, , line); \
 			if (line != ) \
 			  printf(#: %s:%d\nmsgid \%s\\nmsgstr \\\n\n, \
  fixupfilename(), FNR, line); \
@@ -455,14 +455,14 @@ layouts_l10n.pot: $(top_srcdir)/lib/layo
 		/GuiName/ { \
 			line=$$0; \
 			sub(/[[:space:]]*GuiName[[:space:]]*/, , line); \
-			gsub(//, , line); \
+			gsub(/\/, , line); \
 			printf(#: %s:%d\nmsgid \%s\\nmsgstr \\\n\n, \
 fixupfilename(), FNR, line); \
 		} \
 		/ListName/ { \
 			line=$$0; \
 			sub(/[[:space:]]*ListName[[:space:]]*/, , line); \
-			gsub(//, , line); \
+			gsub(/\/, , line); \
 			printf(#: %s:%d\nmsgid \%s\\nmsgstr \\\n\n, \
 fixupfilename(), FNR, line); \
 		}' \

Re: LyX 140 configure problem with awk

[Bennett Helm]

On Sep 12, 2005, at 10:38 AM, Jean-Marc Lasgouttes wrote:


Angus == Angus Leeming [EMAIL PROTECTED] writes:



Angus Jean-Marc Lasgouttes wrote:


To fix 2/ properly, I see two radically different solutions:





a) set POSIXLY_CORRECT before invoking awk, so that gawk is in
POSIX mode and we can use the second gsub flavour.



Angus I think that an app that conforms to POSIX has at least some
Angus chance of working in a multi-platform world. How much work
Angus would it be to ensure that we use POSIX regexes?

OK, people who have problems with gawk, could you try the following
patch?


That seems to work for me.

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Jean-Marc Lasgouttes wrote:
>> To fix 2/ properly, I see two radically different solutions:

>> a) set POSIXLY_CORRECT before invoking awk, so that gawk is in
>> POSIX mode and we can use the second gsub flavour.

Angus> I think that an app that conforms to POSIX has at least some
Angus> chance of working in a multi-platform world. How much work
Angus> would it be to ensure that we use POSIX regexes?

OK, people who have problems with gawk, could you try the following
patch?

JMarc

Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.1023
diff -u -p -r1.1023 ChangeLog
--- ChangeLog	18 Jul 2005 15:49:56 -	1.1023
+++ ChangeLog	12 Sep 2005 14:38:06 -
@@ -1,3 +1,8 @@
+2005-09-12  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+	* configure.ac: check for AWK and use --posix option if we found
+	gawk.
+
 2005-07-18  Lars Gullik Bjønnes  <[EMAIL PROTECTED]>
 
 	* configure.ac: version back to 1.4.0cvs 
Index: configure.ac
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/configure.ac,v
retrieving revision 1.58
diff -u -p -r1.58 configure.ac
--- configure.ac	18 Jul 2005 15:49:57 -	1.58
+++ configure.ac	12 Sep 2005 14:38:06 -
@@ -31,7 +31,8 @@ done
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 
-AC_SUBST(AWK,[gawk])
+AC_PROG_AWK
+test "$AWK" = gawk && AWK="gawk --posix"
 
 #AC_PROG_RANLIB
 AC_CHECK_PROG(KPSEWHICH, kpsewhich, kpsewhich, :)
Index: po/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/ChangeLog,v
retrieving revision 1.229
diff -u -p -r1.229 ChangeLog
--- po/ChangeLog	8 Sep 2005 16:57:13 -	1.229
+++ po/ChangeLog	12 Sep 2005 14:38:06 -
@@ -1,3 +1,7 @@
+2005-09-12  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+	* Makefile.in.in: when invoking awk, use POSIX regexps only.
+
 2005-09-08  Martin Vermeer  <[EMAIL PROTECTED]>
 
 	* he.po: move enum, appendix counter functionality here
Index: po/Makefile.in.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/Makefile.in.in,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile.in.in
--- po/Makefile.in.in	15 Jul 2005 18:58:17 -	1.51
+++ po/Makefile.in.in	12 Sep 2005 14:38:06 -
@@ -446,8 +446,8 @@ layouts_l10n.pot: $(top_srcdir)/lib/layo
 		/LabelString[A-Za-z]*/ { \
 			line=$$0; \
 			sub(/[[:space:]]*LabelString[A-Za-z]*[[:space:]]*/, "", line); \
-			gsub(/"/, "", line); \
-			gsub(/\\/, "", line); \
+			gsub(/\"/, "", line); \
+			gsub(/\/, "", line); \
 			if (line != "") \
 			  printf("#: %s:%d\nmsgid \"%s\"\nmsgstr \"\"\n\n", \
  fixupfilename(), FNR, line); \
@@ -455,14 +455,14 @@ layouts_l10n.pot: $(top_srcdir)/lib/layo
 		/GuiName/ { \
 			line=$$0; \
 			sub(/[[:space:]]*GuiName[[:space:]]*/, "", line); \
-			gsub(/"/, "", line); \
+			gsub(/\"/, "", line); \
 			printf("#: %s:%d\nmsgid \"%s\"\nmsgstr \"\"\n\n", \
 fixupfilename(), FNR, line); \
 		} \
 		/ListName/ { \
 			line=$$0; \
 			sub(/[[:space:]]*ListName[[:space:]]*/, "", line); \
-			gsub(/"/, "", line); \
+			gsub(/\"/, "", line); \
 			printf("#: %s:%d\nmsgid \"%s\"\nmsgstr \"\"\n\n", \
 fixupfilename(), FNR, line); \
 		}' \

Re: LyX 140 configure problem with awk

[Bennett Helm]

On Sep 12, 2005, at 10:38 AM, Jean-Marc Lasgouttes wrote:


"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:



Angus> Jean-Marc Lasgouttes wrote:


To fix 2/ properly, I see two radically different solutions:





a) set POSIXLY_CORRECT before invoking awk, so that gawk is in
POSIX mode and we can use the second gsub flavour.



Angus> I think that an app that conforms to POSIX has at least some
Angus> chance of working in a multi-platform world. How much work
Angus> would it be to ensure that we use POSIX regexes?

OK, people who have problems with gawk, could you try the following
patch?


That seems to work for me.

Bennett

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Some Luddite decided to add gawk-specific code. I believe that
Angus Lars knows where and what...

Well, actually, the gawk-specific code was already there, but we did
not test for it, and thus created broken .pot files. The two problems
that I know about are:

1/ we use some POSIX extensions in regexps, like [[:space:]], but this
  is probably OK in most cases.

2/ GNU awk regexps supports some special escapes:

   The \y, \B, \, \, \w, \W, \`, and \' operators are specific to  gawk;
   they  are  extensions based on facilities in the GNU regular expression
   libraries.

This means, as far as I understand, that a statement like this one
gsub(/\\/, , line); \
which is meant to replace single \ by double ones (to handle 
LabelString with counters) only work with GNU awk, whereas
gsub(/\/, , line); \
is the right one for other awks.


To fix 2/ properly, I see two radically different solutions:

a) set POSIXLY_CORRECT before invoking awk, so that gawk is in POSIX
mode and we can use the second gsub flavour.

b) change all layout files to use \\ in LabelString (the parser will
handle that) so that we do not have to use this gsub.

Insert some random thought about other people being able to
consistently prove me wrong (without the courteous part, of course).

JMarc

Re: LyX 140 configure problem with awk

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
 To fix 2/ properly, I see two radically different solutions:

 a) set POSIXLY_CORRECT before invoking awk, so that gawk is in POSIX
 mode and we can use the second gsub flavour.

I think that an app that conforms to POSIX has at least some chance of
working in a multi-platform world. How much work would it be to ensure
that we use POSIX regexes?

 b) change all layout files to use \\ in LabelString (the parser will
 handle that) so that we do not have to use this gsub.

I don't think that we should do this. Keeping TeX syntax unchanged will
reduce mistakes.

-- 
Angus

Re: LyX 140 configure problem with awk

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Some Luddite decided to add gawk-specific code. I believe that
Angus> Lars knows where and what...

Well, actually, the gawk-specific code was already there, but we did
not test for it, and thus created broken .pot files. The two problems
that I know about are:

1/ we use some POSIX extensions in regexps, like [[:space:]], but this
  is probably OK in most cases.

2/ GNU awk regexps supports some special escapes:

   The \y, \B, \<, \>, \w, \W, \`, and \' operators are specific to  gawk;
   they  are  extensions based on facilities in the GNU regular expression
   libraries.

This means, as far as I understand, that a statement like this one
gsub(/\\/, "", line); \
which is meant to replace single \ by double ones (to handle 
LabelString with counters) only work with GNU awk, whereas
gsub(/\/, "", line); \
is the right one for other awks.


To fix 2/ properly, I see two radically different solutions:

a) set POSIXLY_CORRECT before invoking awk, so that gawk is in POSIX
mode and we can use the second gsub flavour.

b) change all layout files to use \\ in LabelString (the parser will
handle that) so that we do not have to use this gsub.

Insert some random thought about other people being able to
consistently prove me wrong (without the courteous part, of course).

JMarc

Re: LyX 140 configure problem with awk

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> To fix 2/ properly, I see two radically different solutions:

> a) set POSIXLY_CORRECT before invoking awk, so that gawk is in POSIX
> mode and we can use the second gsub flavour.

I think that an app that conforms to POSIX has at least some chance of
working in a multi-platform world. How much work would it be to ensure
that we use POSIX regexes?

> b) change all layout files to use \\ in LabelString (the parser will
> handle that) so that we do not have to use this gsub.

I don't think that we should do this. Keeping TeX syntax unchanged will
reduce mistakes.

-- 
Angus

LyX 140 configure problem with awk

[Bennett Helm]

Now that I've finally got cvs set up again, I notice that there's a  
problem with configure on machines without gawk (like Mac OS X).  
Although the code starting at line 1904 correctly finds that I don't  
have gawk, mawk, or nawk but do have awk, and although ac_cv_prog_AWK  
is properly set to awk, I nonetheless find that line 2225 makes all  
this irrelevant (and prevents things from working for me):


AWK=gawk

Any reason line 2225 shouldn't be deleted?

Thanks.

Bennett

Re: LyX 140 configure problem with awk

[Angus Leeming]

Bennett Helm wrote:

 Now that I've finally got cvs set up again, I notice that there's a
 problem with configure on machines without gawk (like Mac OS X).
 Although the code starting at line 1904 correctly finds that I don't
 have gawk, mawk, or nawk but do have awk, and although ac_cv_prog_AWK
 is properly set to awk, I nonetheless find that line 2225 makes all
 this irrelevant (and prevents things from working for me):
 
 AWK=gawk
 
 Any reason line 2225 shouldn't be deleted?

Some Luddite decided to add gawk-specific code. I believe that Lars knows
where and what...

-- 
Angus

LyX 140 configure problem with awk

[Bennett Helm]

Now that I've finally got cvs set up again, I notice that there's a  
problem with configure on machines without gawk (like Mac OS X).  
Although the code starting at line 1904 correctly finds that I don't  
have gawk, mawk, or nawk but do have awk, and although ac_cv_prog_AWK  
is properly set to awk, I nonetheless find that line 2225 makes all  
this irrelevant (and prevents things from working for me):


AWK=gawk

Any reason line 2225 shouldn't be deleted?

Thanks.

Bennett

Re: LyX 140 configure problem with awk

[Angus Leeming]

Bennett Helm wrote:

> Now that I've finally got cvs set up again, I notice that there's a
> problem with configure on machines without gawk (like Mac OS X).
> Although the code starting at line 1904 correctly finds that I don't
> have gawk, mawk, or nawk but do have awk, and although ac_cv_prog_AWK
> is properly set to awk, I nonetheless find that line 2225 makes all
> this irrelevant (and prevents things from working for me):
> 
> AWK=gawk
> 
> Any reason line 2225 shouldn't be deleted?

Some Luddite decided to add gawk-specific code. I believe that Lars knows
where and what...

-- 
Angus

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Andre Poenitz [EMAIL PROTECTED] writes:

| On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
 On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
  On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
  
   So why not solve that he other way round: Do not blink the cursor unless
   all draws have been finished?
  
  I thought that's what Martin was planning (and it certainly sounds
  right)
 
 I'm note sure we are talking about the same thing now. Anyway I am happy
 the way things have turned out with Lars' cache (though I still don't
 grok it).

| I don't thing anything based on tweaking timers is a conceptionally
| sound solution. It miht work, and this might all we need to get 1.4
| out of the door, but it does not sound right.

It is not tweaking timers it is mostly about getting access to the
event queue. (or do you have a nother way of peeking in the event
queue?)

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Andre Poenitz [EMAIL PROTECTED] writes:

| On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
 On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
 
  So why not solve that he other way round: Do not blink the cursor unless
  all draws have been finished?
 
 I thought that's what Martin was planning (and it certainly sounds
 right)

| Oh I see. I was swamped with messages suggesting that we try to hide
| the problem using some well-tuned timer

It is my event queue thingie you are talking about that is not about
tweaking some timer.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
>> On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
>> > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
>> > 
>> > > So why not solve that he other way round: Do not blink the cursor unless
>> > > all draws have been finished?
>> > 
>> > I thought that's what Martin was planning (and it certainly sounds
>> > right)
>> 
>> I'm note sure we are talking about the same thing now. Anyway I am happy
>> the way things have turned out with Lars' cache (though I still don't
>> grok it).
>
| I don't thing anything based on tweaking timers is a conceptionally
| sound solution. It miht work, and this might all we need to get 1.4
| out of the door, but it does not sound right.

It is not tweaking timers it is mostly about getting access to the
event queue. (or do you have a nother way of peeking in the event
queue?)

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
>> On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
>> 
>> > So why not solve that he other way round: Do not blink the cursor unless
>> > all draws have been finished?
>> 
>> I thought that's what Martin was planning (and it certainly sounds
>> right)
>
| Oh I see. I was swamped with messages suggesting that we try to hide
| the problem using some well-tuned timer

It is my event queue thingie you are talking about that is not about
tweaking some timer.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[John Levon]

On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:

 So why not solve that he other way round: Do not blink the cursor unless
 all draws have been finished?

I thought that's what Martin was planning (and it certainly sounds
right)

regards
john

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
 On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
 
  So why not solve that he other way round: Do not blink the cursor unless
  all draws have been finished?
 
 I thought that's what Martin was planning (and it certainly sounds
 right)

I'm note sure we are talking about the same thing now. Anyway I am happy
the way things have turned out with Lars' cache (though I still don't
grok it).

- Martin



pgpMcwK4CjNos.pgp
Description: PGP signature

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
 On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
 
  So why not solve that he other way round: Do not blink the cursor unless
  all draws have been finished?
 
 I thought that's what Martin was planning (and it certainly sounds
 right)

Oh I see. I was swamped with messages suggesting that we try to hide
the problem using some well-tuned timer

Andre'

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
 On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
  On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
  
   So why not solve that he other way round: Do not blink the cursor unless
   all draws have been finished?
  
  I thought that's what Martin was planning (and it certainly sounds
  right)
 
 I'm note sure we are talking about the same thing now. Anyway I am happy
 the way things have turned out with Lars' cache (though I still don't
 grok it).

I don't thing anything based on tweaking timers is a conceptionally
sound solution. It miht work, and this might all we need to get 1.4
out of the door, but it does not sound right.

Andre'

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Sat, May 14, 2005 at 08:42:08PM +0200, Andre Poenitz wrote:
 On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
  On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
  
   So why not solve that he other way round: Do not blink the cursor unless
   all draws have been finished?
  
  I thought that's what Martin was planning (and it certainly sounds
  right)
 
 Oh I see. I was swamped with messages suggesting that we try to hide
 the problem using some well-tuned timer

...and I have a nagging suspicion that that is what Lars' solution
amounts to, but he tells me no...

- Martin



pgpAS7VKCh0a1.pgp
Description: PGP signature

Re: Profiling LyX-140 on Mac

[John Levon]

On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:

> So why not solve that he other way round: Do not blink the cursor unless
> all draws have been finished?

I thought that's what Martin was planning (and it certainly sounds
right)

regards
john

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> 
> > So why not solve that he other way round: Do not blink the cursor unless
> > all draws have been finished?
> 
> I thought that's what Martin was planning (and it certainly sounds
> right)

I'm note sure we are talking about the same thing now. Anyway I am happy
the way things have turned out with Lars' cache (though I still don't
grok it).

- Martin



pgpMcwK4CjNos.pgp
Description: PGP signature

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> 
> > So why not solve that he other way round: Do not blink the cursor unless
> > all draws have been finished?
> 
> I thought that's what Martin was planning (and it certainly sounds
> right)

Oh I see. I was swamped with messages suggesting that we try to hide
the problem using some well-tuned timer

Andre'

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
> On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> > 
> > > So why not solve that he other way round: Do not blink the cursor unless
> > > all draws have been finished?
> > 
> > I thought that's what Martin was planning (and it certainly sounds
> > right)
> 
> I'm note sure we are talking about the same thing now. Anyway I am happy
> the way things have turned out with Lars' cache (though I still don't
> grok it).

I don't thing anything based on tweaking timers is a conceptionally
sound solution. It miht work, and this might all we need to get 1.4
out of the door, but it does not sound right.

Andre'

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Sat, May 14, 2005 at 08:42:08PM +0200, Andre Poenitz wrote:
> On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> > 
> > > So why not solve that he other way round: Do not blink the cursor unless
> > > all draws have been finished?
> > 
> > I thought that's what Martin was planning (and it certainly sounds
> > right)
> 
> Oh I see. I was swamped with messages suggesting that we try to hide
> the problem using some well-tuned timer

...and I have a nagging suspicion that that is what Lars' solution
amounts to, but he tells me no...

- Martin



pgpAS7VKCh0a1.pgp
Description: PGP signature

Re: Profiling LyX-140 on Mac

[Stephan Witt]

Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:41, Asger Alstrup wrote:
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjønnes wrote:

How can events be reordered?
Precisely my question.
Did you check that your keyboard queue is really a queue, and not a stack?

There is no keyboard (or other) queue in the patch that I committed.
Just an idea... maybe a bad one.
I think, there is an implicit stacking everytime event driven
reentrance happens.
I suspect you will use the call stack as event stack too,
when you call processevents() inside an action to handle
a keypress.
Scenario:
Fast typing The last time I tested lyx produces The last tim I tested lyxe
When handling the keypress e of time the processevents entered a new
level on top of the call stack and the rest of the sentence is handled by that.
After returning from that level the pending e is processed and appended at
the end of the text.
Regards,
Stephan

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars So it seems that my brilliant idea was a bit lousy. I do not see
Lars what | Qt machinery could help us, except perhaps
Lars QApplication::postEvent. We | could setup an eventFilter for the
Lars application that fileters user | input events and posts them for
Lars later.

Lars | I am not even sure it would work, but it is similar to the
Lars idea of | queueing key events for later use.

Lars Then I think a queueing solution with coalescing of events is
Lars nicer.

Lars Then we just need a timer that kicks in some 10-20 times a
Lars second to check the queue and do the real work.

Did you try to look at what posteven does? It maintains a queue of
'delayed' events, that it will fire at the next call to processEvents.
It handles event coalescing too. This part of the qt source is quite
easy to follow, actually. This seems a bit simpler to me that your
timer-based approach.

JMarc

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| Lars | I am not even sure it would work, but it is similar to the
| Lars idea of | queueing key events for later use.

| Lars Then I think a queueing solution with coalescing of events is
| Lars nicer.

| Lars Then we just need a timer that kicks in some 10-20 times a
| Lars second to check the queue and do the real work.

| Did you try to look at what posteven does? It maintains a queue of
| 'delayed' events, that it will fire at the next call to
| processEvents.

I already have the events... why do I want to handle them again?

| It handles event coalescing too. This part of the qt source is quite
| easy to follow, actually. This seems a bit simpler to me that your
| timer-based approach.

How will you handle pruning of auto-repeat keyevents then?

and by coalescing I mean combining 'O' and 'h' into 'Oh' before
sending it for insertion into lyx core. fex. (not quite sure if this
will be possible...)

(actually it will, we will have to pass a list of events for the core
to handle, then no scrren update will be done untill the last one has
been handled.)

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Thu, May 12, 2005 at 10:14:26AM +0200, Juergen Spitzmueller wrote:
 I think we should try if LyX builds with Qt4 beta, then we have a real chance 
 that Qt4/Win Free will work too.

Qt4 is vastly different from Qt3. It's basically a new frontend from
LyX's point of view. It is impossible to share much code due to
lots of renamed functions.

Andre'

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Wed, May 11, 2005 at 04:16:53PM +0100, John Levon wrote:
  Well, AFAICS that's only cosmetic. (Question: were there any
  non-cosmetic problems with this? I don't see any.)
 
 What a bizarre attitude! Cosmetics are how every single user interacts
 with LyX, with the single exception of the LyX server.
 
 I am DEAD against breaking this. We absolutely have to process all
 pending draw events before reshowing the cursor, IMHO.

So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?

Andre'

Re: [patch] key event queue (was: Profiling LyX-140 on Mac)

[Andre Poenitz]

On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
 this is kindo a proof-of-concept.

Is there a specific reason this queue is in the frontend and not in the
core?

If it were in the core we could have an 'update' lfuns, and a 'dont need
up-to-date cache'  lfun flags and play games...

Suppose we have a queue like  a, b, Down, c, i.e.

 Key-a[implicitupdate] Key-b[implicitupdate]
 Down[implicitupdate] Key-c[implicitpdate] ...

we'd flag Key-* as 'dont need cache' and Down as 'need cache' and
transform the queue to

  Key-a Key-b Update Down Key-c ...

Andre'

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Thu, May 12, 2005 at 04:05:27PM +0100, Angus Leeming wrote:
  What is making it slower?
  Is it the screen drawing or the new two-stage drawing thing?
 
 In 1.3 we have a row cache and redraw only those rows that have changed. 
 In 1.4 we redraw the entire document on every single key press.

Shouldn't we just draw all (at least partially) visible paragraphs?
At least that was the intention.

Andre'

Re: Profiling LyX-140 on Mac

[Stephan Witt]

Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:41, Asger Alstrup wrote:
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjønnes wrote:

How can events be reordered?
Precisely my question.
Did you check that your keyboard queue is really a queue, and not a stack?

There is no keyboard (or other) queue in the patch that I committed.
Just an idea... maybe a bad one.
I think, there is an implicit stacking everytime event driven
reentrance happens.
I suspect you will use the call stack as event stack too,
when you call processevents() inside an action to handle
a keypress.
Scenario:
Fast typing "The last time I tested lyx" produces "The last tim I tested lyxe"
When handling the keypress "e" of "time" the processevents entered a new
level on top of the call stack and the rest of the sentence is handled by that.
After returning from that level the pending "e" is processed and appended at
the end of the text.
Regards,
Stephan

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> So it seems that my brilliant idea was a bit lousy. I do not see
Lars> what | Qt machinery could help us, except perhaps
Lars> QApplication::postEvent. We | could setup an eventFilter for the
Lars> application that fileters user | input events and posts them for
Lars> later.
>>
Lars> | I am not even sure it would work, but it is similar to the
Lars> idea of | queueing key events for later use.

Lars> Then I think a queueing solution with coalescing of events is
Lars> nicer.

Lars> Then we just need a timer that kicks in some 10-20 times a
Lars> second to check the queue and do the real work.

Did you try to look at what posteven does? It maintains a queue of
'delayed' events, that it will fire at the next call to processEvents.
It handles event coalescing too. This part of the qt source is quite
easy to follow, actually. This seems a bit simpler to me that your
timer-based approach.

JMarc

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| Lars> | I am not even sure it would work, but it is similar to the
| Lars> idea of | queueing key events for later use.
>
| Lars> Then I think a queueing solution with coalescing of events is
| Lars> nicer.
>
| Lars> Then we just need a timer that kicks in some 10-20 times a
| Lars> second to check the queue and do the real work.
>
| Did you try to look at what posteven does? It maintains a queue of
| 'delayed' events, that it will fire at the next call to
| processEvents.

I already have the events... why do I want to handle them again?

| It handles event coalescing too. This part of the qt source is quite
| easy to follow, actually. This seems a bit simpler to me that your
| timer-based approach.

How will you handle pruning of auto-repeat keyevents then?

and by coalescing I mean combining 'O' and 'h' into 'Oh' before
sending it for insertion into lyx core. fex. (not quite sure if this
will be possible...)

(actually it will, we will have to pass a list of events for the core
to handle, then no scrren update will be done untill the last one has
been handled.)

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Thu, May 12, 2005 at 10:14:26AM +0200, Juergen Spitzmueller wrote:
> I think we should try if LyX builds with Qt4 beta, then we have a real chance 
> that Qt4/Win Free will work too.

Qt4 is vastly different from Qt3. It's basically a new frontend from
LyX's point of view. It is impossible to share much code due to
lots of renamed functions.

Andre'

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Wed, May 11, 2005 at 04:16:53PM +0100, John Levon wrote:
> > Well, AFAICS that's only cosmetic. (Question: were there any
> > non-cosmetic problems with this? I don't see any.)
> 
> What a bizarre attitude! Cosmetics are how every single user interacts
> with LyX, with the single exception of the LyX server.
> 
> I am DEAD against breaking this. We absolutely have to process all
> pending draw events before reshowing the cursor, IMHO.

So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?

Andre'

Re: [patch] key event queue (was: Profiling LyX-140 on Mac)

[Andre Poenitz]

On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> this is kindo a proof-of-concept.

Is there a specific reason this queue is in the frontend and not in the
core?

If it were in the core we could have an 'update' lfuns, and a 'dont need
up-to-date cache'  lfun flags and play games...

Suppose we have a queue like  a, b, , c, i.e.

 [implicitupdate] [implicitupdate]
 [implicitupdate] [implicitpdate] ...

we'd flag  as 'dont need cache' and  as 'need cache' and
transform the queue to

   ...

Andre'

Re: Profiling LyX-140 on Mac

[Andre Poenitz]

On Thu, May 12, 2005 at 04:05:27PM +0100, Angus Leeming wrote:
> > What is making it slower?
> > Is it the screen drawing or the new two-stage drawing thing?
> 
> In 1.3 we have a row cache and redraw only those rows that have changed. 
> In 1.4 we redraw the entire document on every single key press.

Shouldn't we just draw all (at least partially) visible paragraphs?
At least that was the intention.

Andre'

Re: Profiling LyX-140 on Mac

[Juergen Spitzmueller]

John Levon wrote:
  3.1.

 OK, then we need to make that the minimum Qt version we support,
 finally. 

Agreed. As long as we silently take care that LyX at least builds against 
Qt2/Win Free unless Qt4 is out.

 Pity about Qt/Win Free or whatever it was but there's not much 
 we can do otherwise.

I think we should try if LyX builds with Qt4 beta, then we have a real chance 
that Qt4/Win Free will work too.

Jürgen

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett But with a large-ish document (about 1 words and with
Bennett many footnotes, citations, and cross references, but with no
Bennett math or graphics), typing at a normal speed is simply
Bennett impossible: the order letters appear in the document is no
Bennett longer the order I type them.

How is the situation now? I am not sure it is going to be faster, but
at least you should be able to provide a profile that is usable...

JMarc

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 15:57, Bennett Helm wrote:
 On May 12, 2005, at 5:45 AM, Jean-Marc Lasgouttes wrote:
 
  Bennett == Bennett Helm [EMAIL PROTECTED] writes:
 
  Bennett But with a large-ish document (about 1 words and with
  Bennett many footnotes, citations, and cross references, but with no
  Bennett math or graphics), typing at a normal speed is simply
  Bennett impossible: the order letters appear in the document is no
  Bennett longer the order I type them.
 
  How is the situation now? I am not sure it is going to be faster, but
  at least you should be able to provide a profile that is usable...
 
 Well, it's worse in two ways.
 
 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing 
 The last time I tested lyx results in: Th attm Itsedlx.

I don't manage to reproduce this, even in the User Guide. But I'm not a
fast typist.

 2. (Unrelated?) Moving the mouse pointer within the LyX window 
 automatically selects text, even when the mouse button has not been 
 pressed.

Not here.

 In case it's useful, I've attached another profile. (Please let me know 
 if this is the right sort of report to provide.)
 
 Bennett

Do I see this correctly?

 | + 54.8% QFontEngineMac::doTextTask(QChar const*, int, int, int, unsigned 
char, int, int, QPaintDevice*, QRegion const*) const (LyX)
 | |   0.1% qMacVersion() (LyX)
 | | - 0.1% QFontEngineMac::doTextTask(QChar const*, int, int, int, unsigned 
char, int, int, QPaintDevice*, QRegion const*) const (LyX)
 | |   0.1% dyld_stub_GetGWorld (LyX)

QFontEngineMac::doTextTask eating 55% of your CPU? Or spending 55% of
its time there, waiting for drawing to finish?

Remember, something's gotta give. We can switch off processEvents
completely, then all keystrokes are eventually processed, but until that
happens, the screen will look unfinished. As I understand these are the
drawing glitches that processEvents was introduced to get rid of. If you
want the screen to be up to date all the time, don't allow keystrokes in
while drawing.

Older LyX also silently drops keystrokes if you type too fast. Only, it
is so much faster that that rarely happens. Perhaps we should work on
1.4 speed, then.

Or should we switch off processEvents just for the Mac architecture?

- Martin



signature.asc
Description: This is a digitally signed message part

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 16:34, Andreas Vox wrote:
 Am 11.05.2005 um 12:55 schrieb Jean-Marc Lasgouttes:

...

 
  It would be interesting to know how things have evolved since Martin's
  latest patch.
 
 
 showCursor() is still recursive.

Yes, but it is allowed to be. It is called also from outside screen
update.

 100% ~ 1 sec cpu time of 30 secs real time
 
 /Andreas

- Martin


signature.asc
Description: This is a digitally signed message part

Re: Profiling LyX-140 on Mac

[Angus Leeming]

Martin Vermeer wrote:
 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
 The last time I tested lyx results in: Th attm Itsedlx.
 
 I don't manage to reproduce this, even in the User Guide. But I'm not a
 fast typist.

I see it when using LyX remotely (Qt/X11).

 Remember, something's gotta give. We can switch off processEvents
 completely, then all keystrokes are eventually processed, but until that
 happens, the screen will look unfinished. As I understand these are the
 drawing glitches that processEvents was introduced to get rid of. If you
 want the screen to be up to date all the time, don't allow keystrokes in
 while drawing.
 
 Older LyX also silently drops keystrokes if you type too fast. Only, it
 is so much faster that that rarely happens. Perhaps we should work on
 1.4 speed, then.

I think we have to. 1.4 is soo much slower than 1.3.
-- 
Angus

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Martin Vermeer wrote:
 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
 The last time I tested lyx results in: Th attm Itsedlx.
 
 I don't manage to reproduce this, even in the User Guide. But I'm not a
 fast typist.

| I see it when using LyX remotely (Qt/X11).

So... where is events ditched?

 Remember, something's gotta give. We can switch off processEvents
 completely, then all keystrokes are eventually processed, but until that
 happens, the screen will look unfinished. As I understand these are the
 drawing glitches that processEvents was introduced to get rid of. If you
 want the screen to be up to date all the time, don't allow keystrokes in
 while drawing.
 
 Older LyX also silently drops keystrokes if you type too fast. Only, it
 is so much faster that that rarely happens. Perhaps we should work on
 1.4 speed, then.

| I think we have to. 1.4 is soo much slower than 1.3.

What is making it slower?
Is it the screen drawing or the new two-stage drawing thing?

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

 Martin == Martin Vermeer [EMAIL PROTECTED] writes:

Martin QFontEngineMac::doTextTask eating 55% of your CPU? Or spending
Martin 55% of its time there, waiting for drawing to finish?

That's weird, especially since none of this time is credited to a
lower-level function.

Martin Older LyX also silently drops keystrokes if you type too fast.
Martin Only, it is so much faster that that rarely happens. Perhaps
Martin we should work on 1.4 speed, then.

Martin Or should we switch off processEvents just for the Mac
Martin architecture?

What may happen is that the processEvents flag means: silently eat
keystroke events instead of leave them in the queue.

Actually reading qeventloop_x11.cpp confirms this analysis (it uses
XNextEvent, whereas XPeekEvent would be better for what we want to
do).

So it seems that my brilliant idea was a bit lousy. I do not see what
Qt machinery could help us, except perhaps QApplication::postEvent. We
could setup an eventFilter for the application that fileters user
input events and posts them for later.

I am not even sure it would work, but it is similar to the idea of
queueing key events for later use.

JMarc

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Angus Leeming [EMAIL PROTECTED] writes:
Lars | Martin Vermeer wrote:
 1. Instead of reordering keystrokes, it drops keystrokes. Thus,
 typing The last time I tested lyx results in: Th attm
 Itsedlx.
  I don't manage to reproduce this, even in the User Guide. But I'm
 not a fast typist.

Lars | I see it when using LyX remotely (Qt/X11).

Lars So... where is events ditched?

By the filter in QEventLoop::processEvents. I hoped that it would let
them in place, but unfortunately, it just silently ditches them.

JMarc

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| So it seems that my brilliant idea was a bit lousy. I do not see what
| Qt machinery could help us, except perhaps QApplication::postEvent. We
| could setup an eventFilter for the application that fileters user
| input events and posts them for later.

| I am not even sure it would work, but it is similar to the idea of
| queueing key events for later use.

Then I think a queueing solution with coalescing of events is nicer.

Then we just need a timer that kicks in some 10-20 times a second to
check the queue and do the real work.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Angus Leeming]

Lars Gullik Bjønnes wrote:

 Angus Leeming [EMAIL PROTECTED] writes:
 
 | Martin Vermeer wrote:
 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
 The last time I tested lyx results in: Th attm Itsedlx.
 
 I don't manage to reproduce this, even in the User Guide. But I'm not a
 fast typist.

 | I see it when using LyX remotely (Qt/X11).
 
 So... where is events ditched?

Attached is QEventLoop::ProcessEvents(). If you can make sense of it...

 Remember, something's gotta give. We can switch off processEvents
 completely, then all keystrokes are eventually processed, but until
 that happens, the screen will look unfinished. As I understand these
 are the drawing glitches that processEvents was introduced to get rid
 of. If you want the screen to be up to date all the time, don't allow
 keystrokes in while drawing.
 
 Older LyX also silently drops keystrokes if you type too fast. Only, it
 is so much faster that that rarely happens. Perhaps we should work on
 1.4 speed, then.

 | I think we have to. 1.4 is soo much slower than 1.3.
 
 What is making it slower?
 Is it the screen drawing or the new two-stage drawing thing?

In 1.3 we have a row cache and redraw only those rows that have changed. 
In 1.4 we redraw the entire document on every single key press. If the row 
is 'on screen' then the real painter is called. If not, then the painting 
is performed by the null painter.

RowPainter.C:

void paintPar
(PainterInfo  pi, LyXText const  text, pit_type pit, int x, int 
y)
{
//  lyxerrpaintPar: pit:   pit   at y:   y  endl;
static NullPainter nop;
static PainterInfo nullpi(pi.base.bv, nop);
int const ww = pi.base.bv-workHeight();

Paragraph  par = text.paragraphs()[pit];

RowList::const_iterator const rb = par.rows().begin();
RowList::const_iterator const re = par.rows().end();
theCoords.parPos()[text][pit] = Point(x, y);

y -= rb-ascent();
for (RowList::const_iterator rit = rb; rit != re; ++rit) {
y += rit-ascent();
bool const inside = (y + rit-descent() = 0
y - rit-ascent()  ww);
RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x, y);

y += rit-descent();
rp.paintAppendix();
rp.paintDepthBar();
rp.paintChangeBar();
if (rit == rb)
rp.paintFirst();
if (rit + 1 == re)
rp.paintLast();
rp.paintText();
}
}


-- 
Angus/
** $Id: qt/qeventloop_x11.cpp   3.3.4   edited Nov 11 22:10 $
**
** Implementation of QEventLoop class
**
** Copyright (C) 2000-2004 Trolltech AS.  All rights reserved.
**
** This file is part of the kernel module of the Qt GUI Toolkit.
**
** This file may be distributed under the terms of the Q Public License
** as defined by Trolltech AS of Norway and appearing in the file
** LICENSE.QPL included in the packaging of this file.
**
** This file may be distributed and/or modified under the terms of the
** GNU General Public License version 2 as published by the Free Software
** Foundation and appearing in the file LICENSE.GPL included in the
** packaging of this file.
**
** Licensees holding valid Qt Enterprise Edition or Qt Professional Edition
** licenses for Unix/X11 may use this file in accordance with the Qt Commercial
** License Agreement provided with the Software.
**
** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
**
** See http://www.trolltech.com/pricing.html or email [EMAIL PROTECTED] for
**   information about Qt Commercial License Agreements.
** See http://www.trolltech.com/qpl/ for QPL licensing information.
** See http://www.trolltech.com/gpl/ for GPL licensing information.
**
** Contact [EMAIL PROTECTED] if any conditions of this licensing are
** not clear to you.
**
**/

#include qeventloop_p.h // includes qplatformdefs.h
#include qeventloop.h
#include qapplication.h
#include qbitarray.h
#include qcolor_p.h
#include qt_x11_p.h

#if defined(QT_THREAD_SUPPORT)
#  include qmutex.h
#endif // QT_THREAD_SUPPORT

#include errno.h


// resolve the conflict between X11's FocusIn and QEvent::FocusIn
#undef FocusOut
#undef FocusIn

static const int XKeyPress = KeyPress;
static const int XKeyRelease = KeyRelease;
#undef KeyPress
#undef KeyRelease

// from qapplication.cpp
extern bool qt_is_gui_used;

// from qeventloop_unix.cpp
extern timeval *qt_wait_timer();
extern void cleanupTimers();

// ### this needs to go away at some point...
typedef void (*VFPTR)();
typedef QValueListVFPTR QVFuncList;
void qt_install_preselect_handler( VFPTR );
void qt_remove_preselect_handler( VFPTR );

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
  Martin == Martin Vermeer [EMAIL PROTECTED] writes:

...

 So it seems that my brilliant idea was a bit lousy. I do not see what
 Qt machinery could help us, except perhaps QApplication::postEvent. We
 could setup an eventFilter for the application that fileters user
 input events and posts them for later.

No, it wasn't lousy. Eating keystrokes is bad only if it also eats the
scripted events reaching LyX though a scripting interface; this is what
Andre objected to in one of my earlier clever ideas. Here, there is no
such danger: this keystroke eating only affects real, physical
keystrokes from a human being containing slow, wet electrochemical
circuitry sitting at the keyboard.

We should just get LyX faster than 99% of touch typists, then the
problem goes away.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| | So it seems that my brilliant idea was a bit lousy. I do not see what
| | Qt machinery could help us, except perhaps QApplication::postEvent. We
| | could setup an eventFilter for the application that fileters user
| | input events and posts them for later.

| | I am not even sure it would work, but it is similar to the idea of
| | queueing key events for later use.

| Then I think a queueing solution with coalescing of events is nicer.

| Then we just need a timer that kicks in some 10-20 times a second to
| check the queue and do the real work.

and with the queue doing the right thing we can actually put
processEvents allover as much as we want to to make the interactive
feeling better. Because we know that all events that is sendt to lyx
core is queued up until we allow them to be handed.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Michael Schmitt]

Juergen Spitzmueller wrote:
Agreed. As long as we silently take care that LyX at least builds against 
Qt2/Win Free unless Qt4 is out.
 

I will care about Qt 3/Win Free (which BTW is version 3.3.4)
Michael

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 18:05, Angus Leeming wrote:

...
 
  What is making it slower?
  Is it the screen drawing or the new two-stage drawing thing?
 
 In 1.3 we have a row cache and redraw only those rows that have changed. 
 In 1.4 we redraw the entire document on every single key press. If the row 
 is 'on screen' then the real painter is called. If not, then the painting 
 is performed by the null painter.
 
 RowPainter.C:
 
 void paintPar
 (PainterInfo  pi, LyXText const  text, pit_type pit, int x, int 
 y)
 {
 //  lyxerrpaintPar: pit:   pit   at y:   y  endl;
 static NullPainter nop;
 static PainterInfo nullpi(pi.base.bv, nop);
 int const ww = pi.base.bv-workHeight();
 
 Paragraph  par = text.paragraphs()[pit];
 
 RowList::const_iterator const rb = par.rows().begin();
 RowList::const_iterator const re = par.rows().end();
 theCoords.parPos()[text][pit] = Point(x, y);
 
 y -= rb-ascent();
 for (RowList::const_iterator rit = rb; rit != re; ++rit) {
 y += rit-ascent();
 bool const inside = (y + rit-descent() = 0
 y - rit-ascent()  ww);
 RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x, y);
 
 y += rit-descent();
 rp.paintAppendix();
 rp.paintDepthBar();
 rp.paintChangeBar();
 if (rit == rb)
 rp.paintFirst();
 if (rit + 1 == re)
 rp.paintLast();
 rp.paintText();
 }
 }

Yes... and in the end, what gets called is pain_.text(...), which for
the null painter just returns without doing anything, like any other
paint operation.

I understand that the number of such calls amounts roughly to the number
of same-font substrings in the document, right? That's what this comment

271 // collect as much similar chars as we can

seems to imply.

Does this amount of empty function calls really produce the slowness we
are seeing? Or is it the glue inbetween?

- Martin



signature.asc
Description: This is a digitally signed message part

[patch] key event queue (was: Profiling LyX-140 on Mac)

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| | Then we just need a timer that kicks in some 10-20 times a second to
| | check the queue and do the real work.

| and with the queue doing the right thing we can actually put
| processEvents allover as much as we want to to make the interactive
| feeling better. Because we know that all events that is sendt to lyx
| core is queued up until we allow them to be handed.

this is kindo a proof-of-concept.

Would be nice if people could try this a bit and see if the problems
seen earlier can be reproduced with this patch applied.

- most likely a check for update in progress is needed in the
  keyeventTimeout
- event coalescing would be nice... (may be 1.5 stuff if we go this route)

Index: QContentPane.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.32
diff -u -p -B -b -w -r1.32 QContentPane.C
--- QContentPane.C	1 Aug 2004 21:24:03 -	1.32
+++ QContentPane.C	12 May 2005 16:43:58 -
@@ -23,6 +23,8 @@
 
 #include boost/bind.hpp
 
+#include queue
+
 namespace {
 
 /// return the LyX key state from Qt's
@@ -73,6 +75,10 @@ mouse_button::state q_motion_state(Qt::B
 	return b;
 }
 
+QTimer * step_timer;
+typedef boost::shared_ptrQLyXKeySym SharedSym;
+std::queuestd::pairSharedSym, key_modifier::state  keyeventQueue;
+
 } // namespace anon
 
 
@@ -90,6 +96,10 @@ QContentPane::QContentPane(QWorkArea * p
 		boost::bind(QContentPane::generateSyntheticMouseEvent,
 			this));
 
+step_timer = new QTimer(this);
+connect(step_timer, SIGNAL(timeout()), SLOT(keyeventTimeout()));
+step_timer-start(50); // signal every .05 seconds
+
 	setFocusPolicy(QWidget::WheelFocus);
 	setFocus();
 	setCursor(ibeamCursor);
@@ -218,7 +228,17 @@ void QContentPane::keyPressEvent(QKeyEve
 {
 	boost::shared_ptrQLyXKeySym sym(new QLyXKeySym);
 	sym-set(e);
-	wa_-workAreaKeyPress(sym, q_key_state(e-state()));
+keyeventQueue.push(std::make_pair(sym, q_key_state(e-state(;
+}
+
+
+void QContentPane::keyeventTimeout()
+{
+while (!keyeventQueue.empty()) {
+std::pairboost::shared_ptrQLyXKeySym, key_modifier::state sym = keyeventQueue.front();
+keyeventQueue.pop();
+wa_-workAreaKeyPress(sym.first, sym.second);
+}
 }
 
 
Index: QContentPane.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.h,v
retrieving revision 1.14
diff -u -p -B -b -w -r1.14 QContentPane.h
--- QContentPane.h	19 Jan 2005 15:03:30 -	1.14
+++ QContentPane.h	12 May 2005 16:43:58 -
@@ -105,6 +105,8 @@ public slots:
 	void doubleClickTimeout();
 
 	void scrollBarChanged(int);
+void keyeventTimeout();
+
 private:
 	/// The slot connected to SyntheticMouseEvent::timeout.
 	void generateSyntheticMouseEvent();
Index: lyx_gui.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/lyx_gui.C,v
retrieving revision 1.82
diff -u -p -B -b -w -r1.82 lyx_gui.C
--- lyx_gui.C	11 May 2005 20:09:20 -	1.82
+++ lyx_gui.C	12 May 2005 16:43:58 -
@@ -259,9 +259,7 @@ void sync_events()
 	// During screen update/ redraw, this method is disabled to 
 	// prevent keyboard events being handed to the LyX core, where
 	// they could cause re-entrant calls to screen update.
-#if QT_VERSION = 0x030100
-	qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
-#endif
+	qApp-processEvents();
 }
 
 

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Martin Vermeer [EMAIL PROTECTED] writes:

  So... where is events ditched?
 
 | Well, if you call processEvents with QEventLoop::ExcludeUserInput, what
 | happens is (I think) that whenever the call empties the X event queue,
 | those events that are user input (i.e., keystrokes among others) are
 | silently discarded. This happens when LyX is busy drawing. When not,
 | keystrokes are processed in regular fashion.
 
 So we are back to getting rid of processEvents completely then?

| Well, if you insist on not losing keystrokes, and we don't get 1.4
| speeded up enough... remember we're only competing with the human
| nervous system. We should win this :-)

We should do both. Both speed up and ensure that we cannot loose
keystrokes. (if something else throw the keystroke on the floor then
we dont care. But as long as the keystroke is delivered to use we
should do our best to handle it. (note: some keystrokes we actually
_want_ to get rid of. page down and hold it. The moment we release
the button we should prune _all_ queued up page down events. (that
same goes basically for all auto-repeat events (there are code in the
xforms frontend that tries to accomplish this.

 or having our own queue of keyevents? (that would perhaps not be a bad
 thing anyway... since then we could coalece keyevents and insert more
 than one char at a time.)

| Where would you put this queue?

| If we get rid of processEvents entirely

I think that we clever/correct use of a queue, we can actually to the
processEvent at any time and as much as we want to. This would then
improve the feeling in some cases. (menus redrawn etc.)

|, all keystrokes come in through
| the Qt event loop. Every keystroke calls workAreaKeyPress, so that's
| where it should happen. Hmmm... I had one like that:



| @@ -511,7 +511,22 @@ void BufferView::Pimpl::scroll(int /*lin
|  void BufferView::Pimpl::workAreaKeyPress(LyXKeySymPtr key,
|  key_modifier::state state)
|  {
| -   owner_-getLyXFunc().processKeySym(key, state);
| +   // Queue keystrokes during update/redraw/coord cache refresh.
| +   // Needed as scripting requires no keystrokes are dropped.
| +   /*
| +
| +   key_entry ke;
| +   ke = make_pair(key, state);
| +   Q_.push(ke);
| +   if (theCoords.isUpdating())
| +   return;
| +   while (!theCoords.isUpdating()  !Q_.empty()) {
| +   key = Q_.front().first;
| +   state = Q_.front().second;
| +   Q_.pop();
| +*/
| +   owner_-getLyXFunc().processKeySym(key, state);
| +   //}

| /* This is perhaps a bit of a hack. When we move
|  * around, or type, it's nice to be able to see

I would hope that we could leave the core out of this and handle this
solely in the frontend.

Also I think that in 1.5 we should try to get rid of workAreaKeyPress
entirely and move this into the frontend. Thus making dispatch(...)
the only mecanism for the frontend to communicate with the core.
(as such the frontend would just be another client)

| Would that really work? No characters are forwarded to LyX while drawing
| is going on. Would that eliminate the rendering glitches? I kind of
| doubt it... there are other events than keystrokes. We could
| shortcircuit mouse events in workAreaDispatch though.

Other events could be queued as well...

We could even have a queue of of deferred (user generated) events
stored in a queue (boost::function) that we only process say 20 times
a second. And if some update is in progress we just skip processing
events for that time-slice

I think it would work, and quite nicely.

-- 
Lgb

Re: [patch] key event queue (was: Profiling LyX-140 on Mac)

[Martin Vermeer]

On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
 [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
 
 | | Then we just need a timer that kicks in some 10-20 times a second to
 | | check the queue and do the real work.
 
 | and with the queue doing the right thing we can actually put
 | processEvents allover as much as we want to to make the interactive
 | feeling better. Because we know that all events that is sendt to lyx
 | core is queued up until we allow them to be handed.
 
 this is kindo a proof-of-concept.
 
 Would be nice if people could try this a bit and see if the problems
 seen earlier can be reproduced with this patch applied.
 
 - most likely a check for update in progress is needed in the
   keyeventTimeout
 - event coalescing would be nice... (may be 1.5 stuff if we go this route)

On risk of appearing dense, would you please go over this patch step by
step and explain what it is doing, and why it appears to be effective.

- QContentPane::keyPressEvent is called for every time you press a key,
right? Is this asynchronous?

- keyeventTimeout is called every 0.05 seconds, _always_; right? Is
_this_ asynchronous? 

- Where precisely are keystrokes being held back until we (the LyX
core?) are ready to handle them? How do you know (and _who_ knows) when 
that is? What happens above and beyond keystrokes being collected and
dispatched in neat little packets of 50 msec?

- Why does the call to processEvents now only rarely find any unprocessed
keyboard event? (Apparently that is the reason we only see occasional
order reversals.)

I honestly don't get the logic of this.

Head scratching,

- Martin



pgpcXT1mGK6mV.pgp
Description: PGP signature

Re: Profiling LyX-140 on Mac

[Alfredo Braunstein]

Angus Leeming wrote:

 In 1.3 we have a row cache and redraw only those rows that have changed.
 In 1.4 we redraw the entire document on every single key press. If the row
 is 'on screen' then the real painter is called. If not, then the painting
 is performed by the null painter.

I think you are reading the code wrongly. We don't paint the entire
document, just entire paragraphs. (So the difference from 1.3 is the
portion of the first par and last par that are off-screen)

Moreover, the optimisation in 1.3 was not exactly fine-grained to the level
of single arbitrary rows, but just remembered the last unchanged row and
painted from there. So when typing at the top of the screen, there was no
improvement at all (and in average, say we got 2x improvement wrt 1.4). 

I don't think that these two amount to the difference between 1.3 and 1.4.
But if they are, I'm sure they can be reintroduced in some encapsulated,
clean way. (and anyway these assertions are free ;-))

Regards, Alfredo
 
 RowPainter.C:
 
 void paintPar
 (PainterInfo  pi, LyXText const  text, pit_type pit, int x, int
 y)
 {
 //  lyxerrpaintPar: pit:   pit   at y:   y  endl;
 static NullPainter nop;
 static PainterInfo nullpi(pi.base.bv, nop);
 int const ww = pi.base.bv-workHeight();
 
 Paragraph  par = text.paragraphs()[pit];
 
 RowList::const_iterator const rb = par.rows().begin();
 RowList::const_iterator const re = par.rows().end();
 theCoords.parPos()[text][pit] = Point(x, y);
 
 y -= rb-ascent();
 for (RowList::const_iterator rit = rb; rit != re; ++rit) {
 y += rit-ascent();
 bool const inside = (y + rit-descent() = 0
 y - rit-ascent()  ww);
 RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x,
 y);
 
 y += rit-descent();
 rp.paintAppendix();
 rp.paintDepthBar();
 rp.paintChangeBar();
 if (rit == rb)
 rp.paintFirst();
 if (rit + 1 == re)
 rp.paintLast();
 rp.paintText();
 }
 }
 
 

Re: Profiling LyX-140 on Mac

[Helge Hafting]

On Thu, May 12, 2005 at 06:19:39PM +0300, Martin Vermeer wrote:
 On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
   Martin == Martin Vermeer [EMAIL PROTECTED] writes:
 
 ...
 
  So it seems that my brilliant idea was a bit lousy. I do not see what
  Qt machinery could help us, except perhaps QApplication::postEvent. We
  could setup an eventFilter for the application that fileters user
  input events and posts them for later.
 
 No, it wasn't lousy. Eating keystrokes is bad only if it also eats the
 scripted events reaching LyX though a scripting interface; this is what
 Andre objected to in one of my earlier clever ideas. Here, there is no
 such danger: this keystroke eating only affects real, physical
 keystrokes from a human being containing slow, wet electrochemical
 circuitry sitting at the keyboard.
 
 We should just get LyX faster than 99% of touch typists, then the
 problem goes away.

Sigh.  How do you know it is a typist, and not something fancy like:

* barcode reader (or similiar device) connected to the keyboard cable?
  These devices inserts whole strings as fast as the hardware can receive.
  Lyx can't know this.

* Some cut/paste mechanism outside lyx, such as X pasting or even better: 
  some paste utility program messing with the os keyboard driver?
  Lyx may figure out X pasting, but not the other case.

* os support for OCR into the keyboard buffer, a page at a time . . .

Loosing keypresses that actually got delivered to lyx won't do.
Even a horribly lagging lyx is better than that.
(Loosing autorepeats _by design_ is of course ok.)

Helge Hafting 

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Helge Hafting [EMAIL PROTECTED] writes:

| Loosing keypresses that actually got delivered to lyx won't do.
| Even a horribly lagging lyx is better than that.
| (Loosing autorepeats _by design_ is of course ok.)

This is what my patch tries to do... never loose keyevents but prune
autorepeats to avoid the forever-rolling-screen syndrome.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Juergen Spitzmueller]

John Levon wrote:
> > 3.1.
>
> OK, then we need to make that the minimum Qt version we support,
> finally. 

Agreed. As long as we silently take care that LyX at least builds against 
Qt2/Win Free unless Qt4 is out.

> Pity about Qt/Win Free or whatever it was but there's not much 
> we can do otherwise.

I think we should try if LyX builds with Qt4 beta, then we have a real chance 
that Qt4/Win Free will work too.

Jürgen

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> But with a large-ish document (about 1 words and with
Bennett> many footnotes, citations, and cross references, but with no
Bennett> math or graphics), typing at a normal speed is simply
Bennett> impossible: the order letters appear in the document is no
Bennett> longer the order I type them.

How is the situation now? I am not sure it is going to be faster, but
at least you should be able to provide a profile that is usable...

JMarc

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 15:57, Bennett Helm wrote:
> On May 12, 2005, at 5:45 AM, Jean-Marc Lasgouttes wrote:
> 
> >> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
> >
> > Bennett> But with a large-ish document (about 1 words and with
> > Bennett> many footnotes, citations, and cross references, but with no
> > Bennett> math or graphics), typing at a normal speed is simply
> > Bennett> impossible: the order letters appear in the document is no
> > Bennett> longer the order I type them.
> >
> > How is the situation now? I am not sure it is going to be faster, but
> > at least you should be able to provide a profile that is usable...
> 
> Well, it's worse in two ways.
> 
> 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing 
> "The last time I tested lyx" results in: "Th attm Itsedlx".

I don't manage to reproduce this, even in the User Guide. But I'm not a
fast typist.

> 2. (Unrelated?) Moving the mouse pointer within the LyX window 
> automatically selects text, even when the mouse button has not been 
> pressed.

Not here.

> In case it's useful, I've attached another profile. (Please let me know 
> if this is the right sort of report to provide.)
> 
> Bennett

Do I see this correctly?

 | + 54.8% QFontEngineMac::doTextTask(QChar const*, int, int, int, unsigned 
char, int, int, QPaintDevice*, QRegion const*) const (LyX)
 | |   0.1% qMacVersion() (LyX)
 | | - 0.1% QFontEngineMac::doTextTask(QChar const*, int, int, int, unsigned 
char, int, int, QPaintDevice*, QRegion const*) const (LyX)
 | |   0.1% dyld_stub_GetGWorld (LyX)

QFontEngineMac::doTextTask eating 55% of your CPU? Or spending 55% of
its time there, waiting for drawing to finish?

Remember, "something's gotta give". We can switch off processEvents
completely, then all keystrokes are eventually processed, but until that
happens, the screen will look unfinished. As I understand these are the
drawing glitches that processEvents was introduced to get rid of. If you
want the screen to be up to date all the time, don't allow keystrokes in
while drawing.

Older LyX also silently drops keystrokes if you type too fast. Only, it
is so much faster that that rarely happens. Perhaps we should work on
1.4 speed, then.

Or should we switch off processEvents just for the Mac architecture?

- Martin



signature.asc
Description: This is a digitally signed message part

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 16:34, Andreas Vox wrote:
> Am 11.05.2005 um 12:55 schrieb Jean-Marc Lasgouttes:

...

> >
> > It would be interesting to know how things have evolved since Martin's
> > latest patch.
> 
> 
> showCursor() is still recursive.

Yes, but it is allowed to be. It is called also from outside screen
update.

> 100% ~ 1 sec cpu time of 30 secs real time
> 
> /Andreas

- Martin


signature.asc
Description: This is a digitally signed message part

Re: Profiling LyX-140 on Mac

[Angus Leeming]

Martin Vermeer wrote:
>> 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
>> "The last time I tested lyx" results in: "Th attm Itsedlx".
> 
> I don't manage to reproduce this, even in the User Guide. But I'm not a
> fast typist.

I see it when using LyX remotely (Qt/X11).

> Remember, "something's gotta give". We can switch off processEvents
> completely, then all keystrokes are eventually processed, but until that
> happens, the screen will look unfinished. As I understand these are the
> drawing glitches that processEvents was introduced to get rid of. If you
> want the screen to be up to date all the time, don't allow keystrokes in
> while drawing.
> 
> Older LyX also silently drops keystrokes if you type too fast. Only, it
> is so much faster that that rarely happens. Perhaps we should work on
> 1.4 speed, then.

I think we have to. 1.4 is soo much slower than 1.3.
-- 
Angus

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Martin Vermeer wrote:
>>> 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
>>> "The last time I tested lyx" results in: "Th attm Itsedlx".
>> 
>> I don't manage to reproduce this, even in the User Guide. But I'm not a
>> fast typist.
>
| I see it when using LyX remotely (Qt/X11).

So... where is events ditched?

>> Remember, "something's gotta give". We can switch off processEvents
>> completely, then all keystrokes are eventually processed, but until that
>> happens, the screen will look unfinished. As I understand these are the
>> drawing glitches that processEvents was introduced to get rid of. If you
>> want the screen to be up to date all the time, don't allow keystrokes in
>> while drawing.
>> 
>> Older LyX also silently drops keystrokes if you type too fast. Only, it
>> is so much faster that that rarely happens. Perhaps we should work on
>> 1.4 speed, then.
>
| I think we have to. 1.4 is soo much slower than 1.3.

What is making it slower?
Is it the screen drawing or the new two-stage drawing thing?

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> QFontEngineMac::doTextTask eating 55% of your CPU? Or spending
Martin> 55% of its time there, waiting for drawing to finish?

That's weird, especially since none of this time is credited to a
lower-level function.

Martin> Older LyX also silently drops keystrokes if you type too fast.
Martin> Only, it is so much faster that that rarely happens. Perhaps
Martin> we should work on 1.4 speed, then.

Martin> Or should we switch off processEvents just for the Mac
Martin> architecture?

What may happen is that the processEvents flag means: "silently eat
keystroke events" instead of "leave them in the queue".

Actually reading qeventloop_x11.cpp confirms this analysis (it uses
XNextEvent, whereas XPeekEvent would be better for what we want to
do).

So it seems that my brilliant idea was a bit lousy. I do not see what
Qt machinery could help us, except perhaps QApplication::postEvent. We
could setup an eventFilter for the application that fileters user
input events and posts them for later.

I am not even sure it would work, but it is similar to the idea of
queueing key events for later use.

JMarc

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Angus Leeming <[EMAIL PROTECTED]> writes:
Lars> | Martin Vermeer wrote:
 1. Instead of reordering keystrokes, it drops keystrokes. Thus,
 typing "The last time I tested lyx" results in: "Th attm
 Itsedlx".
>>>  I don't manage to reproduce this, even in the User Guide. But I'm
>>> not a fast typist.
>>
Lars> | I see it when using LyX remotely (Qt/X11).

Lars> So... where is events ditched?

By the filter in QEventLoop::processEvents. I hoped that it would let
them in place, but unfortunately, it just silently ditches them.

JMarc

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| So it seems that my brilliant idea was a bit lousy. I do not see what
| Qt machinery could help us, except perhaps QApplication::postEvent. We
| could setup an eventFilter for the application that fileters user
| input events and posts them for later.
>
| I am not even sure it would work, but it is similar to the idea of
| queueing key events for later use.

Then I think a queueing solution with coalescing of events is nicer.

Then we just need a timer that kicks in some 10-20 times a second to
check the queue and do the real work.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Angus Leeming]

Lars Gullik Bjønnes wrote:

> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | Martin Vermeer wrote:
 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
 "The last time I tested lyx" results in: "Th attm Itsedlx".
>>> 
>>> I don't manage to reproduce this, even in the User Guide. But I'm not a
>>> fast typist.
>>
> | I see it when using LyX remotely (Qt/X11).
> 
> So... where is events ditched?

Attached is QEventLoop::ProcessEvents(). If you can make sense of it...

>>> Remember, "something's gotta give". We can switch off processEvents
>>> completely, then all keystrokes are eventually processed, but until
>>> that happens, the screen will look unfinished. As I understand these
>>> are the drawing glitches that processEvents was introduced to get rid
>>> of. If you want the screen to be up to date all the time, don't allow
>>> keystrokes in while drawing.
>>> 
>>> Older LyX also silently drops keystrokes if you type too fast. Only, it
>>> is so much faster that that rarely happens. Perhaps we should work on
>>> 1.4 speed, then.
>>
> | I think we have to. 1.4 is soo much slower than 1.3.
> 
> What is making it slower?
> Is it the screen drawing or the new two-stage drawing thing?

In 1.3 we have a row cache and redraw only those rows that have changed. 
In 1.4 we redraw the entire document on every single key press. If the row 
is 'on screen' then the real painter is called. If not, then the painting 
is performed by the null painter.

RowPainter.C:

void paintPar
(PainterInfo & pi, LyXText const & text, pit_type pit, int x, int 
y)
{
//  lyxerr << "  paintPar: pit: " << pit << " at y: " << y << endl;
static NullPainter nop;
static PainterInfo nullpi(pi.base.bv, nop);
int const ww = pi.base.bv->workHeight();

Paragraph & par = text.paragraphs()[pit];

RowList::const_iterator const rb = par.rows().begin();
RowList::const_iterator const re = par.rows().end();
theCoords.parPos()[][pit] = Point(x, y);

y -= rb->ascent();
for (RowList::const_iterator rit = rb; rit != re; ++rit) {
y += rit->ascent();
bool const inside = (y + rit->descent() >= 0
   && y - rit->ascent() < ww);
RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x, y);

y += rit->descent();
rp.paintAppendix();
rp.paintDepthBar();
rp.paintChangeBar();
if (rit == rb)
rp.paintFirst();
if (rit + 1 == re)
rp.paintLast();
rp.paintText();
}
}


-- 
Angus/
** $Id: qt/qeventloop_x11.cpp   3.3.4   edited Nov 11 22:10 $
**
** Implementation of QEventLoop class
**
** Copyright (C) 2000-2004 Trolltech AS.  All rights reserved.
**
** This file is part of the kernel module of the Qt GUI Toolkit.
**
** This file may be distributed under the terms of the Q Public License
** as defined by Trolltech AS of Norway and appearing in the file
** LICENSE.QPL included in the packaging of this file.
**
** This file may be distributed and/or modified under the terms of the
** GNU General Public License version 2 as published by the Free Software
** Foundation and appearing in the file LICENSE.GPL included in the
** packaging of this file.
**
** Licensees holding valid Qt Enterprise Edition or Qt Professional Edition
** licenses for Unix/X11 may use this file in accordance with the Qt Commercial
** License Agreement provided with the Software.
**
** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
**
** See http://www.trolltech.com/pricing.html or email [EMAIL PROTECTED] for
**   information about Qt Commercial License Agreements.
** See http://www.trolltech.com/qpl/ for QPL licensing information.
** See http://www.trolltech.com/gpl/ for GPL licensing information.
**
** Contact [EMAIL PROTECTED] if any conditions of this licensing are
** not clear to you.
**
**/

#include "qeventloop_p.h" // includes qplatformdefs.h
#include "qeventloop.h"
#include "qapplication.h"
#include "qbitarray.h"
#include "qcolor_p.h"
#include "qt_x11_p.h"

#if defined(QT_THREAD_SUPPORT)
#  include "qmutex.h"
#endif // QT_THREAD_SUPPORT

#include 


// resolve the conflict between X11's FocusIn and QEvent::FocusIn
#undef FocusOut
#undef FocusIn

static const int XKeyPress = KeyPress;
static const int XKeyRelease = KeyRelease;
#undef KeyPress
#undef KeyRelease

// from qapplication.cpp
extern bool qt_is_gui_used;

// from qeventloop_unix.cpp
extern timeval *qt_wait_timer();
extern void cleanupTimers();

// ### this needs to go away at some point...
typedef void (*VFPTR)();
typedef QValueList 

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

...

> So it seems that my brilliant idea was a bit lousy. I do not see what
> Qt machinery could help us, except perhaps QApplication::postEvent. We
> could setup an eventFilter for the application that fileters user
> input events and posts them for later.

No, it wasn't lousy. "Eating keystrokes" is bad only if it also eats the
scripted events reaching LyX though a scripting interface; this is what
Andre objected to in one of my earlier clever ideas. Here, there is no
such danger: this keystroke eating only affects real, physical
keystrokes from a human being containing slow, wet electrochemical
circuitry sitting at the keyboard.

We should just get LyX faster than 99% of touch typists, then the
problem goes away.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
| | So it seems that my brilliant idea was a bit lousy. I do not see what
| | Qt machinery could help us, except perhaps QApplication::postEvent. We
| | could setup an eventFilter for the application that fileters user
| | input events and posts them for later.
>>
| | I am not even sure it would work, but it is similar to the idea of
| | queueing key events for later use.
>
| Then I think a queueing solution with coalescing of events is nicer.
>
| Then we just need a timer that kicks in some 10-20 times a second to
| check the queue and do the real work.

and with the queue doing the right thing we can actually put
processEvents allover as much as we want to to make the interactive
feeling better. Because we know that all events that is sendt to lyx
core is queued up until we allow them to be handed.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Michael Schmitt]

Juergen Spitzmueller wrote:
Agreed. As long as we silently take care that LyX at least builds against 
Qt2/Win Free unless Qt4 is out.
 

I will care about Qt 3/Win Free (which BTW is version 3.3.4)
Michael

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Thu, 2005-05-12 at 18:05, Angus Leeming wrote:

...
 
> > What is making it slower?
> > Is it the screen drawing or the new two-stage drawing thing?
> 
> In 1.3 we have a row cache and redraw only those rows that have changed. 
> In 1.4 we redraw the entire document on every single key press. If the row 
> is 'on screen' then the real painter is called. If not, then the painting 
> is performed by the null painter.
> 
> RowPainter.C:
> 
> void paintPar
> (PainterInfo & pi, LyXText const & text, pit_type pit, int x, int 
> y)
> {
> //  lyxerr << "  paintPar: pit: " << pit << " at y: " << y << endl;
> static NullPainter nop;
> static PainterInfo nullpi(pi.base.bv, nop);
> int const ww = pi.base.bv->workHeight();
> 
> Paragraph & par = text.paragraphs()[pit];
> 
> RowList::const_iterator const rb = par.rows().begin();
> RowList::const_iterator const re = par.rows().end();
> theCoords.parPos()[][pit] = Point(x, y);
> 
> y -= rb->ascent();
> for (RowList::const_iterator rit = rb; rit != re; ++rit) {
> y += rit->ascent();
> bool const inside = (y + rit->descent() >= 0
>&& y - rit->ascent() < ww);
> RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x, y);
> 
> y += rit->descent();
> rp.paintAppendix();
> rp.paintDepthBar();
> rp.paintChangeBar();
> if (rit == rb)
> rp.paintFirst();
> if (rit + 1 == re)
> rp.paintLast();
> rp.paintText();
> }
> }

Yes... and in the end, what gets called is pain_.text(...), which for
the null painter just returns without doing anything, like any other
paint operation.

I understand that the number of such calls amounts roughly to the number
of same-font substrings in the document, right? That's what this comment

271 // collect as much similar chars as we can

seems to imply.

Does this amount of empty function calls really produce the slowness we
are seeing? Or is it the "glue" inbetween?

- Martin



signature.asc
Description: This is a digitally signed message part

[patch] key event queue (was: Profiling LyX-140 on Mac)

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| | Then we just need a timer that kicks in some 10-20 times a second to
| | check the queue and do the real work.
>
| and with the queue doing the right thing we can actually put
| processEvents allover as much as we want to to make the interactive
| feeling better. Because we know that all events that is sendt to lyx
| core is queued up until we allow them to be handed.

this is kindo a proof-of-concept.

Would be nice if people could try this a bit and see if the problems
seen earlier can be reproduced with this patch applied.

- most likely a check for update in progress is needed in the
  keyeventTimeout
- event coalescing would be nice... (may be 1.5 stuff if we go this route)

Index: QContentPane.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.32
diff -u -p -B -b -w -r1.32 QContentPane.C
--- QContentPane.C	1 Aug 2004 21:24:03 -	1.32
+++ QContentPane.C	12 May 2005 16:43:58 -
@@ -23,6 +23,8 @@
 
 #include 
 
+#include 
+
 namespace {
 
 /// return the LyX key state from Qt's
@@ -73,6 +75,10 @@ mouse_button::state q_motion_state(Qt::B
 	return b;
 }
 
+QTimer * step_timer;
+typedef boost::shared_ptr SharedSym;
+std::queue > keyeventQueue;
+
 } // namespace anon
 
 
@@ -90,6 +96,10 @@ QContentPane::QContentPane(QWorkArea * p
 		boost::bind(::generateSyntheticMouseEvent,
 			this));
 
+step_timer = new QTimer(this);
+connect(step_timer, SIGNAL(timeout()), SLOT(keyeventTimeout()));
+step_timer->start(50); // signal every .05 seconds
+
 	setFocusPolicy(QWidget::WheelFocus);
 	setFocus();
 	setCursor(ibeamCursor);
@@ -218,7 +228,17 @@ void QContentPane::keyPressEvent(QKeyEve
 {
 	boost::shared_ptr sym(new QLyXKeySym);
 	sym->set(e);
-	wa_->workAreaKeyPress(sym, q_key_state(e->state()));
+keyeventQueue.push(std::make_pair(sym, q_key_state(e->state(;
+}
+
+
+void QContentPane::keyeventTimeout()
+{
+while (!keyeventQueue.empty()) {
+std::pair sym = keyeventQueue.front();
+keyeventQueue.pop();
+wa_->workAreaKeyPress(sym.first, sym.second);
+}
 }
 
 
Index: QContentPane.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.h,v
retrieving revision 1.14
diff -u -p -B -b -w -r1.14 QContentPane.h
--- QContentPane.h	19 Jan 2005 15:03:30 -	1.14
+++ QContentPane.h	12 May 2005 16:43:58 -
@@ -105,6 +105,8 @@ public slots:
 	void doubleClickTimeout();
 
 	void scrollBarChanged(int);
+void keyeventTimeout();
+
 private:
 	/// The slot connected to SyntheticMouseEvent::timeout.
 	void generateSyntheticMouseEvent();
Index: lyx_gui.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/lyx_gui.C,v
retrieving revision 1.82
diff -u -p -B -b -w -r1.82 lyx_gui.C
--- lyx_gui.C	11 May 2005 20:09:20 -	1.82
+++ lyx_gui.C	12 May 2005 16:43:58 -
@@ -259,9 +259,7 @@ void sync_events()
 	// During screen update/ redraw, this method is disabled to 
 	// prevent keyboard events being handed to the LyX core, where
 	// they could cause re-entrant calls to screen update.
-#if QT_VERSION >= 0x030100
-	qApp->eventLoop()->processEvents(QEventLoop::ExcludeUserInput);
-#endif
+	qApp->processEvents();
 }
 
 

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Martin Vermeer <[EMAIL PROTECTED]> writes:

>> >> So... where is events ditched?
>> >
>> | Well, if you call processEvents with QEventLoop::ExcludeUserInput, what
>> | happens is (I think) that whenever the call empties the X event queue,
>> | those events that are user input (i.e., keystrokes among others) are
>> | silently discarded. This happens when LyX is busy drawing. When not,
>> | keystrokes are processed in regular fashion.
>> 
>> So we are back to getting rid of processEvents completely then?
>
| Well, if you insist on not losing keystrokes, and we don't get 1.4
| speeded up enough... remember we're "only" competing with the human
| nervous system. We should win this :-)

We should do both. Both speed up and ensure that we cannot loose
keystrokes. (if something else throw the keystroke on the floor then
we dont care. But as long as the keystroke is delivered to use we
should do our best to handle it. (note: some keystrokes we actually
_want_ to get rid of.  and hold it. The moment we release
the button we should prune _all_ queued up  events. (that
same goes basically for all auto-repeat events (there are code in the
xforms frontend that tries to accomplish this.

>> or having our own queue of keyevents? (that would perhaps not be a bad
>> thing anyway... since then we could coalece keyevents and insert more
>> than one char at a time.)
>
| Where would you put this queue?
>
| If we get rid of processEvents entirely

I think that we clever/correct use of a queue, we can actually to the
processEvent at any time and as much as we want to. This would then
improve the feeling in some cases. (menus redrawn etc.)

|, all keystrokes come in through
| the Qt event loop. Every keystroke calls workAreaKeyPress, so that's
| where it should happen. Hmmm... I had one like that:
>
>
>
| @@ -511,7 +511,22 @@ void BufferView::Pimpl::scroll(int /*lin
|  void BufferView::Pimpl::workAreaKeyPress(LyXKeySymPtr key,
|  key_modifier::state state)
|  {
| -   owner_->getLyXFunc().processKeySym(key, state);
| +   // Queue keystrokes during update/redraw/coord cache refresh.
| +   // Needed as scripting requires no keystrokes are dropped.
| +   /*
| +
| +   key_entry ke;
| +   ke = make_pair(key, state);
| +   Q_.push(ke);
| +   if (theCoords.isUpdating())
| +   return;
| +   while (!theCoords.isUpdating() && !Q_.empty()) {
| +   key = Q_.front().first;
| +   state = Q_.front().second;
| +   Q_.pop();
| +*/
| +   owner_->getLyXFunc().processKeySym(key, state);
| +   //}
>
| /* This is perhaps a bit of a hack. When we move
|  * around, or type, it's nice to be able to see

I would hope that we could leave the core out of this and handle this
solely in the frontend.

Also I think that in 1.5 we should try to get rid of workAreaKeyPress
entirely and move this into the frontend. Thus making dispatch(...)
the only mecanism for the frontend to communicate with the core.
(as such the frontend would just be another client)

| Would that really work? No characters are forwarded to LyX while drawing
| is going on. Would that eliminate the rendering glitches? I kind of
| doubt it... there are other events than keystrokes. We could
| shortcircuit mouse events in workAreaDispatch though.

Other events could be queued as well...

We could even have a queue of of deferred (user generated) events
stored in a queue (boost::function) that we only process say 20 times
a second. And if some update is in progress we just skip processing
events for that "time-slice"

I think it would work, and quite nicely.

-- 
Lgb

Re: [patch] key event queue (was: Profiling LyX-140 on Mac)

[Martin Vermeer]

On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
> 
> | | Then we just need a timer that kicks in some 10-20 times a second to
> | | check the queue and do the real work.
> >
> | and with the queue doing the right thing we can actually put
> | processEvents allover as much as we want to to make the interactive
> | feeling better. Because we know that all events that is sendt to lyx
> | core is queued up until we allow them to be handed.
> 
> this is kindo a proof-of-concept.
> 
> Would be nice if people could try this a bit and see if the problems
> seen earlier can be reproduced with this patch applied.
> 
> - most likely a check for update in progress is needed in the
>   keyeventTimeout
> - event coalescing would be nice... (may be 1.5 stuff if we go this route)

On risk of appearing dense, would you please go over this patch step by
step and explain what it is doing, and why it appears to be effective.

- QContentPane::keyPressEvent is called for every time you press a key,
right? Is this asynchronous?

- keyeventTimeout is called every 0.05 seconds, _always_; right? Is
_this_ asynchronous? 

- Where precisely are keystrokes being held back until "we" (the LyX
core?) are ready to handle them? How do you know (and _who_ knows) when 
that is? What happens above and beyond keystrokes being collected and
dispatched in neat little packets of 50 msec?

- Why does the call to processEvents now only rarely find any unprocessed
keyboard event? (Apparently that is the reason we only see occasional
order reversals.)

I honestly don't get the logic of this.

Head scratching,

- Martin



pgpcXT1mGK6mV.pgp
Description: PGP signature

Re: Profiling LyX-140 on Mac

[Alfredo Braunstein]

Angus Leeming wrote:

> In 1.3 we have a row cache and redraw only those rows that have changed.
> In 1.4 we redraw the entire document on every single key press. If the row
> is 'on screen' then the real painter is called. If not, then the painting
> is performed by the null painter.

I think you are reading the code wrongly. We don't paint the entire
document, just entire paragraphs. (So the difference from 1.3 is the
portion of the first par and last par that are off-screen)

Moreover, the optimisation in 1.3 was not exactly fine-grained to the level
of single arbitrary rows, but just remembered "the last unchanged row" and
painted from there. So when typing at the top of the screen, there was no
improvement at all (and in average, say we got 2x improvement wrt 1.4). 

I don't think that these two amount to the difference between 1.3 and 1.4.
But if they are, I'm sure they can be reintroduced in some encapsulated,
clean way. (and anyway these assertions are free ;-))

Regards, Alfredo
 
> RowPainter.C:
> 
> void paintPar
> (PainterInfo & pi, LyXText const & text, pit_type pit, int x, int
> y)
> {
> //  lyxerr << "  paintPar: pit: " << pit << " at y: " << y << endl;
> static NullPainter nop;
> static PainterInfo nullpi(pi.base.bv, nop);
> int const ww = pi.base.bv->workHeight();
> 
> Paragraph & par = text.paragraphs()[pit];
> 
> RowList::const_iterator const rb = par.rows().begin();
> RowList::const_iterator const re = par.rows().end();
> theCoords.parPos()[][pit] = Point(x, y);
> 
> y -= rb->ascent();
> for (RowList::const_iterator rit = rb; rit != re; ++rit) {
> y += rit->ascent();
> bool const inside = (y + rit->descent() >= 0
>&& y - rit->ascent() < ww);
> RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x,
> y);
> 
> y += rit->descent();
> rp.paintAppendix();
> rp.paintDepthBar();
> rp.paintChangeBar();
> if (rit == rb)
> rp.paintFirst();
> if (rit + 1 == re)
> rp.paintLast();
> rp.paintText();
> }
> }
> 
> 

Re: Profiling LyX-140 on Mac

[Helge Hafting]

On Thu, May 12, 2005 at 06:19:39PM +0300, Martin Vermeer wrote:
> On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> ...
> 
> > So it seems that my brilliant idea was a bit lousy. I do not see what
> > Qt machinery could help us, except perhaps QApplication::postEvent. We
> > could setup an eventFilter for the application that fileters user
> > input events and posts them for later.
> 
> No, it wasn't lousy. "Eating keystrokes" is bad only if it also eats the
> scripted events reaching LyX though a scripting interface; this is what
> Andre objected to in one of my earlier clever ideas. Here, there is no
> such danger: this keystroke eating only affects real, physical
> keystrokes from a human being containing slow, wet electrochemical
> circuitry sitting at the keyboard.
> 
> We should just get LyX faster than 99% of touch typists, then the
> problem goes away.

Sigh.  How do you know it is a typist, and not something fancy like:

* barcode reader (or similiar device) connected to the keyboard cable?
  These devices inserts whole strings as fast as the hardware can receive.
  Lyx can't know this.

* Some cut/paste mechanism outside lyx, such as X pasting or even better: 
  some "paste utility program" messing with the os keyboard driver?
  Lyx may figure out X pasting, but not the other case.

* os support for OCR into the keyboard buffer, a page at a time . . .

Loosing keypresses that actually got delivered to lyx won't do.
Even a horribly lagging lyx is better than that.
(Loosing autorepeats _by design_ is of course ok.)

Helge Hafting 

Re: Profiling LyX-140 on Mac

[Lars Gullik Bjønnes]

Helge Hafting <[EMAIL PROTECTED]> writes:

| Loosing keypresses that actually got delivered to lyx won't do.
| Even a horribly lagging lyx is better than that.
| (Loosing autorepeats _by design_ is of course ok.)

This is what my patch tries to do... never loose keyevents but prune
autorepeats to avoid the forever-rolling-screen syndrome.

-- 
Lgb

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

 Andreas == Andreas Vox [EMAIL PROTECTED] writes:

Andreas Am 07.04.2005 um 17:58 schrieb Jean-Marc Lasgouttes:

 Andreas == Andreas Vox [EMAIL PROTECTED] writes:

Andreas I also did some profiling and got the attached screenshot
Andreas when scrolling down using PageDown.
  Do I really see 38% in showCursor? This is very weird...
 

Andreas Not really. sync_events() is quite expensive, because it
Andreas calls BufferView::Pimple::workareaKeyPress() and
Andreas renderPreview::imageReady()

Andreas See my note to bug #1790.

It would be interesting to know how things have evolved since Martin's
latest patch.

JMarc

Re: Profiling LyX-140 on Mac

[Jean-Marc Lasgouttes]

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett On May 11, 2005, at 6:55 AM, Jean-Marc Lasgouttes wrote:
 It would be interesting to know how things have evolved since
 Martin's latest patch.

Bennett Here you go -- profile attached, done the same way as my
Bennett previous report: tree view, with system libraries charged to
Bennett callers; 30-second sample, with me typing constantly during
Bennett the sampling.

Thanks. I am not sure I manage to make sense of it, especially since
there is still a lot of recursivity going on.

Bennett Thus, if I type 1234 quickly (but slowly enough to be sure
Bennett I'm typing them in that order!), I actually get 1342 or
Bennett 1432 in the document. Similarly, typing The last time I
Bennett tested lyx results in The lsttim Iteted slyx e a. This did
Bennett not happen before.

Ouch! That's not good, isn't it.

Martin, did you read this?

JMarc

Re: Profiling LyX-140 on Mac

[Martin Vermeer]

On Wed, 2005-05-11 at 16:36, Bennett Helm wrote:
 On May 11, 2005, at 6:55 AM, Jean-Marc Lasgouttes wrote:
 
  It would be interesting to know how things have evolved since Martin's
  latest patch.
 
 Here you go -- profile attached, done the same way as my previous 
 report: tree view, with system libraries charged to callers; 30-second 
 sample, with me typing constantly during the sampling.
 
 The last time I tested lyx-140 -- just to see whether it felt like 
 there was an improvement -- was a couple days ago, and not much had 
 changed from when I first complained about slowness. However, my 
 subjective experience of the latest CVS is that things have gotten 
 markedly worse in the last 48 hours. When testing with an ordinary 
 blank document, things are fine. But with a large-ish document (about 
 1 words and with many footnotes, citations, and cross references, 
 but with no math or graphics), typing at a normal speed is simply 
 impossible: the order letters appear in the document is no longer the 
 order I type them. Thus, if I type 1234 quickly (but slowly enough to 
 be sure I'm typing them in that order!), I actually get 1342 or 
 1432 in the document. Similarly, typing The last time I tested lyx 
 results in The lsttim Iteted slyx e a. This did not happen before.
 
 Bennett

Oops, that's bad. Could this be due to calling sync_events twice during
a cursor blink sequence? (both in showCursor and in hideCursor.) I did
that to make LyX snappier ;-/

Alternatively, now the time between two calls to processEvents is never
shorter than 0.4 sec. Could that be the problem? This time is set in the
BufferView::Pimpl::Pimpl constructor. (Actually this isn't quite true:
there are some calls to showCursor in the code where the blink counter
is forcibly reset.)

A third suspect: in BufferView_pimpl's update, we see that processEvents
is masked from line 627 onward, i.e., during the first (metrics) drawing
step, and the second. This didn't use to be so. I think this is right:
allow_sync_ must be coordinated with startUpdating/doneUpdating. But it
may cause extra delay.

But... if it works right for small docs, perhaps we should look at the
rendering efficiency scaling behaviour with size.

Does anyone have an idea how the input order reversal could come about?
Again, are there any guarantees that the X queue gives events back in
time order?

- Martin



signature.asc
Description: This is a digitally signed message part