Hi, In a moment or so, I will upload a new version that can have multiple lua interpreters. My current syntax is extremely minimal: \lua<int>{<lua stuff>} \latelua<int>{<lua stuff>} So, just like before but with an extra integer, just like the \marks syntax. Non-existing interpreters are auto-initialized. There is no provision (yet?) to "clean up" an interpreter. WDYT? Taco
Taco Hoekwater wrote:
Hi,
In a moment or so, I will upload a new version that can have multiple lua interpreters. My current syntax is extremely minimal:
\lua<int>{<lua stuff>} \latelua<int>{<lua stuff>}
So, just like before but with an extra integer, just like the \marks syntax. Non-existing interpreters are auto-initialized. There is no provision (yet?) to "clean up" an interpreter. WDYT?
can you use \directlua instead of \lua so that we can define \def\lua{\directlua0} which is convenient Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Taco Hoekwater wrote:
Hi,
In a moment or so, I will upload a new version that can have multiple lua interpreters. My current syntax is extremely minimal:
\lua<int>{<lua stuff>} \latelua<int>{<lua stuff>}
So, just like before but with an extra integer, just like the \marks syntax. Non-existing interpreters are auto-initialized. There is no provision (yet?) to "clean up" an interpreter. WDYT?
can you use \directlua instead of \lua so that we can define \def\lua{\directlua0}
sure, no problem, submitting that now. Taco
Taco Hoekwater wrote:
Hans Hagen wrote:
Taco Hoekwater wrote:
Hi,
In a moment or so, I will upload a new version that can have multiple lua interpreters. My current syntax is extremely minimal:
\lua<int>{<lua stuff>} \latelua<int>{<lua stuff>}
So, just like before but with an extra integer, just like the \marks syntax. Non-existing interpreters are auto-initialized. There is no provision (yet?) to "clean up" an interpreter. WDYT?
we need indeed a way to clean up (i.e kill pending processes/clear related mem) Hans -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
we need indeed a way to clean up (i.e kill pending processes/clear related mem)
I was bored a bit, so I've committed a version with an initial version of \closelua: \directlua1{a="hello";} \directlua1{print(a);} % => hello \immediate\closelua1 \directlua1{print(a);} % => nil \latelua2{a="late";} \latelua2{print(a);} % => late \closelua2 \latelua2{print(a);} % => nil Some things are perhaps strange: \closelua is not expandable, even though \directlua is. So: do not attempt to close a lua interpreter inside an \edef. (The non-immediate form of \closelua cannot be expandable, because it has to insert a node, and that implies that the other form cannot be either. For that, we would need separate \closedirectlua and \closelatelua commands, which is a bit weird). Also, the non-immediate form of \closelua is illegal in dvi mode, just like \latelua, but the \immediate form is allowed, just like \directlua. This could be easily fixed by disallowing \directlua in DVI mode as well :-) Cheers, Taco
participants (2)
-
Hans Hagen -
Taco Hoekwater