• View
• Edit
• Upload
• History
• Print

FurtherHelp

How to get further assistance

§1.  You still haven't answered my question!

Then RTFM, especially the Tutorial. The documentation really is quite good.

There are also numerous example files included with LyX. Try File→Open→Examples.

If you think your problem may be LaTeX related, then look in LaTeX, A Document Preparation System, 2nd Ed. by Leslie Lamport (1994) or The LaTeX Companion, 2nd Ed. by Frank Mittelbach et al. (2004).

Furthermore, for LaTeX related questions, there is an excellent newsgroup comp.text.tex, which is archived ([1]). There are also numerous LaTeX FAQ's and other resources on the web (we especially recommend The TeX Users Group FAQ).

For LyX related questions, a search in the lyx-users or lyx-devel mail archives is often helpful, also remember that google is your friend (TM).

§2.  I want to mail someone about my problem.

Send email to the LyX Users list lyx-users@lists.lyx.org. If LyX is actually crashing or otherwise non-functional, then try the developers' list at lyx-devel@lists.lyx.org.

§3.  What to put in a request for help.

Include your version of LyX and a description of what you are trying to do, along with evidence that you've actually read the docs. Also, please send a minimal example.

If LyX has crashed, include the version of LyX, the operating system, the frontend (xforms, qt), the version of the frontend toolkit* (if it seems to be a screen drawing problem), and a precise description of the events that lead to the crash. The easier it is for the developers to reproduce your crash, the more likely it will get fixed. If you're brave and like to hack, use gdb to generate a backtrace and include the results with your mail. If this is not possible, just describe what you did as completely as you can.

• typing lyx --version in a terminal will give you most of these informations.

§4.  The developers asked my to provide a backtrace. What's that?

A backtrace is a list of the last function calls of a programm before a certain event, e.g. a crash. It helps the developers to find out where the crash occured and which operations were involved.

A backtrace can be produced as follows:

1.) Linux

• assure that program gdb is installed
• open a console/terminal
• type gdb lyx
• type run; LyX will start
• now try to trigger the crash; note that LyX will not close
• type bt to get the backtrace and post the result

This type of backtrace is better than nothing, but note that much better backtrace can be done if you compile LyX yourself from the sources or (svn-tree) and give additional parameter for configure script (./configure --enable-debug). If the names do not show in the backtrace, try running gdb with libtool --mode=execute gdb src/lyx instead. Also, it is sometimes useful to see the backtrace for all the threads, which can be displayed with thread apply all bt instead of bt.

§5.  The developers asked me to provide a profile. How?

You will find here a description in the case where you are building LyX with configure.

There are three main types of tools

• System-wide profilers, such as sysprof or oprofile on Linux, or Shark.app on Mac OS X:
  • configure LyX with --enable-build-type=prof, then make
  • launch your profiler and then run LyX and do the actions you want to measure.
  • the tool will give you the proportion of time spent in different parts of the code (LyX, graphics drivers, kernel...).
• gprof, the GNU profiler, which reports spent time in the part of the code that has been instrumented (i.e., not the kernel, nor Qt or the graphics drivers)
  • configure lyx with --enable-build-type=gprof, then make
  • run LyX and do the actions you want to measure. File gmon.out is created in the current directory.
  • to create a report run something like: gprof src/lyx gmon.out > gprof.txt
  • the first part of the report gives times spent in function, no subcalls included. the second part includes also subcalls (it also lists above the functions which calls the current examined function and below those which are called by the current f), note however that neither Qt nor X calls are included.
• Callgrind (http://www.valgrind.org) with a profile data visualizer such as kcachegrind
  • Install valgrind and kcachegrind (packages valgrind kcachegrind graphviz under Debian/Ubuntu).
  • Compile LyX in developer mode (--enable-build-type=dev).
  • Run LyX via valgrind with valgrind --tool=callgrind --instr-atstart=no lyx. The option no tells valgrind not to record immediately, which would considerably slow down LyX starting up.
  • Start recording with callgrind_control --instr=on. Stop recording with callgrind_control --instr=off. Generate a new profile data file with callgrind_control --dump.
  • Opening the profile data with kcachegrind lets you explore the function calls and gives the proportion spent in different subcalls. A graph at a particular point of interest can be exported with File ▷ Export Graph.

FAQ

<< | FAQ.PageList | >>