On Tue, Feb 23, 2016 at 09:18:50PM -0700, Jerry wrote:
> 
> On Feb 23, 2016, at 3:28 PM, Scott Kostyshak <skost...@lyx.org> wrote:

> > Jerry does this happen even when Flexiglass is not running?
> 
> Yes. The behavior is the same, which is, using a non-new LyX but running 
> Reconfigure, one instance of luatex hitting 200-250 MB (it can vary 10s of MB 
> between Activity Monitor updates, which is about 3 seconds--Activity Monitor 
> is I believe eye candy over tops) and roughly 20-100% of a single CPU. That 
> luatex crashes in 4-5 minutes. The message about the Python command not 
> finishing is displayed. Clicking "let it run" causes a message displayed that 
> the system has been reconfigured and to restart LyX. LyX does not crash.
> 
> I'll try to remember to quit Flexiglass when doing LyX testing but I probably 
> use it a hundred+ times a day.

I imagine it is hard. Actually the useful thing is to know whether you
can reproduce bugs that you find when Flexiglass is not running. So you
do not always have to remember to turn it off, but maybe it is hard to
remember to do it even in these cases.

> > Can you run that python command manually in a terminal?
> Yes
> > Can you
> > reproduce the freeze when you do this?
> No. The command ran for 35 minutes with almost of it with the line "+Indexing 
> TeX files..." displayed.

This is important information. 35 minutes is not normal. For me it takes 9 
seconds (although I would not be surprised if it takes up to a couple of 
minutes on some computers).

> There were two Python instances during this time, one possibly spawned by the 
> other. It (they) appear(s) to have finished normally. In my home directory 
> the following files and directories--all empty--were created. I'm going to 
> trash them.

I forgot to specify that normally this command would be run from your
LyX user directory (which you can find the location of in Help > About).

> +Indexing TeX files... 

So this is where it pauses for a long time? How many minutes out of the
35?

> +checking for default encoding (this may take a long time)

This is the only place where we say that it might take a long time. Does
the script pause here for a while?

> kpathsea: Running mktextfm ecrm1000
> /opt/local/share/texmf-texlive/web2c/mktexnam: Could not map source 
> abbreviation  for ecrm1000.
> /opt/local/share/texmf-texlive/web2c/mktexnam: Need to update ?
> mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
> input ecrm1000
> This is METAFONT, Version 2.7182818 (TeX Live 2015/MacPorts 2015_8) 
> (preloaded base=mf)
> 
> 
> kpathsea: Running mktexmf ecrm1000
> ! I can't find file `ecrm1000'.
> <*> ...ljfour; mag:=1; nonstopmode; input ecrm1000
>                                                   
> Please type another input file name
> ! Emergency stop.
> <*> ...ljfour; mag:=1; nonstopmode; input ecrm1000
>                                                   
> Transcript written on mfput.log.
> grep: ecrm1000.log: No such file or directory
> mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input 
> ecrm1000' failed to make ecrm1000.tfm.
> kpathsea: Appending font creation commands to missfont.log.

This doesn't look normal. I'm not sure if it's LyX's fault or your TeX
installation. Whatever it is, LyX should at least exit with error here,
no?

>  Python terminal output.txt
> > 
> > To make sure I understand correctly, you experienced a similar problem
> > with LyX 2.1.x except that LyX did not crash. What is new in beta2 is
> > that LyX crashes. Did I get that right?
> I can't remember if LyX has actually ever crashed in this respect--it rather 
> seems to become unresponsive while the one or two luatex are running, 2.1.x 
> and 2.2.x. I seem to recall that when first running a new version I might 
> have had to force-quit LyX after the two luatex instances either crashed (at 
> least one) or I killed them.
> 
> I just also ran Reconfigure on LyX 2.1.4 which is not a new installation, 
> with the same results as 2.2.0beta, different path to the Python command 
> notwithstanding.

OK so it seems that this is not a regression. This is good to know
(although it makes finding the cause more difficult).

Scott

Attachment: signature.asc
Description: PGP signature

Reply via email to