Re: wget 1.11.1 make test fails
Hello Micah,
On Monday, March 31, 2008 at 11:39:43 -0700, Micah Cowan wrote:
could you try to isolate which part of test_dir_matches_p is failing?
The only failing src/utils.c 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.
| ALL TESTS PASSED
| Tests run: 7
Of course this test then fails on newer systems.
Alain.
Re: wget 1.11.1 make test fails
Alain Guibert [EMAIL PROTECTED] writes:
Hello Micah,
On Monday, March 31, 2008 at 11:39:43 -0700, Micah Cowan wrote:
could you try to isolate which part of test_dir_matches_p is failing?
The only failing src/utils.c 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.
It sounds like a libc problem rather than a gcc problem. Try
#undefing SYSTEM_FNMATCH in sysdep.h and see if it works then.
RE: Looking for 1.9.1 user manual
I've looked through both wget-1.9.1.tar.gz and wget-1.9.tar.gz and do not see a user manual. An example of what I'm calling a user manual is at http://www.gnu.org/software/wget/manual/wget.html for 1.11.1, but I do not see previous versions available there. Is there another place I can look? Please cc me as I'm not on the mailing list. Thanks, Kevin -Original Message- From: Steven M. Schweda [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 7:11 PM To: WGET@sunsite.dk Cc: Kevin Low Subject: Re: Looking for 1.9.1 user manual From: Kevin.Low What I'm looking for today is simply, the 1.9.1 user manual. [...] Do you seek anything which is not part of the usual source kit(s), as seen, for example, at: http://ftp.gnu.org/gnu/wget/ ? (Pick a version, any version...) Steven M. Schweda [EMAIL PROTECTED] 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: wget 1.11.1 make test fails
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hrvoje Niksic wrote:
Alain Guibert [EMAIL PROTECTED] writes:
Hello Micah,
On Monday, March 31, 2008 at 11:39:43 -0700, Micah Cowan wrote:
could you try to isolate which part of test_dir_matches_p is failing?
The only failing src/utils.c 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.
Well, that's assuming you pass it the FNM_PATHNAME flag (which, for
dir_matches_p, we always do).
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 and whatnot?
- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer,
and GNU Wget Project Maintainer.
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH86+L7M8hyUobTrERApHKAJsFbO8+PtAqFhHJ2Psv1AuKSy17YwCcDsi2
9WHcJ0Pzkc4XmNbcEUCXf6U=
=r8ZV
-END PGP SIGNATURE-
Re: Looking for 1.9.1 user manual
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: I've looked through both wget-1.9.1.tar.gz and wget-1.9.tar.gz and do not see a user manual. An example of what I'm calling a user manual is at http://www.gnu.org/software/wget/manual/wget.html for 1.11.1, but I do not see previous versions available there. Is there another place I can look? All source tarballs come with the texinfo user manual, which is the usual documentation format for GNU projects. If you go visit the doc/ source directory, and have GNU Info installed, you can simply run: info ./wget.info to access the manual (if you've never used info before, you might want to run info info first). Alternatively, you can generate the HTML documentation, if you have texi2html installed (you may be able to obtain it from your OS vendor, or else in source form from texi2html.cvshome.org). To do this, go to the Wget source directory and do: ./configure cd doc make wget_toc.html - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH87I97M8hyUobTrERAl7nAJ9PlQ8kFPnCCVL82V4mTUVOfwX8PACeKjpv jPhgzN/l3D47XzdlPv85ZYI= =MMmn -END PGP SIGNATURE-
Re: wget fails using proxy with https-protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micah Cowan wrote: Julien, I've CC'd you, in case you think this might be something you'd want to add to your GSoC proposal. If it _is_, it's probably something that should be done before the rest, so I can backport it into the 1.11 branch for a 1.11.2 release (since this is an important regression), rather than make people wait for 1.12 to come out (which is where I expect the rest of the authorization improvements would go). Er, on reflection, that's a terrible idea, given that coding for GSoC doesn't even start until nearly June, and this is a serious regression that should be fixed as soon as it can be got to. Still, if you'd like to tackle it out-of-band, that'd be handy. :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH87mY7M8hyUobTrERAuyjAJ0XJ8ImAFZ/J49EGQlc+HWWNdxhQACgiK3U bgyhQErH//V6bDkaeE9mLYM= =3fn1 -END PGP SIGNATURE-
FW: Looking for 1.9.1 user manual
I downloaded and FTP'd, and untarred/expanded both of these: wget-1.9.tar.gz texi2html-1.78.zip They created directories, /home/portal/klow/wget-1.9 /home/portal/klow/texi2html-1.78 I ran ./configure in each one of them, then tried the make $ cd wget-1.9/doc $ make wget_toc.html texi2html -expandinfo -split_chapter ./wget.texi Make: Cannot load texi2html. Stop. *** Error exit code 1 # I added the texi2html directory to the PATH... $ PATH=$PATH:home/portal/klow/texi2html-1.78 $ make... (same error) In my texi2html-1.78 directory there are these similarly named files: texi2html.init texi2html.pl texi2html.spec texi2html.spec.in texi2html_configured.pl Is the make file trying to find one of them? Or what is the make program trying to find when it says cannot load texi2html? I'm not on the mailing list - please cc me. Thanks, Kevin -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 11:20 AM To: Kevin Low Cc: Wget Subject: Re: Looking for 1.9.1 user manual -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: I've looked through both wget-1.9.1.tar.gz and wget-1.9.tar.gz and do not see a user manual. An example of what I'm calling a user manual is at http://www.gnu.org/software/wget/manual/wget.html for 1.11.1, but I do not see previous versions available there. Is there another place I can look? All source tarballs come with the texinfo user manual, which is the usual documentation format for GNU projects. If you go visit the doc/ source directory, and have GNU Info installed, you can simply run: info ./wget.info to access the manual (if you've never used info before, you might want to run info info first). Alternatively, you can generate the HTML documentation, if you have texi2html installed (you may be able to obtain it from your OS vendor, or else in source form from texi2html.cvshome.org). To do this, go to the Wget source directory and do: ./configure cd doc make wget_toc.html - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH87I97M8hyUobTrERAl7nAJ9PlQ8kFPnCCVL82V4mTUVOfwX8PACeKjpv jPhgzN/l3D47XzdlPv85ZYI= =MMmn -END PGP SIGNATURE-
Re: FW: Looking for 1.9.1 user manual
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: I downloaded and FTP'd, and untarred/expanded both of these: wget-1.9.tar.gz texi2html-1.78.zip They created directories, /home/portal/klow/wget-1.9 /home/portal/klow/texi2html-1.78 I ran ./configure in each one of them, then tried the make snip Is the make file trying to find one of them? Or what is the make program trying to find when it says cannot load texi2html? It means you don't have texi2html installed where it can find it: I included a link to where it can be found in my previous message. It also appears that you might have to do a make all in the doc directory before make wget_toc.html will work (otherwise it will complain about a certain missing file). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8+ru7M8hyUobTrERApGIAJ0YMbqpAj0iFf/TEGSbcsTFL+MzowCfRzxq bYB6mtP/SZQUzbBcirq6AAc= =oIRr -END PGP SIGNATURE-
Re: wget 1.11.1 make test fails
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 and
whatnot?
The conventional wisdom among free software of the 90s was that
fnmatch() was too buggy to be useful. For that reason all free shells
rolled their own fnmatch, as did other programs that needed it,
including Wget. Maybe the conventional wisdom was right for the
reporter's system.
Another possibility is that something else is installing fnmatch.h in
a directory on the compiler's search path and breaking the system
fnmatch. IIRC Apache was a known culprit that installed fnmatch.h in
/usr/local/include. That was another reason why Wget used to
completely ignore system-provided fnmatch.
In any case, it should be easy enough to isolate the problem:
#include stdio.h
#include fnmatch.h
int main()
{
printf(%d\n, fnmatch(foo*, foo/bar, FNM_PATHNAME));
return 0;
}
It should print a non-zero value.
Re: wget 1.11.1 make test fails
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 are targeting. Supporting I18N file names would require modifications to our fnmatch; but on the other hand, we still need it for Windows, so we'd have to make those changes anyway. Providing added value in our fnmatch implementation should go a long way towards preventing complaints of code bloat. In particular, it would probably resolve the remaining issue with that one bug you reported about fnmatch() failing on strings whose encoding didn't match the locale. It would. Additionally, I've been toying with the idea of adding something like a ** to match all characters, including slashes. That would be great. That kind of thing is known to zsh users anyway, and it's a useful feature.
Tips on Applying for Wget at GSoC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following message is intended to describe how I prioritize GSoC applications; it is intended to be useful as a basis for students to improve their chances of getting accepted. It's my assumption that serious GSoC applicants will already be subscribed to this list, or at least be reading it through the archives or gmane's news portal. The GNU Project will not be informed on the number of student slots it will receive, until some time after the application period has closed. Once the GNU Project's GSoC administrator has been informed of this, the slots will be doled out to individual GNU projects as appropriate. I have been informed that, based on experience from last year, the administrator believes it is likely that Wget will receive just one student slot. I am personally hopeful that we'll be allotted at least two, but I may be forced to choose just one. If that's the case, it will be a truly heart-wrenching decision, as there are already several quite-excellent proposals. This being the case, please bear in mind that if you are not accepted this year, it doesn't mean that I wasn't interested in your application. You may have missed getting a slot by a very thin margin: competition is close. Please don't get discouraged, and please do consider submitting your proposal to Wget again next year, if you are still an eligible student. The primary motivation for the policies by which I intend to rate applications, is selfish: what is most likely to benefit Wget, both now and in the long term? To this end, the better an asset a given student appears phe may become to the GNU Wget development team, and the more important the proposed work is to Wget, the more attractive the application is to me. So, without further ado, the specific factors I've been using to evaluate existing applications. These are _not_ listed in order of priority: they all contribute together towards the final decision. Proficiency as a Programmer - --- People with significant experience and expertise in coding with the C programming language, who can demonstrate that they've learned good coding habits and can avoid common pitfalls in C, are likelier to get more work done at a higher level of quality, in the period of time allotted to them for coding. It also means less hand-holding to me, which is attractive because I already have insufficient time to do the work that needs to be done for Wget. An alternative approach would of course be that I should give consideration to willing and eager, but less-experienced students, so that they may have the benefit of enhanced knowledge and experience, and become overall better coders. However, the reason for Wget's involvement in GSoC is a selfish one: to better Wget. Bettering others is of course desirable as a secondary goal; but it cannot be our primary goal. Therefore, we are looking for students who are already well-studied, wherever possible. It is of course impossible for me to establish how proficient someone is with C unless they supply me with example source code. This can be examples of patches, contributed to Wget or other projects; however, unless these patches contribute significant additional code, rather than being mainly tweaks to existing functionality, they'll tell me relatively little. The ideal would be to link to complete programs or libraries that the student has written. It's OK if it's code you now find embarrassing: I'm interested in what kind of a coder you are _now_, not what kind of a coder you once were. If you'd do things differently today, explain _how_. But please give me code. :) Aptitude for the Proposed Task - -- In addition to understanding how to write in C, you need to understand the problem domain of whatever it is you're proposing to do, and how it might be solved. Are you working on HTTP authentication? Your proposal should demonstrate understanding of RFC 2617, and probably the underlying security principles. Implementing internationalization enhancements? I need to see, in the detailed description, or at least the public comment threads, a sufficient description of the solution as to instill confidence that you understand the basics of technologies such as UTF-8 encoding, handling transcoding where appropriate, etc. Is your proposal likely to require organization of medium-to-large quantities of data? I'd like to see that you have a solid understanding of algorithms and ADTs, and that you have an idea as to which ones might be appropriate for storing and looking up the data you'll be using. * Please note, the above examples are _examples_; they are not meant to imply anything about whether the students who have actually submitted proposals for those features have failed to demonstrate aptitude. The specific cases of HTTP auth and i18n each have exactly one proposal so far, and I already have confidence in both students involved that they
Re: Tips on Applying for Wget at GSoC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micah Cowan wrote: The following message is intended to describe how I prioritize GSoC applications; it is intended to be useful as a basis for students to improve their chances of getting accepted. It's my assumption that serious GSoC applicants will already be subscribed to this list, or at least be reading it through the archives or gmane's news portal. The content of this post is now also available on the Wget Wgiki: http://wget.addictivecode.org/SummerOfCode (It is read-only.) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9Brf7M8hyUobTrERAu+NAJ9y/MoWbX26mJKNtN68Q3swErA5EACfXitm 5Pvu1wvlDlLCmBtwaNaVpNk= =kukh -END PGP SIGNATURE-
