* Modules @ 2002-01-17 21:57 Marco Kuhlmann 2002-01-18 18:30 ` Modules Giuseppe Bilotta ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Marco Kuhlmann @ 2002-01-17 21:57 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 2219 bytes --] Today I got into trouble. In summer, I have started what I thought would be my transition from LaTeX to ConTeXt. It all seemed so obvious: ConTeXt is richer in features, has much cleaner code, and there's a lot of innovation. And if I had a problem, or even a feature request, I could just write to you all. Today my view of things got challenged. I must admit that the cause (though not the causing) for my doubts is my disappointment with the math module on the one hand, and the pressure that I put onto myself to convert my society's macro collections into ConTeXt on the other. However, here they are: One of the strengths of LaTeX is the number of add-on packages available for it. Of course, this also is one of its weaknesses: there is a lot of overhead, some packages do not interact well with each other, there are a lot of developers with different styles, etc. When I prepared my first book using ConTeXt, I was amazed to see that everything got so simple. However, I wonder if not ConTeXt needs some of that LaTeX feeling. In LaTeX, when you miss a feature, you know that there is a package out there that implements it. In ConTeXt, you ask Hans et al. Why are there so few modules? It may of course be due to the relatively small number of users. However, one important reason in my opinion is the lack of a well-defined module interface. How should modules be designed? Is there a standard library of functions that they could or should use? If I wrote a new module, how would I distribute it (for LaTeX, I would use CTAN)? What I propose it that we should think about going public. ConTeXt has so much to offer, it should become more widely used. A promising way to achieve this is to get more and more people involved in enhancing and documenting it. That does not say, of course, that base ConTeXt could and should not remain in the hands of PRAGMA. But an active community of developers working on extensions to the core is a good thing. And if it is well organised, it does not have to threaten the integrity of the system as a whole. What do you think? Marco -- Marco Kuhlmann http://www.ps.uni-sb.de/~kuhlmann/ [-- Attachment #2: Type: application/pgp-signature, Size: 248 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-17 21:57 Modules Marco Kuhlmann @ 2002-01-18 18:30 ` Giuseppe Bilotta 2002-01-19 23:20 ` Modules Hans Hagen 2002-01-19 18:07 ` Modules Berend de Boer 2002-01-20 20:05 ` Modules Hans Hagen 2 siblings, 1 reply; 16+ messages in thread From: Giuseppe Bilotta @ 2002-01-18 18:30 UTC (permalink / raw) Cc: ntg-context Thursday, January 17, 2002 Marco Kuhlmann wrote: MK> However, I wonder if not ConTeXt needs some of that LaTeX MK> feeling. In LaTeX, when you miss a feature, you know that there MK> is a package out there that implements it. In ConTeXt, you ask MK> Hans et al. Why are there so few modules? MK> It may of course be due to the relatively small number of MK> users. I think this is the main reason. MK> However, one important reason in my opinion is the lack MK> of a well-defined module interface. How should modules be MK> designed? Is there a standard library of functions that they MK> could or should use? I use pre-existent core and add-on modules to get the ideas for mine. Much of my knowledge of ConTeXt internal comes from studying the sources (of course, if Hans used English instead of Dutch, it would ease my work a lot ;-> but he's working along this path). MK> If I wrote a new module, how would I MK> distribute it (for LaTeX, I would use CTAN)? I suppose you could put it on CTAN as well. Maybe CTAN should have a /third-party/<contributor name> set of directories under the context branch. And of course you could ask Hans to host it. MK> What I propose it that we should think about going public. MK> ConTeXt has so much to offer, it should become more widely MK> used. A promising way to achieve this is to get more and more MK> people involved in enhancing and documenting it. How would you propose to do this? I've seen some new people posting about ConTeXt in the comp.text.tex newsgroup, but most ConTeXt question are put here (which sort of excludes us from the rest of the TeX community). Maybe Hans and the other experts could monitor those newsgroup, filtering out all messages which don't contain ConTeXt in the subject. Yet for ConTeXt to become widely used it would need to be at least on par with LaTeX, which it is currently not (e.g. I have to stick to LaTeX when doing heavy mathematics): when people would have to choose between ConTeXt and LaTeX they would go for the one which would present them less problems. ConTeXt has some very strong points, but they may not be the ones seeked by the users. MK> That does not MK> say, of course, that base ConTeXt could and should not remain MK> in the hands of PRAGMA. But an active community of developers MK> working on extensions to the core is a good thing. And if it is MK> well organised, it does not have to threaten the integrity of MK> the system as a whole. There are two things I don't like about the LaTeX packages: (1) their clashing with each other: this usually happens when two packages change the same LaTeX internal (LaTeX internals often don't offer hooks to the developers, which is pretty strange IMO considering how many LaTeX 'extenders' are there). We can prevent this in ConTeXt by requiring that no public module hacks any core command: if someone needs to extend a core command, he should ask Hans to provide a hook for the extensions. (2) different packages achieving the same result in different ways: this is harder to deal with because the LaTeX situation comes from the fact that different people have different ideas on what should be achieved and why. We should then require that if an existing module with the same functionality is already provided, no new module should be implemented: if someone desires to change something, (s)he would provide a patch to the original module. Or something of the sort. Of course this would only hold for "public" modules. Another thing developers would need is a module interface to TeXUtil: when a ConTeXt module requires some particular postprocessing, it should provide a Perl module to be loaded by TeXUtil. Extensions to TeXUtil should be "registered" so that the .tui file can contain hooks to modules in the form x <id> <data> where x stands for extension and <id> is a code registered by a module. TeXUtil would then call whatever appropriate routine is defined in the module hooking on extension <id> and pass <data> as the parameters. This is needed for example by a module of mine (x-desc), but could be needed by the bibliography module if we want to get rid of the bibtex executable (we could reimplement bibtex in Perl in a module called m-bib.pl so that when someone uses Taco's m-bib.tex module TeXUtil would also load the Perl bib module to deal with the bibliography data.) -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-18 18:30 ` Modules Giuseppe Bilotta @ 2002-01-19 23:20 ` Hans Hagen 2002-01-21 10:13 ` Modules Taco Hoekwater 0 siblings, 1 reply; 16+ messages in thread From: Hans Hagen @ 2002-01-19 23:20 UTC (permalink / raw) Cc: Marco Kuhlmann, ntg-context At 07:30 PM 1/18/2002 +0100, Giuseppe Bilotta wrote: >Thursday, January 17, 2002 Marco Kuhlmann wrote: > >MK> However, I wonder if not ConTeXt needs some of that LaTeX >MK> feeling. In LaTeX, when you miss a feature, you know that there >MK> is a package out there that implements it. In ConTeXt, you ask >MK> Hans et al. Why are there so few modules? > >MK> It may of course be due to the relatively small number of >MK> users. > >I think this is the main reason. much of the functionality built in latex styles is available in the context core so there is less need for modules >MK> However, one important reason in my opinion is the lack >MK> of a well-defined module interface. How should modules be >MK> designed? Is there a standard library of functions that they >MK> could or should use? > >I use pre-existent core and add-on modules to get the ideas for >mine. Much of my knowledge of ConTeXt internal comes from studying >the sources (of course, if Hans used English instead of Dutch, it >would ease my work a lot ;-> but he's working along this path). as long as you use a proper namespace in you local macros ... also, you can use the *documented* low level macros in syst-*.tex and supp-*.tex >MK> If I wrote a new module, how would I >MK> distribute it (for LaTeX, I would use CTAN)? > >I suppose you could put it on CTAN as well. Maybe CTAN should have >a /third-party/<contributor name> set of directories under the >context branch. And of course you could ask Hans to host it. /third/... with ... being something meaningful also, the modules should have t-* names, no m-* or else hosting is no problem, >MK> What I propose it that we should think about going public. >MK> ConTeXt has so much to offer, it should become more widely >MK> used. A promising way to achieve this is to get more and more >MK> people involved in enhancing and documenting it. > >How would you propose to do this? I've seen some new people >posting about ConTeXt in the comp.text.tex newsgroup, but most >ConTeXt question are put here (which sort of excludes us from the >rest of the TeX community). Maybe Hans and the other experts could >monitor those newsgroup, filtering out all messages which don't >contain ConTeXt in the subject. there is the everlasting mail list problem: beginners versus experienced users now, with respect to comp.tex.whatever, i purposely am not on that list (i don't want the overhead, don't want to be dragged into too many discussions, etc). I leave it upto other members of the context list to support those lists. and ... filtering is not my strongest point >Yet for ConTeXt to become widely used it would need to be at least >on par with LaTeX, which it is currently not (e.g. I have to stick >to LaTeX when doing heavy mathematics): when people would have to choose >between ConTeXt and LaTeX they would go for the one which would >present them less problems. ConTeXt has some very strong points, >but they may not be the ones seeked by the users. hm, i see no problem with using multiple packages along each other -) you may expect more math in future versions >MK> That does not >MK> say, of course, that base ConTeXt could and should not remain >MK> in the hands of PRAGMA. But an active community of developers >MK> working on extensions to the core is a good thing. And if it is >MK> well organised, it does not have to threaten the integrity of >MK> the system as a whole. > >There are two things I don't like about the LaTeX packages: > >(1) their clashing with each other: this usually happens when two >packages change the same LaTeX internal (LaTeX internals often >don't offer hooks to the developers, which is pretty strange IMO >considering how many LaTeX 'extenders' are there). > >We can prevent this in ConTeXt by requiring that no public module >hacks any core command: if someone needs to extend a core command, >he should ask Hans to provide a hook for the extensions. right, normally i do my best to provide those hooks asap [and while upgrading modules, i add more] on my agenda is a reimplementation of some modules, after which the context core should become relatively stable; we could of course follow a ghostscript approach, with two versions etc etc >(2) different packages achieving the same result in different >ways: this is harder to deal with because the LaTeX situation >comes from the fact that different people have different ideas on >what should be achieved and why. > >We should then require that if an existing module with the same >functionality is already provided, no new module should be >implemented: if someone desires to change something, (s)he would >provide a patch to the original module. Or something of the sort. what i have in mind is a plug in model, as with the (rather beta) otr modules, in that case (given a defined interface) users can pop in own code, overload functionality etc. In that case there can be different flavors as well as an official kernel >Of course this would only hold for "public" modules. > >Another thing developers would need is a module interface to >TeXUtil: when a ConTeXt module requires some particular >postprocessing, it should provide a Perl module to be loaded by >TeXUtil. i know -) and hav esome ideas on that -) -) >Extensions to TeXUtil should be "registered" so that the .tui file >can contain hooks to modules in the form > >x <id> <data> it maybe that texexec will control all of this Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- fall-back web server: www.pragma-pod.nl ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-19 23:20 ` Modules Hans Hagen @ 2002-01-21 10:13 ` Taco Hoekwater 2002-01-21 14:31 ` Re[2]: Modules Giuseppe Bilotta ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Taco Hoekwater @ 2002-01-21 10:13 UTC (permalink / raw) Cc: bourbaki, mk, ntg-context On Sun, 20 Jan 2002 00:20:37 +0100 "Hans Hagen" <pragma@wxs.nl> wrote: > >I use pre-existent core and add-on modules to get the ideas for > >mine. Much of my knowledge of ConTeXt internal comes from studying > >the sources (of course, if Hans used English instead of Dutch, it > >would ease my work a lot ;-> but he's working along this path). Same for me. Just reading the source is a good idea, and using something like 'grep' or 'ctags' helps a lot. > also, you can use the *documented* low level macros in syst-*.tex and > supp-*.tex ... and the predefined key/value names in mult-con.tex/mult-com.tex > also, the modules should have t-* names, no m-* or else or else what? ;) This functionality is already in ConTeXt, Hans? > now, with respect to comp.tex.whatever, i purposely am not on that list (i > don't want the overhead, don't want to be dragged into too many > discussions, etc). I leave it upto other members of the context list to > support those lists. Same for me. I already have too much to read as it is. However, I could set up a public forum for ConTeXt support if there are people interested. It would solve some problems with separation of beginners/experts/programmers. OTOH, it would be HTTP based and therefore less accessible than a mailing list. What do you guys think? > >Another thing developers would need is a module interface to > >TeXUtil: when a ConTeXt module requires some particular > >postprocessing, it should provide a Perl module to be loaded by > >TeXUtil. > > > it maybe that texexec will control all of this Not sure about that, extensions usually don't need texexec but texutil. Usually, you want to put some extra info in the tui file. It makes more sense to do this from texutil directly. -- groeten, Taco ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[2]: Modules 2002-01-21 10:13 ` Modules Taco Hoekwater @ 2002-01-21 14:31 ` Giuseppe Bilotta 2002-01-21 18:07 ` Berend de Boer 2002-01-21 14:47 ` Modules Hans Hagen 2002-01-22 11:03 ` Modules Eckhart Guthöhrlein 2 siblings, 1 reply; 16+ messages in thread From: Giuseppe Bilotta @ 2002-01-21 14:31 UTC (permalink / raw) Cc: ntg-context Monday, January 21, 2002 Taco Hoekwater wrote: >> >I use pre-existent core and add-on modules to get the ideas for >> >mine. Much of my knowledge of ConTeXt internal comes from studying >> >the sources (of course, if Hans used English instead of Dutch, it >> >would ease my work a lot ;-> but he's working along this path). TH> Same for me. Just reading the source is a good idea, and using TH> something like 'grep' or 'ctags' helps a lot. Yeah, and being Dutch helps even more ;-) >> also, the modules should have t-* names, no m-* or else TH> or else what? ;) TH> This functionality is already in ConTeXt, Hans? It is indeed because the modules I use have the t- prefix. TH> Same for me. I already have too much to read as it is. However, TH> I could set up a public forum for ConTeXt support if there are TH> people interested. There is not much request for ConTeXt help on comp.text.tex; rather than creating a new forum, you could simply follow the newsgroup and filter out all non-pertinent posts (that is, most of them ;->) >> >Another thing developers would need is a module interface to >> >TeXUtil: when a ConTeXt module requires some particular >> >postprocessing, it should provide a Perl module to be loaded by >> >TeXUtil. >> >> it maybe that texexec will control all of this TH> Not sure about that, extensions usually don't need texexec TH> but texutil. Usually, you want to put some extra info in the tui TH> file. It makes more sense to do this from texutil directly. This is precisely my view of it. Hans, you could get an idea of what is needed by giving a look to my xdesc module (and the relative, patched, texutil) -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Re[2]: Modules 2002-01-21 14:31 ` Re[2]: Modules Giuseppe Bilotta @ 2002-01-21 18:07 ` Berend de Boer 2002-01-22 9:38 ` Re[4]: Modules Giuseppe Bilotta 0 siblings, 1 reply; 16+ messages in thread From: Berend de Boer @ 2002-01-21 18:07 UTC (permalink / raw) Cc: Taco Hoekwater, ntg-context Giuseppe Bilotta <bourbaki@bigfoot.com> writes: > TH> Same for me. Just reading the source is a good idea, and using > TH> something like 'grep' or 'ctags' helps a lot. > > Yeah, and being Dutch helps even more ;-) Well, no one is stopping you :-)) -- Groetjes, Berend. (-: ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[4]: Modules 2002-01-21 18:07 ` Berend de Boer @ 2002-01-22 9:38 ` Giuseppe Bilotta 0 siblings, 0 replies; 16+ messages in thread From: Giuseppe Bilotta @ 2002-01-22 9:38 UTC (permalink / raw) Cc: ntg-context Monday, January 21, 2002 Berend de Boer wrote: BdB> Giuseppe Bilotta <bourbaki@bigfoot.com> writes: >> TH> Same for me. Just reading the source is a good idea, and using >> TH> something like 'grep' or 'ctags' helps a lot. >> >> Yeah, and being Dutch helps even more ;-) BdB> Well, no one is stopping you :-)) Heck, true! Now if I met a nice Dutch girl willing to teach me the, uhm, language ... ;-) -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-21 10:13 ` Modules Taco Hoekwater 2002-01-21 14:31 ` Re[2]: Modules Giuseppe Bilotta @ 2002-01-21 14:47 ` Hans Hagen 2002-01-22 9:10 ` Modules Taco Hoekwater 2002-01-22 11:03 ` Modules Eckhart Guthöhrlein 2 siblings, 1 reply; 16+ messages in thread From: Hans Hagen @ 2002-01-21 14:47 UTC (permalink / raw) Cc: bourbaki, mk, ntg-context At 11:13 AM 1/21/2002 +0100, Taco Hoekwater wrote: > > also, the modules should have t-* names, no m-* or else > >or else what? ;) x-* for xml stuff, s-* for styles, and p-* for pragma private stuff >This functionality is already in ConTeXt, Hans? right > > now, with respect to comp.tex.whatever, i purposely am not on that list (i > > don't want the overhead, don't want to be dragged into too many > > discussions, etc). I leave it upto other members of the context list to > > support those lists. > >Same for me. I already have too much to read as it is. However, >I could set up a public forum for ConTeXt support if there are >people interested. It would solve some problems with separation >of beginners/experts/programmers. OTOH, it would be HTTP based and >therefore less accessible than a mailing list. > >What do you guys think? we can also ask jules (ntg list manager) for possibilities (actually, what is a forum?) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- fall-back web server: www.pragma-pod.nl ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-21 14:47 ` Modules Hans Hagen @ 2002-01-22 9:10 ` Taco Hoekwater 0 siblings, 0 replies; 16+ messages in thread From: Taco Hoekwater @ 2002-01-22 9:10 UTC (permalink / raw) Cc: ntg-context On Mon, 21 Jan 2002 15:47:22 +0100 "Hans Hagen" <pragma@wxs.nl> wrote: > At 11:13 AM 1/21/2002 +0100, Taco Hoekwater wrote: > > >Same for me. I already have too much to read as it is. However, > >I could set up a public forum for ConTeXt support if there are > >people interested. It would solve some problems with separation > >of beginners/experts/programmers. OTOH, it would be HTTP based and > >therefore less accessible than a mailing list. > > > >What do you guys think? > > we can also ask jules (ntg list manager) for possibilities (actually, what > is a forum?) This is an example of a forum: http://www.chatalicious.nl It is in dutch and this one is actually my wife's hobby, but it does explain the principle. -- groeten, Taco ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-21 10:13 ` Modules Taco Hoekwater 2002-01-21 14:31 ` Re[2]: Modules Giuseppe Bilotta 2002-01-21 14:47 ` Modules Hans Hagen @ 2002-01-22 11:03 ` Eckhart Guthöhrlein 2 siblings, 0 replies; 16+ messages in thread From: Eckhart Guthöhrlein @ 2002-01-22 11:03 UTC (permalink / raw) Cc: Hans Hagen, bourbaki, mk, ntg-context Taco Hoekwater wrote: > > Same for me. I already have too much to read as it is. However, > I could set up a public forum for ConTeXt support if there are > people interested. It would solve some problems with separation > of beginners/experts/programmers. OTOH, it would be HTTP based and > therefore less accessible than a mailing list. > > What do you guys think? > I think that context support via this list is excellent and that there is no need for additional support channels. Personally, I prefer mailing lists and newsgroups and dislike forums. Concerning the separation: I don't know if this is necessary or desirable. I assume that the programmers on this list do communicate additionally in some other ways. The advantage of combining the user levels is obvious: Simple questions can be answered by simple users. On the other hand, trickier questions will find their way to the experts. As far as I know, Hans is interested in having a user interface accessible and understandable to non-experts. So he may very well be interested in watching the problems arising when those simple users actually try to use the system. Furthermore, I understand that time (for most of you/us) is not sufficient to follow even more discussions from sources like comp.text.tex. Most questions in the newsgroups will be answered by someone, and/or users will be directed to this list. Eckhart ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-17 21:57 Modules Marco Kuhlmann 2002-01-18 18:30 ` Modules Giuseppe Bilotta @ 2002-01-19 18:07 ` Berend de Boer 2002-01-19 18:17 ` Modules Marco Kuhlmann 2002-01-20 21:57 ` Modules Hans Hagen 2002-01-20 20:05 ` Modules Hans Hagen 2 siblings, 2 replies; 16+ messages in thread From: Berend de Boer @ 2002-01-19 18:07 UTC (permalink / raw) Cc: ConTeXt ML Marco Kuhlmann <mk@mcqm.net> writes: > users. However, one important reason in my opinion is the lack > of a well-defined module interface. How should modules be > designed? Is there a standard library of functions that they > could or should use? If I wrote a new module, how would I > distribute it (for LaTeX, I would use CTAN)? 1. What is a well-defined module interface? You have \usemodule. A module is just any ConTeXt file for now. 2. You can use any ConTeXt code, why should a module be limited? 3. Distribution mechanism isn't there, but I'm sure Hans is quite willing to put up links on his ConTeXt page to 3rd party stuff. Perhaps a good idea, what do you think Hans? -- Groetjes, Berend. (-: ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-19 18:07 ` Modules Berend de Boer @ 2002-01-19 18:17 ` Marco Kuhlmann 2002-01-20 16:03 ` Re[2]: Modules Giuseppe Bilotta 2002-01-20 22:04 ` Modules Hans Hagen 2002-01-20 21:57 ` Modules Hans Hagen 1 sibling, 2 replies; 16+ messages in thread From: Marco Kuhlmann @ 2002-01-19 18:17 UTC (permalink / raw) * Berend de Boer <berend@pobox.com> (2002-01-19 19:07:18 +0100): > 1. What is a well-defined module interface? You have \usemodule. A > module is just any ConTeXt file for now. Exactly. But what about - module parameters - standard \setup keywords - namespaces - usage of standard library macros > 2. You can use any ConTeXt code, why should a module be limited? For portability reasons, for example. If there were some kind of standard library, then one would rather want to use that instead of self-hacked things, because it will still work and the sizes of the modules will be smaller. Of course, in general, you can do whatever you want. This is merely a question of maintenance and system integrity -- which LaTeX lacks, for example. > 3. Distribution mechanism isn't there, but I'm sure Hans is quite > willing to put up links on his ConTeXt page to 3rd party > stuff. Perhaps a good idea, what do you think Hans? It certainly would be. However, it should also be on CTAN. And Giuseppe's comments on things like TeXUtil hooks etc. are worth considering, in my opinion. Marco ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[2]: Modules 2002-01-19 18:17 ` Modules Marco Kuhlmann @ 2002-01-20 16:03 ` Giuseppe Bilotta 2002-01-20 22:04 ` Modules Hans Hagen 1 sibling, 0 replies; 16+ messages in thread From: Giuseppe Bilotta @ 2002-01-20 16:03 UTC (permalink / raw) Cc: ntg-context Saturday, January 19, 2002 Marco Kuhlmann wrote: MK> * Berend de Boer <berend@pobox.com> (2002-01-19 19:07:18 +0100): >> 1. What is a well-defined module interface? You have \usemodule. A >> module is just any ConTeXt file for now. MK> Exactly. But what about MK> - module parameters ConTeXt is extremely parameter driven: just have a look at how parameters are parsed by ConTeXt core code and use the same on your module: define an appropriate \setupwhatever relative to your function. MK> - standard \setup keywords Have a look at mult-con.tex MK> - namespaces I don't know. I suppose this means automatic namespaces; prefixing internal variables with the module name would ensure uniqueness. MK> - usage of standard library macros I'm not sure I follow this. What exactly do you mean by this? >> 2. You can use any ConTeXt code, why should a module be limited? MK> For portability reasons, for example. If there were some kind MK> of standard library, then one would rather want to use that MK> instead of self-hacked things, because it will still work and MK> the sizes of the modules will be smaller. Of course, in MK> general, you can do whatever you want. This is merely a MK> question of maintenance and system integrity -- which LaTeX MK> lacks, for example. But there are lots of "tools" available from ConTeXt internals: just have a look at the syst-* modules. >> 3. Distribution mechanism isn't there, but I'm sure Hans is quite >> willing to put up links on his ConTeXt page to 3rd party >> stuff. Perhaps a good idea, what do you think Hans? MK> It certainly would be. However, it should also be on CTAN. And MK> Giuseppe's comments on things like TeXUtil hooks etc. are worth MK> considering, in my opinion. IIRC Hans already he wanted to set up an "other contributions" in the ConTeXt site (I'd have to search the old posts ...) And of course I do indeed think Giuseppe's comments are worth considering ;-) -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-19 18:17 ` Modules Marco Kuhlmann 2002-01-20 16:03 ` Re[2]: Modules Giuseppe Bilotta @ 2002-01-20 22:04 ` Hans Hagen 1 sibling, 0 replies; 16+ messages in thread From: Hans Hagen @ 2002-01-20 22:04 UTC (permalink / raw) Cc: ConTeXt ML At 06:17 PM 1/19/2002 +0000, Marco Kuhlmann wrote: >* Berend de Boer <berend@pobox.com> (2002-01-19 19:07:18 +0100): > > > 1. What is a well-defined module interface? You have \usemodule. A > > module is just any ConTeXt file for now. > >Exactly. But what about > > - module parameters > - standard \setup keywords > - namespaces > - usage of standard library macros - command names - documentation i think that we should set up some kind of registration for this; i can also imagine a validation process, i.e. some people testing / reading the code in order to identify conflicts in names or potential usage of lib macros > > 2. You can use any ConTeXt code, why should a module be limited? > >For portability reasons, for example. If there were some kind >of standard library, then one would rather want to use that >instead of self-hacked things, because it will still work and >the sizes of the modules will be smaller. Of course, in >general, you can do whatever you want. This is merely a >question of maintenance and system integrity -- which LaTeX >lacks, for example. btw, i can imagine that package developers meets occasionally [next eurotex is a nice occasion, nice place too, not that far from de btw] > > 3. Distribution mechanism isn't there, but I'm sure Hans is quite > > willing to put up links on his ConTeXt page to 3rd party > > stuff. Perhaps a good idea, what do you think Hans? > >It certainly would be. However, it should also be on CTAN. And >Giuseppe's comments on things like TeXUtil hooks etc. are worth >considering, in my opinion. sure (and bg know how to put pressure on me), those hooks will be provided, but not as quick hack -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- fall-back web server: www.pragma-pod.nl ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-19 18:07 ` Modules Berend de Boer 2002-01-19 18:17 ` Modules Marco Kuhlmann @ 2002-01-20 21:57 ` Hans Hagen 1 sibling, 0 replies; 16+ messages in thread From: Hans Hagen @ 2002-01-20 21:57 UTC (permalink / raw) Cc: Marco Kuhlmann, ConTeXt ML At 07:07 PM 1/19/2002 +0100, Berend de Boer wrote: >3. Distribution mechanism isn't there, but I'm sure Hans is quite > willing to put up links on his ConTeXt page to 3rd party > stuff. Perhaps a good idea, what do you think Hans? no problem, hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- fall-back web server: www.pragma-pod.nl ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Modules 2002-01-17 21:57 Modules Marco Kuhlmann 2002-01-18 18:30 ` Modules Giuseppe Bilotta 2002-01-19 18:07 ` Modules Berend de Boer @ 2002-01-20 20:05 ` Hans Hagen 2 siblings, 0 replies; 16+ messages in thread From: Hans Hagen @ 2002-01-20 20:05 UTC (permalink / raw) Cc: ConTeXt ML At 06:57 AM 1/18/2002 +0000, Marco Kuhlmann wrote: >What I propose it that we should think about going public. eh ... it *is* public >ConTeXt has so much to offer, it should become more widely >used. A promising way to achieve this is to get more and more >people involved in enhancing and documenting it. That does not >say, of course, that base ConTeXt could and should not remain >in the hands of PRAGMA. But an active community of developers >working on extensions to the core is a good thing. And if it is >well organised, it does not have to threaten the integrity of >the system as a whole. because at pragma we depend on this system this is a tricky thing to do; i already changed the policy by making code public faster that we used to do, which troubles me because i hate to maintain unstable code. when something new is cooked up (currently some new things are being worked on), the process is rougly as follows: 1 program an experimental framework 2 use it in a project, experiment with features 3 redo the whole thing (mostly) from scratch 4 write a manual and in the process rewrite again now, esp stage 4 takes quite some time, but is also the stage where the interfacing (and hooks) becomes stable. Involving more people in stage 1-3 (currently only a few people are involved in these steps; participants can be customers, people on this list, others) would slow me down so much that it would limit my free time even more. In the process i clean up core code; once this is done (and documented) other development processes can be considered. In the end, given enough hooks into the kernel, i can imagine multiple solutions showing up for the same typo problem, either or not written by me or others. The main thing here is to guard the interface, i.e. control the naming of commands and key/values. > What do you think? ^^^ i suppose you mean me -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- fall-back web server: www.pragma-pod.nl ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-01-22 11:03 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-17 21:57 Modules Marco Kuhlmann 2002-01-18 18:30 ` Modules Giuseppe Bilotta 2002-01-19 23:20 ` Modules Hans Hagen 2002-01-21 10:13 ` Modules Taco Hoekwater 2002-01-21 14:31 ` Re[2]: Modules Giuseppe Bilotta 2002-01-21 18:07 ` Berend de Boer 2002-01-22 9:38 ` Re[4]: Modules Giuseppe Bilotta 2002-01-21 14:47 ` Modules Hans Hagen 2002-01-22 9:10 ` Modules Taco Hoekwater 2002-01-22 11:03 ` Modules Eckhart Guthöhrlein 2002-01-19 18:07 ` Modules Berend de Boer 2002-01-19 18:17 ` Modules Marco Kuhlmann 2002-01-20 16:03 ` Re[2]: Modules Giuseppe Bilotta 2002-01-20 22:04 ` Modules Hans Hagen 2002-01-20 21:57 ` Modules Hans Hagen 2002-01-20 20:05 ` Modules Hans Hagen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).