Re: [VM] MIME encoding/decoding
On Fri, 18 Jul 2014, Patrick P Murphy wrote: On Fri, 18 Jul 2014 09:13:37 +0200, Ulrich Mueller u...@gentoo.org said: These C programs were first shipped with in VM 6.76 which was released in September 2000. This is somewhat surprising, because at that time Emacs (version 20.4 then) already included the base64-decode-region etc. functions. No, it's not surprising. Typical resources at the time for a near top-of-the-line PC would have been: 550 MHz processor (just one, no cores) 64 Megabytes (not Gigabytes) of RAM if you were very lucky ATA-2 hard drive, maybe 10 or 20 Gigabytes. Performance was a real issue, and in a speed battle between emacs lisp and a compiled C program, the latter usually won by at least one order of magnitude, maybe two. The base64-* functions always were internal Emacs functions, i.e. implemented in C. Therefore I doubt that one could improve performance by calling an external program, which has additional overhead for spawning a new process. Adding these programs to VM would still have made sense in the late 1990s, but no longer in 2000 when Emacs 20.4 had the built-in C functions. Ulrich
Re: [VM] MIME encoding/decoding
Hi Uday, Suggest keeping these in the source tree if anyone really needs them, but not make part of a standard package. Mark Uday Reddy usr.vm.ro...@gmail.com writes: VM has traditionally shipped with C programs for MIME encoding/decoding. Rob F created an entire Unix-like infrastructure (Make files, configure, autoconf etc.) pretty much to handle just these. If we get rid of these C programs, VM can be shipped just like any other emacs library. Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality for base64. So, we can use them. For the Quoted Printable format, emacs-lisp seems to be fast enough. Gnus has been using it for ages and everybody seems happy with that. So, I am thinking of getting rid of the C programs for MIME. Does anybody see any problem with that? Cheers, Uday (Coming back after a long hibernation)
Re: [VM] MIME encoding/decoding
On Wed, 16 Jul 2014, Uday Reddy wrote: VM has traditionally shipped with C programs for MIME encoding/decoding. Rob F created an entire Unix-like infrastructure (Make files, configure, autoconf etc.) pretty much to handle just these. If we get rid of these C programs, VM can be shipped just like any other emacs library. Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality for base64. So, we can use them. For the Quoted Printable format, emacs-lisp seems to be fast enough. Gnus has been using it for ages and everybody seems happy with that. These C programs were first shipped with in VM 6.76 which was released in September 2000. This is somewhat surprising, because at that time Emacs (version 20.4 then) already included the base64-decode-region etc. functions. So, I am thinking of getting rid of the C programs for MIME. Does anybody see any problem with that? It may well be that they have outlived their purpose. But before removing them, please make sure that it doesn't have any negative impact on performance. Ulrich
Re: [VM] MIME encoding/decoding
On Fri, 18 Jul 2014 09:13:37 +0200, Ulrich Mueller u...@gentoo.org said: On Wed, 16 Jul 2014, Uday Reddy wrote: VM has traditionally shipped with C programs for MIME encoding/decoding. ... These C programs were first shipped with in VM 6.76 which was released in September 2000. This is somewhat surprising, because at that time Emacs (version 20.4 then) already included the base64-decode-region etc. functions. No, it's not surprising. Typical resources at the time for a near top-of-the-line PC would have been: 550 MHz processor (just one, no cores) 64 Megabytes (not Gigabytes) of RAM if you were very lucky ATA-2 hard drive, maybe 10 or 20 Gigabytes. Performance was a real issue, and in a speed battle between emacs lisp and a compiled C program, the latter usually won by at least one order of magnitude, maybe two. Times change. Computers are faster. For most modest size attachments, people don't notice the difference anymore. People who get massive attachments in the mail from others still do. I work in a big data environment so I see this sort of thing a lot, even though most of my co-workers know that SMTP is a rotten way to send large files around ;-} I'm neutral on whether the programs are left as part of the VM tree or not, as long as (a) the same functionality is available elsewhere [it is, modulo cmd line arguments]; and (b) hooks are left in place to allow us to override the built-in versions. - Pat -- Patrick P. Murphy, Ph.D. https://www.nrao.edu/~pmurphy/ NRAO Information Security Officer NRAO Webmaster [East] Ég skildi, að orð er á Íslandi til um allt, sem er hugsað á jorðu.
Re: [VM] MIME encoding/decoding
Uday Reddy usr.vm.ro...@gmail.com writes: VM has traditionally shipped with C programs for MIME encoding/decoding. Rob F created an entire Unix-like infrastructure (Make files, configure, autoconf etc.) pretty much to handle just these. If we get rid of these C programs, VM can be shipped just like any other emacs library. Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality for base64. So, we can use them. For the Quoted Printable format, emacs-lisp seems to be fast enough. Gnus has been using it for ages and everybody seems happy with that. So, I am thinking of getting rid of the C programs for MIME. Does anybody see any problem with that? Sounds good to me. Thanks! /Lew --- Lew Perin / pe...@acm.org http://babelcarp.org
Re: [VM] MIME encoding/decoding
Uday Reddy wrote at 18:39 +0100 on Jul 16, 2014: VM has traditionally shipped with C programs for MIME encoding/decoding. Rob F created an entire Unix-like infrastructure (Make files, configure, autoconf etc.) pretty much to handle just these. If we get rid of these C programs, VM can be shipped just like any other emacs library. Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality for base64. So, we can use them. For the Quoted Printable format, emacs-lisp seems to be fast enough. Gnus has been using it for ages and everybody seems happy with that. So, I am thinking of getting rid of the C programs for MIME. Does anybody see any problem with that? Cheers, Uday (Coming back after a long hibernation) We should check the performance of builtin decoding - particularly with larger messages on slower machines. That said, most of the unix flavors cygwin out there now have one or more command line tools to en/decode base64 (less prevalent are qp tools) which can take the place of the vm versions: mmencode (both) mimencode (both) base64 b64en/decode qprint not to mention perl python one liners.
Re: [VM] MIME encoding/decoding
Sounds good to me too! --Manuel -- - Manuel Hermenegildo |manuel.hermenegi...@imdea.org -
Re: [VM] MIME encoding/decoding
John Hein writes: We should check the performance of builtin decoding - particularly with larger messages on slower machines. That said, most of the unix flavors cygwin out there now have one or more command line tools to en/decode base64 (less prevalent are qp tools) which can take the place of the vm versions: As I said, base64 is now a non-issue because Emacsen have built-in functions for it. For Quoted Pritable, you can check performance of the elisp code by setting qp-decoder-program and qp-encoder-program to nil. Cheers, Uday
[VM] MIME encoding/decoding
VM has traditionally shipped with C programs for MIME encoding/decoding. Rob F created an entire Unix-like infrastructure (Make files, configure, autoconf etc.) pretty much to handle just these. If we get rid of these C programs, VM can be shipped just like any other emacs library. Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality for base64. So, we can use them. For the Quoted Printable format, emacs-lisp seems to be fast enough. Gnus has been using it for ages and everybody seems happy with that. So, I am thinking of getting rid of the C programs for MIME. Does anybody see any problem with that? Cheers, Uday (Coming back after a long hibernation)
