Info about creating modules for beginners.
Hello, masters ... I would like create my first context mkiv module. Can someone please steer me what the first study and where to find some good advice for beginners? Appropriate would be also a simple module, which was easy to read and find out how to do everything correctly. Thanx Jaroslav
On 23-9-2010 6:35, Jaroslav Hajtmar wrote:
Hello, masters ... I would like create my first context mkiv module. Can someone please steer me what the first study and where to find some good advice for beginners? Appropriate would be also a simple module, which was easy to read and find out how to do everything correctly.
just take a look at wolfgang's ... they use the latest mkiv abstractions (module namespaces etc, something that Wolfgang, Aditya and I are working on). 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 -----------------------------------------------------------------
Am 23.09.2010 um 22:32 schrieb Hans Hagen:
On 23-9-2010 6:35, Jaroslav Hajtmar wrote:
Hello, masters ... I would like create my first context mkiv module. Can someone please steer me what the first study and where to find some good advice for beginners? Appropriate would be also a simple module, which was easy to read and find out how to do everything correctly.
just take a look at wolfgang's ... they use the latest mkiv abstractions (module namespaces etc, something that Wolfgang, Aditya and I are working on).
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder. is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files? steffen
Am 23.09.2010 um 22:42 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree. Wolfgang
Am 23.09.2010 um 22:47 schrieb Wolfgang Schuster:
Am 23.09.2010 um 22:42 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ... For example I have in a project's folder a project_test file with these line: \environment Style_Test \usemodule[p-my-test] Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs. The module is never found. What is missing? Steffen
On 23-9-2010 11:08, Steffen Wolfrum wrote:
Am 23.09.2010 um 22:47 schrieb Wolfgang Schuster:
Am 23.09.2010 um 22:42 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
\usemodule[p][my-test] ----------------------------------------------------------------- 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 -----------------------------------------------------------------
Am 23.09.2010 um 23:08 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
What is missing?
Can you give more information or a example, you don’t mention which file you process and what’s loaded in them. Wolfgang
On Thu, 23 Sep 2010, Wolfgang Schuster wrote:
Can you give more information or a example, you don’t mention which file you process and what’s loaded in them.
Consider a simple setup: root-dir/ p-module.tex env-file.tex project-file.tex subdir/ component-file1.tex component-file2.tex Suppose the component-file1 file says \environment env-file while component-file2 says \usemodule[p][module] If I run everything from the root directory, then both component1 and component2 compile fine. On the other hand if I run everything from the subdir, then component1 compiles fine, but component2 will fail to load the module. Basically, module search does not look in parent directories. Aditya
On Thu, 23 Sep 2010, Wolfgang Schuster wrote:
Am 23.09.2010 um 23:21 schrieb Aditya Mahajan:
Basically, module search does not look in parent directories.
But you can use a construct like
\doifmodeelse{component} {\usemodule[module]} {\usemodule[../module]}
And if you are two directories deep for some components and one dir deep for others. \environment \component etc use a heirarchical search. I think that \usemodule should also use that. Aditya
Am 23.09.2010 um 23:42 schrieb Aditya Mahajan:
On Thu, 23 Sep 2010, Wolfgang Schuster wrote:
Am 23.09.2010 um 23:21 schrieb Aditya Mahajan:
Basically, module search does not look in parent directories.
But you can use a construct like
\doifmodeelse{component} {\usemodule[module]} {\usemodule[../module]}
And if you are two directories deep for some components and one dir deep for others.
\environment \component etc use a heirarchical search. I think that \usemodule should also use that.
And what’s with pictures, \setupexternalfigure[directory=...] has the same problem as \usemodule? Wolfgang
On Thu, 23 Sep 2010, Wolfgang Schuster wrote:
And if you are two directories deep for some components and one dir deep for others.
\environment \component etc use a heirarchical search. I think that \usemodule should also use that.
And what’s with pictures, \setupexternalfigure[directory=...] has the same problem as \usemodule?
I agree. That is why I have started running everything from the root directory. So the fact that \environment etc look at parent directories is useless to me in large projects. Aditya
On Thu, Sep 23 2010, Aditya Mahajan wrote:
\environment \component etc use a heirarchical search. I think that \usemodule should also use that.
You can consider, that \environment \component etc. are for a project (environment for project-settings, something like a style-file), and modules for project-independent code, that should be put in some texmf-tree (TEXMFHOME for example). If you think, that modules and environments should behave the same way, I don't know, why there should be 2 concepts then instead of 1. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
Am 23.09.2010 um 23:15 schrieb Wolfgang Schuster:
Am 23.09.2010 um 23:08 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
What is missing?
Can you give more information or a example, you don’t mention which file you process and what’s loaded in them.
It's like this (mapping context's recommended project structure): project-dir/ p-module.tex env-file.tex project-file.tex product-file.tex subdir/ component-file1.tex component-file2.tex The project-file file says \environment Style_Test \usemodule[p][module] Now I run from the subdir eg. component-file1.tex: the environment was loaded the module was not. Steffen
Hello, Thanks very much everyone for your advice, I am certainly now a better starting position ... I will try to learn something ... Maybe it sounds silly but at the very beginning I was surprised by the type of construction: \def\????ld{@@@@ld} \def\????ls{@@@@ls} Where do I read about it more? You have not it easy with me, right? :-) But luckily I learn fairly quickly :-)... One more thanx - I appreciate your willingness... Jarda Dne 23.9.2010 23:30, Steffen Wolfrum napsal(a):
Am 23.09.2010 um 23:15 schrieb Wolfgang Schuster:
Am 23.09.2010 um 23:08 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
What is missing?
Can you give more information or a example, you don’t mention which file you process and what’s loaded in them.
It's like this (mapping context's recommended project structure):
project-dir/ p-module.tex env-file.tex project-file.tex product-file.tex subdir/ component-file1.tex component-file2.tex
The project-file file says \environment Style_Test \usemodule[p][module]
Now I run from the subdir eg. component-file1.tex: the environment was loaded the module was not.
Steffen ___________________________________________________________________________________ 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 ___________________________________________________________________________________
Am 23.09.2010 um 23:36 schrieb Jaroslav Hajtmar:
Hello, Thanks very much everyone for your advice, I am certainly now a better starting position ... I will try to learn something ...
Maybe it sounds silly but at the very beginning I was surprised by the type of construction:
\def\????ld{@@@@ld} \def\????ls{@@@@ls}
Where do I read about it more?
These are namespaces but you don't need these constructs anymore in mkiv because there is now a \definenamespace command which takes care of this. You need a namespace when you use a setup command with key-value-pairs to have unique names for the keys. BTW: The two letter namespaces are reserved for Hams and me but you’re free to use longer ones (we should collect them on a page at the wiki). Wolfgang
On 2010-09-23 <23:43:15>, Wolfgang Schuster wrote:
These are namespaces but you don't need these constructs anymore in mkiv because there is now a \definenamespace command which takes care of this.
Hi Wolfgang, following your fancybreak module I put together dummy module. ··8<····························································· \startmodule[test] \unprotect \startinterface all \setinterfacevariable {TEST} {TEST} \stopinterface \definenamespace[testns] [ type=module, name=TEST, command=yes, setup=list, ] \unexpanded\def\typetest{% \TESTparameter{teststyle} This is a test.% } \defineTEST[\v!TEST] \setupTEST[ teststyle=\sc ] \protect \endinput ··8<····························································· When called like: \usemodule[test] \starttext \typetest \stoptext it works as expected. Could you please explain what these other parameters do: style=yes, parent=fb Also, what other values would the parameter ‘setup’ accept besides ‘list’?
BTW: The two letter namespaces are reserved for Hams and me but you’re free to use longer ones (we should collect them on a page at the wiki).
What information should go into this list? In my dummy, the namespace ‘testns’ declares the \defineXX and \setupXX commands, where XX=name and name=TEST. Thus if I am not mistaken, namespace clashes might occur both a) among the \????…, and b) among the \setup…|\define… commands. A table on the wiki will need at least three columns: +-----------+------------+---------------------+ | Namespace | Setup | Reserved for module | +===========+============+=====================+ | fb | fancybreak | Fancy Break | +-----------+------------+---------------------+ | … | … | … | Is this OK so far? Anything critical I missed? Philipp -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Am 25.09.2010 um 17:07 schrieb Philipp Gesang:
Could you please explain what these other parameters do: style=yes, parent=fb Also, what other values would the parameter ‘setup’ accept besides ‘list’?
I’ll come back to this later.
BTW: The two letter namespaces are reserved for Hams and me but you’re free to use longer ones (we should collect them on a page at the wiki).
What information should go into this list? In my dummy, the namespace ‘testns’ declares the \defineXX and \setupXX commands, where XX=name and name=TEST. Thus if I am not mistaken, namespace clashes might occur both a) among the \????…, and b) among the \setup…|\define… commands.
- namespace (the first argument of \definenamespace) - the value for the “name” key - the name of the module (e.g. t-fancybreak) - a short description (e.g. fancybreak is a module to insert thought breaks) +-----------+------------+--------------+-------------+ | Namespace | Name | File | Description | +-----------+-----------------------------------------+ | fb | fancybreak | t-fancybreak | … | +-----------+------------+--------------+-------------+ | … | … | … | … | Wolfgang
Hi all! On 2010-09-25 <19:35:31>, Wolfgang Schuster wrote:
Am 25.09.2010 um 17:07 schrieb Philipp Gesang:
Could you please explain what these other parameters do: style=yes, parent=fb Also, what other values would the parameter ‘setup’ accept besides ‘list’?
I’ll come back to this later.
Thanks in advance! For now there’s question marks galore on the wiki page.
+-----------+------------+--------------+-------------+ | Namespace | Name | File | Description | +-----------+-----------------------------------------+ | fb | fancybreak | t-fancybreak | … | +-----------+------------+--------------+-------------+ | … | … | … | … |
Hmm, i was thinking with a proper hyperlink the description would be superfluous. But as there’s plenty of horizontal space in the table that is not a problem. (After all, it’s not wikipedia; can’t hurt to have some real information.) I think it has to be up to the maintainer of module to register it on the wiki. If the module is orphaned, a regular user should be fine as well. The wiki page is written with mkiv in mind only. Now, should the module list extend to mkii style modules as well or should we wait for the modules to be adapted by the maintainers? An extra column indicating the version could do as well. Regards, Philipp -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Am 23.09.2010 um 23:15 schrieb Wolfgang Schuster:
Am 23.09.2010 um 23:08 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
What is missing?
Can you give more information or a example, you don’t mention which file you process and what’s loaded in them.
Attached you may find a nice minimal example: the module should trigger french date, the environment shoud trigger german date when chap_1.tex is set. The second works, the first fails: french is not loaded ... the date is set english ;o( Steffen
On Thu, 23 Sep 2010, Steffen Wolfrum wrote:
Am 23.09.2010 um 22:47 schrieb Wolfgang Schuster:
Am 23.09.2010 um 22:42 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
What is missing?
Module lookups do not search in the parent or grand parent directories. One alternative is to always run files from the top project folder: context dir/dir/file Aditya
Am 23.09.2010 um 23:17 schrieb Aditya Mahajan:
On Thu, 23 Sep 2010, Steffen Wolfrum wrote:
Am 23.09.2010 um 22:47 schrieb Wolfgang Schuster:
Am 23.09.2010 um 22:42 schrieb Steffen Wolfrum:
btw: modules are used to be stored eg. in ~/context/tex/texmf-local/tex/context/third/ folder.
is is also possible to keep/find them not in texfm tree but in a projects folder? or do I have to use for this purpose environment files?
You can put modules in your project folder and these are always loaded before the files in the tex tree.
Sounds good, but ...
For example I have in a project's folder a project_test file with these line:
\environment Style_Test \usemodule[p-my-test]
Both files (Style_Test.tex and p-my-test.tex are stored next to project_test.tex in the project's folder). The environment file is found without problems ... even when I change the file's name between two runs.
The module is never found.
What is missing?
Module lookups do not search in the parent or grand parent directories.
I rather suspected that. Steffen
Am 23.09.2010 um 22:32 schrieb Hans Hagen:
On 23-9-2010 6:35, Jaroslav Hajtmar wrote:
Hello, masters ... I would like create my first context mkiv module. Can someone please steer me what the first study and where to find some good advice for beginners? Appropriate would be also a simple module, which was easy to read and find out how to do everything correctly.
just take a look at wolfgang's ... they use the latest mkiv abstractions (module namespaces etc, something that Wolfgang, Aditya and I are working on).
fancybreak [1] is at the moment the only module with all these things but the other will follow [1] http://bitbucket.org/wolfs/fancybreak/src/tip/files/ Wolfgang
On Thu, 23 Sep 2010, Wolfgang Schuster wrote:
Am 23.09.2010 um 22:32 schrieb Hans Hagen:
On 23-9-2010 6:35, Jaroslav Hajtmar wrote:
Hello, masters ... I would like create my first context mkiv module. Can someone please steer me what the first study and where to find some good advice for beginners? Appropriate would be also a simple module, which was easy to read and find out how to do everything correctly.
just take a look at wolfgang's ... they use the latest mkiv abstractions (module namespaces etc, something that Wolfgang, Aditya and I are working on).
fancybreak [1] is at the moment the only module with all these things but the other will follow
Does it make sense to copy the definition of mult-aux.mkiv to mkii? Everything other than \definenamespace should work in both mkii and mkiv. That way, I can use it in modules that target both mkii and mkiv. BTW, I am still amused how Hans manages to write such code. If you replace \expandafter with \@EA, this code will have more # than other characters combined :) \unexpanded\def\doinstallparameterhandler#1#2#3#4#5#6#7% {\def#3##1{\csname#4{#1#2}{##1}\endcsname}% \def#4##1##2{\ifcsname##1##2\endcsname##1##2\else\expandafter#5\csname##1\s!parent\endcsname{##2}\fi}% \def#5##1##2{\ifx##1\relax\s!empty\else#4{##1}{##2}\fi}% \def#6##1##2{\csname#4{#1##1}{##2}\endcsname}% \def#7##1{\detokenize\expandafter\expandafter\expandafter{\csname#1##1\endcsname}}} Aditya
On 26-9-2010 2:02, Aditya Mahajan wrote:
Does it make sense to copy the definition of mult-aux.mkiv to mkii? Everything other than \definenamespace should work in both mkii and mkiv. That way, I can use it in modules that target both mkii and mkiv.
if you consider it useful ... keep in mind that it uses the new inheritance model of mkiv (less predefined hash entries at the cost of a bit more runtime but also more powerful) ... adding it would not mean that I'd adapt all old mkii code to it
BTW, I am still amused how Hans manages to write such code. If you replace \expandafter with \@EA, this code will have more # than other characters combined :)
grep for "#\@ea" or "#\expandafter" and you will see some real horror 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 -----------------------------------------------------------------
On Sep 26, 2010, at 7:24 AM, Hans Hagen
On 26-9-2010 2:02, Aditya Mahajan wrote:
Does it make sense to copy the definition of mult-aux.mkiv to mkii? Everything other than \definenamespace should work in both mkii and mkiv. That way, I can use it in modules that target both mkii and mkiv.
if you consider it useful ... keep in mind that it uses the new inheritance model of mkiv (less predefined hash entries at the cost of a bit more runtime but also more powerful) ... adding it would not mean that I'd adapt all old mkii code to it
I understand. I am not asking any change in the mkii code. Just want the macros for the inheritance code (without the definenamespace macro that uses lua) to be available in mkii so that I can use the new inheritance model with mkii in my modules. (I use it anyways, but with boilerplate macros borrowed from Wolfgang. All I want to do is reduce that boilerplate) Aditya
Am 26.09.2010 um 02:02 schrieb Aditya Mahajan:
Does it make sense to copy the definition of mult-aux.mkiv to mkii? Everything other than \definenamespace should work in both mkii and mkiv. That way, I can use it in modules that target both mkii and mkiv.
Parameter handling is different in mkii and mkiv and it’s not such a problem to write different code for each of them. For fancybreak i used different mechanism for each of them and i think you should do this as well with your filter module. Wolfgang
On Sep 26, 2010, at 10:06 AM, Wolfgang Schuster
Am 26.09.2010 um 02:02 schrieb Aditya Mahajan:
Does it make sense to copy the definition of mult-aux.mkiv to mkii? Everything other than \definenamespace should work in both mkii and mkiv. That way, I can use it in modules that target both mkii and mkiv.
Parameter handling is different in mkii and mkiv and it’s not such a problem to write different code for each of them.
But right now, I use a unified parameter handling for both mkii and mkiv.
For fancybreak i used different mechanism for each of them and i think you should do this as well with your filter module.
You are essentially maintaining two modules, one for mkii and one for mkiv. At least for the filter module, I would like to maintain only one module. The current version has manual parameter handling. Some of which can be automated using \installparameterhandler etc. That is why I am asking part of mult-aux.mkiv to be copied to mkii. Aditya
On Sun, Sep 26 2010, Aditya Mahajan wrote:
You are essentially maintaining two modules, one for mkii and one for mkiv. At least for the filter module, I would like to maintain only one module. The current version has manual parameter handling. Some of which can be automated using \installparameterhandler etc. That is why I am asking part of mult-aux.mkiv to be copied to mkii.
Hello, It would be interesting, to know how many people actually use mkii. Perhaps a survey on the wiki...? Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
participants (7)
-
Aditya Mahajan -
Hans Hagen -
Jaroslav Hajtmar -
Peter Münster -
Philipp Gesang -
Steffen Wolfrum -
Wolfgang Schuster