Re: wget 1.10 alpha 2
Doug Kaufman <[EMAIL PROTECTED]> writes: > On Wed, 20 Apr 2005, Hrvoje Niksic wrote: > >> Herold Heiko <[EMAIL PROTECTED]> writes: >> >> I am greatly surprised. Do you really believe that Windows users >> outside an academic environment are proficient in using the compiler? >> I have never seen a home Windows installation that even contained a >> compiler, the only exception being ones that belonged to professional >> C or C++ developers. > > This is what Cygwin is all about. Once you open up the Cygwin bash > shell, all you have to do with most source code is "configure; make; > make install". Oh, I know that and I *love* Cygwin and use it all the time (while in Windows)! But that is beside the point because this problem doesn't occur under Cygwin in the first place -- Cygwin compilation is as clean as it gets. My point was that a typical Windows (not Cygwin) user doesn't know about the compilation process, nor can he be bothered to learn. That's a great shame, but it's something that's not likely to change. Making the code uglier for the sake of ordinary Windows users willing to compile it brings literally no gain. The above shouldn't be construed as not wanting to support Windows at all. There are Windows users, on this list and elsewhere, who are perfectly able and willing to compile Wget from source. But those users are also able to read the documentation, to turn off optimization for offending functions, not to mention to upgrade their compiler, or get a free one that is much less buggy (the Borland compiler comes to mind, but there are also Mingw, Cygwin, Watcom, etc.)
Re: wget 1.10 alpha 2
On Wed, 20 Apr 2005, Hrvoje Niksic wrote: > Herold Heiko <[EMAIL PROTECTED]> writes: > > I am greatly surprised. Do you really believe that Windows users > outside an academic environment are proficient in using the compiler? > I have never seen a home Windows installation that even contained a > compiler, the only exception being ones that belonged to professional > C or C++ developers. This is what Cygwin is all about. Once you open up the Cygwin bash shell, all you have to do with most source code is "configure; make; make install". I am not a programmer and have been compiling programs for several years. As long as the program copiles cleanly, there shouldn't be a problem under Windows. I don't have any idea of how many Windows users would try to patch the code if it didn't compile "out of the box." > The very idea that a Windows user might grab source code and compile a > package is strange. I don't remember ever seeing a Windows program > distributed in source form. See, for example, "htmldoc" which converts html into a pdf file. The free version is only distributed as source code. Or see "consoletelnet", distributed both as source and binary. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED]
Re: wget 1.10 alpha 2
On Wednesday 20 April 2005 02:42 pm, Hrvoje Niksic wrote: > Mauro Tortonesi <[EMAIL PROTECTED]> writes: > > On Wednesday 20 April 2005 04:58 am, Hrvoje Niksic wrote: > >> Mauro Tortonesi <[EMAIL PROTECTED]> writes: > >> > i totally agree with hrvoje here. in the worst case, we can add an > >> > entry in the FAQ explaining how to compile wget with those buggy > >> > versions of microsoft cc. > >> > >> Umm. What FAQ? :-) > > > > the official FAQ: > > > > http://www.gnu.org/software/wget/faq.html > > This is the first time that I see it. It's actually pretty good, I > like it. yes, i like it very much too. it will need an update after the release of 1.10, though. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human & Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.10 alpha 2
Mauro Tortonesi <[EMAIL PROTECTED]> writes: > On Wednesday 20 April 2005 04:58 am, Hrvoje Niksic wrote: >> Mauro Tortonesi <[EMAIL PROTECTED]> writes: >> > i totally agree with hrvoje here. in the worst case, we can add an >> > entry in the FAQ explaining how to compile wget with those buggy >> > versions of microsoft cc. >> >> Umm. What FAQ? :-) > > the official FAQ: > > http://www.gnu.org/software/wget/faq.html This is the first time that I see it. It's actually pretty good, I like it.
Re: wget 1.10 alpha 2
On Wednesday 20 April 2005 05:55 am, Herold Heiko wrote: > (sorry for the late answer, three days of 16+ hours/day migration aren't > fun, UPS battery exploding inside the UPS almost in my face even less) > > > -Original Message- > > From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] > > > > Herold Heiko <[EMAIL PROTECTED]> writes: > > > do have a compiler but aren't really developers (yet) (for example > > > first year CS students with old lab computer compilers). > > > > From my impressions of the Windows world, non-developers won't touch > > source code anyway -- they will simply use the binary. > > I feel I must dissent. Even today I'm not exactly a developer, I certainly > wasn't when I first placed my greedy hands on wget sources (in order to add > a couple of chars to URL_UNSAFE... back in 98 i think). I just knew where I > could use a compiler and followed instructions. > I'd just like wget still being compilable in an old setup by (growing) > newbies, for the learning value. Maybe something like a small note in the > windows/Readme instructions would be ok, as by the enclosed patch ? publishing a separate patch on the website and including it in the tarball along with a note in windows/Readme is ok for me. but including an ugly workaround in the main sources just to support some older versions of microsoft c is definitely not. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human & Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.10 alpha 2
On Wednesday 20 April 2005 04:58 am, Hrvoje Niksic wrote: > Mauro Tortonesi <[EMAIL PROTECTED]> writes: > > i totally agree with hrvoje here. in the worst case, we can add an > > entry in the FAQ explaining how to compile wget with those buggy > > versions of microsoft cc. > > Umm. What FAQ? :-) the official FAQ: http://www.gnu.org/software/wget/faq.html -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human & Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.10 alpha 2
Herold Heiko <[EMAIL PROTECTED]> writes: >> From my impressions of the Windows world, non-developers won't touch >> source code anyway -- they will simply use the binary. > > I feel I must dissent. I am greatly surprised. Do you really believe that Windows users outside an academic environment are proficient in using the compiler? I have never seen a home Windows installation that even contained a compiler, the only exception being ones that belonged to professional C or C++ developers. The very idea that a Windows user might grab source code and compile a package is strange. I don't remember ever seeing a Windows program distributed in source form. > Even today I'm not exactly a developer, I certainly wasn't when I > first placed my greedy hands on wget sources (in order to add a > couple of chars to URL_UNSAFE... back in 98 i think). I just knew > where I could use a compiler and followed instructions. I'd just > like wget still being compilable in an old setup by (growing) > newbies, for the learning value. Maybe something like a small note > in the windows/Readme instructions would be ok, as by the enclosed > patch ? That would be fine with me.
RE: wget 1.10 alpha 2
(sorry for the late answer, three days of 16+ hours/day migration aren't fun, UPS battery exploding inside the UPS almost in my face even less) > -Original Message- > From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] > Herold Heiko <[EMAIL PROTECTED]> writes: > > > do have a compiler but aren't really developers (yet) (for example > > first year CS students with old lab computer compilers). > > From my impressions of the Windows world, non-developers won't touch > source code anyway -- they will simply use the binary. I feel I must dissent. Even today I'm not exactly a developer, I certainly wasn't when I first placed my greedy hands on wget sources (in order to add a couple of chars to URL_UNSAFE... back in 98 i think). I just knew where I could use a compiler and followed instructions. I'd just like wget still being compilable in an old setup by (growing) newbies, for the learning value. Maybe something like a small note in the windows/Readme instructions would be ok, as by the enclosed patch ? > The really important thing is to make sure that the source works for > the person likely to create the binaries, in this case you. Ideally > he should have access to the latest compiler, so we don't have to > cater to brokenness of obsolete compiler versions. This is not about I must confess I'm torn between the two options. Your point is very valid, on the other hand while it is still possible I'd like to continue using an old setup exactly because there are still plenty of those around and I'd like to catch these problems. Unfortunately I don't have the time to test everything on two setups, so I think I'll continue with the old one till easily feasable. > Also note that there is a technical problem with your patch (if my > reading of it is correct): it unconditionally turns on debugging, > disregarding the command-line options. Is it possible to save the old > optimization options, turn off debugging, and restore the old options? > (Borland C seems to support some sort of "#pragma push" to achieve > that effect.) It seems not, msdn mentions push only for "#pragma warning", not for "#pragma optimize" :( > optimization, or with a lesser optimization level. Ideally this > would be done by configure.bat if it detects the broken compiler > version. I tried but didn't find a portably (w9x-w2x) way to do that, since in w9x we can't redirect easily the standard error used by cl.exe. Possibly this could be worked around by running the test from a simple perl script, on the other hand today perl is required (on released packages) only in order to build the documentation, not for the binary, adding another dependency would be a pity. > You mean that you cannot use later versions of C++ to produce > Win95/Win98/NT4 binaries? I'd be very surprised if that were the Absolutely not, what I meant is, later versions can't be installed on older windows operating systems. I think Visual Studio 6 is the last MS compiler which runs on even NT4. > > Personally I feel wget should try to still support that not-so-old > > compiler platform if possible, > > Sure, but in this case some of the burden falls on the user of the > obsolete platform: he has to turn off optimization to avoid a bug in > his compiler. That is not entirely unacceptable. I concur, after all if a note is dropped in the windows/Readme either they will read it, or they will stall due to OpenSSL dependencies (on by default) anyway. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax 20050420.winreadme.diff Description: Binary data
Re: wget 1.10 alpha 2
Mauro Tortonesi <[EMAIL PROTECTED]> writes: > i totally agree with hrvoje here. in the worst case, we can add an > entry in the FAQ explaining how to compile wget with those buggy > versions of microsoft cc. Umm. What FAQ? :-)
Re: wget 1.10 alpha 2
On Friday 15 April 2005 07:24 am, Hrvoje Niksic wrote: > Herold Heiko <[EMAIL PROTECTED]> writes: > > However there are still lots of people using Windows NT 4 or even > > win95/win98, with old compilers, where the compilation won't work > > without the patch. Even if we place a comment in the source file or > > the windows/Readme many of those will be discouraged, say those who > > do have a compiler but aren't really developers (yet) (for example > > first year CS students with old lab computer compilers). > > From my impressions of the Windows world, non-developers won't touch > source code anyway -- they will simply use the binary. > > The really important thing is to make sure that the source works for > the person likely to create the binaries, in this case you. Ideally > he should have access to the latest compiler, so we don't have to > cater to brokenness of obsolete compiler versions. This is not about > Microsoft bashing, either: at at least one point Wget triggered a GCC > bug; I never installed the (ugly) workaround because later versions of > GCC fixed the bug. > > Also note that there is a technical problem with your patch (if my > reading of it is correct): it unconditionally turns on debugging, > disregarding the command-line options. Is it possible to save the old > optimization options, turn off debugging, and restore the old options? > (Borland C seems to support some sort of "#pragma push" to achieve > that effect.) > > There are other possibilities, too: > > * Change the Makefile to compile the offending files without > optimization, or with a lesser optimization level. Ideally this > would be done by configure.bat if it detects the broken compiler > version. > > * Change the Makefile to simply not use optimization by default. This > is suboptimal, but would not be a big problem for Wget in practice > -- the person creating the binaries would use optimization in his > build, which means most people would still have access to an > optimized Wget. i don't really like these two options and i don't think they're necessary when there is a freely downloadable microsoft compiler which works perfectly for us. > > Not yet, but I will certainly. Nevertheless, I think the point is > > the "continue to support existing installation if possble" issue, > > after all VC6 is not free either, and at least one newer commercial > > VC version has been reported to compile without problems. Those, > > however, certainly don't support Win95, probably don't Win98/ME > > or/and NT4 either (didn't yet check though). > > You mean that you cannot use later versions of C++ to produce > Win95/Win98/NT4 binaries? I'd be very surprised if that were the > case! yes, this would be very weird. > > Personally I feel wget should try to still support that not-so-old > > compiler platform if possible, > > Sure, but in this case some of the burden falls on the user of the > obsolete platform: he has to turn off optimization to avoid a bug in > his compiler. That is not entirely unacceptable. i totally agree with hrvoje here. in the worst case, we can add an entry in the FAQ explaining how to compile wget with those buggy versions of microsoft cc. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human & Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.10 alpha 2
Herold Heiko <[EMAIL PROTECTED]> writes: > However there are still lots of people using Windows NT 4 or even > win95/win98, with old compilers, where the compilation won't work > without the patch. Even if we place a comment in the source file or > the windows/Readme many of those will be discouraged, say those who > do have a compiler but aren't really developers (yet) (for example > first year CS students with old lab computer compilers). >From my impressions of the Windows world, non-developers won't touch source code anyway -- they will simply use the binary. The really important thing is to make sure that the source works for the person likely to create the binaries, in this case you. Ideally he should have access to the latest compiler, so we don't have to cater to brokenness of obsolete compiler versions. This is not about Microsoft bashing, either: at at least one point Wget triggered a GCC bug; I never installed the (ugly) workaround because later versions of GCC fixed the bug. Also note that there is a technical problem with your patch (if my reading of it is correct): it unconditionally turns on debugging, disregarding the command-line options. Is it possible to save the old optimization options, turn off debugging, and restore the old options? (Borland C seems to support some sort of "#pragma push" to achieve that effect.) There are other possibilities, too: * Change the Makefile to compile the offending files without optimization, or with a lesser optimization level. Ideally this would be done by configure.bat if it detects the broken compiler version. * Change the Makefile to simply not use optimization by default. This is suboptimal, but would not be a big problem for Wget in practice -- the person creating the binaries would use optimization in his build, which means most people would still have access to an optimized Wget. > Not yet, but I will certainly. Nevertheless, I think the point is > the "continue to support existing installation if possble" issue, > after all VC6 is not free either, and at least one newer commercial > VC version has been reported to compile without problems. Those, > however, certainly don't support Win95, probably don't Win98/ME > or/and NT4 either (didn't yet check though). You mean that you cannot use later versions of C++ to produce Win95/Win98/NT4 binaries? I'd be very surprised if that were the case! > Personally I feel wget should try to still support that not-so-old > compiler platform if possible, Sure, but in this case some of the burden falls on the user of the obsolete platform: he has to turn off optimization to avoid a bug in his compiler. That is not entirely unacceptable.
RE: wget 1.10 alpha 2
> From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > the patch you've posted is really such an ugly workaround > (shame on microsoft Exactly the same opinion here. Please don't misunderstand me, personally for most of my work on windows I use cygnus (including wget) anyway. However there are still lots of people using Windows NT 4 or even win95/win98, with old compilers, where the compilation won't work without the patch. Even if we place a comment in the source file or the windows/Readme many of those will be discouraged, say those who do have a compiler but aren't really developers (yet) (for example first year CS students with old lab computer compilers). I suppose we could leave that stuff present but commented out, and print a warning when configure.bat --msvc is called. Maybe we could even make that warning conditionally (run cl.exe, use the dos/windows find.exe in order to check the output, if 12.00 echo warning) but that would be even more hacky. > have you tried the microsoft visual c++ toolkit 2003? maybe > it works. you can > download it for free at the following URL: > > http://msdn.microsoft.com/visualc/vctoolkit2003/ Not yet, but I will certainly. Nevertheless, I think the point is the "continue to support existing installation if possble" issue, after all VC6 is not free either, and at least one newer commercial VC version has been reported to compile without problems. Those, however, certainly don't support Win95, probably don't Win98/ME or/and NT4 either (didn't yet check though). Personally I feel wget should try to still support that not-so-old compiler platform if possible, even if there are other options, either the direct successor (current VC) or not (free alternatives like cygnus, mingw and borland compilers), in order to keep the development process easily accessible to old installations, in order to have more choices for everybody. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax
Re: wget 1.10 alpha 2
On Wednesday 13 April 2005 07:39 am, Herold Heiko wrote: > With MS Visual Studio 6 still needs attached patch in order to compile > (disable optimization for part of http.c and retr.c if cl.exe version > <=12). > > Windows msvc test binary at http://xoomer.virgilio.it/hherold/ hi herold, the patch you've posted is really such an ugly workaround (shame on microsoft and their freaking compilers) that i am not very willing to merge it into our cvs. have you tried the microsoft visual c++ toolkit 2003? maybe it works. you can download it for free at the following URL: http://msdn.microsoft.com/visualc/vctoolkit2003/ -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human & Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.10 alpha 2
Hrvoje Niksic <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > >> If possible, it seems preferable to me to use the platform's C >> library regex support rather than make wget dependent on another >> library... > > Note that some platforms don't have library support for regexps, so > we'd have to bundle anyway. Oh, and POSIX regexps don't support -- and never will -- non-greedy quantifiers, which are perhaps the most useful single additions of Perl 5 regexps. Incidentally, regex.c bundled with GNU Emacs supports them, along with non-capturing ("shy") groups, another very useful feature.
Re: wget 1.10 alpha 2
[EMAIL PROTECTED] writes: > If possible, it seems preferable to me to use the platform's C > library regex support rather than make wget dependent on another > library... Note that some platforms don't have library support for regexps, so we'd have to bundle anyway.
Re: wget 1.10 alpha 2
> Tobias Tiederle's regex patch: > > regex is a very nice feature which i am planning to include in a future > release of wget (hopefully 1.11). but, since wget supports so many platforms, > we have to come up with a portable implementation of regex and i don't know > yet if from this point of view using the PCRE library as Tobias does in its > patch is the best thing to do. i would like to hear other opinions on this > point. If possible, it seems preferable to me to use the platform's C library regex support rather than make wget dependent on another library... A useful enhancement to Tobias's scheme, if I've understood it correctly, would be to have two new regex options (ideally with POSIX basic & extended options -- user selectable), eg. --exclude-regex-contents and --include-regex-contents which effectively grep (or grep -E) each d/l file of html and keep or delete it based on its contents. By matching on data in meta-tags or relevant text strings in the body of the html, should make a powerful way to prevent wget -H, in particular, from wandering off topic when the target pages have many links to adsites and other unwanted stuff. Regards Tom Crane -- Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill, Egham, Surrey, TW20 0EX, England. Email: [EMAIL PROTECTED] Fax:+44 (0) 1784 472794
RE: wget 1.10 alpha 2
With MS Visual Studio 6 still needs attached patch in order to compile (disable optimization for part of http.c and retr.c if cl.exe version <=12). Windows msvc test binary at http://xoomer.virgilio.it/hherold/ Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax > -Original Message- > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 13, 2005 12:36 AM > To: wget@sunsite.dk; [EMAIL PROTECTED] > Cc: Johannes Hoff; Leonid Petrov; Doug Kaufman; Tobias Tiederle; Jim > Wright; garycao; Steven M.Schweda > Subject: wget 1.10 alpha 2 > > > > dear friends, > > i have just released the second alpha version of wget 1.10: [snip] 20050413.diff Description: Binary data