Re: /usr/lib/apt/methods/http - close(-1)
Russell Coker <[EMAIL PROTECTED]> writes: > What is a close(-1) supposed to do? The http program does one and > I'm curious as to why... It usually means someone isn't checking the return value from open/socket/etc... -- http://www.greenend.org.uk/rjk/
Re: suggestions for improvement
Jonathan Walther writes: > No. Consider the case of America and Canada. They share 5 > timezones between them, but differ in the default dictionaries that > are appropriate. Too much work for too little gain. However, if > you make a nice patch and submit it to the maintainer of the > "dictionary" package, perhaps it will get in. Fair enough; probably the timezone is the wrong place to start. But given a bit of geographic information, you can guess sensible defaults or in some cases fixed values for a number of things: * timezone * locale settings (language, number formats, currency, ...) * dictionary packages to install * usenet hierarchies to feed (de.* in German-speaking places, etc.) * ISPs that one might want to connect to * choice of dialup software/hardware (e.g. UUCP is more popular in some places than others, ditto ISDN, some places have cable modems and others don't, ...) * mirror site to use for updates (or even for the initial install, for users with cheap bandwidth) * whether to offer certain software for install (crypto is still illegal in some countries, other countries may have patent problems with some software, &c). Some of these are probably less useful to think about than others. However I'm sure there's lots of other things that vary in a fairly predictable fashion from place to place. ttfn/rjk
Install-time byte-compiling: Why bother?
Jonathan Walther writes: > On Sat, 8 May 1999, Richard Kettlewell wrote: >> 3. A lot of the Emacs packages spend ages byte-compiling various >> files during the install. Given that the results might well never be >> used this seems rather wasteful. Also it's quite time-consuming, even >> on a fast machine; I hate to think what it'd be like on a much slower >> machine. > > I've never found it to take more than a few minutes. Again, if you want to > submit a patch to emacs so that packages are byte-compiled when they are > first called, feel free. Actually, I've just done some timings. On one machine, a 233Mhz K6, I invoked Gnus in Xemacs20. When the byte-compiled .elc files were available, it took 12 seconds. When they weren't, and emacs had to byte-compile on the fly, it took 14 seconds. On another machine, this a 300Mhz K6-2, I invoked W3 in Xemacs20 (using lisp interaction mode to eliminate the wait for the user to enter a URL). In this case it was 10 seconds for .elc files, 15 seconds if it had to byte-compile the .el files themselves. This was to retrieve and render a 4Kbyte web page with no images/frames/etc, retrieved via the local ethernet. Now these are delays that you have to suffer once per Emacs session, not each time you enter Gnus/view a web page/etc. We're talking at best a 30% improvement from those numbers. My methods are hardly scientific, I know - perhaps others can produce similar comparisons for slower or faster machines. What's the cost of install-time byte-compilation? In my experience it's an incredibly fragile process; see for example my recently submitted bug report #37355. Right now I don't have a correctly installed emacs19 or emacs20 on lyonesse (which is one reasons why I only used Xemacs20 above). I suggest, therefore, that the install-time byte-compilation of elisp files be either eliminated completely, or turned into an option, with the default set to "off". ttfn/rjk
Re: suggestions for improvement
Branden Robinson writes: > The sad thing is, it's not necessary to ask this at all. [...] > > Please file a bug against any package that asks you to choose between mono > and color app-defaults files, and include this mail in it if you want. OK, I've submitted bug reports against xftpd and xsysinfo, which are the two examples of this problem I encountered. ttfn/rjk
Re: Install-time byte-compiling: Why bother?
Chris Waters writes: > I *strongly* oppose eliminating it, and I'm not real big on the idea > of making the default be "off". Installing new packages takes a > while, I don't mind a few extra moments there. I *do* mind run-time > delays, even if they're small, There is always a delay; this is unavoidable. The question is how big the delay is. How often have you timed the startup times for these packages? > and only once per session (and they're not if you unload features to > save RAM). If there's a bug in the install, it should be reported > and fixed, but I have yet to see one. See bug reports 37375, 37355 for a couple of examples. > That said, I'm perfectly happy to see it be optional, as long as it > doesn't result in more install-time questions. But the *default* > should be whatever is best for the novice running stable. Which is > "on", since a novice may not be able to figure out how to byte-compile > the package himself. And stable *better* not have problems in the > install, so problems in the install aren't sufficient justification > for a default of "off". The current scheme can generate hundreds of lines of noise from which just one or two lines need to be extracted to determine even what package(s) the bug is in. See the discussion in bug report 37355 for an example. Run-time compilation of elisp would slow things down slightly. In many cases if you didn't time it, you wouldn't even notice. I know what I think is better for the novice! ttfn/rjk
Re: Install-time byte-compiling: Why bother?
Torsten Landschoff writes: > [EMAIL PROTECTED] wrote: >> On another machine, this a 300Mhz K6-2, I invoked W3 in Xemacs20 >> (using lisp interaction mode to eliminate the wait for the user to >> enter a URL). In this case it was 10 seconds for .elc files, 15 >> seconds if it had to byte-compile the .el files themselves. This was > > Interesting! Where did you get that version of Xemacs? My xemacs > does not byte-compile the .el-Files on loading (that would take > REALLY long) but instead slows down a bit. Obviously I've misunderstood the behaviour of Emacs here - I'd assumed that the internal form was the same regardless of whether one got there via byte-compiling or not. Apparently this isn't the case! > I don't think it's valid to compare times for LOADING the > files. It's quite simple to load the .el-Files. Try to run some lisp > code doing heavy stuff - e.g. opening a 200k html file with w3. Ah yes, that does make a significant difference - 67s with *.elc versus 120s with *.el for a 100613 byte HTML file. Then again, neither time is remotely tolerable for web browsing, given that Lynx and Netscape both render the same web page in less than a second! The point is well made, though. ttfn/rjk
Re: Time to rewrite dpkg
Marcus Brinkmann writes: > We all are blinded by dpkg. It works, yes. How long? The current > sources don't even build properly out of the box. Problems are > cropping up without people knowing how to fix them (see the bug > list). Even very simple patches and changes need months to get into > yet another non-maintainer release. While I couldn't get the published source to build, IWJ's source tree builds for me. Perhaps you should encourage him to make it more widely available? ttfn/rjk
