Hello, which XML processing Lua engine is used by ConTeXt? There are more XML processors developed for Lua - LuaXML, LuaExpat etc. Does ConTeXt use one of these or another, or its own - a built-in one? As I'm processing XML tables with pure Lua, too, I'd like to use only one engine in pure Lua scripts and within ConTeXt; I believe it could be possible. Best regards, Lukas -- Ing. Lukáš Procházka [mailto:LPr@pontex.cz] Pontex s. r. o. [mailto:pontex@pontex.cz] [http://www.pontex.cz] Bezová 1658 147 14 Praha 4 Tel: +420 244 062 238 Fax: +420 244 461 038
On 03/05/2013 10:59 AM, Procházka Lukáš Ing. - Pontex s. r. o. wrote:
which XML processing Lua engine is used by ConTeXt?
There are more XML processors developed for Lua - LuaXML, LuaExpat etc.
Does ConTeXt use one of these or another, or its own - a built-in one?
As I'm processing XML tables with pure Lua, too, I'd like to use only one engine in pure Lua scripts and within ConTeXt; I believe it could be possible.
Hans can give the authoritative answer, of course, but if you look into http://www.pragma-ade.com/general/manuals/mk.pdf , chapter XVII, you will see that he has indeed written his own parser, based on lpeg, and not used any of the lua libraries (I'm not a programmer, so take my word with a ton of salt, but I had a look at them and found them truly awful, compared to what, e.g., python and perl have to offer). Thomas
On 3/5/2013 10:59 AM, Procházka Lukáš Ing. - Pontex s. r. o. wrote:
Hello,
which XML processing Lua engine is used by ConTeXt?
There are more XML processors developed for Lua - LuaXML, LuaExpat etc.
Does ConTeXt use one of these or another, or its own - a built-in one?
Its own (1) because there was none and (2) because we want full control over the two-way interface.
As I'm processing XML tables with pure Lua, too, I'd like to use only one engine in pure Lua scripts and within ConTeXt; I believe it could be possible.
Just use the one that is built in context mkiv. You can load the xml parser code in regular Lua code that you write. Here is the most recent list of reasonable defaults: "l-lua.lua", "l-lpeg.lua", "l-function.lua", "l-string.lua", "l-table.lua", "l-io.lua", "l-number.lua", "l-set.lua", "l-os.lua", "l-file.lua", -- limited functionality when no lfs "l-md5.lua", -- not loaded when no md5 library "l-url.lua", "l-dir.lua", -- limited functionality when no lfs "l-boolean.lua", "l-unicode.lua", "l-math.lua", "util-tab.lua", "util-sto.lua", "util-str.lua", "util-mrg.lua", "util-prs.lua", "trac-inf.lua", "trac-set.lua", "trac-log.lua", "util-tpl.lua", "util-env.lua", "lxml-tab.lua", "lxml-lpt.lua", "lxml-mis.lua", "lxml-aux.lua", "lxml-xml.lua", If you cannot use mtxrun --script <yourscript> for some reason, you can load these files explicitly. In one of the upcoming betas I'll add a script that I use for some months now that permits you to build a merged lib out of these (and more) that then can be includes with one require call (and put alongside whatever code you use). The advantage is that you then have a sort of snapshot. (I use that approach in for instance web services.) Think of: lua mtxlibs.lua --selfmerge my-used-libs.lua trac-lmx util-jsn util-sql util-sql-imp-client util-sql-imp-library util-sql-sessions util-sql-tickets util-sql-loggers util-sql-users util-sql-logins This produces my-used-libs.lua which on top of the list above adds some more to it. You then only need to require this one lib and can avoid dependencies, path mess, etc. 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 -----------------------------------------------------------------
participants (3)
-
Hans Hagen -
Procházka Lukáš Ing. - Pontex s. r. o. -
Thomas A. Schmitz