beta test version of patch 2 to gawk 3.1 available 
Author Message
 beta test version of patch 2 to gawk 3.1 available

This note is to announce the first BETA release of patch 2 to version
3.1 of gawk.

It is available from:

        ftp://ftp.freefriends.org/arnold/gawk/gawk-3.1.1l.tar.gz
        ftp://ftp.freefriends.org/arnold/gawk/gawk-3.1.1l.tar.bz2

and from:

        http://www.*-*-*.com/
        http://www.*-*-*.com/

This release fixes a number of bugs, as well as offering performance
improvements in both space and time for arrays, time for function calls,
and several other areas.  The list of changes from the NEWS file is
appended, below.

As far as I can tell, the documentation and code have both hit the
freeze point.  Other than changing the version and patch levels, this
is what I expect to release as 3.1.2.

So, why do a beta release? So that you, yes you, the end user, can see
if anything I've done breaks gawk for you.  Then you can TELL ME ABOUT
IT so that I can fix it for the final release.

Thanks,

Arnold Robbins

---------------------------------------------
Changes from 3.1.1 to 3.1.2
---------------------------

1. Loops of the form:

        for (iggy in foo)
                next

   no longer leak memory.

2. gawk -v FIELDWIDTHS="..." now sets PROCINFO["FS"] correctly.

3. All builtin operations and functions should now fully evaluate their
   arguments so that side effects take place correctly.

4. Fixed a logic bug in gsub/gensub for matches to null strings that occurred
   later in the string after a nonnull match.

5. getgroups code now works on Ultrix again.

6. Completely new version of the full GNU regex engine now in place.

7. Argument parsing and variable assignment has been cleaned up.

8. An I/O bug on HP-UX has been documented and worked around. See
   README_d/README.hpux.

9. awklib/grcat should now compile correctly.

10. Updated to automake 1.7.2, autoconf 2.57 and gettext 0.11.5 ; thanks to
    Paul Eggert for the initial automake and autoconf work.

11. As a result of #6, removed the use of the dfa code from GNU grep.

12. It is now possible to use ptys for |& two-way pipes instead of
    pipes.  The basic plumbing for this was provided by Paolo Bonzini.
    To make this happen:

        command = "unix command etc"
        PROCINFO[command, "pty"] = 1

        print ... |& command
        command |& getline stuff

    In other words, set the element in PROCINFO *before* opening the
    two-way pipe, and then gawk will use ptys instead of pipes.

    On systems without ptys or where all the ptys are in use, gawk
    will fall back to using plain pipes.

13. Fixed a regex matching across buffer boundaries bug, with a
    heuristic.  See io.c:rsre_get_a_record().

14. Profiling no longer dumps core if there are extension functions in place.

15. Grammar and scanner cleaned up, courtesy of Stepen Kasal, to hopefully
    once and for all fix the `/=' operator vs. `/=.../' regex ambiguity.
    Lots of other grammar simplifications applied, as well.

16. BINMODE should work now on more Windows ports.

17. Updated to bison 1.875.  Includes fix to bisonfix.sed script.

18. The NODE structure is now 20% (8 bytes) smaller (on x86, anyway), which
    should help conserve memory.

19. Builds not in the source directory should work again.

20. Arrays now use 2 NODE's per element instead of three. Combined with
    #18, (on the x86) this reduces the overhead from 120 bytes per element
    to just 64 bytes: almost a 50% improvement.

21. Programs that make heavy use of changing IGNORECASE should now be
    much faster, particularly if using a regular expression for FS or RS.
    IGNORECASE now correctly affects RS regex record splitting, as well.

22. IGNORECASE no longer affects single-character field splitting (FS = "c"),
    or single-character record splitting (RS = "c").

    This cleans up some weird behavior, and makes gawk better match the
    documentation, which says it only affects regex-based field splitting
    and record splitting.

    The documentation on this was improved, too.

23. The framework in test/ has been simplified, making it much easier to
    add new tests while keeping the size of Makefile.am reasonable. Thanks
    for this to Stepan Kasal.

24. --lint=invalid causes lint warnings only about stuff that's actually
    invalid.  This needs additional work.

25. More translations.

26. The get_a_record() routine has been revamped (currently by splitting it
    into three variants).  This should improve long-term maintainability.

27. match() now adds more entries to 3rd array arg:
        match("the big dog", /([a-z]+) ([a-z]+) ([a-z]+)/, data)
    fills in variables:
        data[1, "start"], data[1, "length"], and so on.

28. New asorti() function with same interface as asort(), but sorts indices
    instead of values.  

29. Documentation updated to FDL 1.2.

30. Various minor cleanups, see the ChangeLog for details.
--

P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 928 569 9018
Nof Ayalon              Cell Phone: +972 51  297-545
D.N. Shimshon 99785     ISRAEL



Fri, 05 Aug 2005 20:51:01 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:

>28. New asorti() function with same interface as asort(), but sorts indices
>    instead of values.  

Great!  At long last...

By the way, does WHINY_USERS still work?



Fri, 05 Aug 2005 21:21:38 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:

> [...]
> 12. It is now possible to use ptys for |& two-way pipes instead of
>     pipes.  The basic plumbing for this was provided by Paolo Bonzini.
>     To make this happen:

Excellent, can use |& without worrying about{*filter*} processes. One question,
will it be possible to use |& with an inherited fd like this:

      print "XXX" |& "/dev/fd/N"

John



Sat, 06 Aug 2005 08:20:42 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:



>>28. New asorti() function with same interface as asort(), but sorts indices
>>    instead of values.  

>Great!  At long last...

>By the way, does WHINY_USERS still work?

Yes.
--

P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 928 569 9018
Nof Ayalon              Cell Phone: +972 51  297-545
D.N. Shimshon 99785     ISRAEL


Sat, 06 Aug 2005 19:14:09 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:


>> [...]
>> 12. It is now possible to use ptys for |& two-way pipes instead of
>>     pipes.  The basic plumbing for this was provided by Paolo Bonzini.
>>     To make this happen:

>Excellent, can use |& without worrying about{*filter*} processes. One question,
>will it be possible to use |& with an inherited fd like this:

>      print "XXX" |& "/dev/fd/N"

>John

This construct makes no sense.  |& is for use with two way communication with a running
program (or socket).  Just use > and < to the inherited fd, and it ought to work.

        print "xxx" > "/dev/fd/N"
        getline stuff < "/dev/fd/N"

Or use expect.

Arnold
--

P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 928 569 9018
Nof Ayalon              Cell Phone: +972 51  297-545
D.N. Shimshon 99785     ISRAEL



Sat, 06 Aug 2005 19:16:25 GMT  
 beta test version of patch 2 to gawk 3.1 available


Quote:
>This note is to announce the first BETA release of patch 2 to version
>3.1 of gawk.

>It is available from:

>       ftp://ftp.freefriends.org/arnold/gawk/gawk-3.1.1l.tar.gz
>       ftp://ftp.freefriends.org/arnold/gawk/gawk-3.1.1l.tar.bz2

>and from:

>       http://www.skeeve.com/gawk-3.1.1l.tar.gz
>       http://www.skeeve.com/gawk-3.1.1l.tar.bz2

>This release fixes a number of bugs, as well as offering performance
>improvements in both space and time for arrays, time for function calls,
>and several other areas.  The list of changes from the NEWS file is
>appended, below.

>As far as I can tell, the documentation and code have both hit the
>freeze point.  Other than changing the version and patch levels, this
>is what I expect to release as 3.1.2.

>So, why do a beta release? So that you, yes you, the end user, can see
>if anything I've done breaks gawk for you.  Then you can TELL ME ABOUT
>IT so that I can fix it for the final release.

>Thanks,

>Arnold Robbins


There seems to be a bug in the Makefile in the following area: -

# object files
AWKOBJS1 = array$O builtin$O eval$O field$O gawkmisc$O io$O main$O
AWKOBJS2 = ext$O msg$O node$O profile$O re$O regcomp$O regex_in$O
regexec$O version$O
PAWKOBJS1 = array$O builtin$O eval_p$O field$O gawkmisc$O io$O main$O
PAWKOBJS2 = ext$O msg$O node$O profile_p$O re$O regcomp$O regex_in$O
regexec$O version$O
AWKOBJS = $(AWKOBJS1) $(AWKOBJS2)

These lines refer to regex_in$O which I changed to regex_internal$O in
two places.

I am using the djgpp port of gcc 3.2.1
I used shell GNU bash, version 2.04.7(1)-release (i386-pc-msdosdjgpp)

I had to delete file C:\djgpp\lib\GCC-LIB\DJGPP\3.21\include\stdarg.h to
remove a re-definition of va_list in the header files but this is a
problem with the djgpp port of gcc 3.2.1 rather than an awk problem.
Please ignore the following if you think this may affect my results.

Twelve of the tests seem to have failed but some of these failures are
expected with the djgpp version. I assume the filenames beginning with
"_" are error outputs.

sh-2.04$ ls -l test/_*
-rw-r--r--   1 dosuser  root          137 Feb 19 00:02 test/_argarray
-rw-r--r--   1 dosuser  root           63 Feb 19 00:03 test/_clos1way
-rw-r--r--   1 dosuser  root           13 Feb 19 00:03 test/_fsrs
-rw-r--r--   1 dosuser  root           98 Feb 19 00:03 test/_leadnl
-rw-r--r--   1 dosuser  root            0 Feb 19 00:03 test/_nlinstr
-rw-r--r--   1 dosuser  root           25 Feb 19 00:03 test/_pid
-rw-r--r--   1 dosuser  root           12 Feb 19 00:03 test/_pid.in
-rw-r--r--   1 dosuser  root           10 Feb 19 00:03 test/_rs
-rw-r--r--   1 dosuser  root            0 Feb 19 00:03 test/_rsnul1nl
-rw-r--r--   1 dosuser  root            0 Feb 19 00:03 test/_rswhite
-rw-r--r--   1 dosuser  root           96 Feb 19 00:03 test/_space
-rw-r--r--   1 dosuser  root           46 Feb 19 00:03 test/_strtod

sh-2.04$ awk 'FNR==1{print "\nFILENAME="FILENAME};{print}' test/_* >
test/badtest

FILENAME=test/_argarray
here we have 3 arguments
which are
         gawk
         ../argarray.in
         -
Environment variable TEST=
and the current input file is called ""

FILENAME=test/_clos1way
gawk: clos1way.awk:7: fatal: `|&' not supported
EXIT CODE: 2

FILENAME=test/_fsrs
a b
c d
e f

FILENAME=test/_leadnl
Name is:  Jane Doe
Address is:  123 Main Street
City and State are:  Anywhere, SE 12345-6789

FILENAME=test/_pid
Bad ppid 7892, wanted 0

FILENAME=test/_pid.in
7893
7892

FILENAME=test/_rs
a b
c d

FILENAME=test/_space
gawk: fatal: can't open source file ` ' for reading (Permission denied
(EACCES))
EXIT CODE: 2

FILENAME=test/_strtod
0x345 0
345 is not zero
000e-5 is not zero

Hope this helps
--
Alan Linton



Sun, 07 Aug 2005 08:12:56 GMT  
 beta test version of patch 2 to gawk 3.1 available

Hi,
Great.

Just one point.
In a discussion about simulating binary I/O in awk i mentioned using a
regexp
with only dots for RS (and playing with RT) getline would then do the
right thing.
Sadly it gets very slow when the number of . is increased.

Maybe this degenerate case could be optimized to give the possibility to
have IO
in chunks.

It would make it easy to have gawk acting as a true binary filter
o simply to process structured binary data; for example an ASCII NUL
remover
that keeps the memory footprint low in all cases of input.

At a time when shell developers start considering adding binary I/O
(ksh, bash)
is there really any fundamental reason not
to have it in the core (I know  it can be an extension).
Thanks

  sgt19.vcf
< 1K Download


Sun, 07 Aug 2005 18:21:49 GMT  
 beta test version of patch 2 to gawk 3.1 available
Hello,

Quote:

> with only dots for RS ...
> Sadly it gets very slow when the number of . is increased.

could you try to use RS=".{n}" instead (where n is a suitable number)?
You have to specify --re-interval.

This could improve the performance in these cases.

Stepan



Sun, 07 Aug 2005 21:42:19 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:

> Hello,


> > with only dots for RS ...
> > Sadly it gets very slow when the number of . is increased.

> could you try to use RS=".{n}" instead (where n is a suitable number)?
> You have to specify --re-interval.

> This could improve the performance in these cases.

> Stepan

Hi, I also tried that, and it is slow. I would say from my understanding
of the code it is logically slow.

My point was the following: as nobody uses this type of regular expression
   (for example RS=.{1024}" or you build it with a loop in order not to
     specify --re-interval)
  this is a degenerate case that allows an optimization (for the implementer

  - Arnold and you -) to add IO in chunks (still one has to fiddle with RT
  when the number of imput bytes is not a multiple of the chunk size)

  I mean you don't need any new syntax for binary IO this way.

Thanks
Stephan

  sgt19.vcf
< 1K Download


Mon, 08 Aug 2005 16:59:06 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:

> This note is to announce the first BETA release of patch 2 to version
> 3.1 of gawk.

It is slow. Frighteningly slow.

Using 170MB of data (866,000 lines), the program
    awk '{ print }' > /dev/null
 increased its run time from 4.4s (awk 3.1.0) to 4.9s (3.1.1l).
That is user time as reported by Unix time command; sys time
increased from 0.6s to 1s.

These timings are averaged from 5 runs, after an initial run
whose times were ignored (to get things cached).
That was on an x86 linux box. I'll try Sparc/Solaris and also 3.1.1.
The system was otherwise idle, and real == user + sys (more-or-less).

More worryingly though, and pointing the finger (tentatively) at
the new regex package, is that
    awk -F= ' NF == 48 { print } ' # NF never does == 48, btw
is 50% slower: 12s rather than 8s real and 0.9s as opposed to 0.53s sys.

I realise the superior functionality of the new regex package but
wonder whether it might be possible to use it only when called
for by a particular expression -- most field separators are not
complex regular expressions.

Not sure if this is the right forum for this sort of feedback, btw.

John.



Mon, 08 Aug 2005 20:43:14 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:



>> This note is to announce the first BETA release of patch 2 to version
>> 3.1 of gawk.

>It is slow. Frighteningly slow.

>Using 170MB of data (866,000 lines), the program
>    awk '{ print }' > /dev/null
> increased its run time from 4.4s (awk 3.1.0) to 4.9s (3.1.1l).
>That is user time as reported by Unix time command; sys time
>increased from 0.6s to 1s.

Um, I have to say that you are exaggerating considerably.  I did some timing
tests.  To create a large file, I `cat'ed 150 copies of doc/gawk.texi into
one big file:

        $ ls -l /tmp/mongofile
        -rw-r--r--    1 arnold   wheel    153547800 Feb 23 11:39 /tmp/mongofile

For all of these tests, I first did `cat /tmp/mongofile > /dev/null' to prime
the buffer cache. (I've got 512M RAM on my system, so it can all fit in
the buffer cache.)

First, gawk 3.1.1, 4 repeats of time ./gawk '{ print }' /tmp/mongofile > /dev/null:

        real    0m21.318s
        user    0m19.559s
        sys     0m0.658s

        real    0m21.411s
        user    0m19.313s
        sys     0m0.705s

        real    0m21.309s
        user    0m19.223s
        sys     0m0.707s

        real    0m21.204s
        user    0m19.686s
        sys     0m0.578s

Now gawk 3.1.1l, 4 repeats of time ./gawk '{ print }' /tmp/mongofile > /dev/null:

        real    0m20.264s
        user    0m17.824s
        sys     0m1.275s

        real    0m20.854s
        user    0m18.213s
        sys     0m1.297s

        real    0m21.664s
        user    0m18.115s
        sys     0m1.219s

        real    0m20.320s
        user    0m18.047s
        sys     0m1.225s

The wall clock times are about the same, or maginally faster for the
new gawk.

The increase in system time is notable, but not terrible.  In particular,
profiling indicated that the amount of time spent reading data is less,
and more time is being spent *printing* data.

Initially, I was worried that the new routine that reads a record wasn't
reading in multiples of the disk block size.  Changing that gave me a
very slight improvement.  I conclude that gawk is spending less time in
user land thinking about data and more time actually moving it around.

The profiling, though, did show me that gawk was spending a lot of
time in the print routine doing work that's not needed for a plain
`print' command.  Modifying the code a bit to special case plain `print'
statments, gave me the following:

My-development-gawk, 4 repeats of time ./gawk '{ print }' /tmp/mongofile > /dev/null:

        real    0m14.434s
        user    0m12.553s
        sys     0m1.082s

        real    0m14.602s
        user    0m12.428s
        sys     0m1.146s

        real    0m14.523s
        user    0m12.551s
        sys     0m1.029s

        real    0m14.497s
        user    0m12.586s
        sys     0m1.072s

(Whether this is a "legitimate optimisation" or a "hack" is open to debate, but
I'll leave it in the code for now.)

Quote:
>More worryingly though, and pointing the finger (tentatively) at
>the new regex package, is that
>    awk -F= ' NF == 48 { print } ' # NF never does == 48, btw
>is 50% slower: 12s rather than 8s real and 0.9s as opposed to 0.53s sys.

I also don't see this kind of result.  Testing separately /tmp/mongofile
with -F= tells me that there are no more than 9 fields on any record.
Thus:

gawk-3.1.1, 4 repeats of time ./gawk -F= 'NF == 12 { print }' /tmp/mongofile:

        real    0m22.173s
        user    0m20.631s
        sys     0m0.527s

        real    0m23.702s
        user    0m20.398s
        sys     0m0.578s

        real    0m22.415s
        user    0m20.508s
        sys     0m0.531s

        real    0m22.564s
        user    0m20.514s
        sys     0m0.504s

gawk-3.1.1l, 4 repeats of time ./gawk -F= 'NF == 12 { print }' /tmp/mongofile:

        real    0m23.365s
        user    0m20.768s
        sys     0m1.217s

        real    0m23.055s
        user    0m20.682s
        sys     0m1.209s

        real    0m23.091s
        user    0m20.730s
        sys     0m1.146s

        real    0m23.048s
        user    0m20.676s
        sys     0m1.170s

These times are within .5 second wall clock time of 3.1.1, and the user-level
CPU time is essentially the same.

Quote:
>I realise the superior functionality of the new regex package but
>wonder whether it might be possible to use it only when called
>for by a particular expression -- most field separators are not
>complex regular expressions.

The regex package is NOT used for single character field splitting,
so you're pointing the finger at the wrong thing, sorry.

I did try to reproduce your core dump with the files you emailed me.
Using both gcc 3.2 and gcc 2.95.3, I had no problems.  I uncommented
the prints, and got output.  In no case did I get a core dump; I'm using
Red Hat 8.0 Linux.

This is for both 3.1.1l, and my current sources, which have updated the
regex package to match what's in glibc CVS.

No-one else has reported core dumps; either no-one else is testing it
(wah, sniff, why not?), or there's something unusual about your system.
I have no idea which, and will be happy to work with you to try to figure
out why it's core dumping for you.  But we need to do that offline,
not in the newsgroup.

Arnold

[ P.S. Alan Linton, drop me a note to make sure I have your email address;
an email that should have worked bounced a few days ago. ]
--

P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 928 569 9018
Nof Ayalon              Cell Phone: +972 51  297-545
D.N. Shimshon 99785     ISRAEL



Thu, 11 Aug 2005 18:28:18 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:





> >> This note is to announce the first BETA release of patch 2 to version
> >> 3.1 of gawk.

> I did try to reproduce your core dump with the files you emailed me.
> Using both gcc 3.2 and gcc 2.95.3, I had no problems.  I uncommented
> the prints, and got output.  In no case did I get a core dump; I'm using
> Red Hat 8.0 Linux.

> This is for both 3.1.1l, and my current sources, which have updated the
> regex package to match what's in glibc CVS.

Yes, this is what I got and reported to you. With the original 3.1.1l (beta)
release, I got core dumps. My gdb backtrace pointed to sigsegv in regex.
Stepan Kasal supplied a patched release updated to the fixed glibc regex,
after which there were no further coredumps.

You are also using the updated glibc regex and have no core dumps.

John.



Fri, 12 Aug 2005 05:09:29 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:





> >> This note is to announce the first BETA release of patch 2 to version
> >> 3.1 of gawk.

> >It is slow. Frighteningly slow.

> >Using 170MB of data (866,000 lines), the program
> >    awk '{ print }' > /dev/null
> > increased its run time from 4.4s (awk 3.1.0) to 4.9s (3.1.1l).
> >That is user time as reported by Unix time command; sys time
> >increased from 0.6s to 1s.

> Um, I have to say that you are exaggerating considerably.  I did some timing
> tests.  To create a large file, I `cat'ed 150 copies of doc/gawk.texi into
> one big file:

> $ ls -l /tmp/mongofile
> -rw-r--r--    1 arnold   wheel    153547800 Feb 23 11:39 /tmp/mongofile

> For all of these tests, I first did `cat /tmp/mongofile > /dev/null' to prime
> the buffer cache. (I've got 512M RAM on my system, so it can all fit in
> the buffer cache.)

> [ ... snip results showing marginal speedup in new version ... ]

Ah yes, I see that too now. But I also see a big slowdown.

Recreating your mongofile from 150 gawk.texis and running tests gives:

        dawn$ awk --version | head -1
        GNU Awk 3.1.1l
        dawn$ time awk -F= 'NF==11' mongofile > /dev/null

        real    0m14.495s
        user    0m13.570s
        sys     0m0.920s

        dawn$ hawk --version | head -1
        GNU Awk 3.1.1
        dawn$ time hawk -F= 'NF==11' mongofile > /dev/null

        real    0m15.015s
        user    0m14.480s
        sys     0m0.460s

        dawn$ gawk --version | head -1
        GNU Awk 3.1.0
        dawn$ time gawk -F= 'NF==11' mongofile > /dev/null

        real    0m9.217s
        user    0m8.700s
        sys     0m0.520s

As mentioned in passing in my earlier post, I was comparing
the new beta with 3.1.0 rather than 3.1.1 and it was here
that the huge slowdown occurred. Note these are with -F=.

John.



Fri, 12 Aug 2005 06:25:10 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:



>> I did try to reproduce your core dump with the files you emailed me.
>> Using both gcc 3.2 and gcc 2.95.3, I had no problems.  I uncommented
>> the prints, and got output.  In no case did I get a core dump; I'm using
>> Red Hat 8.0 Linux.

>> This is for both 3.1.1l, and my current sources, which have updated the
>> regex package to match what's in glibc CVS.

>Yes, this is what I got and reported to you. With the original 3.1.1l (beta)
>release, I got core dumps. My gdb backtrace pointed to sigsegv in regex.
>Stepan Kasal supplied a patched release updated to the fixed glibc regex,
>after which there were no further coredumps.

>You are also using the updated glibc regex and have no core dumps.

>John.

Even with 3.1.1l, which does not have the up-to-date regex, I did not
get core dumps.

I will look at the speed issue in comparison against 3.1.0; I thought you
compared against 3.1.1.

Arnold
--

P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 928 569 9018
Nof Ayalon              Cell Phone: +972 51  297-545
D.N. Shimshon 99785     ISRAEL



Fri, 12 Aug 2005 15:50:26 GMT  
 beta test version of patch 2 to gawk 3.1 available

Quote:

>Ah yes, I see that too now. But I also see a big slowdown.

OK, I see this too.  This change occurred at 3.1.1, which is what confused
me initially.  It's due to the fact that gawk now supports multibyte characters
everywhere; the multibyte code is what's slowing down single-character field
splitting.

I am working on this.  Hopefully I can get the performance closer to 3.1.0.

Arnold
--

P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 928 569 9018
Nof Ayalon              Cell Phone: +972 51  297-545
D.N. Shimshon 99785     ISRAEL



Fri, 12 Aug 2005 19:23:19 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Patch #1 to gawk 3.1 now available

2. Second beta of gawk 3.1 now available

3. 2nd Beta of gawk 3.1.2 now available for testing

4. gawk 3.0.95, beta for gawk 3.1.0, now available

5. gawk version 3.1

6. GNAT-aware beta-test version of GDB available

7. OREXX Windows 3.1 Beta Test

8. ANNOUNCE: GroupKit 3.1 Beta 2 release available

9. gawk FPAT patch: patch to the patch

10. Mac Itcl 3.1 for 8.3.2p1 available for testing

11. public beta of next gawk release now available

12. UNOFFICIAL networking patch for gawk 3.0.4 now available

 

 
Powered by phpBB® Forum Software