Upgrading ConTeXt and testing

Upgrading ConTeXt and testing

[Idris Samawi Hamid]

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

Re: Upgrading ConTeXt and testing

[Taco Hoekwater]

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

Re: Upgrading ConTeXt and testing

[Hans Hagen]

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

Re: Upgrading ConTeXt and testing

[Brooks Moses]

At 06:04 AM 8/29/2005, Hans Hagen <pragma@wxs.nl> wrote:
>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

Re: Upgrading ConTeXt and testing

[jjgod]

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.