Upgrading ConTeXt and testing
Dear gang, I understand that ConTeXt is a HUGE system, and it is impossible for Hans to micro-test everything. However, it is not infrequent that upgrades by users lead to sometimes days of lost productivity. For example, a recent change in the indentation code ruined a 425-page manuscript and it took me hours to identify the source of the problem. And that was only one problem. Given the problems some of us have faced when upgrading, I think that we really need a test suite of documents that provide some benchmarks for each part of the system, from building supported format files to features to supported output formats. Maybe this would take a long time; but perhaps the task could be delegated among is. I would be willing to be part of that team (including but not exclusively the aleph-dvipdfmx cycle). When a new ConTeXt is released, Taco or someone else could then document which bugs are fixed, features added, and, most importantly, what features are changed or broken. That way, upgrading does not always have to be a leap in the dark with fingers crossed. The above is just an idea. I hope it can be developed into something actually workable and useful. A related point (disussed before) is that ConTeXt needs to become completely independent of the TeX distributions. mswincontext.zip is a good start (I no longer use fpTeX), but things like dvipdfmx and the plain format (for testing purposes) need to be thoroughly supported and tested. Again, a support team for Hans is needed (especially for Mac OSX and Unix), and I'm willing to help as far as my skills will allow. Best Idris ============================ Professor Idris Samawi Hamid Department of Philosophy Colorado State University Fort Collins, CO 80523
Hi Idris (and all), Idris Samawi Hamid wrote:
When a new ConTeXt is released, Taco or someone else could then document which bugs are fixed, features added, and, most importantly, what features are changed or broken.
Whenever someone reports a problem, the release notes on the wiki enable me to quickly look up changes in the code (to check for possible regression errors). It has saved me a lot of time in the last half year or so. But the release notes is not enough, we are aware of that. Three other projects in the pipeline are: * A read-only CVS containing as many of the old ConTeXt releases as we can find, for reference and regression checks. This cannot be started immediately because we first have to collect all of the old zips, so they can be imported in the correct order. (assigned to Patrick and me) * A limited-access CVS with Hans' current working sources, so that some of the active developers can apply patches themselves (assigned to Hans) * A test suite, precisely as you proposed (not assigned to anybody yet <wink>) The best way to boot this project is to request/create a project on Fabrice Popineau's gforge/subversion server: https://foundry.supelec.fr/ (we intend to use the same gforge server for the read-only CVS)
A related point (disussed before) is that ConTeXt needs to become completely independent of the TeX distributions. mswincontext.zip is a good start (I no longer use fpTeX), but things like dvipdfmx and the plain format (for testing purposes) need to be thoroughly supported and tested.
Yeah, I very much agree. Here is the run-down on last night's problem: Hans does not ship lang-us.pat, probably because someone told him not to (that sort of stuff is a whole different story). What happens then is that context's file synonym mechanism tries to find a replacement file for lang-us.pat. I do not have ushyphmax.tex installed, so on my system, that means ushyph.tex, and it works fine. But apparently (sometimes? dependant on install options perhaps?) miktex ships a ushyphmax.tex. And a broken one, at that. It took most of yesterday-evening to discover that. :-(
Again, a support team for Hans is needed (especially for Mac OSX and Unix), and I'm willing to help as far as my skills will allow.
Lately, we get a lot of bug reports for miktex, which is problematic since none of us use miktex: I believe Hans has a fptex-ish system, and most other 'core' people are either linux or macintosh based. A volunteer for miktex would be brilliant (even better: someone who knows how to compile miktex executables). Greetings, Taco
Taco Hoekwater wrote:
Hi Idris (and all),
Idris Samawi Hamid wrote:
When a new ConTeXt is released, Taco or someone else could then document which bugs are fixed, features added, and, most importantly, what features are changed or broken.
Whenever someone reports a problem, the release notes on the wiki enable me to quickly look up changes in the code (to check for possible regression errors). It has saved me a lot of time in the last half year or so.
But the release notes is not enough, we are aware of that. Three other projects in the pipeline are:
* A read-only CVS containing as many of the old ConTeXt releases as we can find, for reference and regression checks.
subversion -) i'll set that up as soon as possible and taco can mirror that (interesting experiment anyway, mirroring a svn archive) we can use fabrices gforce archive if needed
This cannot be started immediately because we first have to collect all of the old zips, so they can be imported in the correct order. (assigned to Patrick and me)
-)
* A limited-access CVS with Hans' current working sources, so that some of the active developers can apply patches themselves (assigned to Hans)
indeed; i'll open a svn repository for that with access for approved dev's
* A test suite, precisely as you proposed (not assigned to anybody yet <wink>) The best way to boot this project is to request/create a project on Fabrice Popineau's gforge/subversion server: https://foundry.supelec.fr/
indeed
(we intend to use the same gforge server for the read-only CVS)
right
A related point (disussed before) is that ConTeXt needs to become completely independent of the TeX distributions. mswincontext.zip is a good start (I no longer use fpTeX), but things like dvipdfmx and the plain format (for testing purposes) need to be thoroughly supported and tested.
Yeah, I very much agree. Here is the run-down on last night's problem:
Hans does not ship lang-us.pat, probably because someone told him not to (that sort of stuff is a whole different story). What happens then is that context's file synonym mechanism tries to find a replacement file for lang-us.pat.
I do not have ushyphmax.tex installed, so on my system, that means ushyph.tex, and it works fine. But apparently (sometimes? dependant on install options perhaps?) miktex ships a ushyphmax.tex. And a broken one, at that. It took most of yesterday-evening to discover that. :-(
sigh, what a mess; so, we set up a repository for that as well: context -> sources (copy from one of our internal servers) history generic patterns distribution manuals (copy from one of our internal servers)
Again, a support team for Hans is needed (especially for Mac OSX and Unix), and I'm willing to help as far as my skills will allow.
Lately, we get a lot of bug reports for miktex, which is problematic since none of us use miktex: I believe Hans has a fptex-ish system, and most other 'core' people are either linux or macintosh based.
A volunteer for miktex would be brilliant (even better: someone who knows how to compile miktex executables).
yeah, i have to pick up that thread, since newtexexec needs to be miktex aware; 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 -----------------------------------------------------------------
At 06:04 AM 8/29/2005, Hans Hagen
Taco Hoekwater wrote:
* A read-only CVS containing as many of the old ConTeXt releases as we can find, for reference and regression checks.
subversion -)
i'll set that up as soon as possible and taco can mirror that (interesting experiment anyway, mirroring a svn archive)
Recently, I came across something called SVK, which apparently is specifically intended for mirroring and merging subversion archives. It looks like it might also solve the problem you (Hans) were mentioning earlier of wanting to have a local version of the repository on your laptop that you could periodically merge with the main repository. There's a webpage on it here: http://svk.elixus.org/ Personally, I haven't used it yet, but I got the link from a friend of mine who is a very competent sysadmin, and he seemed happy with it. - Brooks
Taco Hoekwater wrote:
Lately, we get a lot of bug reports for miktex, which is problematic since none of us use miktex: I believe Hans has a fptex-ish system, and most other 'core' people are either linux or macintosh based.
The problem is, currently MikTeX (2.4) does not have a SDK, the maintainer said a SDK will be released in version 2.5, but the release date is not fixed yet. MikTeX use a different way (compare to tetex) to load web2c config file, so the kpathsea library in MikTeX is just a wrapper of function calls to the MikTeX library. Without a SDK we have to fetch all the source code of MikTeX to compile such a library, which is rather difficult. To name one problem I encounted, the Win32 binaries of afm2pl (from http://tex.aanhet.net/afm2pl/) does not work in MikTeX (because the reason I just described), but it's really hard to compile a binary (with libkpse support) by myself.
A volunteer for miktex would be brilliant (even better: someone who knows how to compile miktex executables).
- jjgod.
participants (5)
-
Brooks Moses -
Hans Hagen -
Idris Samawi Hamid -
jjgod -
Taco Hoekwater