Weird texexec hang

Weird texexec hang

[nico]

Hello,

I took me quite some time to extract the following sequence from a 300p  
book, that makes the compilation hang. It looks like if it's in an  
infinite loop, but I don't know what happens. It seems related to the  
interaction of float, verbatim, and background stuff.

I thought it was a local resource problem (few memory on my machine) but  
trying the code in live context never gave something either (i hope it is  
not still running!).

What's wrong in my definitions/setups to have such a behaviour?

\setuplayout[middle]
\setupcolors[state=start]
\setupinteraction[state=start]

\definefloat[dbsidebar]
\setupfloat
    [dbsidebar]
    [criterium=0.7\textwidth,
     leftmargindistance=-\outercombitotal,
     rightmargindistance=-\outercombitotal,
     default={outer,middle}]

\setupcaption[dbsidebar][location=bottom,number=no]

\defineframedtext
    [framesidebar]
    [width=.9\textwidth,bodyfont=small,
     corner=round,background=screen,backgroundscreen=.95]

\setupbackground
   [background=screen,
    frame=on,
    strut=yes,
    topoffset=2mm,
    width=broad,
    before=\blank,
    after={\blank[small]},
    align=right]

% Verbatim environment for programlisting
\definetyping[code]

\setuptyping[code]
             [bodyfont=small,
              before={\startbackground},
              after={\stopbackground}]

\starttext

\input tufte
\input tufte

\placedbsidebar{joke}
{\startframesidebar
\startcode
some code
\stopcode
\stopframesidebar}

\input tufte
\input tufte

\placedbsidebar{joke}
{\startframesidebar
\startcode
some code
\stopcode
\stopframesidebar}

\stoptext


Regards,
BG

Re: Weird texexec hang

[Hans Hagen]

nico wrote:
> Hello,
>
> I took me quite some time to extract the following sequence from a 300p  
> book, that makes the compilation hang. It looks like if it's in an  
> infinite loop, but I don't know what happens. It seems related to the  
> interaction of float, verbatim, and background stuff.
>
> I thought it was a local resource problem (few memory on my machine) but  
> trying the code in live context never gave something either (i hope it is  
> not still running!).
>
> What's wrong in my definitions/setups to have such a behaviour?
>
> \setuplayout[middle]
> \setupcolors[state=start]
> \setupinteraction[state=start]
>
> \definefloat[dbsidebar]
> \setupfloat
>     [dbsidebar]
>     [criterium=0.7\textwidth,
>      leftmargindistance=-\outercombitotal,
>      rightmargindistance=-\outercombitotal,
>      default={outer,middle}]
>
> \setupcaption[dbsidebar][location=bottom,number=no]
>
> \defineframedtext
>     [framesidebar]
>     [width=.9\textwidth,bodyfont=small,
>      corner=round,background=screen,backgroundscreen=.95]
>
> \setupbackground
>    [background=screen,
>     frame=on,
>     strut=yes,
>     topoffset=2mm,
>     width=broad,
>     before=\blank,
>     after={\blank[small]},
>     align=right]
>
> % Verbatim environment for programlisting
> \definetyping[code]
>
> \setuptyping[code]
>              [bodyfont=small,
>               before={\startbackground},
>               after={\stopbackground}]
>
> \starttext
>
> \input tufte
> \input tufte
>
> \placedbsidebar{joke}
> {\startframesidebar
> \startcode
> some code
> \stopcode
> \stopframesidebar}
>
> \input tufte
> \input tufte
>
> \placedbsidebar{joke}
> {\startframesidebar
> \startcode
> some code
> \stopcode
> \stopframesidebar}
>
> \stoptext
>   
backgrounds inside a float ... not the ideal combination (some otr intereference), but how about: 

\setuplayout[middle]
\setupcolors[state=start]
\setupinteraction[state=start]

\definefloat[dbsidebar]

\setupfloat
    [dbsidebar]
    [criterium=0.7\textwidth,
     leftmargindistance=-\outercombitotal,
     rightmargindistance=-\outercombitotal,
     default={outer,middle}]

\setupcaption[dbsidebar][location=bottom,number=no]

\defineframedtext
  [framesidebar]
  [width=.9\textwidth,bodyfont=small,
   corner=round,
   background=screen,backgroundscreen=.95]

\defineframedtext
  [nestedframesidebar]
  [width=broad,
   background=screen,backgroundscreen=.80]

\definetyping[code]

\setuptyping
  [code]
  [before={\startframesidebar\startnestedframesidebar},
   after={\stopnestedframesidebar\stopframesidebar}]

\starttext

\input tufte
\input tufte

\placedbsidebar{joke}{
\startcode
some code
\stopcode
}

\input tufte
\input tufte

\placedbsidebar{joke}{
\startcode
some code
\stopcode
}

\stoptext


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: Weird texexec hang

[nico]

On Fri, 19 May 2006 15:00:31 +0200, Hans Hagen <pragma@wxs.nl> wrote:

> nico wrote:
>> Hello,
>>
>> It took me quite some time to extract the following sequence from a 300p
>> book, that makes the compilation hang. It looks like if it's in an
>> infinite loop, but I don't know what happens. It seems related to the
>> interaction of float, verbatim, and background stuff.
>>
>> I thought it was a local resource problem (few memory on my machine) but
>> trying the code in live context never gave something either (i hope it  
>> is
>> not still running!).
>>
>> What's wrong in my definitions/setups to have such a behaviour?
>>
> backgrounds inside a float ... not the ideal combination (some otr  
> intereference),

What does mean otr?

> but how about:

Yes, replacing background by a framedtext works fine. In fact I used that  
(and the 300 pages book compiled fine :-) but I changed to background to  
allow the code portions to split in several pages (when put in normal text  
flow). But if you say that background should be avoided in floats i'll use  
the framed typing definition for floats (that cannot split anyway).

BTW, is there other known unsafe combinations to avoid?

Thanks,
BG

Re: Weird texexec hang

[Hans Hagen]

nico wrote:
> Yes, replacing background by a framedtext works fine. In fact I used that  
> (and the 300 pages book compiled fine :-) but I changed to background to  
> allow the code portions to split in several pages (when put in normal text  
> flow). But if you say that background should be avoided in floats i'll use  
> the framed typing definition for floats (that cannot split anyway).
>   
i adapted the backgrounds to recognize floats, i'll sen dyou the file
> BTW, is there other known unsafe combinations to avoid?
>   
well, \starttextbackground is the more modern way to go (only one level needed since one can hook in mp code) 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: Weird texexec hang

[nico]

On Fri, 19 May 2006 15:52:56 +0200, Hans Hagen <pragma@wxs.nl> wrote:

> nico wrote:
>> Yes, replacing background by a framedtext works fine. In fact I used  
>> that
>> (and the 300 pages book compiled fine :-) but I changed to background to
>> allow the code portions to split in several pages (when put in normal  
>> text
>> flow). But if you say that background should be avoided in floats i'll  
>> use
>> the framed typing definition for floats (that cannot split anyway).
>>
> i adapted the backgrounds to recognize floats, i'll sen dyou the file

Ok, thanks, i'll try it.

>> BTW, is there other known unsafe combinations to avoid?
>>
> well, \starttextbackground is the more modern way to go (only one level  
> needed since one can hook in mp code)

I tried this too, but it became a real nightmare. It compiles ok, but is  
so slow: there were hundred of MP files, and the result was ugly (strange  
offsets, strange framed lines, strange color...). I deduced that I  
certainly did something wrong, but had no time to investigate in this  
area. And the compilation time is certainly the main drawback for me.

Regards,
BG