2008/4/5, Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Stenberg wrote:
This system allows us to write unit-tests if we'd like to, but mostly so
far we've focused to test it system-wide. It is hard enough for us!
Yeah, I thought I'd seen
2008/4/5, Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Stenberg wrote:
This system allows us to write unit-tests if we'd like to, but mostly so
far we've focused to test it system-wide. It is hard enough for us!
Yeah, I thought I'd seen
an automated test suite definitely
sounds like ignoring the costs of such an abstraction layer.
I _am_ thinking that it'd probably be best to forgo the idea of
one-to-one correspondence of Berkeley sockets, and pass around a struct
net_connector * (and struct net_listener *), so we're not forced
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Micah Cowan wrote:
Yeah. But we're not doing streaming. And you still haven't given much
explanation for _why_ it's as hard and time-consuming as you say. Making
a claim and demonstrating it are different things, I think.
To be clear, I'm not
2008/4/4, Micah Cowan [EMAIL PROTECTED]:
IMO, if it's worth testing, it's probably better to have external
linkage anyway.
I got it.
1) Select functions which can be tested in unit test.
But How can I select them? is difficult.
Basically the less dependency the function
2008/4/5, Yoshihiro Tanaka [EMAIL PROTECTED]:
2008/4/4, Micah Cowan [EMAIL PROTECTED]:
IMO, if it's worth testing, it's probably better to have external
linkage anyway.
I got it.
1) Select functions which can be tested in unit test.
But How can I select them
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yoshihiro Tanaka wrote:
2008/4/5, Yoshihiro Tanaka [EMAIL PROTECTED]:
Yes, since I want to write proposal for Unit testing, I can't skip this
problem. But considering GSoC program is only 2 month, I'd rather narrow
down the target - to gethttp
On Sat, 5 Apr 2008, Micah Cowan wrote:
Or did you mean to write wget version of socket interface? i.e. to write
our version of socket, connect,write,read,close,bind, listen,accept,,,?
sorry I'm confused.
Yes! That's what I meant. (Except, we don't need listen, accept; and we only
need bind
Micah Cowan [EMAIL PROTECTED] writes:
Or did you mean to write wget version of socket interface? i.e. to
write our version of socket, connect,write,read,close,bind,
listen,accept,,,? sorry I'm confused.
Yes! That's what I meant. (Except, we don't need listen, accept; and
we only need bind
emulated versions.
Unless you're willing to spend a lot of time in careful design of these
abstractions, I think this is a mistake.
Related:
In the curl project we took a simpler route: we have our own dumb test servers
in the test suite to run tests against and we have single files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Stenberg wrote:
On Sat, 5 Apr 2008, Micah Cowan wrote:
Or did you mean to write wget version of socket interface? i.e. to
write our version of socket, connect,write,read,close,bind,
listen,accept,,,? sorry I'm confused.
Yes! That's what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Stenberg wrote:
In the curl project we took a simpler route: we have our own dumb test
servers in the test suite to run tests against and we have single files
that describe each test case: what the server should respond, what the
protocol
.
While Daniel was of course right that we'd need listen, accept, etc, we
_wouldn't_ need them to begin using this layer to test against http.c.
We wouldn't even need bind, if we didn't include --bind-address in our
first tests of the http code.
This would mean we'd need to separate uses of read
Hello, I want to ask about Unit test of Wget in the future.
I want to ask about unit test.
Now unit test of Wget is written only for following .c files.
-- http.c init.c main.c res.c url.c utils.c (test.c)
So as written in Wiki, new unit test suite is necessary.
(ref. http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yoshihiro Tanaka wrote:
Hello, I want to ask about Unit test of Wget in the future.
I want to ask about unit test.
Now unit test of Wget is written only for following .c files.
-- http.c init.c main.c res.c url.c utils.c (test.c)
So
Alain Guibert [EMAIL PROTECTED] writes:
On Wednesday, April 2, 2008 at 23:09:52 +0200, Hrvoje Niksic wrote:
Micah Cowan [EMAIL PROTECTED] writes:
It's hard for me to imagine an fnmatch that ignores FNM_PATHNAME
The libc 5.4.33 fnmatch() supports FNM_PATHNAME, and there is code
apparently
. It is not a '*' anymore, so the loop exits
prematurely. Just below, a test for NUL returns 0.
Thanks for the analysis. Looking at the current fnmatch code in
gnulib, it seems that the fix is to change that NUL test to something
like:
if (c == '\0')
{
/* The wildcard(s
the end of the pattern,
and points to a NUL. It is not a '*' anymore, so the loop exits
prematurely. Just below, a test for NUL returns 0.
Thanks for the analysis. Looking at the current fnmatch code in
gnulib, it seems that the fix is to change that NUL test to something
like
(the libc code uses only this alias). Anyway I had
noticed your comment about incompatible headers, and double-checked your
little test program also with explicit value 1: same results.
BTW everybody should be able to reproduce the make test failure, on any
system, just by #undefining SYSTEM_FNMATCH
On Thursday, April 3, 2008 at 9:14:52 -0700, Micah Cowan wrote:
Are you certain you rebuilt cmpt.o? This seems pretty unlikely, to me.
Certain: make test after touching src/sysdep.h rebuilds both cmpt.o, the
normal in src/ and the one in tests/. And both those cmpt.o become
784 bytes bigger
Alain Guibert [EMAIL PROTECTED] writes:
This old system does HAVE_WORKING_FNMATCH_H (and thus
SYSTEM_FNMATCH). When #undefining SYSTEM_FNMATCH, the test still
fails at the very same line. And then it also fails on modern
systems. I guess this points at the embedded src/cmpt.c:fnmatch
On Wednesday, April 2, 2008 at 23:09:52 +0200, Hrvoje Niksic wrote:
Micah Cowan [EMAIL PROTECTED] writes:
It's hard for me to imagine an fnmatch that ignores FNM_PATHNAME
The libc 5.4.33 fnmatch() supports FNM_PATHNAME, and there is code
apparently intending to return FNM_NOMATCH on a slash.
advances the pattern pointer. This one reaches the end of the pattern,
and points to a NUL. It is not a '*' anymore, so the loop exits
prematurely. Just below, a test for NUL returns 0.
The body of the loop, returning FNM_NOMATCH on a slash, is not executed
at all. That isn't moderately broken
below, a test for NUL returns 0.
The body of the loop, returning FNM_NOMATCH on a slash, is not executed
at all. That isn't moderately broken, is it?
I haven't stepped through it, but it sure looks broken to my eyes too. I
am tired at the moment, though, so may be missing something.
GNUlib has
of dir_matches_p() and fnmatch() to guess what
is supposed to happen. But with false replaced by true, this test and
following succeed.
| ALL TESTS PASSED
| Tests run: 7
Of course this test then fails on newer systems.
Alain.
, false },
I don't understand enough of dir_matches_p() and fnmatch() to guess
what is supposed to happen. But with false replaced by true, this
test and following succeed.
'*' is not supposed to match '/' in regular fnmatch.
It sounds like a libc problem rather than a gcc problem. Try
test_array[] line is:
| { { *COMPLETE, NULL, NULL }, foo/!COMPLETE, false },
I don't understand enough of dir_matches_p() and fnmatch() to guess
what is supposed to happen. But with false replaced by true, this
test and following succeed.
'*' is not supposed to match '/' in regular fnmatch
Micah Cowan [EMAIL PROTECTED] writes:
It sounds like a libc problem rather than a gcc problem. Try
#undefing SYSTEM_FNMATCH in sysdep.h and see if it works then.
It's hard for me to imagine an fnmatch that ignores FNM_PATHNAME: I
mean, don't most shells rely on this to handle file globbing
Micah Cowan [EMAIL PROTECTED] writes:
I'm wondering whether it might make sense to go back to completely
ignoring the system-provided fnmatch?
One argument against that approach is that it increases code size on
systems that do correctly implement fnmatch, i.e. on most modern
Unixes that we
Hello,
With an old gcc 2.7.2.1 compiler, wget 1.11.1 make test fails:
| gcc -I. -I. -I./../src -DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\
-DLOCALEDIR=\/usr/local/share/locale\ -O2 -Wall -DTESTING -c ../src/test.c
| ../src/test.c: In function `all_tests':
| ../src/test.c:51: parse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alain Guibert wrote:
Hello,
With an old gcc 2.7.2.1 compiler, wget 1.11.1 make test fails:
| gcc -I. -I. -I./../src -DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\
-DLOCALEDIR=\/usr/local/share/locale\ -O2 -Wall -DTESTING -c ../src
Test Message
Test Message
On Wed, 20 Feb 2008 16:00:06 +0500
sohail [EMAIL PROTECTED] wrote:
Test Message
Now my day is complete. Not one, but two worthless 'test' messages.
--
Gerard
[EMAIL PROTECTED]
Marijuana: Nature's way of saying, Hi!
signature.asc
Description: PGP signature
A loop-test; trouble with my subscription.
--gv
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
I have tried out again the current wget version from svn to see the
progress on
various discussed problems.
Someone recently reported an inability to specify the prefix
I have tried out again the current wget version from svn to see the progress on
various discussed problems.
Someone recently reported an inability to specify the prefix for libssl.
Hmm, yes, I reported this a year ago ;-)
That works now again as expected. When I specify
Dharmesh Vyas wrote:
Hello Group,
Are there any automated tests available for Wget that comes with the
compoent itself or Is there any way we can write some test for it?
actually, yes. in the SVN trunk:
http://svn.dotsrc.org/repo/wget/trunk/
we have just implemented support for unit testing
...
Is it possible to use WGET to test a website for being up only. I don't want to download any files just test the site for availability? Any ideas?
Psudo code: wget www.google.com. Is connected? YES/NO. If YES write answer to a log. If No write to a log and timestamp it.
Thanks
--
Frank McCown
Hello,
I have been looking around and haven't found an answer yet...
Is it possible to use WGET to test a website for being up only. I don't want to
download any files just test the site for availability? Any ideas?
Psudo code: wget www.google.com. Is connected? YES/NO. If YES write
Thanks a lot for setting this up. I'll try to get Wget to log in.
BTW how are you running IIS on the Linux workstation? vmware?
Hi!
You may use this server to test NTLM-authentication on wget.
http://212.50.205.135/ntlm/
usr: testuser
pwd: DummyUser
Server is not promised to be available all the time, because
it is actually running under my linux workstation.
Server is MS Windows Server 2003
Is there a test server where one can try out NTLM authentication? I'm
working on adapting Daniel's code to Wget, and having a test server
would be of great help.
On Mon, 4 Apr 2005, Hrvoje Niksic wrote:
Is there a test server where one can try out NTLM authentication? I'm
working on adapting Daniel's code to Wget, and having a test server would be
of great help.
Just for your info:
I had friends providing the test servers for both host and proxy
For now I'd start with applying David's patch, so that people can test
its functionality. It is easy to fix the behavior of `wget -q -b'
later.
David, can I apply your patch now?
Hrvoje Niksic wrote:
For now I'd start with applying David's patch, so that people can test
its functionality. It is easy to fix the behavior of `wget -q -b'
later.
David, can I apply your patch now?
Sure.
The attached patch corrects a few minor formatting details but is otherwise
identical
Thanks for the patch, I've now applied it to CVS.
You might want to add a comment in front of fake_fork() explaining
what it does, and why. The comment doesn't have to be long, only
several sentences so that someone reading the code later understands
what the heck a fake fork is and why we're
Hrvoje Niksic wrote:
Thanks for the patch, I've now applied it to CVS.
You might want to add a comment in front of fake_fork() explaining
what it does, and why. The comment doesn't have to be long, only
several sentences so that someone reading the code later understands
what the heck a fake
David Fritz [EMAIL PROTECTED] writes:
Ok, I'll submit a patch latter tonight. Do you think it would be a
good idea to include README.fork in windows/ (the directory with the
Windows Makefiles, etc. in it)?
I don't think that's necessary. Simply explain how the fork emulation
works in
-- +39-041-5907472 fax
-Original Message-
From: David Fritz [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 20, 2004 2:37 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PATCH] A working implementation of
fork_to_background() under
Windows please test
Attached
have a small
performance impact and introduce some race-conditions, but I think the
advantages (having b work) outweigh the disadvantages.
The implementation is, I hope, fairly straightforward. I have attempted to
explain it in moderate detail in an attached README.
I'm hoping others can test
!gvw I?uDHQLa!-6
U??#brx|bN$Qv
`?8Lf2o#R4SF#p;3rB*uX6BFF8L
!a$TLpxzAh7E^R)m
X].X%N?Heyp Sv~_CkNhD
98C9TJaRcXIO5??P'eA%MpP5;Fj$(VS{_,`v
d2'w?e6LzixR;j
2[a
vsIzTC$IM/V-pK$9*Z;o{KH
2s9`5|
1r,/Sng48|*OW?:x85d-*{rAr?P/[Qe
^ )#q{Ow5i /rqds-?5)?xwnwE9eX7??39~wV
\
ts(k,0:~-7vU?*7p
[
is`0{\`
attachment:
The message cannot be represented in 7-bit ASCII encoding and has been sent as a
binary attachment.
doc.zip
Description: Binary data
Test
--
SunSITE.dk Staff
http://SunSITE.dk
I have run across this problem too. It is because with Linux 2.4.18 (and
other
versions??) in certain circumstances, gettimeofday() is broken and will
jump
backwards. See http://kt.zork.net/kernel-traffic/kt20020708_174.html#1.
Is there any particular reason for this assert? If there is,
Hartwig, Thomas wrote:
I got a assert exit of wget in retr.c in the function calc_rate
because msecs is 0 or lesser than 0 (in spare cases).
I don't know how perhaps because I have a big line to the server or
the wrong OS. To get worked with this I patched retr.c setting
msecs = 1 if equal
57 matches
Mail list logo
