Paranormal bug in TL 2016
Dear list, at some point my document started throwing an error ! error: (nodes): trying to delete an attribute reference of a non attribute node I managed to extract a minimal example which shows the error (below). However, the error only occurs when the filename of the document contains a hyphen! When I save the document as `test-error.tex' the error comes up, when I save it as `testerror.tex' it typesets smoothly. Unfortunately, I currently cannot update to latest beta because I have an important document where I cannot afford any regressions. Cheers, Henri --- \version[temporary] \definebreakpoints[hyphen] \definebreakpoint [hyphen] [-] [nleft=3,nright=3,type=6,range=yes] \setbreakpoints[hyphen] \setuppagenumbering [alternative=doublesided] \starttext \startstandardmakeup \stopstandardmakeup {\em Detailtypografie} by Friedrich Frossman \stoptext
On 10/10/2016 12:14 PM, Henri Menke wrote:
Dear list,
at some point my document started throwing an error
! error: (nodes): trying to delete an attribute reference of a non attribute node
I managed to extract a minimal example which shows the error (below). However, the error only occurs when the filename of the document contains a hyphen! When I save the document as `test-error.tex' the error comes up, when I save it as `testerror.tex' it typesets smoothly.
Unfortunately, I currently cannot update to latest beta because I have an important document where I cannot afford any regressions.
Cheers, Henri
Hi Henri, I can confirm that running context tl 2016 (2016.05.17 19:20) on your example triggers this error; the same file compiles cleanly with the current beta. Not sure if this is good news or bad news for you... Thomas
Dear Thomas, does it also compile on latest beta when there is a hyphen in the filename? BTW, the example can be simplified a little by just using \setbreakpoints[compound] instead of my complicated hyphen thing (Updated example is below.). Also I'm very sure that it is mainly related to the breakpoints thing. As I mentioned in the original post, I currently cannot update because of critical documents being composed with the TL 2016 version and I cannot afford any regressions. Cheers, Henri --- \version[temporary] \setbreakpoints[compound] \setuppagenumbering[alternative=doublesided] \starttext \startstandardmakeup \stopstandardmakeup {\em Detailtypografie} by Friedrich Frossman \stoptext On 10/10/2016 12:31 PM, Thomas A. Schmitz wrote:
On 10/10/2016 12:14 PM, Henri Menke wrote:
Dear list,
at some point my document started throwing an error
! error: (nodes): trying to delete an attribute reference of a non attribute node
I managed to extract a minimal example which shows the error (below). However, the error only occurs when the filename of the document contains a hyphen! When I save the document as `test-error.tex' the error comes up, when I save it as `testerror.tex' it typesets smoothly.
Unfortunately, I currently cannot update to latest beta because I have an important document where I cannot afford any regressions.
Cheers, Henri
Hi Henri,
I can confirm that running context tl 2016 (2016.05.17 19:20) on your example triggers this error; the same file compiles cleanly with the current beta. Not sure if this is good news or bad news for you...
Thomas ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 10/10/2016 01:49 PM, Henri Menke wrote:
Dear Thomas,
does it also compile on latest beta when there is a hyphen in the filename? BTW, the example can be simplified a little by just using \setbreakpoints[compound] instead of my complicated hyphen thing (Updated example is below.). Also I'm very sure that it is mainly related to the breakpoints thing.
As I mentioned in the original post, I currently cannot update because of critical documents being composed with the TL 2016 version and I cannot afford any regressions.
Cheers, Henri
Yes, I had saved your file as test-test.tex, and it compiles with 2016.10.08 00:11 Thomas
I have found another thread reporting the same problem https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html However, Hans only replied with »has been fixed already«. Does anyone know how to find the fix? Cheers, Henri On 10/10/2016 02:03 PM, Thomas A. Schmitz wrote:
On 10/10/2016 01:49 PM, Henri Menke wrote:
Dear Thomas,
does it also compile on latest beta when there is a hyphen in the filename? BTW, the example can be simplified a little by just using \setbreakpoints[compound] instead of my complicated hyphen thing (Updated example is below.). Also I'm very sure that it is mainly related to the breakpoints thing.
As I mentioned in the original post, I currently cannot update because of critical documents being composed with the TL 2016 version and I cannot afford any regressions.
Cheers, Henri
Yes, I had saved your file as test-test.tex, and it compiles with 2016.10.08 00:11
Thomas ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all In case you find the fix, I can "backport" it to TL's repository and users doing regular upgrades with tlmgr will get it at least. Mojca
On 10/10/2016 03:59 PM, Mojca Miklavec wrote:
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all
I'm willing to bisect it but I don't know how to integrate the git repo into the standalone distribution. Are there instructions somewhere?
In case you find the fix, I can "backport" it to TL's repository and users doing regular upgrades with tlmgr will get it at least.
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 10/10/2016 03:59 PM, Mojca Miklavec wrote:
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all
Okay, I have identified the relevant commit to be da91490 [1]. Unfortunately, the diff to the TL 2016 version which is something like af172a8 [2] is huge. I was not yet able to identify the change which fixed the bug. Also I have no idea what to look out for. So far I have just been looking for occurrences of setattr and the like. [1] https://bitbucket.org/phg/context-mirror/commits/da9149010f4d34eef23a504682d... [2] https://bitbucket.org/phg/context-mirror/commits/af172a8db5f7583d0117635edde...
In case you find the fix, I can "backport" it to TL's repository and users doing regular upgrades with tlmgr will get it at least.
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 10/10/2016 03:59 PM, Mojca Miklavec wrote:
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all
Okay. This does not make *any* sense! I started merging files until the bug disappeared and it happened when I merged cont-new.mkiv. The diff is -\newcontextversion{2016.05.17 10:06} +\newcontextversion{2016.07.01 16:28} So this is basically the version number. Can someone enlighten me what is going on?
In case you find the fix, I can "backport" it to TL's repository and users doing regular upgrades with tlmgr will get it at least.
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 11 October 2016 at 15:33, Henri Menke wrote:
On 10/10/2016 03:59 PM, Mojca Miklavec wrote:
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all
Okay. This does not make *any* sense! I started merging files until the bug disappeared and it happened when I merged cont-new.mkiv. The diff is
-\newcontextversion{2016.05.17 10:06} +\newcontextversion{2016.07.01 16:28}
So this is basically the version number. Can someone enlighten me what is going on?
I would suspect that changing the version number triggers regenerating the formats. Most likely one of the other files fixed the problem, but the problem only disappeared once you regenerated the format. That's pure guesswork though. Mojca
On 10/11/2016 03:45 PM, Mojca Miklavec wrote:
On 11 October 2016 at 15:33, Henri Menke wrote:
On 10/10/2016 03:59 PM, Mojca Miklavec wrote:
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all
Okay. This does not make *any* sense! I started merging files until the bug disappeared and it happened when I merged cont-new.mkiv. The diff is
-\newcontextversion{2016.05.17 10:06} +\newcontextversion{2016.07.01 16:28}
So this is basically the version number. Can someone enlighten me what is going on?
I would suspect that changing the version number triggers regenerating the formats. Most likely one of the other files fixed the problem, but the problem only disappeared once you regenerated the format. That's pure guesswork though.
I have to correct myself, it just looked like it worked. It didn't generate the PDF due to Fatal Error > Your format does not match the base files! The search continues.
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On Tue, Oct 11, 2016 at 3:58 PM, Henri Menke
I have to correct myself, it just looked like it worked. It didn't generate the PDF due to
Fatal Error > Your format does not match the base files!
The search continues.
To be sure, just give context --make ; contextjit --make ;mtxrun --script plain --make ; mtxrunjit --script plain --make every time you change something (ie new version of luatex , luajittex , context and so on) -- luigi
On 11 Oct 2016, at 15:58, Henri Menke
[…]
I have to correct myself, it just looked like it worked. It didn't generate the PDF due to
Fatal Error > Your format does not match the base files!
The search continues.
Hi Henri, The error is indeed extremely bizarre, and maybe funny, but if you want just to find a temporary solution in order to finish your project, it seems that adding a special word (or maybe something else…) allows the typesetting of your file. I tried the following modification of your sample with ConTeXt ver: 2016.05.17 19:20 (and LuaTeX Version 0.95.0) from TeX Live 2016. The file name is bizarre-error.tex (if there no hyphen in the file name everything is allright). It compiles both with the latest beta in standalone ConTeXt, as well as with the stable one from TeXLive 2016. It is important to have a blank line before the line containing « \phantom{Junior} ». If I remove the line « \phantom{Junior} » then the file does not compile with the version of ConTeXt from TeXLive… (but it does with the latest beta) If I replace it with the word « Junior », again it compiles fine. However if I replace that line with « \phantom{Bizarre} » or even the word « Bizarre », the file does not compile :-) But if your replace it with « Bizarre \phantom{Junior} » or with « \phantom{Bizarre} \phantom{Junior} » it compiles again… All this seems funny to me, but I understand that it might stress you! Best regards: OK % begin bizarre-error.tex \version[temporary] \setbreakpoints[compound] \setuppagenumbering[alternative=doublesided] \starttext \startstandardmakeup \stopstandardmakeup {\em Detailtypografie} by Friedrich Frossman \phantom{Junior} \stoptext % end bizarre-error.tex
I got it working using the patch below. One has to rebuild the format using context --make; contextjit --make; mtxrun --script plain --make; mtxrunjit --script plain --make for the changes to take effect. --- typo-brk.lua 2016-10-12 11:15:31.769189346 +0200 +++ typo-brk.lua 2016-10-12 11:16:16.897979419 +0200 @@ -272,6 +272,7 @@ if map then local cmap = map[char] if cmap then + setattr(current,a_breakpoints,unsetvalue) -- should not be needed -- for now we collect but when found ok we can move the handler here -- although it saves nothing in terms of performance local lang = getfield(current,"lang") @@ -301,7 +302,6 @@ else current = getnext(current) end - setattr(start,a_breakpoints,unsetvalue) -- should not be needed else current = getnext(current) end On 10/11/2016 03:45 PM, Mojca Miklavec wrote:
On 11 October 2016 at 15:33, Henri Menke wrote:
On 10/10/2016 03:59 PM, Mojca Miklavec wrote:
On 10 October 2016 at 15:31, Henri Menke wrote:
I have found another thread reporting the same problem
https://www.mail-archive.com/ntg-context@ntg.nl/msg82349.html
However, Hans only replied with »has been fixed already«.
Does anyone know how to find the fix?
Unless Hans remembers what he fixed exactly, my only idea is doing a bisection over https://bitbucket.org/phg/context-mirror/commits/all
Okay. This does not make *any* sense! I started merging files until the bug disappeared and it happened when I merged cont-new.mkiv. The diff is
-\newcontextversion{2016.05.17 10:06} +\newcontextversion{2016.07.01 16:28}
So this is basically the version number. Can someone enlighten me what is going on?
I would suspect that changing the version number triggers regenerating the formats. Most likely one of the other files fixed the problem, but the problem only disappeared once you regenerated the format. That's pure guesswork though.
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
Okay. This does not make *any* sense! I started merging files until the bug disappeared and it happened when I merged cont-new.mkiv. The diff is
-\newcontextversion{2016.05.17 10:06} +\newcontextversion{2016.07.01 16:28}
So this is basically the version number. Can someone enlighten me what is going on?
You missed the actual change and your dichotomy resulted in a meaningless diff. This often happens when trying to detect “offending” changes in a large code base. I can’t be sure, of course, but that seems more likely than a version bump introducing the bug you reported. Have you actually observed that precisely this change caused the bug? Best, Arthur
Am Mon, 10 Oct 2016 13:49:47 +0200 schrieb Henri Menke:
does it also compile on latest beta when there is a hyphen in the filename?
Works fine for me with system > ConTeXt ver: 2016.10.08 00:11 MKIV beta fmt: 2016.10.10 int: english/english and a file "test-error.tex". Btw: Your error report reminded me a miktex bug last year, where everyone thought the hyphen was responsable but at the end it was the length of file names (multiple of 9 broke) which naturally changes is one remove the hyphen ... -- Ulrike Fischer http://www.troubleshooting-tex.de/
participants (7)
-
Arthur Reutenauer -
Henri Menke -
luigi scarso -
Mojca Miklavec -
Otared Kavian -
Thomas A. Schmitz -
Ulrike Fischer