headers
Arto | 1 Oct 2009 08:31
Picon
Favicon

tex2lyx -n -f does not turn noweb code chunks into "scrab" in Debian?

Dear LyX Experts,

I am stuck with a problem that seems to have been sorted out a few years
ago (ticket 3004). The case was about lyx not being able to import a .nw 
(noweb) file, previously exported by lyx from a respective .lyx file (to test 
the noweb import function). I asked help from the lyx-users list some days ago 
but nobody there seems to be familiar with this subject. 

The result of the import test was reported in ticket 3004 to be a garbled .lyx 
file, and that's just what I have encountered (= "layout Standard" where I 
would expect "layout Scrab").
The ticket mentions that a particular user preferences were the culprit, but 
the details have been lost in the mists of time.

I am currently running Debian (Squeeze) and Lyx 1.6.4, installed from .deb 
packages, in two machines. They both share this "feature".

I have tried out inter alia /usr/share/lyx/examples/Literate.lyx, converted it 
to .nw with lyx, then back with $tex2lyx -n -f Literate.nw (using lyx and 
straight from the command line, also with option -c "literate-article"). No 
luck...
I checked that the tex2lyx binary was replaced when updating to 1.6.4 (from the 
file's date, he import has not worked properly for me in earlier lyx versions 
either).

I have not noticed anything amiss with the .nw files with emacs. When I look at 
the imported .lyx files it seems that tex2lyx does not 
recognise "<<chunkname>>=", signalling the start of the code chunk, and act 
accordingly (=apply scrap style to the code chunks). That kind of code seems to 
be in place, however, in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Abdelrazak Younes | 1 Oct 2009 09:20
Favicon

Re: GuiApplication.cpp compile error

BH wrote:
> On Wed, Sep 30, 2009 at 10:30 AM, Abdelrazak Younes <younes@...> wrote:
>   
>> BH wrote:
>>     
>>> But here's another: Open new document; LyX > Preferences; change
>>> anything; click on "Save" button --> Crash. Backtrace is below.
>>>
>>> Once again, this does not happen when no document is open.
>>>
>>>       
>> Fixed.
>>     
>
> Yep. It does.

Good, thanks for testing.

>  But it takes a very long time to save preferences --
> several seconds minimum, eating up processor time. Generally speaking,
> trunk seems to have slowed down considerably (especially noticeable
> with typing speed) in the last month.
>   

Are you sure you compiled in release mode, that is _without_ stdlib-debug?

Abdel.
Permalink | Reply | 13 comments |
headers
Jean-Marc Lasgouttes | 1 Oct 2009 09:37
Favicon

Re: GuiApplication.cpp compile error

Abdelrazak Younes <younes@...> writes:
>>  But it takes a very long time to save preferences --
>> several seconds minimum, eating up processor time. Generally speaking,
>> trunk seems to have slowed down considerably (especially noticeable
>> with typing speed) in the last month.
>>   
>
> Are you sure you compiled in release mode, that is _without_ stdlib-debug?

Several seconds for saving preferences is wrong even with stdlib-debug. 

Can you do some profiling, Bennett?

JMarc
Permalink | Reply | 12 comments |
headers
Abdelrazak Younes | 1 Oct 2009 09:46
Favicon

Re: GuiApplication.cpp compile error

Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <younes@...> writes:
>   
>>>  But it takes a very long time to save preferences --
>>> several seconds minimum, eating up processor time. Generally speaking,
>>> trunk seems to have slowed down considerably (especially noticeable
>>> with typing speed) in the last month.
>>>   
>>>       
>> Are you sure you compiled in release mode, that is _without_ stdlib-debug?
>>     
>
> Several seconds for saving preferences is wrong even with stdlib-debug. 
>   

It's not only about saving preferences, it's also about, basically, 
restarting the GUI. I know, it's a bit of a hammer to reset the GUI for 
any tiny change and we should probably change that...

> Can you do some profiling, Bennett?
>   

Yep, that would be nice... but without stdlib-debug of course ;-)

Abdel.
Permalink | Reply | 11 comments |
headers
Sebastian Guttenberg | 1 Oct 2009 11:42
Picon
Picon
Favicon

RE: strange bug in lyx 1.6.4

Hi Vincent again
Sorry to bother you again, but I wanted to make sure that we are talking
about the same bug. You were saying 

> You can reproduce it by hovering your mouse over the button of the
> (closed) footnote. When LyX tries to show a tooltip with the contents of
> the footnote, it enters an infinite loop.

Instead for me it does not happen for the closed footnote (I just tried
it), and also not for an ordinary closed LyX-note, but only for a
closed LyX-note within a footnote. If this is the bug you mean, and if
it is already fixed, how can I get the fix? Just download the same
version again (1.6.4), or do I have to wait for 1.6.5?
(unfortunately I have many LyX-notes in footnotes ;-) )

Sebastian
Permalink | Reply | 2 comments |
headers
Vincent van Ravesteijn - TNW | 1 Oct 2009 11:51
Picon
Picon

RE: strange bug in lyx 1.6.4


>Hi Vincent again
>Sorry to bother you again, but I wanted to make sure that we are
>talking about the same bug. You were saying 
>
>> You can reproduce it by hovering your mouse over the button of the
>> (closed) footnote. When LyX tries to show a tooltip with the contents

>> of the footnote, it enters an infinite loop.
>
>Instead for me it does not happen for the closed footnote (I just tried
>it), and also not for an ordinary closed LyX-note, but only for a
closed
>LyX-note within a footnote. If this is the bug you mean, and if it is
>already fixed, how can I get the fix? Just download the same version
>again (1.6.4), or do I have to wait for 1.6.5?
>
>(unfortunately I have many LyX-notes in footnotes ;-) )
>

The bug only happens when the context of the inset starts with approx.
70-80 characters without any space (or friends). This can either be a
lot of characters without space, or another Inset (like a LyX-note) with
70-80 characters that may contain a space. As it's very unusual to have
no space in a footnote for 80 characters long, you'll only encounter
this bug when having Insets at the start.

To avoid this bug you can simple go to
Tools->Preferences->Look&Feel->User interface and uncheck "Enable
tooltips in main work area".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jürgen Spitzmüller | 1 Oct 2009 12:36
Favicon

RE: strange bug in lyx 1.6.4

Sebastian Guttenberg wrote:

> If this is the bug you mean, and if
> it is already fixed, how can I get the fix?

If you are able to, you can grab the SVN source of BRANCH_1_6_X and 
recompile yourself:
http://www.lyx.org/HowToUseSVN#toc9

Jürgen
Permalink | Reply | 0 comments |
headers
Jürgen Spitzmüller | 1 Oct 2009 13:56
Favicon

Re: LyX 1.6.4.1 and Snow Leopard

Ludovico Rossi wrote:
> I'm a Lyx user who experienced the autosave crashing issue on Snow
> Leopard. Based on what I've read in this mailing list and in other
> user reports, I've built the 1.6.4.1 source available here
> 
> ftp://ftp.lyx.org/pub/lyx/stable/1.6.x/lyx-1.6.4.1.tar.gz
> 
> manually disabling HAVE_FORK, and then I've used this custom build
> without experiencing any crash. I'm sharing the binary in case
> somebody finds it useful:
> 
> http://www.bluepixysw.com/Lyx.zip

Bennett, could we build an official new binary on this line?

Jürgen
Permalink | Reply | 6 comments |
headers
BH | 1 Oct 2009 14:55
Picon

Re: GuiApplication.cpp compile error

On Thu, Oct 1, 2009 at 3:46 AM, Abdelrazak Younes <younes@...> wrote:
> Jean-Marc Lasgouttes wrote:
>>
>> Abdelrazak Younes <younes@...> writes:
>>
>>>>
>>>>  But it takes a very long time to save preferences --
>>>> several seconds minimum, eating up processor time. Generally speaking,
>>>> trunk seems to have slowed down considerably (especially noticeable
>>>> with typing speed) in the last month.
>>>>
>>>
>>> Are you sure you compiled in release mode, that is _without_
>>> stdlib-debug?
>>>
>>
>> Several seconds for saving preferences is wrong even with stdlib-debug.
>
> It's not only about saving preferences, it's also about, basically,
> restarting the GUI. I know, it's a bit of a hammer to reset the GUI for any
> tiny change and we should probably change that...
>
>> Can you do some profiling, Bennett?
>>
>
> Yep, that would be nice... but without stdlib-debug of course ;-)

I've got --enable-build-type=rel in my configure line, which ensures
that it's without stdlib-debug, right?
(Continue reading)

Permalink | Reply | 1 comment |
headers
BH | 1 Oct 2009 14:59
Picon

Re: LyX 1.6.4.1 and Snow Leopard

On Thu, Oct 1, 2009 at 7:56 AM, Jürgen Spitzmüller <spitz@...> wrote:
> Ludovico Rossi wrote:
>> I'm a Lyx user who experienced the autosave crashing issue on Snow
>> Leopard. Based on what I've read in this mailing list and in other
>> user reports, I've built the 1.6.4.1 source available here
>>
>> ftp://ftp.lyx.org/pub/lyx/stable/1.6.x/lyx-1.6.4.1.tar.gz
>>
>> manually disabling HAVE_FORK, and then I've used this custom build
>> without experiencing any crash. I'm sharing the binary in case
>> somebody finds it useful:
>>
>> http://www.bluepixysw.com/Lyx.zip
>
> Bennett, could we build an official new binary on this line?

I'm not sure what you mean. Do you want me to take that binary and put
it in my usual .dmg, or do you want me to build something fresh, and
if so, from what source? (Perhaps Ludovico would send me a patch for
1.6.4.1.)

In either case, the answer is yes.

BH
Permalink | Reply | 5 comments |

Gmane