Re: mplib

Re: mplib

[Wolfgang Werners-Lucchini]

Hallo Taco,

> > Everything I read below says there should be a 'plain.mem'
> > in the folder where you ran theat file in.  If there
> > really really isn't, then my only advise to you is to buy
> > a less thieving operating system, as it seems this one steals
> > your files before you can even have an admiring look at them.
> :-)

May be you are right that operating system steals files. We should do 
something against that.

Lutz Haseloff has send me his test (he too sees no 'mpost.mem'):
------------------------------------
TeXExec | processing document 'mplibtest.tex'
TeXExec | no ctx file found
TeXExec | tex processing method: context
TeXExec | TeX run 1
TeXExec | writing option file mplibtest.top
TeXExec | using randomseed 256
TeXExec | tex engine: luatex
TeXExec | tex format: cont-en
(./mplibtest.tex

ConTeXt  ver: 2008.04.16 17:34 MKIV  fmt: 2008.4.18  int: 
english/english

language       : language en is active
system         : cont-new loaded
(C:/tex/texmf-context/tex/context/base/cont-new.tex
systems         : beware: some patches loaded from cont-new.tex
(C:/tex/texmf-context/tex/context/base/cont-new.mkiv
lua            : used config path - C:/tex/texmf-
local/web2c/texmf.cnf;C:/tex/texmf-
context/web2c/texmf.cnf;C:/tex/texmf/web2c/texmf.cnf
lua            : used cache path - C:/tex/texmf-cache/luatex-
cache/context/71ddae2d1527093aac63e0e1aa139641
) (C:/tex/texmf-context/tex/context/base/cont-mtx.tex))
system         : cont-old loaded
(C:/tex/texmf-context/tex/context/base/cont-old.tex
loading        : Context Old Macros
)
system         : cont-fil loaded
(C:/tex/texmf-context/tex/context/base/cont-fil.tex
loading        : Context File Synonyms
)
system         : cont-sys loaded
(C:/tex/texmf-local/tex/context/user/cont-sys.tex (C:/tex/texmf-
context/tex/context/base/type-tmf.tex) (C:/tex/texmf-
context/tex/context/base/type-siz.tex) (C:/tex/texmf-
context/tex/context/base/type-otf.tex))
bodyfont       : 12pt rm is loaded
specials       : tex loaded
system         : mplibtest.top loaded
(./mplibtest.top
specials       : loading definition file tpd
(C:/tex/texmf-context/tex/context/base/spec-tpd.tex
specials       : loading definition file fdf
(C:/tex/texmf-context/tex/context/base/spec-fdf.tex (C:/tex/texmf-
context/tex/context/base/spec-fdf.mkiv))
specials       : fdf loaded
)
specials       : fdf loaded
) (./mplibtest.tuo) (./mplibtest.tuo)
systems        : begin file mplibtest at line 2
t={
 ["log"]="This is MetaPost, Version 1.003 (INIMP)  18 APR 2008 06:34 
(mpost.mp(plain.mp\
Preloading the plain mem file, version 0.99)",
 ["status"]=0,
 ["term"]="This is MetaPost, Version 1.003 (Cweb version 0.40) 
(INIMP)\
 (mpost.mp(plain.mp\
Preloading the plain mem file, version 0.99)",
}
nothing
t={
 ["log"]=" )\
Beginning to dump on file mpost.mem\
 (mem=mpost 8.4.18)\
at most 736 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
",
 ["status"]=0,
 ["term"]=" )\
Beginning to dump on file mpost.mem\
 (mem=mpost 8.4.18)\
at most 736 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
Transcript written on mpost.log.\
",
}
nothing
fonts          : resetting map file list
{C:/tex/texmf-context/fonts/map/pdftex/context/original-empty.map}
fonts          : using map file: original-base
{C:/tex/texmf-context/fonts/map/pdftex/context/original-base.map}
fonts          : using map file: lm-math
{C:/tex/texmf/fonts/map/dvips/lm/lm-math.map}
fonts          : using map file: lm-rm
{C:/tex/texmf/fonts/map/dvips/lm/lm-rm.map}
fonts          : using map file: original-ams-base
{C:/tex/texmf-context/fonts/map/pdftex/context/original-ams-base.map}
fonts          : using map file: original-ams-euler
{C:/tex/texmf-context/fonts/map/pdftex/context/original-ams-
euler.map}
fonts          : using map file: original-public-lm
{C:/tex/texmf-context/fonts/map/pdftex/context/original-public-
lm.map} [1.1]
systems        : end file mplibtest at line 38
 )<C:/tex/texmf/fonts/opentype/public/lm/lmroman12-regular.otf>
mkiv lua stats : used config path          - C:/tex/texmf-
local/web2c/texmf.cnf;C:/tex/texmf-
context/web2c/texmf.cnf;C:/tex/texmf/web2c/texmf.cnf
mkiv lua stats : used cache path           - C:/tex/texmf-
cache/luatex-cache/context/71ddae2d1527093aac63e0e1aa139641
mkiv lua stats : modules/dumps/instances   - 84/20/1
mkiv lua stats : input load time           - 0.031 seconds
mkiv lua stats : fonts load time           - 1.063 seconds
mkiv lua stats : xml load time             - 0.000 seconds, 
backreferences: 0, outer filtering time: 0.000
mkiv lua stats : mps conversion time       - 0.000 seconds
mkiv lua stats : node processing time      - 0.000 seconds (including 
kernel)
mkiv lua stats : kernel processing time    - 0.000 seconds
mkiv lua stats : attribute processing time - 0.016 seconds
mkiv lua stats : language load time        - 0.031 seconds, n=2
mkiv lua stats : graphics processing time  - 0.000 seconds, n=0 
(including tex)
mkiv lua stats : metapost processing time  - 0.000 seconds, loading: 
0.000 seconds, execution: 0.000 seconds, n: 0
mkiv lua stats : current memory usage      - 50679203 bytes
mkiv lua stats : cleaned up reserved nodes - 16 nodes, 8 lists of 100
mkiv lua stats : node memory usage         - 19 glue_spec, 2 dir
mkiv lua stats : loaded patterns           - en:en:pat:exc:2
mkiv lua stats : loaded fonts              - file:lmroman10-
bolditalic*default:otf file:lmroman10-italic*default:otf 
file:lmroman12-bold*default:otf file:lmroman12-italic*default:otf 
file:lmroman12-regular*default:otf file:lmroman7-bold*default:otf 
file:lmroman7-regular*default:otf file:lmroman9-bold*default:otf 
file:lmroman9-italic*default:otf file:lmroman9-regular*default:otf 
file:lmromancaps10-regular*default:otf file:lmromanslant10-
bold*default:otf file:lmromanslant10-regular*default:otf 
file:lmromanslant12-regular*default:otf file:lmromanslant9-
regular*default:otf lmex10:tfm lmmi12:tfm lmmi7:tfm lmmi9:tfm 
lmsy10:tfm lmsy7:tfm lmsy9:tfm msam10:tfm msam7:tfm msbm10:tfm 
msbm7:tfm rm-lmr12:tfm rm-lmr7:tfm rm-lmr9:tfm
mkiv lua stats : runtime                   - 1.922 seconds, 1 
processed pages, 1 shipped pages, 0.520 pages/second


LuaTools | running command: luatex --fmt="C:/tex/texmf-cache/luatex-
cache/context/71ddae2d1527093aac63e0e1aa139641/formats/cont-en" --
lua="C:/tex/texmf-cache/luatex-
cache/context/71ddae2d1527093aac63e0e1aa139641/formats/cont-en.luc" 
"mplibtest.tex" ""
LuaTools | 
LuaTools | runtime: 2.313 secondsTeXUtil | parsing file mplibtest.tui
TeXUtil | shortcuts : 0
TeXUtil | expansions: 0
TeXUtil | reductions: 0
TeXUtil | divisions : 0
TeXUtil | loaded files: 1
TeXUtil | temporary files: 0
TeXUtil | commands: 8
TeXUtil | programs: 0
TeXUtil | tuo file saved
TeXExec | renaming mplibtest.tua into mplibtest.tuc
TeXExec | runtime: 2.406

------------------------------------
 
> I tried the same with 'mpost'. This has the advantage that one has
> not to adapt 'plain.mp'.
> 
> But here too, there is no 'mpost.mem' and no 'mpost.log'.
> 
> I have included a test before and after mp:finish().
> 
> Can anybody with a minimal under windows run this example?
> -------------------------------
> \starttext
> % start low-level
> \startlua
> local function finder(name, mode, ftype)
>      if mode=="w" then
>          return name
>      else
>          return kpse.find_file(name,ftype)
>      end
> end
> mp = mplib.new ( {
>      hash_size = 100000,
>      main_memory = 2000000,
>      param_size = 100000,
>      find_file = finder,
>      ini_version = true
> } )
> if mp then
>      res = mp:execute("mpost")
>      tex.print("[" .. tostring(res.status) .. "]")
>      print(table.serialize(res))
>      if io.open("mpost.mem","r") then
>        print("found")
>      else
>        print("nothing")
>      end
>      res = mp:finish()
>      print(table.serialize(res))
>      if io.open("mpost.mem","r") then
>        print("found")
>      else
>        print("nothing")
>      end
> end
> \stoplua
> % stop low-level
> \stoptext
> -------------------------------
 
Grusz, Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Wolfgang Werners-Lucchini wrote:
> Hallo Taco,
> 
>>> Everything I read below says there should be a 'plain.mem'
>>> in the folder where you ran theat file in.  If there
>>> really really isn't, then my only advise to you is to buy
>>> a less thieving operating system, as it seems this one steals
>>> your files before you can even have an admiring look at them.
>> :-)
> 
> May be you are right that operating system steals files. We should do 
> something against that.
> 
> Lutz Haseloff has send me his test (he too sees no 'mpost.mem'):

When Hans and I tested this, it worked just fine. Does the high-level
context interface work for you at all, btw? I have no idea what is
going on, and I cannot test myself, so I am even more lost than you
are. MPlib firmly believes it has written a file:

   Beginning to dump on file mpost.mem
   (mem=mpost 8.4.18)
   at most 736 strings of total length 3629
   3326 memory locations dumped; current usage is 1021&2227
   501 symbolic tokens

There is nothing more I myself can do about it.

Best wishes,
Taco




___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Hi,

Wolfgang Werners-Lucchini wrote:
> 
> May be you are right that operating system steals files. We should do 
> something against that.

Akira found the cause .

>> \startlua
>> local function finder(name, mode, ftype)
>>      if mode=="w" then
>>          return name
>>      else
>>          return kpse.find_file(name,ftype)
>>      end
>> end

It turns out that currently (on windows only) the code above always
runs the "else" branch. So instead of returning a local file name,
it finds the pre-existing format inside the texmf tree. That filename
is then used for writing, and errors result.

Akira says that after a small change to the windows binaries,
all should work as (I) expected again, you just have to update
your binaries in a day or so.

Best wishes,
Taco
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Wolfgang Werners-Lucchini wrote:
> Hi Taco,
> 
>> I can remove that line, it is misleading. The content of the
>> log file is in <result>.log
> 
> What do you mean with <result>?

The res.log entry in the lua result table.
I had forgotten the variable name.

Best wishes,
Taco
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

Hi Taco,

> I can remove that line, it is misleading. The content of the
> log file is in <result>.log

What do you mean with <result>?

There is only ONE log file and that is tst10.log (the log file of the 
tst10.tex which runs the above code).

Wolfgang

___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Hi,

Wolfgang Werners-Lucchini wrote:
> 
> Example 1: my test file with your finder.
> --------------------------------------------------------------
> MPlib finder: mpost.mem -> 

So it was running the kpse.find_file instead of returning a local name,
and it is not found. There is a silent error here that I should make
explicit, but the real problem (as Akira noted) is that it was in
the "else" branch at all.

> Example 2: my test file with your finder and ("wb" not "w")
> --------------------------------------------------------------
> MPlib finder: mpost.mem -> mpost.mem

That is correct, here it will write to the local file mpost.mem

> mpost.mem gets written now but no mpost.log

I can remove that line, it is misleading. The content of the
log file is in <result>.log

Best wishes,
Taco


___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

Hallo Taco et al
> >>>> \startlua
> >>>> local function finder(name, mode, ftype)
> >>>>      if mode=="w" then
> >>>>          return name
> >>>>      else
> >>>>          return kpse.find_file(name,ftype)
> >>>>      end
> >>>> end
> > 
> > Jein!
> > 
> 
> Try this, a little more elaborate, version of finder:
> 
>    local function finder(name, mode, ftype)
>        local found
>        if mode=="w" then
>           found = name
>        else
>           found = kpse.find_file(name,ftype)
>        end
>        print("MPlib finder: " .. name .. " -> " .. found)
>        return found
>    end
> 
> maybe that will give a clue.

Example 1: my test file with your finder.
--------------------------------------------------------------
MPlib finder: mpost.mp -> d:/context/tex/texmf/metapost/base/mpost.mp
MPlib finder: mpost.map -> 
MPlib finder: plain.mp -> d:/context/tex/texmf/metapost/base/plain.mp
t={
 ["log"]="This is MetaPost, Version 1.003 (INIMP)  23 APR 2008 07:51 
(mpost.mp(plain.mp\
Preloading the plain mem file, version 0.99)",
 ["status"]=0,
 ["term"]="This is MetaPost, Version 1.003 (Cweb version 0.40) 
(INIMP)\
 (mpost.mp(plain.mp\
Preloading the plain mem file, version 0.99)",
}
MPlib finder: mpost.mem -> 
t={
 ["log"]=" )\
Beginning to dump on file mpost.mem\
 (mem=mpost 8.4.23)\
at most 736 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
",
 ["status"]=0,
 ["term"]=" )\
Beginning to dump on file mpost.mem\
 (mem=mpost 8.4.23)\
at most 736 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
Transcript written on mpost.log.\
",
}
--------------------------------------------------------------
found = ""
no mpost.mem, no mpost.log

Example 2: my test file with your finder and ("wb" not "w")
--------------------------------------------------------------
MPlib finder: mpost.mp -> d:/context/tex/texmf/metapost/base/mpost.mp
MPlib finder: mpost.map -> 
MPlib finder: plain.mp -> d:/context/tex/texmf/metapost/base/plain.mp
t={
 ["log"]="This is MetaPost, Version 1.003 (INIMP)  23 APR 2008 07:58 
(mpost.mp(plain.mp\
Preloading the plain mem file, version 0.99)",
 ["status"]=0,
 ["term"]="This is MetaPost, Version 1.003 (Cweb version 0.40) 
(INIMP)\
 (mpost.mp(plain.mp\
Preloading the plain mem file, version 0.99)",
}
MPlib finder: mpost.mem -> mpost.mem
t={
 ["log"]=" )\
Beginning to dump on file mpost.mem\
 (mem=mpost 8.4.23)\
at most 736 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
",
 ["status"]=0,
 ["term"]=" )\
Beginning to dump on file mpost.mem\
 (mem=mpost 8.4.23)\
at most 736 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
Transcript written on mpost.log.\
",
}
--------------------------------------------------------------
mpost.mem gets written now
but no mpost.log

grusz Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Wolfgang Werners-Lucchini wrote:
>>>> \startlua
>>>> local function finder(name, mode, ftype)
>>>>      if mode=="w" then
>>>>          return name
>>>>      else
>>>>          return kpse.find_file(name,ftype)
>>>>      end
>>>> end
> 
> Jein!
> 

Try this, a little more elaborate, version of finder:

   local function finder(name, mode, ftype)
       local found
       if mode=="w" then
          found = name
       else
          found = kpse.find_file(name,ftype)
       end
       print("MPlib finder: " .. name .. " -> " .. found)
       return found
   end

maybe that will give a clue.

Best wishes,
Taco
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Hans Hagen]

Wolfgang Werners-Lucchini wrote:
>>>> \startlua
>>>> local function finder(name, mode, ftype)
>>>>      if mode=="w" then
>>>>          return name
>>>>      else
>>>>          return kpse.find_file(name,ftype)
>>>>      end
>>>> end
> 
> Jein!
> 
> The only file in my tex tree which could play that roule is
> 
> cont-en-mpost.mem
> 
> in the cache
> 
> \tex\texmf-cache\luatex-
> cache\context\c80dc1fd5292ec817c6e82c295beaf1e\formats
> 
> this file causes from a metapost:process run
> and is not overwritten by my example.
> 
> So, there is not written any mpost.mem in the whole tree.

mkiv adds cont-en infront of the format name, in order to avoid clashes, 
also formats are only created once

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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

> >> \startlua
> >> local function finder(name, mode, ftype)
> >>      if mode=="w" then
> >>          return name
> >>      else
> >>          return kpse.find_file(name,ftype)
> >>      end
> >> end

Jein!

The only file in my tex tree which could play that roule is

cont-en-mpost.mem

in the cache

\tex\texmf-cache\luatex-
cache\context\c80dc1fd5292ec817c6e82c295beaf1e\formats

this file causes from a metapost:process run
and is not overwritten by my example.

So, there is not written any mpost.mem in the whole tree.

Gruß, Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

On 19 Apr 2008 at 8:58, ntg-context-request@ntg.nl wrote:

> >>> Everything I read below says there should be a 'plain.mem'
> >>> in the folder where you ran theat file in.  If there
> >>> really really isn't, then my only advise to you is to buy
> >>> a less thieving operating system, as it seems this one steals
> >>> your files before you can even have an admiring look at them.
> >> :-)
> > 
> > May be you are right that operating system steals files. We should
> do 
> > something against that.
> > 
> > Lutz Haseloff has send me his test (he too sees no 'mpost.mem'):
> 
Hallo Taco,

> When Hans and I tested this, it worked just fine.

Have you tested exactly my example on a windows minimal?

> Does the high-level
> context interface work for you at all, btw? 

The high-level interface seems to work.

> I have no idea what is
> going on, and I cannot test myself, so I am even more lost than
> you are. MPlib firmly believes it has written a file:
> 
>    Beginning to dump on file mpost.mem
>    (mem=mpost 8.4.18)
>    at most 736 strings of total length 3629
>    3326 memory locations dumped; current usage is 1021&2227
>    501 symbolic tokens
> 

Yes, I know this.

> There is nothing more I myself can do about it.

Do you use a sort of io-buffering in the mplib or a memory-file?
When is the file flushed or closed?

Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

On 16 Apr 2008 at 1:52, ntg-context-request@ntg.nl wrote:

Hallo,

> >>> (I have temporary appended 'dump;' to plain.mp)
> >> After the above, you should have plain.mem in the local
> directory.
> > 
> > No.
> > There is neither a 'plain.fmt' nor a 'plain.mem'!
> 
> Everything I read below says there should be a 'plain.mem'
> in the folder where you ran theat file in.  If there
> really really isn't, then my only advise to you is to buy
> a less thieving operating system, as it seems this one steals
> your files before you can even have an admiring look at them. :-)

I tried the same with 'mpost'. This has the advantage that one has 
not to adapt 'plain.mp'.

But here too, there is no 'mpost.mem' and no 'mpost.log'.

I have included a test before and after mp:finish().

Can anybody with a minimal under windows run this example?
-------------------------------
\starttext
% start low-level
\startlua
local function finder(name, mode, ftype)
     if mode=="w" then
         return name
     else
         return kpse.find_file(name,ftype)
     end
end
mp = mplib.new ( {
     hash_size = 100000,
     main_memory = 2000000,
     param_size = 100000,
     find_file = finder,
     ini_version = true
} )
if mp then
     res = mp:execute("mpost")
     tex.print("[" .. tostring(res.status) .. "]")
     print(table.serialize(res))
     if io.open("mpost.mem","r") then
       print("found")
     else
       print("nothing")
     end
     res = mp:finish()
     print(table.serialize(res))
     if io.open("mpost.mem","r") then
       print("found")
     else
       print("nothing")
     end
end
\stoplua
% stop low-level
\stoptext
-------------------------------

Gruß, Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Wolfgang Werners-Lucchini wrote:
> On 15 Apr 2008 at 13:31, ntg-context-request@ntg.nl wrote:
> 
> Hallo Taco,
> 
>>> (I have temporary appended 'dump;' to plain.mp)
>> After the above, you should have plain.mem in the local directory.
> 
> No.
> There is neither a 'plain.fmt' nor a 'plain.mem'!

Everything I read below says there should be a 'plain.mem'
in the folder where you ran theat file in.  If there
really really isn't, then my only advise to you is to buy
a less thieving operating system, as it seems this one steals
your files before you can even have an admiring look at them. :-)

Best wishes,
Taco




___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

On 15 Apr 2008 at 13:31, ntg-context-request@ntg.nl wrote:

Hallo Taco,

> > (I have temporary appended 'dump;' to plain.mp)
> 
> After the above, you should have plain.mem in the local directory.

No.
There is neither a 'plain.fmt' nor a 'plain.mem'!

I have searched in the local directory, where it should be.
It is not in 'D:\context\tex\texmf-mswin\web2c' where format-files 
usally exist.
It is not in the cache.

I run this:
-------------------------------------------------------
\enableregime[utf-8]
\starttext
% start low-level
\startlua
local function finder(name, mode, ftype)
     if mode=="w" then
         return name
     else
         return kpse.find_file(name,ftype)
     end
end
mp = mplib.new ( {
     hash_size = 100000,
     main_memory = 2000000,
     param_size = 100000,
     find_file = finder,
     ini_version = true
} )
if mp then
     res = mp:execute("plain")
     print(table.serialize(res))
     res = mp:finish()
     print(table.serialize(res))
end
\stoplua
% stop low-level
\stoptext
-------------------------------------------------------

with the following output:

-------------------------------------------------------
t={
 ["log"]="This is MetaPost, Version 1.003 (INIMP)  15 APR 2008 21:00 
(plain.mpPreloading the plain mem file, version 0.99",
 ["status"]=0,
 ["term"]="This is MetaPost, Version 1.003 (Cweb version 0.40) 
(INIMP)\
 (plain.mpPreloading the plain mem file, version 0.99",
}
t={
 ["log"]=" )\
Beginning to dump on file plain.mem\
 (mem=plain 8.4.15)\
at most 735 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
",
 ["status"]=0,
 ["term"]=" )\
Beginning to dump on file plain.mem\
 (mem=plain 8.4.15)\
at most 735 strings of total length 3629\
3326 memory locations dumped; current usage is 1021&2227\
501 symbolic tokens\
Transcript written on plain.log.\
",
}
-------------------------------------------------------

Can you see, what I am missing?

Wolfgang

___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Wolfgang Werners-Lucchini wrote:
>> if mp then
>>      res = mp:execute('plain')
>>      mp:finish()
>> end
> 
> this first step runs with res=0, but there is no 'plain.mem' dumped.

For the other readers: res itself can't really be "zero". It is either
a table, or nil. The actual return value is the status field in the
table, and that can vary from 0 (good run) to 3 (extremely bad run),
and you can end up with "nil" if you have invalid arguments.

> (I have temporary appended 'dump;' to plain.mp)

After the above, you should have plain.mem in the local directory.
You can try printing res.term or res.log or even
   print(table.serialize(res))
to check if what mp is doing.

> after that I produced 'plain.mem' executing
> 'texmfstart texexec --make plain'

I assume that will create a tex plain.fmt file. But even if it
does create a .mem file, you will not succeed unless you are using
"newmpost" from the mplib-alpha-0.40 distribution and the values
you sset up for hash_size, main_memory, and param_size in the loading
stage are identical to the values used by newmpost from texmf.cnf
during mem generation.

Best wishes, Taco
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Hans Hagen]

Wolfgang Werners-Lucchini wrote:
>
> Is there a find_file function necessary to find the mem-file given in 
> 'mem_name' or is such a function only necessary for file-names in 
> 'mp:execute'?

the find function is needed

in context you can use

metapost.process('formatname',datastream)

this will generate the format if needed and reuse it



-----------------------------------------------------------------
                                           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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

On 13 Apr 2008 at 13:31, ntg-context-request@ntg.nl wrote:

Hallo Taco,

thank you for your example.

> % start low-level
> \startlua
> local function finder(name, mode, ftype)
>      if mode=="w" then
>          return name
>      else
>          return kpse.find_file(name,ftype)
>      end
> end
> mp = mplib.new ( {
>      hash_size = 100000,
>      main_memory = 2000000,
>      param_size = 100000,
>      find_file = finder,
>      ini_version = true
> } )
> if mp then
>      res = mp:execute('plain')
>      mp:finish()
> end

this first step runs with res=0, but there is no 'plain.mem' dumped.
(I have temporary appended 'dump;' to plain.mp)
this first step runs with res=0 with mp:execute('mpost'), but no 
'mpost.mem'
the first step even runs with res=0 and mp:execute('\\plain; dump;'), 
but no 'plain.mem'

after that I produced 'plain.mem' executing
'texmfstart texexec --make plain'

> 
> mp = mplib.new ( {
>      hash_size = 100000,
>      main_memory = 2000000,
>      param_size = 100000,
>      find_file = finder,
> } )
> 
> if mp then
>      res = mp:execute(
> "\\beginfig(1) draw (0,0) .. (1,1) .. (2,1); endfig; bye;" )
>      tex.print("[" .. tostring(res.status) .. "]")
>      mp:finish()
> end
> \stoplua
> % stop low-level
> 

this second step returns res=3.

Is there a find_file function necessary to find the mem-file given in 
'mem_name' or is such a function only necessary for file-names in 
'mp:execute'?

Wolfgang

-- 
Musensturm-Verlag -- Postfach 1249 -- 36126 Gersfeld 
>>> http://www.musensturm.de

___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Wolfgang Werners-Lucchini wrote:
> On 12 Apr 2008 at 9:39, ntg-context-request@ntg.nl wrote:
> 
>>> \startlua
>>> mp = mplib.new ( {
>>>     hash_size = 100000,
>>>     main_memory = 2000000,
>>>     param_size = 100000,
>>> } )
>>>
>>> if mp then
>>>     res = mp:execute(
>>> "beginfig(1) draw (0,0) .. (1,1) .. (2,1); endfig; bye;" )
>>>     tex.print("[" .. tostring(res.status) .. "]")
>>>     mp:finish()
>>> end
>>> \stoplua
>> no format, so beginfig, draw etc are unknown
> 
> I thought 'plain.mem' is the default. But I see, there exists only 
> 'metafun.mem'.

If you want to "do the low-level thing", you have to read the
luatex manual carefully. MPlib is just like standalone metapost
in that it wants to load a mem file in non-ini mode, and that
file has to be generated before being used. Here is what you
wanted to do, using just the library core (I did cheat just a
little bit though, I added "dump;" at the end of my plain.mp):

% start low-level
\startlua
local function finder(name, mode, ftype)
     if mode=="w" then
         return name
     else
         return kpse.find_file(name,ftype)
     end
end
mp = mplib.new ( {
     hash_size = 100000,
     main_memory = 2000000,
     param_size = 100000,
     find_file = finder,
     ini_version = true
} )
if mp then
     res = mp:execute('plain')
     mp:finish()
end

mp = mplib.new ( {
     hash_size = 100000,
     main_memory = 2000000,
     param_size = 100000,
     find_file = finder,
} )

if mp then
     res = mp:execute("\\beginfig(1) draw (0,0) .. (1,1) .. (2,1); 
endfig; bye;" )
     tex.print("[" .. tostring(res.status) .. "]")
     mp:finish()
end
\stoplua
% stop low-level

If you just want to run plain metapost images inside of
a context document (instead of metafun), it is much easier
to use Hans' high-level API (once again, you need "dump;"
at the end of plain.mp):

\startlua
metapost.process(
   metapost.format("plain"),
   "beginfig(0); draw (0,0) .. (1,1) .. (2,1); endfig;")
\stoplua

This makes sure that all memory values are the same,
that the mem file is cached inbetween runs, removes the
need for "\\" and "bye;" etc.

Best wishes,
Taco
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Wolfgang Werners-Lucchini]

On 12 Apr 2008 at 9:39, ntg-context-request@ntg.nl wrote:

> > \startlua
> > mp = mplib.new ( {
> >     hash_size = 100000,
> >     main_memory = 2000000,
> >     param_size = 100000,
> > } )
> > 
> > if mp then
> >     res = mp:execute(
> > "beginfig(1) draw (0,0) .. (1,1) .. (2,1); endfig; bye;" )
> >     tex.print("[" .. tostring(res.status) .. "]")
> >     mp:finish()
> > end
> > \stoplua
> 
> no format, so beginfig, draw etc are unknown

I thought 'plain.mem' is the default. But I see, there exists only 
'metafun.mem'.

So I  wrote:
------------------------------------------------------
mp = mplib.new ( {
    hash_size = 100000,
    main_memory = 2000000,
    param_size = 100000,
    mem_name = "metafun.mem"
} )
------------------------------------------------------
and it get the same result

> metapost.process("metafun","some commands")
> 
> may work better
------------------------------------------------------
\startlua
mp = mplib.new ( {
    hash_size = 100000,
    main_memory = 2000000,
    param_size = 100000
} )

if mp then
    res = metapost.process("metafun","beginfig(1) draw (0,0) .. (1,1) 
.. (2,1); endfig; bye;")
    tex.print("[" .. tostring(res.status) .. "]")
    mp:finish()
end
\stoplua
------------------------------------------------------

results in :

------------------------------------------------------
mplib          : loading format: metafun.mp, name: 
d:/context/tex/texmf-cache/luatex-
cache/context/c80dc1fd5292ec817c6e82c295beaf1e/formats/cont-en-
metafun.mem
! Emergency stop.
\@@expanded ..... "]")
--     mp:finish()
-- end
}
                                                  
l.54 \stoplua
             
!  ==> Fatal error occurred, no output PDF file produced!
------------------------------------------------------

why does it load 'metafun.mp'?


after that I tried

------------------------------------------------------
\startlua
mp = mplib.new ( {
    hash_size = 100000,
    main_memory = 2000000,
    param_size = 100000,
    mem_name = "metafun.mem"
} )

if mp then
    res = metapost.process(mp,
         "beginfig(1) draw (0,0) .. (1,1) .. (2,1); endfig; bye;")
    tex.print("[" .. tostring(res.status) .. "]")
    mp:finish()
end
\stoplua
------------------------------------------------------

which gives the following error:

------------------------------------------------------
report >> error: This is MetaPost, Version 1.003 (Cweb version 0.40)

I can't find the PLAIN mem file!
------------------------------------------------------


What else should I check to find the error?

Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Hans Hagen]

Wolfgang Werners-Lucchini wrote:
> Hallo,
> 
> the following compiles ok, but gives me an status 3=fatal error.
> Can someone please point me to the error?
> 
> \startlua
> mp = mplib.new ( {
>     hash_size = 100000,
>     main_memory = 2000000,
>     param_size = 100000,
> } )
> 
> if mp then
>     res = mp:execute(
> "beginfig(1) draw (0,0) .. (1,1) .. (2,1); endfig; bye;" )
>     tex.print("[" .. tostring(res.status) .. "]")
>     mp:finish()
> end
> \stoplua

no format, so beginfig, draw etc are unknown

metapost.process("metafun","some commands")

may work better

-----------------------------------------------------------------
                                           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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

mplib

[Wolfgang Werners-Lucchini]

Hallo,

the following compiles ok, but gives me an status 3=fatal error.
Can someone please point me to the error?

\startlua
mp = mplib.new ( {
    hash_size = 100000,
    main_memory = 2000000,
    param_size = 100000,
} )

if mp then
    res = mp:execute(
"beginfig(1) draw (0,0) .. (1,1) .. (2,1); endfig; bye;" )
    tex.print("[" .. tostring(res.status) .. "]")
    mp:finish()
end
\stoplua

Wolfgang
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Mojca Miklavec]

On Sun, Mar 16, 2008 at 10:58 AM, zs <stryhal@sci.ujep.cz> wrote:
> On Sat, 15 Mar 2008 11:18:33 +0100
>  Hans Hagen <pragma@wxs.nl> wrote:
>
>  > btw, how difficult would it be to add a lua api to gnuplot, in which
>  > case we could communicate via lua tables
>  >
>  > Hans
>
>
>  btw: Some of you may not know about cairo library. (http://cairographics.org/)
>  It's versatile graphic library with many output targets(pdf,svg,png,...) and bindings to different programming languages (including lua!).
>  It can do almost the same things that metapost do.
>  Development version of gnulpot should be able to use cairo library for rendering too.

Cairo (with pango, that needs lots of tweaking to be able to build it,
I do not even dare dreaming about being able to build it on windows)
is able to generate PDFs in gnuplot, but not to input any TeX labels
yet, I'm affraid.

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://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[zs]

On Sat, 15 Mar 2008 11:18:33 +0100
Hans Hagen <pragma@wxs.nl> wrote:

> btw, how difficult would it be to add a lua api to gnuplot, in which 
> case we could communicate via lua tables
> 
> Hans


btw: Some of you may not know about cairo library. (http://cairographics.org/)
It's versatile graphic library with many output targets(pdf,svg,png,...) and bindings to different programming languages (including lua!).
It can do almost the same things that metapost do.
Development version of gnulpot should be able to use cairo library for rendering too.



  ZS
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Mojca Miklavec]

On Sat, Mar 15, 2008 at 11:18 AM, Hans Hagen wrote:
>
> Mojca Miklavec wrote:
>  > On Fri, Mar 14, 2008 at 6:51 PM, Aditya Mahajan wrote:
>  >> On Fri, 14 Mar 2008, Hans Hagen wrote:
>  >>
>  >>  > so, if you have specific wishes ... now is the time to let them know
>  >>
>  >>  Some questions (and hidden wishes)
>  >>
>  >>  Does this mean that text between metapost graphic and context can be
>  >>  really transparent? Currently \sometxt does not work with all macros,
>  >>  (like an old feature request by Mojca to have two optional arguments for
>  >>  setting the font in the gnuplot module). Will mplib mean that the metapost
>  >>  code can place any tex box at the desired location?
>  >
>  > Now that you mention it: I still need to adapt the gnuplot module to
>  > mkiv, but I'm a bit afraid of asking for help. (The most important
>  > thing would be to get rid of that stupid catcode trickery inside
>  > \startGNUPLOTscript ... \stopGNUPLOTscript that always tends to fail
>  > when one needs it, and to have one-to-one conversion, so that %,#, $,
>  > .... will have no special meaning.) Then, it would probably be a nice
>  > benchmark to discover bugs in the library :)
>  >
>  > For example, demos from this page (I'm not saying that they're too
>  > useful since 100x100 is too low resolution anyway):
>  >      http://gnuplot.sourceforge.net/demo_4.3/pm3d.html
>  > currently all fail because of the "out-of-memory" problem (10.000
>  > times "fill unitsquare scaled ... shifted ... withcolor ..."), but
>  > this might be a ConTeXt problem as well (the text inside
>  > \startMPgraphic ... \stopMPgraphic probably needs to be stored
>  > somewhere in TeX, even if there's no need for that).
>
>  let's discuss this a few months from now when i have more code in place
>
>  btw, how difficult would it be to add a lua api to gnuplot, in which
>  case we could communicate via lua tables

Peter Hedwig has already done some work on it:
    http://peter.affenbande.org/gnuplot/

What his patch does: one calls gnuplot normally, and then, when you say
   set term lua dashed fontsize 15
"dashed fontsize 15" is parsed by lua. Then, gnuplot does its work,
and calls functions:
   set_linestyle(3)
   set_color(...)
   draw_line(...)
What Peter did was a mapping from C to lua, so the actual code that
does "draw_line" is actually implemented in lua and can easily be
changed and/or adapted without recompiling gnuplot.

He now "converts" those function calls into TikZ Code, but that could
easily be adapted into anything.

So: output has already been implemented (and would "only" need to be
adapted), while input might need some tweaking. I'm sometimes using a
rather simple C++ library which opens gnuplot and pipes "set terminal
...", "plot ..." commands to gnuplot, so one can pass a C table to
gnuplot. I could take a look at how it's done there. How do you
imagine passing lua tables to gnuplot?

Mojca

PS: no need to say that even though his terminal is much more popular
(it's the only decent LaTeX terminal I know) than the one for ConTeXt,
I have seen zero discussion on the gnuplot mailing list about any
intentions to integrate that code into gnuplot core.
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Hans Hagen]

Mojca Miklavec wrote:
> On Fri, Mar 14, 2008 at 6:51 PM, Aditya Mahajan wrote:
>> On Fri, 14 Mar 2008, Hans Hagen wrote:
>>
>>  > so, if you have specific wishes ... now is the time to let them know
>>
>>  Some questions (and hidden wishes)
>>
>>  Does this mean that text between metapost graphic and context can be
>>  really transparent? Currently \sometxt does not work with all macros,
>>  (like an old feature request by Mojca to have two optional arguments for
>>  setting the font in the gnuplot module). Will mplib mean that the metapost
>>  code can place any tex box at the desired location?
> 
> Now that you mention it: I still need to adapt the gnuplot module to
> mkiv, but I'm a bit afraid of asking for help. (The most important
> thing would be to get rid of that stupid catcode trickery inside
> \startGNUPLOTscript ... \stopGNUPLOTscript that always tends to fail
> when one needs it, and to have one-to-one conversion, so that %,#, $,
> .... will have no special meaning.) Then, it would probably be a nice
> benchmark to discover bugs in the library :)
> 
> For example, demos from this page (I'm not saying that they're too
> useful since 100x100 is too low resolution anyway):
>      http://gnuplot.sourceforge.net/demo_4.3/pm3d.html
> currently all fail because of the "out-of-memory" problem (10.000
> times "fill unitsquare scaled ... shifted ... withcolor ..."), but
> this might be a ConTeXt problem as well (the text inside
> \startMPgraphic ... \stopMPgraphic probably needs to be stored
> somewhere in TeX, even if there's no need for that).

let's discuss this a few months from now when i have more code in place

btw, how difficult would it be to add a lua api to gnuplot, in which 
case we could communicate via lua tables

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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Aditya Mahajan wrote:
>                                        Will mplib mean that the metapost 
> code can place any tex box at the desired location?

Yes. The aim is to have that supported in the next luatex beta.


Best wishes,
Taco
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Mojca Miklavec]

On Fri, Mar 14, 2008 at 6:51 PM, Aditya Mahajan wrote:
> On Fri, 14 Mar 2008, Hans Hagen wrote:
>
>  > so, if you have specific wishes ... now is the time to let them know
>
>  Some questions (and hidden wishes)
>
>  Does this mean that text between metapost graphic and context can be
>  really transparent? Currently \sometxt does not work with all macros,
>  (like an old feature request by Mojca to have two optional arguments for
>  setting the font in the gnuplot module). Will mplib mean that the metapost
>  code can place any tex box at the desired location?

Now that you mention it: I still need to adapt the gnuplot module to
mkiv, but I'm a bit afraid of asking for help. (The most important
thing would be to get rid of that stupid catcode trickery inside
\startGNUPLOTscript ... \stopGNUPLOTscript that always tends to fail
when one needs it, and to have one-to-one conversion, so that %,#, $,
... will have no special meaning.) Then, it would probably be a nice
benchmark to discover bugs in the library :)

For example, demos from this page (I'm not saying that they're too
useful since 100x100 is too low resolution anyway):
     http://gnuplot.sourceforge.net/demo_4.3/pm3d.html
currently all fail because of the "out-of-memory" problem (10.000
times "fill unitsquare scaled ... shifted ... withcolor ..."), but
this might be a ConTeXt problem as well (the text inside
\startMPgraphic ... \stopMPgraphic probably needs to be stored
somewhere in TeX, even if there's no need for that).

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://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Taco Hoekwater]

Hans Hagen wrote:
> Santy, Michael wrote:
>> Its entirely possible that I'm missing something, but I was merely
>> inquiring about running the same timing tests that you did with
>> mplib, but instead using the existing MKII and MKIV image inclusion
>> code.  How much of a speedup over the existing code does the mplib
>> integration buy us for this benchmark?
> 
> well, processing 15K mp graphics either runtime or delayed would take
>  way much time (no fun timing)

IIRC, beginning of the week we had a speedup of 50% against oldfashioned
mkiv (mptopdf-in-lua) with a batched Metapost run, which is alread some 
25% faster than batched Metapost in mkii mode (mptopdf-in-tex). And that
was before we started optimizing, we are at least twice as fast now as
we were then.

And in the old system, batched metapost was a whole lot faster than
runtime Metapost.

Take a look at it this way: if you have a document stuffed full of
backgrounds and borders and decorations, you may have a dozen unique
decorations per page. On a 200-page book, the total runtime used by
the new MPlib-based graphics system is then still less than a second
(well, if you were using Hans' machine).

Best wishes,
Taco




___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Hans Hagen]

Santy, Michael wrote:
> Its entirely possible that I'm missing something, but I was merely inquiring about running the same timing tests that you did with mplib, but instead using the existing MKII and MKIV image inclusion code.  How much of a speedup over the existing code does the mplib integration buy us for this benchmark?

well, processing 15K mp graphics either runtime or delayed would take 
way much time (no fun timing)

it all depends on how you use mp graphics, but for most purposes mp 
processing time goes down to nearly zero

btw, mkiv mp inclusion code is faster than mkii code

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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Santy, Michael]

[-- Attachment #1.1: Type: text/plain, Size: 1883 bytes --]

Its entirely possible that I'm missing something, but I was merely inquiring about running the same timing tests that you did with mplib, but instead using the existing MKII and MKIV image inclusion code.  How much of a speedup over the existing code does the mplib integration buy us for this benchmark?


-----Original Message-----
From: ntg-context-bounces@ntg.nl on behalf of Hans Hagen
Sent: Fri 3/14/2008 12:46 PM
To: mailing list for ConTeXt users
Subject: Re: [NTG-context] mplib
 
Santy, Michael wrote:
> Hans,
> 
> Sounds pretty impressive.  As a point of reference, do you have timing 
> data for the existing MKII and MKIV image processing code?

you mean a difference in speed? it depends on how complex the search is, 
but in general the mkiv code is faster and more robust there and has 
more potential for plugins; also mkiv does runtime conversion if needed; 
of course inclusion itself is not faster while (eventually) manipulation 
will be

-----------------------------------------------------------------
                                           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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


[-- Attachment #1.2: Type: text/html, Size: 3205 bytes --]

[-- Attachment #2: Type: text/plain, Size: 487 bytes --]

___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Aditya Mahajan]

On Fri, 14 Mar 2008, Hans Hagen wrote:

> Hi,
>
> as some of you may know, there is an mplib project ..
>
> last week taco and spent quite some time on exploring the integration in
> luatex (and therefore mkiv)
>
> experiments with loadiing the format, processing graphics and conversion
> to pdf show a throughput of less than 0.001 seconds per graphic; a usual
> we did much timing and although experimental, the code is already pretty
> okay, just to give an idea:
>
> 	mkiv lua stats : metapost processing time  - 6.834 seconds (loading:
> 0.014 seconds, execution: 1.474 seconds, n: 15000)
>
> indeed, that's 15K graphics in 7 seconds.

That is really impressive.

> so, the next couple of months i'll start providing an adapted mp
> handling mechanisms. among the possible options are
>
> - extensions based on pre/postscripts (instead of specials)
> - multiple mp engines (\startuseMPgraphic[metafun]{name} and such)
>
> so, if you have specific wishes ... now is the time to let them know

Some questions (and hidden wishes)

Does this mean that text between metapost graphic and context can be 
really transparent? Currently \sometxt does not work with all macros, 
(like an old feature request by Mojca to have two optional arguments for 
setting the font in the gnuplot module). Will mplib mean that the metapost 
code can place any tex box at the desired location?

One thing which is really shaky in the current implementation is page 
anchors. That is, marking something in a paragraph and then using the page 
background to draw lines between different elements. Will such things be 
easier to do and work correctly with display math? (I want to use these 
effects in presentations, but have never managed to get a satisfactory 
solution that works in display math).

I am assuming that there will be hooks so that packages like tikz to move 
to a mplib backend.

Thanks,

Aditya
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Hans Hagen]

Santy, Michael wrote:
> Hans,
> 
> Sounds pretty impressive.  As a point of reference, do you have timing 
> data for the existing MKII and MKIV image processing code?

you mean a difference in speed? it depends on how complex the search is, 
but in general the mkiv code is faster and more robust there and has 
more potential for plugins; also mkiv does runtime conversion if needed; 
of course inclusion itself is not faster while (eventually) manipulation 
will be

-----------------------------------------------------------------
                                           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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Santy, Michael]

[-- Attachment #1.1: Type: text/plain, Size: 2182 bytes --]

Hans,

Sounds pretty impressive.  As a point of reference, do you have timing 
data for the existing MKII and MKIV image processing code?

Cheers,
Mike


-----Original Message-----
From: ntg-context-bounces@ntg.nl on behalf of Hans Hagen
Sent: Fri 3/14/2008 12:21 PM
To: mailing list for ConTeXt users
Subject: [NTG-context] mplib
 
Hi,

as some of you may know, there is an mplib project ..

last week taco and spent quite some time on exploring the integration in 
luatex (and therefore mkiv)

experiments with loadiing the format, processing graphics and conversion 
to pdf show a throughput of less than 0.001 seconds per graphic; a usual 
we did much timing and although experimental, the code is already pretty 
okay, just to give an idea:

	mkiv lua stats : metapost processing time  - 6.834 seconds (loading: 
0.014 seconds, execution: 1.474 seconds, n: 15000)

indeed, that's 15K graphics in 7 seconds.

so, the next couple of months i'll start providing an adapted mp 
handling mechanisms. among the possible options are

- extensions based on pre/postscripts (instead of specials)
- multiple mp engines (\startuseMPgraphic[metafun]{name} and such)

so, if you have specific wishes ... now is the time to let them know


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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


[-- Attachment #1.2: Type: text/html, Size: 3621 bytes --]

[-- Attachment #2: Type: text/plain, Size: 487 bytes --]

___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

mplib

[Hans Hagen]

Hi,

as some of you may know, there is an mplib project ..

last week taco and spent quite some time on exploring the integration in 
luatex (and therefore mkiv)

experiments with loadiing the format, processing graphics and conversion 
to pdf show a throughput of less than 0.001 seconds per graphic; a usual 
we did much timing and although experimental, the code is already pretty 
okay, just to give an idea:

	mkiv lua stats : metapost processing time  - 6.834 seconds (loading: 
0.014 seconds, execution: 1.474 seconds, n: 15000)

indeed, that's 15K graphics in 7 seconds.

so, the next couple of months i'll start providing an adapted mp 
handling mechanisms. among the possible options are

- extensions based on pre/postscripts (instead of specials)
- multiple mp engines (\startuseMPgraphic[metafun]{name} and such)

so, if you have specific wishes ... now is the time to let them know


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
-----------------------------------------------------------------
___________________________________________________________________________________
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  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: mplib

[Sanjoy Mahajan]

> It also means that some of you will have to do some pretty hefty
> testing of both machineries at the end of the year since context
> mkiv will be used as testbed.

I'll happy write lots of testing scripts.  It'll be an unholy mixture
of bash, make, python, scheme, and (once I learn them) lua and ruby.

-Sanjoy

`Not all those who wander are lost.' (J.R.R. Tolkien)

Re: mplib

[Karl Berry]

    Soon there will also be the option to support specific projects (tug 
    project page).

It is possible to contribute specifically to TUG's development fund,
which is TUG's pigeonhole for dev projects, at
https://www.tug.org/donate.html.  Any donations to that now will end up
going to luatex/mplib.

Donations are, of course, greatly appreciated :).  As Hans said, new
members for TUG (http://tug.org/join.html) or any other user group
(http://tug.org/usergroups.html) are also greatly appreciated.

Cheers,
Karl

Re: mplib

[Hans Hagen]

Hi,

In addition to previous mails about the mplib project we now have 
funding for the programming part of the mplib project  (budgetted 12KEURO)

- dante : 6K
- tug : 1.5K
- tug india : 1K
- ntg : 2K
- cstug : 1K
- gust: will fund a sub-project (metatype1 completion)

TUG indicated that next year there could be additional funding but it 
looks like .5K is enough then, which means that the project funcing is 
secured.

This project is especially nice because it permits us to have a tight 
luatex/mp pair. LuaTeX (opened up, configurable, tunable pdftex), 
TeXGyre (8 open type fonts, finaly with math etc), and MPLib (integrated 
graphical engine) help us boost tex into the  future and without funding 
the programming and font conversion effort, i fear it would have taken 
many more years.

It also means that some of you will have to do some pretty hefty testing 
of both machineries at the end of the year since context mkiv will be 
used as testbed.

It may be clear that projects like this put quite a financial burden on 
user groups (there is already substantial continuous funding of texgyre 
by the mentioned user groups) and luatex is also sponsored (by oriental 
tex project as well as tug). Projects like this put a dent in the 
financial reserves of lugs.

So ... if you're not yet a member of a local user group or tug ... 
consider joining since it's the user groups that keep the good work done 
...

Soon there will also be the option to support specific projects (tug 
project page).

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
-----------------------------------------------------------------

mplib

[Hans Hagen]

Hoi,

cstug 1000 euro, gust conversie van metatype1 naar mp++

dus nu nog 500 van tug lospeuteren

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
-----------------------------------------------------------------