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
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
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 -----------------------------------------------------------------
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);
On 4/14/07, Hans Hagen
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
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.
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
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
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 -----------------------------------------------------------------
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/
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 -----------------------------------------------------------------
participants (7)
-
fdu.xiaojf＠gmail.com -
Hans Hagen -
Horacio Suarez -
luigi scarso -
Taco Hoekwater -
Ulf Martin -
Vyatcheslav Yatskovsky