Re: PATCHES file removed

[Tony Godshall]

On 10/13/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hrvoje Niksic wrote:
> > Micah Cowan <[EMAIL PROTECTED]> writes:
> >
> >> FYI, I've removed the PATCHES file. Not because I don't think it's
> >> useful, but because the information needed updating (now that we're
> >> using Mercurial rather than Subversion), I expect it to be updated
> >> again from time to time, and the Wgiki seems to be the right place
> >> to keep changing documentation
> >> (http://wget.addictivecode.org/PatchGuidelines).
> >>
> >> It's still obviously useful to have patch-submission information
> >> included as part of the Wget distribution itself;
> >
> > It would be nice for the distribution to contain that URL on a
> > prominent place, such as in the README, or even a stub PATCHES file.
>
> It's in NEWS, but putting it in README can't hurt.

Hey, that's a handy link.  I'll follow it for my next rev (--limit-rate nn%)

I had read the README file but I'm not in the habit of looking for a NEWS file.

> >> Speaking of which, I've replaced the MAILING-LISTS file,
> >> regenerating it from the Mailing Lists section of the Texinfo
> >> manual. I suspect it had previously been generated from source, but
> >> it's not clear to me from what (perhaps the web page?), or what tool
> >> was used.
> >
> > It was simply hand-written.  :-)
>
> Oh, yeah, I don't want to do that in three places then (MAILING-LISTS,
> Wgiki, and manual)!
>
> It had a right-aligned "-*- text -*-" thing at the top, so I was
> thinking that was an indication of having been generated.
>
> - --
> Micah J. Cowan
> Programmer, musician, typesetting enthusiast, gamer...
> http://micah.cowan.name/
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHERDH7M8hyUobTrERCKqOAKCGuapIPLSYLpDktbteDDYyU2I2AgCfRWs9
> iznnPJ4ejopsaSgeY/APk78=
> =GHTD
> -END PGP SIGNATURE-
>


-- 
Best Regards.
Please keep in touch.

version.c take two

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've improved the generation of version.c, removing the intermediate
generation of an "hg-id" file and using a more portable replacement for
"hg id | cut -d ' ' -f 1" (can be used on Windows and MS-DOS).

The relevant lines in src/Makefile.am are now:

version.c:  $(wget_SOURCES) $(LDADD)
printf '%s' 'const char *version_string = "@VERSION@' > $@
-hg log -r tip --template=' ({node|short})' >> $@
printf '%s\n' '";' >> $@

(The printf commands aren't portable to Windows AFAIK, but this should
be easier to adapt, at any rate. Note that "echo -n" is not a portable
method for suppressing newlines in echo's output.)

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFAXf7M8hyUobTrERCFFmAJ9cR5Pg2wJb3SP/8c3lVXCuuLcyHACfZCmO
vG29YrdpWnm5csHE381L/Ug=
=HVHe
-END PGP SIGNATURE-

Re: subscribing from this list

[Matthias Vill]

Josh Williams schrieb:
> On 10/15/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
>> Note that this doesn't help him much if he's lost his registration e-mail.
>>
>> Patrick, you'll probably have to go bug the staff at www.dotsrc.org, who
>> hosts this list; send an email to [EMAIL PROTECTED]
> 
> E-mail *address* or just the e-mail? I don't see how having the e-mail
> is important.
> 
How can you actually loose an E-Mail address you keep receiving mails over?
Most times it helps to check E-Mail headers for mailing-lists. There you
can find the E-Mail address via which you receive the mails (maybe
hidden inside the Receive-lines) and also a note telling

Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm

I guess after mailing to that address you should be able to unsubscribe
or recover your password if you need it and lost it.

Greetings

Matthias

Re: subscribing from this list

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Josh Williams wrote:
> On 10/15/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
>> Note that this doesn't help him much if he's lost his registration e-mail.
>>
>> Patrick, you'll probably have to go bug the staff at www.dotsrc.org, who
>> hosts this list; send an email to [EMAIL PROTECTED]
> 
> E-mail *address* or just the e-mail? I don't see how having the e-mail
> is important.

Oh. ... Maybe I misread! :)

I meant/read it as address. As in "_registered_ email address." I see
now that an actual email seems more likely.

BTW, we also keep the unsubscription information in the Wget manual (not
the manpage), and in the file MAILING-LIST that comes with Wget
(probably installed to /usr/share/doc/wget/MAILING-LIST, typically).

- --
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHE6jY7M8hyUobTrERCPSTAJ9LCvZKCchiBhKQ1XitYS/WHRS2jACfSTG4
Y7qtlmEiml8YtxYxKkGH99o=
=TVTr
-END PGP SIGNATURE-

Re: --limit-percent N versus --limit-rate N% ?

[Matthias Vill]

Micah Cowan schrieb:
> Matthias Vill wrote:
>> I would appreciate having a --limit-rate N% option.
> 
>> So now about those "broken" cases. You could do some "least of both"
>> policy (which would of course still need the time to do measuring and
>> can cut only afterwards).
>> Or otherwise you could use a non-percent value as a minimum. This would
>> be especially useful if you add it to your default options and stumble
>> over some slow server only serving you 5KiB/s, where you most probably
>> don't want to further lower the speed on your side.
> 
>> As third approach you would only use the last limiting option.
> 
>> Depending on how difficult the implementation is I would vote for the
>> second behavior, although the first or third option might be more
>> intuitive to some of the users not reading the docs.
> 
> Third option should be more intuitive to the implementer, too. I vote
> for that, as I really want to avoid putting too much sophistication into
> this.

I would expect, that you need to variables for holding percent/fixed
values anyway so I was just wondering whether you could do it as I
suggested secondly.
IMHO that should be quite easy to do by a single
if(fixed&&percent)limit=max(a,b) and thus not even result in any
overhead during actual download.

Greetings

Matthias

P.S.: I'm subscribed via news://sunsite.dk, you don't need to CC me.

Re: subscribing from this list

[Josh Williams]

On 10/15/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> Note that this doesn't help him much if he's lost his registration e-mail.
>
> Patrick, you'll probably have to go bug the staff at www.dotsrc.org, who
> hosts this list; send an email to [EMAIL PROTECTED]

E-mail *address* or just the e-mail? I don't see how having the e-mail
is important.

Re: subscribing from this list

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Josh Williams wrote:
> On 10/15/07, patrick robinson <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I want to unsubscripe from this list but lost my registration e-mail.
>> How is this performed?

I haven't seen this original message yet.

> You can find this (and other information) on the Wget wiki.
> 
> 
> "To unsubscribe from a list, send an email to
> [EMAIL PROTECTED] For more information on list
> commands, send an email to [EMAIL PROTECTED]"

Note that this doesn't help him much if he's lost his registration e-mail.

Patrick, you'll probably have to go bug the staff at www.dotsrc.org, who
hosts this list; send an email to [EMAIL PROTECTED]

- --
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHE6c77M8hyUobTrERCKYNAKCMBnFh/+ONearE23Z90HnCcqFOBQCfVNDk
1UaUI4iYc6adbkLIrcVz6Qg=
=9XcZ
-END PGP SIGNATURE-

Re: subscribing from this list

[Josh Williams]

On 10/15/07, patrick robinson <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I want to unsubscripe from this list but lost my registration e-mail.
> How is this performed?

You can find this (and other information) on the Wget wiki.


"To unsubscribe from a list, send an email to
[EMAIL PROTECTED] For more information on list
commands, send an email to [EMAIL PROTECTED]"

Re: --limit-percent N versus --limit-rate N% ?

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Matthias Vill wrote:
> I would appreciate having a --limit-rate N% option.
> 
> So now about those "broken" cases. You could do some "least of both"
> policy (which would of course still need the time to do measuring and
> can cut only afterwards).
> Or otherwise you could use a non-percent value as a minimum. This would
> be especially useful if you add it to your default options and stumble
> over some slow server only serving you 5KiB/s, where you most probably
> don't want to further lower the speed on your side.
> 
> As third approach you would only use the last limiting option.
> 
> Depending on how difficult the implementation is I would vote for the
> second behavior, although the first or third option might be more
> intuitive to some of the users not reading the docs.

Third option should be more intuitive to the implementer, too. I vote
for that, as I really want to avoid putting too much sophistication into
this.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHE5wl7M8hyUobTrERCEYUAJ9q4Bgi0LNtxuzWBOqmw8taL0K8wgCdGsxQ
EIizwF8wxo1ksJURUGVT9VA=
=mZ/c
-END PGP SIGNATURE-

Re: --limit-percent N versus --limit-rate N% ?

[Matthias Vill]

Micah Cowan wrote:
> I'm kinda leaning toward the idea that we change the parser for
> --limit-rate to something that takes a percentage, instead of adding a
> new option. While it probably means a little extra coding, it handily
> deals with broken cases like people specifying both --limit-rate and
> --limit-percent, and helps consolidate the documentation. Anyone have
> opinions about this?


I would appreciate having a --limit-rate N% option.

So now about those "broken" cases. You could do some "least of both"
policy (which would of course still need the time to do measuring and
can cut only afterwards).
Or otherwise you could use a non-percent value as a minimum. This would
be especially useful if you add it to your default options and stumble
over some slow server only serving you 5KiB/s, where you most probably
don't want to further lower the speed on your side.

As third approach you would only use the last limiting option.

Depending on how difficult the implementation is I would vote for the
second behavior, although the first or third option might be more
intuitive to some of the users not reading the docs.

So greetings

Matthias

Re: Version tracking in Wget binaries

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
> 
>>> Make my src changes, create a "changeset"... And then I'm lost...
>> Alright, so you can make your changes, and issue an "hg diff", and
>> you've basically got what you used to do with svn.
> 
> That is not quite true, because with svn you could also do "svn
> commit" to upload your changes on the global repository seen by
> everyone. It is my understanding that with the "distributed" VC's,
> the moral equivalent of svn commit is only to be done by the
> maintainer, by pulling ("cherry-picking") the patches of various
> contributors.

Untrue. That is simply the model some (notably, Linus and friends)
choose to use.

As with the Subversion set up, active developers with permissions may
"push" to the central repositories; I actually mentioned this during the
initial announcement, but am using SSH key-based authentication to
accomplish this, and so require people's SSH keys in order to give them
push access. So far, the only one who has given their SSH key is
actually Ralf Wildenues, whose key I requested so he could easily push
any necessary changes related to the Automake stuff. So: send your key,
and you'll have push access!

Note that I still prefer to review non-trivial changes, just as I did in
Subversion; but just as in Subversion, I decided against ACLs and
allowed everyone write permission to trunk, though I preferred to merge
there myself, I want all core devs to have write permission to the
public repos, so they can push quick fixes.

> It is most likely the case that I simply didn't (yet) "get" the DVCS
> way of doing things.

It takes a little bit of getting used to, but you'll find that many
things directly translate from using a non-distributed SCM. The biggest
differences that arise (for me so far) tend to be related to the fact
that history is not a linear series of events, where each log entry is
the child of another; it is instead a directed acyclical graph, where
the history can branch off and re-merge later, leaving all history
intact. Subversion and friends, of course, support branching and
merging, but the history wouldn't merge along with the changes, and
you'd typically get the branch merge as one big "slurp" of the total
changes. Tools like svnmerge helped address this (by merging each change
individually, which could be problematic in some circumstances).

For my part, I found using Mercurial very easy to learn, and it is
purposely designed to use an interface very similar to Subversion. It
just takes a little getting used to, like any conversion to a new,
heavily-relied-upon development tool.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHE3177M8hyUobTrERCMpZAJ9MUGXaYa2r+SBmFEujdrnwvjNITQCfevJN
qh2Jicj1A9Iv8Po3E8EUGTA=
=gkeP
-END PGP SIGNATURE-

Re: Version tracking in Wget binaries

[Hrvoje Niksic]

Micah Cowan <[EMAIL PROTECTED]> writes:

>> Make my src changes, create a "changeset"... And then I'm lost...
>
> Alright, so you can make your changes, and issue an "hg diff", and
> you've basically got what you used to do with svn.

That is not quite true, because with svn you could also do "svn
commit" to upload your changes on the global repository seen by
everyone.  It is my understanding that with the "distributed" VC's,
the moral equivalent of svn commit is only to be done by the
maintainer, by pulling ("cherry-picking") the patches of various
contributors.  To me that sounds: a) horribly error-prone if the
maintainer doesn't have access to firewalled checkouts of various
contributors (patches can and do misapply), and b) actually *more*
centralized than CVS/svn!

It is most likely the case that I simply didn't (yet) "get" the DVCS
way of doing things.

--limit-percent N versus --limit-rate N% ?

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Okay, now that it's decided this thing will go in...

I'm kinda leaning toward the idea that we change the parser for
- --limit-rate to something that takes a percentage, instead of adding a
new option. While it probably means a little extra coding, it handily
deals with broken cases like people specifying both --limit-rate and
- --limit-percent, and helps consolidate the documentation. Anyone have
opinions about this?

Also: does the current proposed patch deal properly with situations such
as where the first 15 seconds haven't been taken up by part of a single
download, but rather several very small ones? I'm not very familiar yet
with the rate-limiting stuff, so I really have no idea.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHExRX7M8hyUobTrERCKOwAJ9QFdy3u9j1t9t2jjTBcfQ3n+uSRACfRhFM
sVDzTLk/NrW5g13sz+aGgCc=
=6Sig
-END PGP SIGNATURE-

Suffixes after unique-ing numbers [Re: Two wget patches: min-size/max-size and nc options]

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just getting a chance to look a bit more closely at this again.

Christian Roche wrote:
> Hi there,
> 
> please find attached two small patches that could be
> considered for wget (against revision 2276).
> 
> patch-utils changes the file renaming mechanism when
> the -nc option is in effect.  Instead of trying to
> rename  a file to file.1, file.2 etc, it tries
> prefix-1.suffix, prefix-2.suffix etc, thus preserving
> the filename extension if any.  This is necessary to
> avoid a bug otherwise when the -A option is used:
> renamed files are rejected because they don't match
> the required suffix, although they should really be
> kept.

Is this true? I'm having some trouble reproducing this, either now or in
older versions (1.10.2, 1.9.1), Could you supply a command-line that
produces this problem? ...Because, it seems that Wget will always accept
any file that was explicitly given on the command-line or via
- --input-file; and AFAICT .1, .2 suffixes are not generated in
- --recursive mode.

Your suffixes patch accidentally includes some of the documentation from
- --min-size/--max-size; I'd prefer this not to be part of this patch ;)

Also, the proposed code changes are fine, but IMO a little bit wasteful,
as it allocates strlen(s)-sized buffers for prefix and suffix. Actually,
it really shouldn't be necessary to allocate space for the prefix and
suffix at all, as you can just set markers for them, leaving just the
filename variable to be allocated.

If you can make those changes, I'll probably apply the patch right away;
otherwise, I'll probably wait until I have a chance to do that myself.
Even if the accept/reject thing doesn't apply, this patch has the
benefit of preserving interpretation of .html files, etc. But please let
me know how you were reproducing the accept/reject, as it would still
need a more robust fix.

- --
Thanks!
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHExDa7M8hyUobTrERCFcFAJwJRhLQTfqVeWCB/0ul+GMPW4PdDACdHyua
Sm3JnsEi6m6ZmRrCWzXcUbU=
=GNE5
-END PGP SIGNATURE-