ConTeXt versioning model critique

ConTeXt versioning model critique

[Vyatcheslav Yatskovsky]

Dear Patrtic,

> ... ConTeXt would probably stabilize, which IMHO is not a good thing.
> One thing I really love ConTeXt for is the speed new techniques are
> adopted (pdf features, luatex,...) One day we might have a ConTeXt
> MKII book for those who are afraid of swithing to pdftex2.

ConTeXt should be eventually stabilized so that someone can make some use of it. But, there is a way for rapid adopting of new techniques too.

My experience of using open-source products (I'm best familiar with Moodle) suggest that there should be overlapping cycles in development:
1. Allocate new version number and start implementing new features.  Many things are broken at the moment and the version becomes unusable for production purposes. 
2. Stabilize this version and make definite release (number x.x.). Now it can be used for production.
3. Continue resolve bugs in this version AND perform Step 1 IN PARALLEL.

Moodle follows this model and I always wandered how smooth it was to migrate between releases. Everything is completely predictable.
Please, look at http://download.moodle.org/ to get the idea of their versioning.

I think ConTeXt needs similar versioning model badly. Now it has rather naive model (release dates) that doesn't help in deciding about stability at all.

-- 
Best regards,
Vyatcheslav Yatskovsky

Re: ConTeXt versioning model critique

[Ulf Martin]

Vyatcheslav Yatskovsky schrieb:
[...]
> My experience of using open-source products (I'm best familiar with
> Moodle) suggest that there should be overlapping cycles in
> development: 1. Allocate new version number and start implementing
> new features.  Many things are broken at the moment and the version
> becomes unusable for production purposes. 2. Stabilize this version
> and make definite release (number x.x.). Now it can be used for
> production. 3. Continue resolve bugs in this version AND perform Step
> 1 IN PARALLEL.
[...]
> I think ConTeXt needs similar versioning model badly. Now it has
> rather naive model (release dates) that doesn't help in deciding
> about stability at all.
> 
There is another reason for adopting a versioning model: legacy documents.

I wonder how people (esp. at Pragma) currently deal with this. What
happens if you have a ConTeXt doc from say 1997 that compiles into the
resp. PDF with some ConTeXt version from that time but not today
anymore? Which ConTeXt versions does one have to keep in order to be
able to use such a document? (A good example for this kind of trouble
seem to be the current issues with XeTeX, but I haven't followed this in
detail -- but it kept me away from updating my ConTeXt installation
since December...).

Also remember that Knuth originally intended TeX to be an "eternal"
formatting system (thus we have at least the option to expand all macros
into plain TeX and keep that as the source file).

This raises another question: is ConTeXt developed in an test driven
way? I.e. are there test documents (including e.g. XML documents,
bibligraphic references etc.) that have to pass comilation in order for
changes to be published? If so, they would probably define a standard
set of commands that could go into The ConTeXt Companion.

Cheers
Ulf

Re: ConTeXt versioning model critique

[Hans Hagen]

Ulf Martin wrote:
> I wonder how people (esp. at Pragma) currently deal with this. What
> happens if you have a ConTeXt doc from say 1997 that compiles into the
> resp. PDF with some ConTeXt version from that time but not today
> anymore? Which ConTeXt versions does one have to keep in order to be
> able to use such a document? (A good example for this kind of trouble
> seem to be the current issues with XeTeX, but I haven't followed this in
> detail -- but it kept me away from updating my ConTeXt installation
> since December...).
>   
for projects where we use relatively new features (which evolve) we use 
frozen trees; actually some of this code is not even documented (simply 
no time; take synchronized graphics)

with regards to commands and such ... context is just (supposed to be) 
downward compatible; even kind of obsolete is still there; with regards 
to  different solutions to  problems, we often provide control usign low 
level mode indicators

concerning xetex ... keep in mind that there xetex is the moving target 
(changes/extensions  in interface) and to some extend this was true for 
pdftex as well, but there we could silently adapt  
> Also remember that Knuth originally intended TeX to be an "eternal"
> formatting system (thus we have at least the option to expand all macros
> into plain TeX and keep that as the source file).
>   
plain tex is just a format and unsuitable as expanded format

well, i have some experimental code that dumps the expanded token list 
into a file; nu fun ... a 50 page moderately complex doc becomes some 25 
meg -)

but then, if the sole reason is to reprocess the doc ... just save the 
pdf file -)

> This raises another question: is ConTeXt developed in an test driven
> way? I.e. are there test documents (including e.g. XML documents,
> bibligraphic references etc.) that have to pass comilation in order for
> changes to be published? If so, they would probably define a standard
> set of commands that could go into The ConTeXt Companion.
>
>   
Sanjoy has set up an advanced test system ... so anything that you 
contribute can go in there

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: ConTeXt versioning model critique

[luigi scarso]

On 4/14/07, Hans Hagen <pragma@wxs.nl> wrote:
> Ulf Martin wrote:
> > I wonder how people (esp. at Pragma) currently deal with this.
> for projects where we use relatively new features (which evolve) we use
> frozen trees;
Confirm
One tree of 2002 ("still-crazy-after-all-these-years").
Another of 2004.
Switch to last pdftex/context sometimes second quarter of this year;
switch to luatex at the end of next year.
Why switch ?
Last versions. are better (speed and features);
pdf spec. change .

>
> with regards to commands and such ... context is just (supposed to be)
> downward compatible; even kind of obsolete is still there; with regards
> to  different solutions to  problems, we often provide control usign low
> level mode indicators
On average, my macros are not completly portable from one tree to another,
but I'm sure that this depend from my poor coding tecnique for 95% .
5% is made by spaces and fonts .
>
> concerning xetex ... keep in mind that there xetex is the moving target
> (changes/extensions  in interface) and to some extend this was true for
> pdftex as well, but there we could silently adapt
> > Also remember that Knuth originally intended TeX to be an "eternal"
> > formatting system (thus we have at least the option to expand all macros
> > into plain TeX and keep that as the source file).
> >
> plain tex is just a format and unsuitable as expanded format
>
> well, i have some experimental code that dumps the expanded token list
> into a file; nu fun ... a 50 page moderately complex doc becomes some 25
> meg -)
pdf has some sort of  compression .
Do  \pdfcompresslevel=0 \pdfobjcompresslevel=0
make some differences in your 50page document?

> Sanjoy has set up an advanced test system ... so anything that you
> contribute can go in there
I will install on my machine.



luigi

Re: ConTeXt versioning model critique

[fdu.xiaojf]

Vyatcheslav Yatskovsky wrote:
> Dear Patrtic,
>
>   
>> ... ConTeXt would probably stabilize, which IMHO is not a good thing.
>> One thing I really love ConTeXt for is the speed new techniques are
>> adopted (pdf features, luatex,...) One day we might have a ConTeXt
>> MKII book for those who are afraid of swithing to pdftex2.
>>     
>
> ConTeXt should be eventually stabilized so that someone can make some use of it. But, there is a way for rapid adopting of new techniques too.
>
> My experience of using open-source products (I'm best familiar with Moodle) suggest that there should be overlapping cycles in development:
> 1. Allocate new version number and start implementing new features.  Many things are broken at the moment and the version becomes unusable for production purposes. 
> 2. Stabilize this version and make definite release (number x.x.). Now it can be used for production.
> 3. Continue resolve bugs in this version AND perform Step 1 IN PARALLEL.
>
> Moodle follows this model and I always wandered how smooth it was to migrate between releases. Everything is completely predictable.
> Please, look at http://download.moodle.org/ to get the idea of their versioning.
>
> I think ConTeXt needs similar versioning model badly. Now it has rather naive model (release dates) that doesn't help in deciding about stability at all.
>
>   
  I strongly agree that ConTeXt needs an improved versioning model.

Re: ConTeXt versioning model critique

[Taco Hoekwater]

fdu.xiaojf@gmail.com wrote:
>>
>>   
>   I strongly agree that ConTeXt needs an improved versioning model.

I agree. We probably all agree, Hans included. But we also need
improved days with more (or longer) hours. That, and pdftex and
xetex should stop evolving.  Nothing is as disruptive as new
features :-)

In the autumn, Hans and I hopefully have the spare time to think
about some of the issues related to context releases, patches and
distributions.

Best wishes,
Taco

Re: ConTeXt versioning model critique

[fdu.xiaojf]

Taco Hoekwater wrote:
> fdu.xiaojf@gmail.com wrote:
>   
>>>   
>>>       
>>   I strongly agree that ConTeXt needs an improved versioning model.
>>     
>
> I agree. We probably all agree, Hans included. But we also need
> improved days with more (or longer) hours. That, and pdftex and
> xetex should stop evolving.  Nothing is as disruptive as new
> features :-)
>
>   
  Currently i'm using the standalone version of ConTeXt, which is easy
  to config and works well. So maybe ConTeXt can be distributed as a
  standalone package, and it auto detects available TeX 
resources(Xetex,et al)
  on the computer and make use of them.
> In the autumn, Hans and I hopefully have the spare time to think
> about some of the issues related to context releases, patches and
> distributions.
> Best wishes,
> Taco
>
>   
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: ConTeXt versioning model critique

[Hans Hagen]

fdu.xiaojf@gmail.com wrote:
> Vyatcheslav Yatskovsky wrote:
>   
>> Dear Patrtic,
>>
>>   
>>     
>>> ... ConTeXt would probably stabilize, which IMHO is not a good thing.
>>> One thing I really love ConTeXt for is the speed new techniques are
>>> adopted (pdf features, luatex,...) One day we might have a ConTeXt
>>> MKII book for those who are afraid of swithing to pdftex2.
>>>     
>>>       
>> ConTeXt should be eventually stabilized so that someone can make some use of it. But, there is a way for rapid adopting of new techniques too.
>>
>> My experience of using open-source products (I'm best familiar with Moodle) suggest that there should be overlapping cycles in development:
>> 1. Allocate new version number and start implementing new features.  Many things are broken at the moment and the version becomes unusable for production purposes. 
>>     
in addition to taco's answer:

i seldom do big chances in the distributed version; actually, i always 
use the alpha/beta/whatever in production here;
>> 2. Stabilize this version and make definite release (number x.x.). Now it can be used for production.
>> 3. Continue resolve bugs in this version AND perform Step 1 IN PARALLEL.
>>     
you can consider the tex live versions the formal stable versions -)

fyi: the real experimental stuff is in mkiv code and only a few have 
this on their machines; it's not in alpha/beta releases at all

keep in mind that a more complex versioning model will put my/taco's 
time for 'paid' work even more under pressure
>> Moodle follows this model and I always wandered how smooth it was to migrate between releases. Everything is completely predictable.
>> Please, look at http://download.moodle.org/ to get the idea of their versioning.
>>
>> I think ConTeXt needs similar versioning model badly. Now it has rather naive model (release dates) that doesn't help in deciding about stability at all.
>>
>>   
>>     
>   I strongly agree that ConTeXt needs an improved versioning model.
>   
in principle you can take any version you want from the svn repos 
(nicely packages in zips btw)

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

Table of contents and 2UP or 2SIDE

[Horacio Suarez]

Hello:

When I use (just for saving paper and print time)

\setuparranging[2UP]

o

\setuparranging[2SIDE]

my table of content is empty, just the header (Indice) appears in that page. 
But if I don't use any arranging the TOC it's ok.

I can print the TOC alone, but I want to know if I'm doing somethig wrong, 
as usual...

Thankyou in advance.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: Table of contents and 2UP or 2SIDE

[Hans Hagen]

Horacio Suarez wrote:
> Hello:
>
> When I use (just for saving paper and print time)
>
> \setuparranging[2UP]
>
> o
>
> \setuparranging[2SIDE]
>
> my table of content is empty, just the header (Indice) appears in that page. 
> But if I don't use any arranging the TOC it's ok.
>
> I can print the TOC alone, but I want to know if I'm doing somethig wrong, 
> as usual...
>   
texexec --arrange yourfile 

you have to make sure that there is a last pass without a utility file being produced 

alternatively: 

-- comment \setuparrange
-- run texexex filename 
-- uncomment \setuparrange 
-- run texexec --once filename 

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

Some progress with XeTeX

[Vyatcheslav Yatskovsky]

Hello,

I have some progress with XeTeX already (with the version included in TeXLive distribution).

1a) Including external graphics really requires ImageMagic to be installed.
1b) PDF pictures refuse to be inserted for unknown reason but PNGs are handled fine.

2) To use Windows encoding such as cp1251 (for Cyrrilc), two commands in preamble are needed:
\enableregime[cp1251]
\XeTeXinputencoding[cp1251]


Question: what is a application to prepare custom vector graphics? Since pdfs are not included, it should be something more specific. My favourite one, Inkscape, allows export to .tex formatted for LaTex with PSTricks; obvously ConTeXt failes with it. 

-- 
Best regards,
Vyatcheslav Yatskovsky