modules

modules

[luigi scarso]

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

New version of modules .

http://groups.foundry.supelec.fr/modules/

-- 
luigi

[-- Attachment #1.2: Type: text/html, Size: 192 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
___________________________________________________________________________________

modules

[Hans Hagen]

Hi,

In order to be able to generate new zips i'd like the modules in the 
wiki to be tds compliant as soon as possible.

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

Re: modules

[Nikolai Weibull]

On 4/4/06, Hans Hagen <pragma@wxs.nl> wrote:

> In order to be able to generate new zips i'd like the modules in the
> wiki to be tds compliant as soon as possible.

I"ve kept this mail starred since I first saw it and haven't put any
thought into what you're actually asking about here.  Now, however,
I'd really like to know what /TDS compliant/ means and if there's
something I should do with my BNF model to make it so.

Thanks.

  nikolai

Re: modules

[Sanjoy Mahajan]

TDS is the Tex Directory Structure, designed so that the various tex
distributions use the same file structure.

See <http://www.tug.org/tds/>

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: modules

[Taco Hoekwater]

Nikolai Weibull wrote:
> On 4/4/06, Hans Hagen <pragma@wxs.nl> wrote:
> 
> 
>>In order to be able to generate new zips i'd like the modules in the
>>wiki to be tds compliant as soon as possible.
>  
> I"ve kept this mail starred since I first saw it and haven't put any
> thought into what you're actually asking about here.  Now, however,
> I'd really like to know what /TDS compliant/ means and if there's
> something I should do with my BNF model to make it so.

Have a look at the lettrines module for an example that should
be simple to apply to t-bnf.

Taco

Re: modules

[Nikolai Weibull]

On 8/9/06, Taco Hoekwater <taco@elvenkind.com> wrote:
> Nikolai Weibull wrote:
> > On 4/4/06, Hans Hagen <pragma@wxs.nl> wrote:
> >
> >
> >>In order to be able to generate new zips i'd like the modules in the
> >>wiki to be tds compliant as soon as possible.
> >
> > I"ve kept this mail starred since I first saw it and haven't put any
> > thought into what you're actually asking about here.  Now, however,
> > I'd really like to know what /TDS compliant/ means and if there's
> > something I should do with my BNF model to make it so.
>
> Have a look at the lettrines module for an example that should
> be simple to apply to t-bnf.

Thanks (and thanks Sanjoy).  I suppose the PDF documentation is
auto-generated, so I don't need to include that, right?

  nikolai

Re: modules

[Hans Hagen]

Nikolai Weibull wrote:
> On 8/9/06, Taco Hoekwater <taco@elvenkind.com> wrote:
>   
>> Nikolai Weibull wrote:
>>     
>>> On 4/4/06, Hans Hagen <pragma@wxs.nl> wrote:
>>>
>>>
>>>       
>>>> In order to be able to generate new zips i'd like the modules in the
>>>> wiki to be tds compliant as soon as possible.
>>>>         
>>> I"ve kept this mail starred since I first saw it and haven't put any
>>> thought into what you're actually asking about here.  Now, however,
>>> I'd really like to know what /TDS compliant/ means and if there's
>>> something I should do with my BNF model to make it so.
>>>       
>> Have a look at the lettrines module for an example that should
>> be simple to apply to t-bnf.
>>     
>
> Thanks (and thanks Sanjoy).  I suppose the PDF documentation is
> auto-generated, so I don't need to include that, right?
>   
once you have a valid tpm file describing the package, you can use 

textools --tpmmake

to update such a file and create a zip 

saves time 

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

Re: modules

[Taco Hoekwater]

Nikolai Weibull wrote:
>>Have a look at the lettrines module for an example that should
>>be simple to apply to t-bnf.
> 
> 
> Thanks (and thanks Sanjoy).  I suppose the PDF documentation is
> auto-generated, so I don't need to include that, right?

No, you do have to do that yourself, it is not autogenerated.
(because that would not be very reliable)

Taco

Re: modules

[Nikolai Weibull]

On 8/9/06, Taco Hoekwater <taco@elvenkind.com> wrote:
>
>
> Nikolai Weibull wrote:
> >>Have a look at the lettrines module for an example that should
> >>be simple to apply to t-bnf.
> >
> >
> > Thanks (and thanks Sanjoy).  I suppose the PDF documentation is
> > auto-generated, so I don't need to include that, right?
>
> No, you do have to do that yourself, it is not autogenerated.
> (because that would not be very reliable)

OK, done.  Now how do I get this package to the modules homepage?

  nikolai

Re: modules

[Taco Hoekwater]

Nikolai Weibull wrote:
>>
>>No, you do have to do that yourself, it is not autogenerated.
>>(because that would not be very reliable)
> 
> OK, done.  Now how do I get this package to the modules homepage?

On modules.contextgarden.net,  there is a "log in" link in the
upper right corner. Do that (use your wiki login), and you get a
new set of links for updating your modules.

Cheers, Taco

Re: modules

[Nikolai Weibull]

On 8/9/06, Taco Hoekwater <taco@elvenkind.com> wrote:

> Nikolai Weibull wrote:

> Now how do I get this package to the modules homepage?
>
> On modules.contextgarden.net,  there is a "log in" link in the
> upper right corner. Do that (use your wiki login), and you get a
> new set of links for updating your modules.

I don't have a login, that I know about, so I created a new one.  My
username is "now", so if you could give the user "now" ownership of
the BNF grammar module, that'd be great.

Thanks!

  nikolai

Re: modules

[Patrick Gundlach]

Hello Nikolai,

> I don't have a login, that I know about, so I created a new one.  My
> username is "now", so if you could give the user "now" ownership of
> the BNF grammar module, that'd be great.

Done. If you have any more questions, just ask me. Sorry for the
delay: I was offline for a few days.

Patrick

-- 
ConTeXt wiki and more: http://contextgarden.net

Modules

[Marco Kuhlmann]

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

Re: Modules

[Giuseppe Bilotta]

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

Re: Modules

[Hans Hagen]

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

Re: Modules

[Taco Hoekwater]

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

Re: Modules

[Hans Hagen]

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

Re: Modules

[Taco Hoekwater]

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

Re: Modules

[Eckhart Guthöhrlein]

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

Re: Modules

[Berend de Boer]

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. (-:

Re: Modules

[Marco Kuhlmann]

* 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

Re: Modules

[Hans Hagen]

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

Re: Modules

[Hans Hagen]

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

Re: Modules

[Hans Hagen]

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