![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 19.03.2012 um 00:29 schrieb Kip Warner:
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.
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 Wolfgang
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 20.03.2012 um 02:04 schrieb Kip Warner:
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.
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. Wolfgang
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 20.03.2012 um 06:31 schrieb Kip Warner:
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.
TeX has it’s problem with certain errors, accept 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
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. Wolfgang
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/62c54476729274ddfefd6b1f53e311dc.jpg?s=120&d=mm&r=g)
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. Patrick
![](https://secure.gravatar.com/avatar/7325514c8a7b377b86d86ad29d35e8ef.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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. 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Tue, Mar 20, 2012 at 9:17 AM, Hans Hagen
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
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
On Tue, 2012-03-20 at 09:17 +0100, Hans Hagen wrote:
which is not really a crash of my operating system; there is not much I can do about this issue I fear.
Totally up to you. I just wanted to bring it to your attention. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/7325514c8a7b377b86d86ad29d35e8ef.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Tue, Mar 20, 2012 at 10:24 PM, Kip Warner
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
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
On Tue, 2012-03-20 at 22:41 +0100, luigi scarso wrote:
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 ?
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. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
On Tue, 2012-03-20 at 21:44 +0100, Hans Hagen wrote:
sure, but mu experience is that browsers of email clients are way more demanding than tex when it comes to memory usage
I've never had either take down the entire operating system. There is a different from intended memory usage and unintended anyways. In this case, we are talking about the latter.
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
Well, you saw what happened with my sample minimal. Anyways, if this is normal behaviour, that's fine, I just wanted to bring it to the list's attention. That's all. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c5ae4f9aa0d3a9bd5376e92b322c3e50.jpg?s=120&d=mm&r=g)
On Tue, 20 Mar 2012, Kip Warner wrote:
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
You are back to square one :) You cannot mix options (R, 2*broad, anything without an = sign) with assignments (before=..., after=..., anything with an = sign). The format of \startitemize is \startitemize[options][assignments] or \startitemize[options] or \startitemize[assignments] 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. Aditya
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
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.
- The fact that assignments and simple options have to be separated is not a limitation of TeX, but the way how ConTeXt is programmed. Hans uses a single command that takes all options inside brackets at once that defines (results in) something similar to (syntax is not exact and is probably completely different in MKIV) \@@itmstart -> 11, \@@itmbefore -> \startlinecorrection, etc. - 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 [...,...=...,...] - 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. It would help a lot if somebody could come up with plain LuaTeX example that does approximately the same since it might happen that until the bug gets fixed, Hans might reimplement some functionality and then LuaTeX won't crash on the same input any more. Lots and lots of bugs in LuaTeX have been fixed in past, but most of them happened on regular/proper/allowed input. Not many people use wrong ConTeXt syntax on regular basis to be able to spot such problems. I also bet that if somebody else would start writing his own TeX format comparable to ConTeXt, quite some new bugs might have surfaced that one would never stumble upon during regular use. Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 22-3-2012 11:38, Mojca Miklavec wrote:
- The fact that assignments and simple options have to be separated is not a limitation of TeX, but the way how ConTeXt is programmed. Hans uses a single command that takes all options inside brackets at once that defines (results in) something similar to (syntax is not exact and is probably completely different in MKIV) \@@itmstart -> 11, \@@itmbefore -> \startlinecorrection, etc.
fyi: In mkiv the principle is the same but it's a bit more more dynamic: \<namespace><instance>:<key> with namespace being efficiently shortcut deep down in context. The new fashion is then \<namespace>parameter{key} given that \current<namespace> == <instance> is set. This is the new commandhandler approach that we use in overhauled core code as well as in Wolfgangs and Adityas modules. The dynamic approach is somewhat slower but it's compensated by way less hash entries and other speedups in the overhaul. 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 22-3-2012 11:38, Mojca Miklavec wrote:
- The fact that assignments and simple options have to be separated is not a limitation of TeX, but the way how ConTeXt is programmed. Hans uses a single command that takes all options inside brackets at once that defines (results in) something similar to (syntax is not exact and is probably completely different in MKIV) \@@itmstart -> 11, \@@itmbefore -> \startlinecorrection, etc.
fyi: In mkiv the principle is the same but it's a bit more more dynamic: \<namespace><instance>:<key> with namespace being efficiently shortcut deep down in context. The new fashion is then \<namespace>parameter{key} given that \current<namespace> == <instance> is set. This is the new commandhandler approach that we use in overhauled core code as well as in Wolfgangs and Adityas modules. The dynamic approach is somewhat slower but it's compensated by way less hash entries and other speedups in the overhaul. 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/5ef3be2c0e949ae4c891de058ebf4d76.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5ef3be2c0e949ae4c891de058ebf4d76.jpg?s=120&d=mm&r=g)
On 2012-03-22 12:21, Philipp Gesang wrote:
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.
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! Regards Philipp -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
On Thu, 2012-03-22 at 12:21 +0100, Philipp Gesang wrote:
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
Thanks Philipp. I'm finding that one of the big weaknesses of ConTeXt is similar to a common criticism of the first one listed on Git here: https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ It requires users to know too much about how ConTeXt actually works internally (e.g. its information model). Maybe this is necessary. Maybe it isn't. I'm fairly new to typesetting and never came from a background of decades of experience with TeX. But it seems to me like any programming language, and ConTeXt is a kind of one for document engineering, should have users focusing on creating beautiful books and not on the language's information and processing model. Just my two cents. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
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
On Thu, Mar 22, 2012 at 3:01 AM, Kip Warner
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.
Hm, ConTeXt is rooted in TeX and plain TeX. It helps a lot to know TeX (and eTeX and pdfTeX). -- luigi
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Thu, Mar 22, 2012 at 1:05 PM, luigi scarso
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
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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
One other thing that I should have made more clear, this only happens when I insert the aforementioned line correction commands.
test needed 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 20-3-2012 01:43, Kip Warner wrote:
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.
it depends ... if some node list juggling happens in macros/lua code and something is done wrong there, one can run out of memory (for instance) 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Mon, Mar 19, 2012 at 12:25 AM, Kip Warner
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
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 19-3-2012 00:25, Kip Warner wrote:
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.
Packaging itemizes are on a todo list as I sometimes need it myself, but it has a low priority 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/e4119be23c6b43ebdb1041bb53ac9e67.jpg?s=120&d=mm&r=g)
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
participants (9)
-
Aditya Mahajan
-
Hans Hagen
-
Khaled Hosny
-
Kip Warner
-
luigi scarso
-
Mojca Miklavec
-
Patrick Gundlach
-
Philipp Gesang
-
Wolfgang Schuster