Re: wget2
On Thu, 29 Nov 2007, Alan Thomas wrote: Sorry for the misunderstanding. Honestly, Java would be a great language for what wget does. Perhaps, but not for where wget is used: on numerous platforms as a stand-alone downloadable tool, including on embedded and small-CPU devices. Environments where java doesn't excel. Lots of built-in support for web stuff. That's simply not true. It has some _basic_ support for some web protocols etc, but that's far from enough for a tool such as wget.
Re: wget2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hrvoje Niksic wrote: Mauro Tortonesi [EMAIL PROTECTED] writes: I vote we stick with C. Java is slower and more prone to environmental problems. not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. Not if you count startup time, which is crucial for a program like Wget. Memory use is also incomparable. Yes, and you're right that this is crucial for Wget. However, I do not believe that it is as crucial for Wget 2. Wget is heavily used for single-file fetches; I do not anticipate that to be the primary use for Wget 2. They will have different application domains, and different target markets (see the Thoughts on Wget 2.0 thread). This is a major reason why I advocate the name change, as I don't think the new beast can appropriately be called by the same name as what people are now accustomed to. The New Wget will almost certainly be bulkier, more expensive to build and run, and depend on a variety of other libraries and tools. It will also be more powerful and flexible, hopefully justifying these costs. But Wget's current domain will always find great use in a sleek and still-very-powerful web fetching tool with a smaller footprint and dependencies set. In essence, this drive for a New Wget is my way of saying, all these fancy features like multiple connections, abstracted interfaces with the filesystem, etc, support for MetaFile and JavaScript, etc, etc, are _not_appropriate_for_Wget_; while still allowing these ideas to continue (in another form). :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHUFMu7M8hyUobTrERAmsrAJ9hpPCUI8IE1pKLmthCkU7MQIb9oACeIFIP TxzIeIJnDWRKUBpxdIfQzrQ= =RJwS -END PGP SIGNATURE-
Re: Wget for MP3 streams
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Ginger wrote: On Friday 30 November 2007 03:38:54 Micah Cowan wrote: David Ginger wrote: On Friday 30 November 2007 01:03:06 Micah Cowan wrote: David Ginger wrote: What I'm looking at wget for is saving streamed mp3 from a radio station, crazy but true.. such is life. Isn't that already possible now? Provided that the transport is HTTP, that is? Yes and No . . . Yes I can save a stream, But, not everything works as expected, some of wget's features kick in. Like, I cant get the quota to work no matter how much I fiddle and tinker. Not too surprising, since the documentation points out that the quota never affects the downloading of a single file. :\ So I downloaded the source code . . . and subscribed to the mailing list to find out why :-) Heh, beats me. :) I suspect because that's easiest to implement. There have been requests for stricter quotas; and I think I'm in favor of that. What I'm unsure of is whether the current functionality is desirable to someone or other, and we should add a --strict-quotas or something to activate this behavior; I suspect that might be the case (someone _somewhere_ must be relying on the current method). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHUFBn7M8hyUobTrERAul3AJ4xONtIUx20oGsKJ5bZkS2z95/KZwCfby2L r6t+nTKNvmD4LCbwQvgyjxQ= =OwYy -END PGP SIGNATURE-
Re: wget2
On Friday 30 November 2007 14:48:07 David Ginger wrote: what do you think? Python. i was asking what you guys think of my write a prototype using a dynamic language then incrementally rewrite everything in C proposal, and not trying to start yet another programming language flame war ;-) i believe that for sheer application prototyping purposes, ruby and python are equally good. in addition, i know and like both of them. so, in case micah is actually evaluating ruby and python, i don't really care which one of them he will finally choose to adopt. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng. http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget2
On Friday 30 November 2007 11:59:45 Hrvoje Niksic wrote: Mauro Tortonesi [EMAIL PROTECTED] writes: I vote we stick with C. Java is slower and more prone to environmental problems. not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. Not if you count startup time, which is crucial for a program like Wget. Memory use is also incomparable. right. i was not suggesting to implement wget2 in Java, anyway ;-) but we could definitely make good use of dynamic languages such as Ruby (my personal favorite) or Python, at least for rapid prototyping purposes. both Ruby and Python support event-driven I/O (http://rubyeventmachine.com for Ruby, and http://code.google.com/p/pyevent/ for Python) and asynch DNS (http://cares.rubyforge.org/ for Ruby and http://code.google.com/p/adns-python/ for Python) and both are relatively easy to interface with C code. writing a small prototype for wget2 in Ruby or Python at first, and then incrementally rewrite it in C would save us a lot of development time, IMVHO. what do you think? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng. http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: Wget for MP3 streams
On Friday 30 November 2007 03:38:54 Micah Cowan wrote: David Ginger wrote: On Friday 30 November 2007 01:03:06 Micah Cowan wrote: David Ginger wrote: What I'm looking at wget for is saving streamed mp3 from a radio station, crazy but true.. such is life. Isn't that already possible now? Provided that the transport is HTTP, that is? Yes and No . . . Yes I can save a stream, But, not everything works as expected, some of wget's features kick in. Like, I cant get the quota to work no matter how much I fiddle and tinker. Not too surprising, since the documentation points out that the quota never affects the downloading of a single file. :\ So I downloaded the source code . . . and subscribed to the mailing list to find out why :-)
Re: wget2
On Fri, 30 Nov 2007, Mauro Tortonesi wrote: not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. And GCJ can be asked to compile Java to native machine code too. I think Java per se would be OK as a programming language if it were not for its ridiculously huge standard library. But rewriting Wget just as a proof of concept does not seem a particularly exciting way of spending time. Anyone is free to do so though I presume. ;-) Maciej
Re: wget2
On Friday 30 November 2007 03:29:05 Josh Williams wrote: On 11/29/07, Alan Thomas [EMAIL PROTECTED] wrote: Sorry for the misunderstanding. Honestly, Java would be a great language for what wget does. Lots of built-in support for web stuff. However, I was kidding about that. wget has a ton of great functionality, and I am a reformed C/C++ programmer (or a recent Java convert). But I love using wget! I vote we stick with C. Java is slower and more prone to environmental problems. not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. Wget needs to be as independent as we can possibly make it. A lot of the systems that wget is used on (including mine) do not even have Java installed. That would be a HUGE requirement for many people. i totally agree. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng. http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget2
On Friday 30 November 2007 13:45:08 Mauro Tortonesi wrote: On Friday 30 November 2007 11:59:45 Hrvoje Niksic wrote: Mauro Tortonesi [EMAIL PROTECTED] writes: I vote we stick with C. Java is slower and more prone to environmental problems. not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. Not if you count startup time, which is crucial for a program like Wget. Memory use is also incomparable. right. i was not suggesting to implement wget2 in Java, anyway ;-) but we could definitely make good use of dynamic languages such as Ruby (my personal favorite) or Python, at least for rapid prototyping purposes. both Ruby and Python support event-driven I/O (http://rubyeventmachine.com for Ruby, and http://code.google.com/p/pyevent/ for Python) and asynch DNS (http://cares.rubyforge.org/ for Ruby and http://code.google.com/p/adns-python/ for Python) and both are relatively easy to interface with C code. writing a small prototype for wget2 in Ruby or Python at first, and then incrementally rewrite it in C would save us a lot of development time, IMVHO. what do you think? Python.
Re: Wget Name Suggestions
On Thu, 29 Nov 2007, Josh Williams wrote: I really like the name `fetch` because it does what it says it does. It's more UNIX-like than the other names :-) While I agree that a unix-like name is preferable, I just want to point out that 'fetch' is already used by a http/ftp transfer tool that's bundled with FreeBSD, so that would be a really bad choice...
Re: wget2
Mauro Tortonesi [EMAIL PROTECTED] writes: I vote we stick with C. Java is slower and more prone to environmental problems. not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. Not if you count startup time, which is crucial for a program like Wget. Memory use is also incomparable.
Re: wget2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej W. Rozycki wrote: On Fri, 30 Nov 2007, Mauro Tortonesi wrote: not really. because of its JIT compiler, Java is often as fast as C/C++, and sometimes even significantly faster. And GCJ can be asked to compile Java to native machine code too. I think Java per se would be OK as a programming language if it were not for its ridiculously huge standard library. But rewriting Wget just as a proof of concept does not seem a particularly exciting way of spending time. Anyone is free to do so though I presume. ;-) Ah, well, the rewrite is pretty much inevitable. Wget 2 is too different in scope and functionality for it to be otherwise. And rapid prototyping _is_ desirable. I think prototyping is the wrong word, though, and incrementally rewriting in C is probably unrealistic. A prototype is something that proves a concept, but is written specifically to be thrown away: it doesn't do its job fully and/or robustly. I'm not interested in writing that. Similarly, once a working version is written, in any language, I personally would not plan to reimplement it in another (which is perhaps what you meant when you were talking about rewriting?). As you say, though, others are free to do so :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHUFGw7M8hyUobTrERAhhwAKCNnAvvuyqhDeYYawmdNhTFEI3hLgCfRPdF wxAoUqCjd0i0TN/P+Ok7WUw= =zCU0 -END PGP SIGNATURE-
