AFAIK, all bugs in it have been fixed. Some bugs may still be lurking
but they are more likely to get caught if compression is enabled.
I also replaced COMP_NOTE with static text because xgettext does not
support macros in the argument of N_.
Run: python w32.py. The server listens on port 8900.
It handles only one request. The proper output are numbers
0 through 33999. I have no free disk to test it, but I'm afraid
that the ELinks will hang on Windows after reading 65536 bytes.
Let me know of results of such a test. The ELinks must be compiled
with the zlib library.
Git describe happily picks whatever annotated tag is closest to the
commit. I make use of many annotated tags that correspond not to
ELinks releases but rather to patches posted in bugzilla or sent in
email. So with git describe, the About window can display e.g.
"email/witekfl/2008-02-29-2-g705acfa-dirty", which is not the intended
use of this tag.
In the "next" branch of git.git, git describe apparently supports a
--match option with which it could be made to consider ELinks releases
only. However, that option is not yet in any released version of Git,
and anyhow ELinks should support older versions too.
Instead of using git describe, just show the full SHA-1, like
cg-commit-id would. The About dialog box also displays VERSION
from configure.in, so it isn't even particularly useful to show
the name of the latest tag. (The commit count might help though.)
The build ID now includes both last tagged version, commit generation
since last tagged version, as well as the leading characters of the
commit ID and a flag for dirty working tree.
(cherry picked from commit c2a0d3b969)
The bug was reported by Paul B. Mahol on elinks-users. The example is
from the FTP site he provided:
ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-ia64/
Message-ID: <3a142e750802262008l6fd55be5v44207bc4479dd3fc@mail.gmail.com>
(cherry picked from commit c069403b75)
... so all the tests with responses stretching multiple lines are
actually tested in their entirety.
(cherry picked from commit aa9a847c00,
resolving a conflict due to the use of get_test_opt)
To segregate the historical commits (can't remember why),
I originally placed their pack in an alternate object store,
but later I found that a *.keep file does the job as well.
This gives a considerable speedup in git gc. It takes some
more disk space but OTOH you might then run gc more often
and have fewer loose objects.
real user sys (tested in this order)
1m15.900s 0m59.732s 0m4.336s gc after clone&graft without *.keep
0m23.162s 0m17.549s 0m1.588s gc after clone&graft with *.keep
0m06.932s 0m04.440s 0m0.588s gc after clone&graft&gc with *.keep
0m32.214s 0m24.138s 0m2.284s gc after clone&graft&gc without *.keep
Total size of .git/objects/pack/ was 90592 KiB without *.keep
and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80%
but increased disk space usage by 7.5%.
deflate.c used to call inflateInit2(stream, MAX_WBITS + 32).
This makes zlib first check for a gzip header, and if it doesn't
find one, assume a zlib header. However, if the server said
"Content-Encoding: deflate", then neither header is there, and
zlib does not detect this automatically. So ELinks has to
distinguish between the gzip and deflate encodings, and tell
zlib which one was meant.
This bug resulted in blank pages at blogs.msdn.com accessed
through proxy.suomi.net.
The fully dashed form git-update-server-info is deprecated
in Git 1.5.4 and will cease to work in Git 1.6.0 (unless
PATH is modified). Use git update-server-info instead.
Previously, bzip2_decode_buffer and deflate_decode_buffer left
*new_len unchanged if the compressed input data ended unexpectedly.
This behaviour was also inherited by decode_encoded_buffer,
whose only caller render_encoded_document preinitializes the variable
and so did not crash.
With this change, the functions now store in *new_len the number of
bytes that were successfully decoded, even if more bytes were expected.
An error should perhaps be reported to the user, but I don't think the
previous version did that either, as it returned a non-NULL pointer.
The output should be:
Two lines should be visible.
The second line.
All three tests fail currently when the ELinks is invoked like this:
$ elinks -no-connect path_to_chunked_test
Autoconf and m4 copy the "#" comments from configure.in to configure.
This should make it easier to find the part of configure that was
expanded from a specific check in configure.in.
If a newline has a backslash in front of it, then str_rd replaces it
with a space. However, the newline was in the original config file,
so the line number must still be incremented.
On AMD64 apparently, off_t is long but ELinks detected SIZEOF_OFF_T == 8
and defined OFF_T_FORMAT as "lld", which expects long long and so causes
GCC to warn about a mismatching format specifier. Because --enable-debug
adds -Werror to $CFLAGS, this warning breaks the build. When both
SIZEOF_LONG and SIZEOF_LONG_LONG are 8, ELinks cannot know which type
it should use.
To fix this, do not attempt to find a format specifier for off_t itself.
Instead cast all printed off_t values to a new typedef off_print_T that
is large enough, and replace OFF_T_FORMAT with OFF_PRINT_FORMAT which
is suitable for off_print_T altough not necessarily for off_t. ELinks
already had a similar scheme with time_print_T and TIME_PRINT_FORMAT.
