Am 17.03.2012 um 10:21 schrieb luigi scarso:

...

Hey list,

Is there any way to hint to ConTeXt that the contents of a \startitemize \stopitemize pair should try to be all on the same page?

On Sat, Mar 17, 2012 at 2:47 AM, Kip Warner wrote: plain old tex \vbox{% \startitemize \stopitemize% }

Better: \startitemize[before=\startlinecorrection,after=\stoplinecorrection] … \stopitemize You can control the space before/after the linecorrection environment with the optional argument which accepts all values for \blank, e.g. \startlinecorrection[2*line]. Wolfgang

On Sun, 2012-03-18 at 16:25 -0700, Kip Warner wrote:

On Sat, 2012-03-17 at 11:21 +0100, Wolfgang Schuster wrote:

...

Am 17.03.2012 um 10:21 schrieb luigi scarso:

...

...

Hey list,

Is there any way to hint to ConTeXt that the contents of a \startitemize \stopitemize pair should try to be all on the same page?

On Sat, Mar 17, 2012 at 2:47 AM, Kip Warner wrote: plain old tex \vbox{% \startitemize \stopitemize% }

Better:

\startitemize[before=\startlinecorrection,after=\stoplinecorrection]

\stopitemize

You can control the space before/after the linecorrection environment with the optional argument which accepts all values for \blank, e.g. \startlinecorrection[2*line].

Wolfgang

Hey Wolfgang,

The good news is that this is probably what I need. The bad news is luatex completely blows itself to pieces, allocating memory until the system crashes.

After much grinding of the machine, I managed to finally SIGSTOP and attach gdb to the naughty process.

I've cc'd the luatex user mailing list since this is probably, I suppose, a luatex issue more than a ConTeXt one.

I am using luatex beta-0.71.0-2012030522 (rev 4364) through context version 2012.03.13 21:26 on amd64 hardware running Ubuntu Maverick.

One other thing that I should have made more clear, this only happens when I insert the aforementioned line correction commands. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Mon, 2012-03-19 at 09:17 +0100, Wolfgang Schuster wrote:

Make a example because this works:

\starttext

%\dorecurse{2}{\input tufte\par} \dorecurse{3}{\input tufte\par}

\startitemize[before={\startlinecorrection[blank]},after= \stoplinecorrection] \dorecurse{4}{\startitem \input ward \stopitem} \stopitemize

\dorecurse{3}{\input tufte\par}

\stoptext

I concur that your example works. Attached is an example of a minimal that does not for me. ConTeXt does its thing, invoking luatex which quickly gets nasty and starts spinning the clock - endlessly allocating memory until a 4GB system is run into the ground. This is what I see: $ context minimal.tex resolvers | resolving | loading configuration file 'selfautodir:/share/texmf/web2c/contextcnf.lua' resolvers | resolving | loading configuration file '/usr/share/texmf/web2c/contextcnf.lua' mtx-context | run 1: luatex --fmt="/home/kip/.texmf-var/luatex-cache/context/e570cb3e0e3ab0118ca08dd148bbec7d/formats/cont-en" --lua="/home/kip/.texmf-var/luatex-cache/context/e570cb3e0e3ab0118ca08dd148bbec7d/formats/cont-en.lui" --backend="pdf" "./minimal.tex" \stoptext This is LuaTeX, Version beta-0.71.0-2012030522 (rev 4364) \write18 enabled. resolvers > resolving > loading configuration file '/usr/share/texmf/web2c/contextcnf.lua' (minimal.tex ConTeXt ver: 2012.03.13 21:26 MKIV fmt: 2012.3.14 int: english/english system > cont-new.mkiv loaded (/usr/share/texmf/tex/context/base/cont-new.mkiv system > beware: some patches loaded from cont-new.mkiv ) system > minimal.top loaded (minimal.top) fonts > latin modern fonts are not preloaded languages > language en is active {/usr/share/texmf/fonts/map/pdftex/context/mkiv-base.map} fonts > preloading latin modern fonts (second stage) fonts > typescripts > unknown: library 'loc' {/usr/share/texmf/fonts/map/dvips/lm/lm-math.map}{/usr/share/texmf/fonts/map/dvips/lm/lm-rm.map} fonts > defining > forced type afm of stmary10 not found fonts > defining > font with asked name 'stmary10' is not found using lookup 'file' fonts > virtual math > loading font LMMath7-Regular subfont 9 with name stmary10.afm at 458752 is skipped, not found fonts > defining > forced type afm of stmary10 not found fonts > defining > font with asked name 'stmary10' is not found using lookup 'file' fonts > virtual math > loading font LMMath9-Regular subfont 9 with name stmary10.afm at 589824 is skipped, not found fonts > defining > forced type afm of stmary10 not found fonts > defining > font with asked name 'stmary10' is not found using lookup 'file' fonts > virtual math > loading font LMMath12-Regular subfont 9 with name stmary10.afm at 786432 is skipped, not found fonts > fallback modern rm 12pt is loaded [***hangs at this point***] I am using ConTeXt and LuaTeX packages off of Adam's PPA. These are luatex version beta-0.71.0-2012030522 (rev 4364) under context version 2012.03.13 21:26 on amd64 hardware using Ubuntu Maverick. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Tue, 2012-03-20 at 06:22 +0100, Wolfgang Schuster wrote:

The problem is the empty second argument.

\startitemize[before=\startlinecorrection,after=\stoplinecorrection][]

When you pass two arguments with \startitemize the first argument os for keywords (e.g. packed or fit) and second argument is for assignments (e.g. width=3cm) in your case context is looking for the keywords “before=\startlinecorrection” and “after=\stoplinecorrection” which results in a loop.

Even if that were the case, that's a fragility that no program should its users endure. It should probably have bailed with an error message after seeing that the second argument was empty rather than taking down the entire operating system with it. But regardless, this does not seem to be the case. The following minimal still blows up, even with an assignment in the second parameter. \starttext \startitemize[before=\startlinecorrection,after= \stoplinecorrection][start=11] \item foo \stopitemize \stoptext -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Tue, 2012-03-20 at 06:46 +0100, Wolfgang Schuster wrote:

TeX has it’s problem with certain errors, accept it.

It is not a problem with the program raising an error, it was how it went about doing it. It should not have to take down the entire operating system to indicate to the user that there was a non-intuitive syntactical error in typesetting. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Tue, Mar 20, 2012 at 08:21:35AM +0100, Patrick Gundlach wrote:

Am 20.03.2012 um 06:49 schrieb Kip Warner:

...

On Tue, 2012-03-20 at 06:46 +0100, Wolfgang Schuster wrote:

...

TeX has it’s problem with certain errors, accept it.

It is not a problem with the program raising an error, it was how it went about doing it. It should not have to take down the entire operating system to indicate to the user that there was a non-intuitive syntactical error in typesetting.

I also agree that a segfault is not an acceptable behavior of a program, regardless of the input (unless you are doing low level stuff). But it is not clear if this is a problem on the ConTeXt side or the LuaTeX side.

It did not segfault, it just consumed all available memory :) A sane operating system wouldn't allow any program to do this (mine is not sane, I know, but luatex is hardly the only program that does this to me). Regards, Khaled

On Tue, Mar 20, 2012 at 9:17 AM, Hans Hagen wrote:

On 20-3-2012 06:49, Kip Warner wrote:

...

On Tue, 2012-03-20 at 06:46 +0100, Wolfgang Schuster wrote:

...

TeX has it’s problem with certain errors, accept it.

It is not a problem with the program raising an error, it was how it went about doing it. It should not have to take down the entire operating system to indicate to the user that there was a non-intuitive syntactical error in typesetting.

tex is a macro language and that has benefits but also drawbacks; as soon as you end up in unwanted expansion things can get nasty; anyhow, I get

Runaway argument? {before=\startlinecorrection ,after= \stoplinecorrection }]{\dodoubleemptyYESone \ETC. ! TeX capacity exceeded, sorry [token memory size=90996078].

which is not really a crash of my operating system; there is not much I can do about this issue I fear.

Even here Runaway argument? {before=\startlinecorrection ,after=\stoplinecorrection }]{\dodoubleemptyYESone \ETC. ! TeX capacity exceeded, sorry [token memory size=188689465]. on Linux 32bit kernel (on a 64bit processor) -- is the example on a 64bit kernel ? -- luigi

On Mon, Mar 19, 2012 at 10:49:48PM -0700, Kip Warner wrote:

On Tue, 2012-03-20 at 06:46 +0100, Wolfgang Schuster wrote:

...

TeX has it’s problem with certain errors, accept it.

It is not a problem with the program raising an error, it was how it went about doing it. It should not have to take down the entire operating system to indicate to the user that there was a non-intuitive syntactical error in typesetting.

Older TeX engines had hard memory limit, so in case of such "syntactical" errors the engine would consume all its allocated memory and die (with a misleading error message), LuaTeX dynamically allocates memory (for good reasons) so it won't stop before consuming all your available memory, its the responsibility of an operating system to prevent such a faulty application from taking the whole system down. Regards, Khaled

On 20-3-2012 19:59, Kip Warner wrote:

On Tue, 2012-03-20 at 16:57 +0200, Khaled Hosny wrote:

...

Older TeX engines had hard memory limit, so in case of such "syntactical" errors the engine would consume all its allocated memory and die (with a misleading error message), LuaTeX dynamically allocates memory (for good reasons) so it won't stop before consuming all your available memory, its the responsibility of an operating system to prevent such a faulty application from taking the whole system down.

I'd be very interested in seeing the operating system memory manager's algorithm that could do such a remarkable thing.

well you can try what happens if you run stock lua: local t = { } while true do t[#t+1] = "just a bogus string: " .. (#t+1) end at some point your system will run out of (virtual) memory or lua will run out of whatever its limits are Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On Tue, 2012-03-20 at 20:26 +0100, Hans Hagen wrote:

...

well you can try what happens if you run stock lua:

local t = { } while true do      t[#t+1] = "just a bogus string: " .. (#t+1) end

at some point your system will run out of (virtual) memory or lua will run out of whatever its limits are

Of course. And the same could be done in C, C++, or really any language that supports dynamic memory allocation. We just hope that programs that are built from them won't do that. When TeX says ! TeX capacity exceeded, sorry [token memory size=<...>] it is its graceful way to exit from an irreversible situation. It can be caused by luatex or ConTeXt mkiv but it's *not* a segmentation fault, as you said early: Actually highly probably, since the seg fault is raised in luatex and not context. Even if context is feeding it malformed input, luatex should not ever crash. Only luatex can do a segmentation fault -- of course due a tex macro /lua function possibly called from ConTeXt. What happen for me (linux ubuntu 10lts 32bit) and Hans (windows (7

On Tue, Mar 20, 2012 at 8:59 PM, Kip Warner wrote: professional 64bit ?) ) is a "TeX capacity exceeded," , not a seg. fault, and sometime happen if one calls a macro in a wrong way. So, do you have a segmentation fault or a TeX capacity exceeded on you linux 64bit box ? -- luigi

On Tue, Mar 20, 2012 at 10:24 PM, Kip Warner wrote:

On Tue, 2012-03-20 at 21:39 +0100, luigi scarso wrote:

...

...

Actually highly probably, since the seg fault is raised in luatex and not context. Even if context is feeding it malformed input, luatex should not ever crash. Only luatex can do a segmentation fault -- of course due a tex macro /lua function possibly called  from ConTeXt. What happen for me (linux ubuntu 10lts 32bit)  and Hans (windows (7

When  TeX says ! TeX capacity exceeded, sorry [token memory size=<...>] it is its graceful way to exit from  an irreversible situation. It can be caused by luatex or ConTeXt mkiv but it's *not* a segmentation fault, as you said early: professional 64bit ?) )  is a "TeX capacity exceeded," , not a seg. fault, and sometime happen if one calls a macro in a wrong way. So, do you have a segmentation fault or a TeX capacity exceeded on you linux 64bit box ?

As I said earlier, I get a segmentation fault if I leave it to run, but I always have to kill it before it takes down the entire operating system with it (apparently this is normal). I don't get the TeX capacity exceeded error message, as you saw from my earlier console output. Ok, this is not normal and I suspect that it's linux 64bit issue -- can be bug of luatex then. Can anyone confirm that on linux 64bit the following \starttext

\startitemize[before=\startlinecorrection,after=\stoplinecorrection][] \item foo \stopitemize \stoptext gives a segmentation fault ? -- luigi

On 20-3-2012 20:59, Kip Warner wrote:

On Tue, 2012-03-20 at 20:26 +0100, Hans Hagen wrote:

...

well you can try what happens if you run stock lua:

local t = { } while true do t[#t+1] = "just a bogus string: " .. (#t+1) end

at some point your system will run out of (virtual) memory or lua will run out of whatever its limits are

Of course. And the same could be done in C, C++, or really any language that supports dynamic memory allocation. We just hope that programs that are built from them won't do that.

sure, but mu experience is that browsers of email clients are way more demanding than tex when it comes to memory usage for tex it depends how much memory is permitted (there are some maxima that can be set in configuration files) ... i must say that I never run out of memory, although with doing extreme torture tests with many fonts one can come pretty close Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On Tue, 2012-03-20 at 06:46 +0100, Wolfgang Schuster wrote:

You can’t have a assignment in both parameters because this would lead to the same problem as before, combine both settings in one argument and it works.

I must not be doing it right because the item numbers are gone now and replaced with hyphens: \startitemize[R,2*broad,before=\startlinecorrection,after= \stoplinecorrection,start=11] \setupitemize[left=(, right=)] \item foo. \item foo. \stopitemize -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Tue, 2012-03-20 at 18:22 -0400, Aditya Mahajan wrote:

Anything else will leave to undersirable behaviour (or segfaults :) ) As I had said in one of my earlier emails, this is the case for ALL context macros that take both options and assignments.

Fair enough. I got it to work now with, \startitemize[R,2*broad][start=11,before=\startlinecorrection,after= \stoplinecorrection] My only concern here is that, for something as incredibly fundamental and recurring in the world of ConTeXt, the caveats and distinctions to be made between options and assignments, that can and have taken down entire operating systems, or cause hour after hour of no end of vague syntactical errors, or even successful compilations with the wrong effects, shouldn't that probably have been mentioned at least once, even if only in passing, somewhere within the 369 page user manual? The word "assignment" I couldn't locate once. I'm not sure if this is a concept inherited from TeX, but if it is, it's probably not a good idea for the documentation and the user interface to assume that ConTeXt users have a background with TeX or derived. Thanks for the help, -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On 2012-03-22 11:38, Mojca Miklavec wrote:

On Thu, Mar 22, 2012 at 03:01, Kip Warner wrote:

...

On Tue, 2012-03-20 at 18:22 -0400, Aditya Mahajan wrote:

...

Anything else will leave to undersirable behaviour (or segfaults :) ) As I had said in one of my earlier emails, this is the case for ALL context macros that take both options and assignments.

Fair enough. I got it to work now with,

\startitemize[R,2*broad][start=11,before=\startlinecorrection,after= \stoplinecorrection]

My only concern here is that, for something as incredibly fundamental and recurring in the world of ConTeXt, the caveats and distinctions to be made between options and assignments, that can and have taken down entire operating systems, or cause hour after hour of no end of vague syntactical errors, or even successful compilations with the wrong effects, shouldn't that probably have been mentioned at least once, even if only in passing, somewhere within the 369 page user manual? The word "assignment" I couldn't locate once.

You’re right, it can cause confusion to people migrating from Latex where package options, afair, allows mixed key-value/list syntax (like e.g. Lua does as well). Random example from the KOMA-Script manual: \documentclass[BCOR=12mm,DIV=calc,twoside]{scrartcl} ^^^^^^^^^ ^^^^^^^ assignment … switch Therefore the difference to Context deserves mention at least somewhere in http://wiki.contextgarden.net/From_LaTeX_to_ConTeXt which said migrators are most likely to consult first.

- Maybe it could be more explicit, but if you ever take a look at documentation, for example http://wiki.contextgarden.net/Command/setupitemgroup you will notice that some brackets are depicted with [...,...] and others with [...,...=...,...]

And while we are handing out reading assignments (pun intended) here are two wiki links that provide background information: http://wiki.contextgarden.net/System_Macros/Comma_Separated_Lists http://wiki.contextgarden.net/System_Macros/Key_Value_Assignments Perhaps it makes most sense to think of Comma Lists v. Assignment Lists in terms of the two different argument parsers being used to process them. Regards Philipp -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On Thu, 2012-03-22 at 12:58 +0100, Philipp Gesang wrote:

Fyi I just added a couple words to the article: http://wiki.contextgarden.net/From_LaTeX_to_ConTeXt#Optional_Arguments_and_S... please expand as needed!

Thank you. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Thu, 2012-03-22 at 11:38 +0100, Mojca Miklavec wrote:

- Maybe it could be more explicit, but if you ever take a look at documentation

Sorry, but which documentation should one obviously be looking at? The half a dozen PDFs, the several versions of the wiki, the mailing list, one of the actual hard copy books, the source code? Bits and pieces are scattered everywhere with little rhyme or reason at times.

, for example http://wiki.contextgarden.net/Command/setupitemgroup you will notice that some brackets are depicted with [...,...] and others with [...,...=...,...]

Yes, and where was the thinking behind that explained in the user manual? It wasn't. Look for the word "assignment".

- The fact that luatex crashes is simply a bug that should be fixed, so if you didn't do it already, please add a ticket to the tracker.

I cc'd the minimal example to the luatex mailing list, but I won't have time right now to get more details for them on their tracker. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Thu, Mar 22, 2012 at 1:05 PM, luigi scarso wrote:

On Thu, Mar 22, 2012 at 3:01 AM, Kip Warner wrote:

...

What's probably happening is eventually the system runs out of memory, the swap gets depleted as well, and as a last act of desperation, the kernel finally denies an allocation request to luatex which is pretty rare. The latter probably then dereferences the null pointer and then it blows. Yes, can be, but LuaTex has it's memory manager that  should manage this situation just to avoid segmentation faults. I will see if I'm able to setup a vm . On a qemu vm Suse 11.3 Linux linux 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 x86_64 x86_64 x86_64 GNU/Linux at runlevel 3 after 7minuts I have

Runaway argument? {before=\startlinecorrection ,after=\stoplinecorrection }]{\dodoubleemptyYESone \ETC. ! TeX capacity exceeded, sorry [token memory size=226427358]. The vm was slow but usable, the max load factor was 2.3 . No segmentation fault. -- luigi

On Mon, 2012-03-19 at 22:49 +0100, Hans Hagen wrote:

On 19-3-2012 00:29, Kip Warner wrote:

...

...

I've cc'd the luatex user mailing list since this is probably, I suppose, a luatex issue more than a ConTeXt one.

not that probable

Actually highly probably, since the seg fault is raised in luatex and not context. Even if context is feeding it malformed input, luatex should not ever crash.

test needed

On it. My book is a couple hundred pages long, so hopefully I will be able to come up with one. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

On Mon, Mar 19, 2012 at 12:25 AM, Kip Warner wrote:

On Sat, 2012-03-17 at 11:21 +0100, Wolfgang Schuster wrote:

...

Am 17.03.2012 um 10:21 schrieb luigi scarso:

...

...

Hey list,

Is there any way to hint to ConTeXt that the contents of a \startitemize \stopitemize pair should try to be all on the same page?

On Sat, Mar 17, 2012 at 2:47 AM, Kip Warner wrote: plain old tex \vbox{% \startitemize \stopitemize% }

Better:

\startitemize[before=\startlinecorrection,after=\stoplinecorrection]

\stopitemize

You can control the space before/after the linecorrection environment with the optional argument which accepts all values for \blank, e.g. \startlinecorrection[2*line].

Wolfgang

Hey Wolfgang,

The good news is that this is probably what I need. The bad news is luatex completely blows itself to pieces, allocating memory until the system crashes. example ? -- luigi

On Mon, 2012-03-19 at 22:50 +0100, Hans Hagen wrote:

Packaging itemizes are on a todo list as I sometimes need it myself, but it has a low priority

Ok, but I thought they were already "packaged" with context? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com