error
some time appear this error assertion "ptr != NULL" failed: file "xmalloc.c", line 190
Re: error
Василевский Сергей <[EMAIL PROTECTED]> writes: > some time appear this error > assertion "ptr != NULL" failed: file "xmalloc.c", line 190 What were you doing when the error appeared? Do you have the rest of Wget's output?
Re: No more Libtool (long)
Hrvoje Niksic wrote: > Google doesn't show even nearly enough hits when you search for "libtool > sucks". Because it's an understatement. :-) -- .-. .-.Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | |[EMAIL PROTECTED]
Re: No more Libtool (long)
On Sat, 25 Jun 2005, Hrvoje Niksic wrote: > Despite the apparent consensus that it should be integrated in > Autoconf, the integration never materialized. When I queried about > this in 2003 (http://tinyurl.com/a63lc), the single response > charmingly told me that "the solution is libtool." I now think the > appropriate answer to that should have been, "Libtool -- just say NO!" Well, this is certainly an overstatement, but you certainly have a point. The idea behind libtool is good and the implementation is reasonable. Bugs are of course inevitable and you shouldn't be surprised seeing them especially as on exotic platforms (you even admit you've never been able to reproduce some of the other's problems on your systems). GNU software relies on public testing, but unfortunately many users fail to provide useful reports for bugs they spot and for those exotic platforms it may mean nobody ever knows about them. You're certainly right C++/Fortran/whatever tests are superfluous, not only for wget -- they should probably only be enabled on demand, like GCJ tests already are. That should qualify as a bug -- but have you filed it to the libtool team? You mentioned the lack of documentation, but it doesn't appear magically by itself, does it? Perhaps nobody else tried to use libtool like wget did. Yours could be a useful experience -- have you considered submitting your results for inclusion? Having said that I have to admit you are probably right with your decision -- OpenSSL are not libtool libraries and this is probably the most important cause of problems. For building programs rather than libraries themselves libtool is most useful when libtool libraries are involved. In this case for example it can help with pulling dependencies for static libraries (archives) that do not record that information themselves. With non-libtool libraries you need to discover it yourself anyway. Finally, there are so many people complaining about libtool -- but how many of them actually did anything to make it better? Of these, how many failed to achieve their goal due to a conceptual problem with libtool? -- only these can actually claim they have rights to blame libtool. Everyone else please either file bug reports (or better yet fix bugs you trip over) or keep silent. Maciej
Re: No more Libtool (long)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: > Bugs are of course inevitable and you shouldn't be surprised seeing > them especially as on exotic platforms (you even admit you've never > been able to reproduce some of the other's problems on your > systems). Please note that a platform doesn't qualify as "exotic" just because I don't currently have access to it. I have regular access to only Linux and Solaris. > Finally, there are so many people complaining about libtool -- but > how many of them actually did anything to make it better? I haven't tried to make it better partly because I wasn't convinced that Libtool was the right tool for the problem to begin with. As soon as a more focused alternative solution appeared, I used it and I think it was the right decision. > Of these, how many failed to achieve their goal due to a conceptual > problem with libtool? -- only these can actually claim they have > rights to blame libtool. Everyone else please either file bug > reports (or better yet fix bugs you trip over) or keep silent. Sorry, I find that my time is more productively spent doing other things. And I don't accept the position that one has to *earn* his right to speak of Libtool's shortcomings, or that others should "keep silent" just because they don't have the inclination to work on it.
Re: wget and ASCII mode
from Hrvoje Niksic: > [...] Unfortunately EOL conversions break > automatic downloads resumption (REST in FTP), Could be true. > manual resumption (wget -c), Could be true. (I never use "wget -c".) > break timestamping, How so? > and probably would break checksums if we added them. You don't have them, and anyone who would be surprised by this should be directed to the note in the documentation which would explain why. > Most Wget's users seem to want byte-by-byte copies, because I don't > remember a single bug report about the lack of ASCII conversions. You mean other than the one from the fellow who started this thread? > The one thing that is surely wrong about my approach is the ';type=a' > option, which should either be removed or come with a big fat warning > that it *doesn't* implement the required conversion to native EOL > convention and that it's provided for the sake of people who need text > transfers and are willing to invoke dos2unix/unix2dos (or their OS > equivalent) themselves. Interesting. I'd have made ";type=a" work right (which I claim to have done), and then perhaps included a run-time error or documentation warning if it were mixed with incompatible options (which I haven't done). Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street[EMAIL PROTECTED] Saint Paul MN 55105-2547
Re: wget and ASCII mode
[EMAIL PROTECTED] (Steven M. Schweda) writes: > from Hrvoje Niksic: > >> [...] Unfortunately EOL conversions break >> automatic downloads resumption (REST in FTP), > >Could be true. > >> manual resumption (wget -c), > >Could be true. (I never use "wget -c".) It's the consequence of EOL conversion affecting file size. >> break timestamping, > >How so? By changing file size, which will appear different than what is reported by the server and will cause the file to always be downloaded due to size mismatch. >> Most Wget's users seem to want byte-by-byte copies, because I don't >> remember a single bug report about the lack of ASCII conversions. > > You mean other than the one from the fellow who started this thread? Yes, sorry.
Re: No more Libtool (long)
On Mon, 27 Jun 2005, Hrvoje Niksic wrote: > > Bugs are of course inevitable and you shouldn't be surprised seeing > > them especially as on exotic platforms (you even admit you've never > > been able to reproduce some of the other's problems on your > > systems). > > Please note that a platform doesn't qualify as "exotic" just because I > don't currently have access to it. I have regular access to only > Linux and Solaris. Well, it's "exotic" to you in the sense you rely on others testing it for you. > > Of these, how many failed to achieve their goal due to a conceptual > > problem with libtool? -- only these can actually claim they have > > rights to blame libtool. Everyone else please either file bug > > reports (or better yet fix bugs you trip over) or keep silent. > > Sorry, I find that my time is more productively spent doing other > things. And I don't accept the position that one has to *earn* his > right to speak of Libtool's shortcomings, or that others should "keep > silent" just because they don't have the inclination to work on it. Certainly you may speak of its (and anything else's) shortcomings, state facts, etc. But to say it's "broken" you need to "earn" the right. Note that I haven't addressed the concern (most) specifically to you -- as a maintainer of a program who attempted to use libtool you have the right to express your experiences -- but there are a lot of others who just make a judgement on libtool based on their single-shot experience with their pet system (or perhaps even someone else's opinion). Also for most projects integrating libtool is almost as simple as placing AC_PROG_LIBTOOL into their configure.ac template. And it works. Even for so complicated setups as GCC, including cross-builds when some parts are built multiple times for different hosts. Libtool did fail for me a few times, but it was always due to a bug, not a design decision and my patches or proposals for fixes have always been welcomed warmly. Maciej
RE: No more Libtool (long)
This is the kind of obnoxious commentary I've learned to expect from glibc's maintainers. It's no more becoming from you (or anyone else). Buzz off. Mark Post -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej W. Rozycki Sent: Monday, June 27, 2005 8:01 AM To: Hrvoje Niksic Cc: wget@sunsite.dk Subject: Re: No more Libtool (long) -snip- Everyone else please either file bug reports (or better yet fix bugs you trip over) or keep silent.
RE: No more Libtool (long)
On Mon, 27 Jun 2005, Post, Mark K wrote: > This is the kind of obnoxious commentary I've learned to expect from > glibc's maintainers. It's no more becoming from you (or anyone else). Well, but unlike with glibc, maintainers of libtool do actually handle problems reported by users. But they have to know about them first. And no, it does not mean telling them there are problems in general -- that they already know for sure -- they need specific details as crystal balls are a scarce resource these days. Of course in theory you can debug software by proof-reading, but even that requires knowledge of external interactions. Like every GNU project libtool relies on user feedback. And fortunately some people actually do support it one way or another within their skills rather than complain (what a waste of time!). Please note the glibc approach is "specific", which is regrettable, but that's nothing that can be changed easily. > Buzz off. Let's focus on technical issues rather than making it personal, OK? Maciej
RE: No more Libtool (long)
You already blew that opportunity when you told us to shut up. Blame yourself. Mark Post -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej W. Rozycki Sent: Monday, June 27, 2005 11:15 AM To: Post, Mark K Cc: wget@sunsite.dk Subject: RE: No more Libtool (long) -snip- Let's focus on technical issues rather than making it personal, OK? Maciej
RE: ftp bug in 1.10
> From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
> the 64-bit "download sum", doesn't work for you. What does this
> program print?
>
> #include
> int
> main (void)
> {
> __int64 n = 100I64; // ten billion, doesn't fit in 32 bits
> printf("%I64\n", n);
> return 0;
> }
>
> It should print a line containing "100". If it does, it means
> we're applying the wrong format. If it doesn't, then we must find
> another way of printing LARGE_INT quantities on Windows.
Folks, sorry for the delay, I've been on vacation and I'm still trying to
catch up with work and stuff.
%I64 not ok, %I64d is.
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED]
-- +39-041-5907073 ph
-- +39-041-5907472 fax
Name or service not known error
I got a "Name or service not known" error from wget 1.10 running on Linux. When I installed an earlier version of wget, it worked just fine. It also works just fine on version 1.10 running on Windows. Any ideas? Here's the output on Linux: wget --versionGNU Wget 1.9-beta1 wget http://www.calottery.com/Games/MegaMillions/--17:29:59-- http://www.calottery.com/Games/MegaMillions/ => `index.html.8'Resolving www.calottery.com... 64.164.108.164, 64.164.108.202Connecting to www.calottery.com[64.164.108.164]:80... connected.HTTP request sent, awaiting response... 200 OKLength: 45,166 [text/html] 100%[==>] 45,166 166.21K/s 17:30:01 (166.17 KB/s) - `index.html.8' saved [45166/45166] wget --versionGNU Wget 1.10 wget http://www.calottery.com/Games/MegaMillions/--17:30:17-- http://www.calottery.com/Games/MegaMillions/ => `index.html.9'Resolving www.calottery.com... failed: Name or service not known.
Re: wget and ASCII mode
from Hrvoje Niksic: > >> break timestamping, > > > >How so? > > By changing file size, which will appear different than what is > reported by the server and will cause the file to always be downloaded > due to size mismatch. Ah, yes. As I live in an environment (VMS) which maintains disk block counts instead of byte counts, I'd gotten into the habit of thinking of "timestamping" as involving time stamps, rather tnan time stamps _and_ file sizes. (A better name would have been better.) At least with the ASCII FTP line-ending fix confined to the VMS-adapted code, there seems to be little danger of contaminating the main development code with it. Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street[EMAIL PROTECTED] Saint Paul MN 55105-2547
