Possible problem with context using the ARM 64bit download for Apple Silicon M1
Hi all I have been using ConTeXt (X86 64bits) on my mac mini Apple Silicon M1 and it works well using Rosetta translation for the M1. I recently installed the ARM 64bits version (separately from the X86 64bits version) which I assume does not require translation using Rosetta. However I had a error with the lmt_shade command in the ARM 64bits ConTeXt verson but not in with the X86 64bits version of ConTeXt. The MWE is shown below. This is actually taken from the LuaMetaFun manual. I also noticed that some figures are missing in the manual (Chapter 7, Shade) which is part of the ARM 64bit tree but not in the manual in the X86 64bits tree. Best Wishes Keith McKay Hamilton, Scotland. %%%%%%%%%%%%%%%%%%%%%%%%% \setuppapersize [A4, portrait] \usecolors[crayola] \starttext \startMPpage StartPage; width := PaperWidth ; height := PaperHeight ; unit := cm ; definecolor [ name = "MyColor3", r = 0.22, g = 0.44, b = 0.66 ] ; definecolor [ name = "MyColor4", r = 0.66, g = 0.44, b = 0.22 ] ; draw lmt_shade [ path = fullcircle scaled 4cm, direction = "right", domain = { 0, 2 }, colors = { "MyColor3", "MyColor4" }, ] ; StopPage; \stopMPpage \stoptext %%%%%%%%%%%%%%%%%%%%%%%% Here is the error taken from the log <snip> system > system > ConTeXt ver: 2021.02.20 16:50 LMTX fmt: 2021.2.21 int: english/english system > system > 'cont-new.mkxl' loaded <snip> metapost > initializing number mode 'scaled' metafun > log > metafun > log > error: Not a cycle metafun > log > metapost > log > <to be read again> metapost > log > withprescript metapost > log > <argument> ...asparameter"vector":center_a:=point(getparameter"vector"1)of.mfun_shade_path;center_b:=point(getparameter"vector"2)of.mfun_shade_path;fi.fill.mfun_shade_path.withprescript metapost > log > "sh_domain="... metapost > log > image->begingroup.save.currentpicture;picture.currentpicture;currentpicture:=nullpicture;(TEXT3) metapost > log > ;currentpicture.if.str(SUFFIX2)<>"":shifted(mfun_labxf(SUFFIX2)*lrcorner.p+mfun_labyf(SUFFIX2)*ulcorn... metapost > log > lmt_do_shade->...ve="circular":draw.fullcircle.scaled(radius_a)shifted.center_a.dashed.evenly;draw.fullcircle.scaled(factor*radius_b)shifted-center_b.dashed.evenly;fi.fi.popparameters;) metapost > log > endgroup metapost > log > <scantokens> lmt_do_shade metapost > log > metapost > log > <*> ... name = "MyColor4", r = 0.66, g = 0.44, b = 0.22 ] ; draw lmt_shade [ path = fullcircle scaled 4cm, direction = "right", domain = { 0, 2 }, colors = { "MyColor3", "MyColor4" }, ] metafun > log > metafun > log > That contour should have ended with '.. cycle' or '& cycle'. So I'll not change anything just now. metafun > log > metapost > log > ; StopPage; ; metapost > log >
I have been using ConTeXt (X86 64bits) on my mac mini Apple Silicon M1 and it works well using Rosetta translation for the M1. I recently installed the ARM 64bits version (separately from the X86 64bits version) which I assume does not require translation using Rosetta. However I had a error with the lmt_shade command in the ARM 64bits ConTeXt verson but not in with the X86 64bits version of ConTeXt. The MWE is shown below. This is actually taken from the LuaMetaFun manual. I also noticed that some figures are missing in the manual (Chapter 7, Shade) which is part of the ARM 64bit tree but not in the manual in the X86 64bits tree. That arm version was an experiment so it's definitely not in sync with
On 2/23/2021 5:51 PM, Keith McKay wrote: the latest luametatex/lmtx combination. It was crosscompiled on an intel mac which took ages so it stuck as experiment. Because th eintel bin runs on the arm mac it has a low priority (unless someone donates an arm mini to the farm). So, forget about the arm apple bins for now. We do generate windows arm but that's because it's easy to do, boit that we have a machine to test if it actually works. Btw, in the latest upload the metafun manual should compile ok (Otared tested till we had all working in lmtx which does some things differnetly deep down; there were also some resources missing). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Thanks for your reply Hans. I half suspected that the ARM version was experimental but thought I should report it anyway. Much as I would love to donate an ARM mini to the farm the best I can do is offer to compile on my mac mini Silicon M1, however, I would have to add the caveat that this is something I have never done so would need a lot of hand holding. Best Wishes Keith On 23/02/2021 17:21, Hans Hagen wrote:
On 2/23/2021 5:51 PM, Keith McKay wrote:
I have been using ConTeXt (X86 64bits) on my mac mini Apple Silicon M1 and it works well using Rosetta translation for the M1. I recently installed the ARM 64bits version (separately from the X86 64bits version) which I assume does not require translation using Rosetta. However I had a error with the lmt_shade command in the ARM 64bits ConTeXt verson but not in with the X86 64bits version of ConTeXt. The MWE is shown below. This is actually taken from the LuaMetaFun manual. I also noticed that some figures are missing in the manual (Chapter 7, Shade) which is part of the ARM 64bit tree but not in the manual in the X86 64bits tree. That arm version was an experiment so it's definitely not in sync with the latest luametatex/lmtx combination. It was crosscompiled on an intel mac which took ages so it stuck as experiment. Because th eintel bin runs on the arm mac it has a low priority (unless someone donates an arm mini to the farm). So, forget about the arm apple bins for now.
We do generate windows arm but that's because it's easy to do, boit that we have a machine to test if it actually works.
Btw, in the latest upload the metafun manual should compile ok (Otared tested till we had all working in lmtx which does some things differnetly deep down; there were also some resources missing).
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 2/23/2021 8:10 PM, Keith McKay wrote:
Thanks for your reply Hans.
I half suspected that the ARM version was experimental but thought I should report it anyway.
Much as I would love to donate an ARM mini to the farm the best I can do is offer to compile on my mac mini Silicon M1, however, I would have to add the caveat that this is something I have never done so would need a lot of hand holding. it would mean opening up your machien to mojca, adding it to the compile farm etc etc .. not a good idea, keeping it running 24/7 because we cannot afforc to miss a binary ... so we just wait till these arm machines make in into our homes .. no hurry i guess
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 23 Feb 2021, at 19:20, Hans Hagen
On 2/23/2021 8:10 PM, Keith McKay wrote:
Thanks for your reply Hans. I half suspected that the ARM version was experimental but thought I should report it anyway. Much as I would love to donate an ARM mini to the farm the best I can do is offer to compile on my mac mini Silicon M1, however, I would have to add the caveat that this is something I have never done so would need a lot of hand holding. it would mean opening up your machien to mojca, adding it to the compile farm etc etc .. not a good idea, keeping it running 24/7 because we cannot afforc to miss a binary ... so we just wait till these arm machines make in into our homes .. no hurry i guess
Are the source files and test cases in a Git / Mercurial / Fossil / whatever repository somewhere? It would be easy enough to set up an automated daily check to see if there had been a change and then trigger a fresh build. It doesn't even need to be that integrated - just a check on the latest intel binary and if that has been touched then trigger a download and local compile. If Keith's scripting skills aren't up to it then I could do it and then developer sign and upload the resulting binary to OneDrive or similar. Regards, — Bruce Horrocks Hampshire, UK
participants (3)
-
Bruce Horrocks -
Hans Hagen -
Keith McKay