Re: Inefficiency in mm-uu.el

Re: Inefficiency in mm-uu.el

[Shenghuo ZHU]

>>>>> "HN" == Hrvoje Niksic <hniksic@srce.hr> writes:

HN> The uuencode interface to mm seems very inefficient, because of
HN> two separate reasons.  When I `g' a message containing a, say, an
HN> uuencoded image, it insists on decoding the uuencoded region (I
HN> can tell by the time `g' takes and by the conducted profiles.)

HN> When I click on the image button to show it, it decodes it again.
HN> Why this double encoding?

The first decoding is due to mm-inlinable-p. With the attached patch,
each type is tested at most once in a session.

HN> The other question is about the strange default -- the code
HN> defaults to using the internal, elisp-based decoding, even when a
HN> perfectly valid `uudecode' is found on the system.  This makes
HN> decoding of large stuff (and uuencoded stuff is large, more often
HN> than not) abysmally slow, even on very very fast machines.  I can
HN> imagine that on slower machines it's closer to "unusable".

Do you mean to automatically setup mm-uu-decode-function by searching
uudecode on the system at loading time of mm-uu.el?  If so, please
feel free to patch it.

-- 
Shenghuo

:- cut -----
--- ChangeLog	1998/11/29 08:49:39	1.1
+++ ChangeLog	1998/11/29 08:51:02
@@ -1,3 +1,7 @@
+Sun Nov 29 03:50:20 1998  Shenghuo ZHU  <zsh@cs.rochester.edu>
+
+	* mm-decode.el (mm-inlinable-p): Save the result of test.
+
 Fri Nov 27 12:26:10 1998  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>
 
 	* gnus.el: Pterodactyl Gnus v0.55 is released.

--- mm-decode.el	1998/11/29 08:44:18	1.1
+++ mm-decode.el	1998/11/29 08:47:55
@@ -357,9 +357,11 @@
 	test)
     (while alist
       (when (equal type (caar alist))
-	(setq test (caddar alist)
-	      alist nil)
-	(setq test (eval test)))
+	(setq test (caddar alist))
+	(when (consp test)
+	  (setq test (eval test))
+	  (setf (caddar alist) test))
+	(setq alist nil))
       (pop alist))
     test))
 

Re: Inefficiency in mm-uu.el

[Hrvoje Niksic]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> >>>>> "HN" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> HN> The uuencode interface to mm seems very inefficient, because of
> HN> two separate reasons.  When I `g' a message containing a, say, an
> HN> uuencoded image, it insists on decoding the uuencoded region (I
> HN> can tell by the time `g' takes and by the conducted profiles.)
> 
> HN> When I click on the image button to show it, it decodes it again.
> HN> Why this double encoding?
> 
> The first decoding is due to mm-inlinable-p. With the attached
> patch, each type is tested at most once in a session.

Cool, thanks.

> HN> The other question is about the strange default -- the code
> HN> defaults to using the internal, elisp-based decoding, even when
> HN> a perfectly valid `uudecode' is found on the system.  This makes
> HN> decoding of large stuff (and uuencoded stuff is large, more
> HN> often than not) abysmally slow, even on very very fast machines.
> HN> I can imagine that on slower machines it's closer to "unusable".
> 
> Do you mean to automatically setup mm-uu-decode-function by
> searching uudecode on the system at loading time of mm-uu.el?

Yes.

> If so, please feel free to patch it.

Yes, if Lars will accept the patch.  I seem to recall he said
something about "not trusting external programs" for base64, so I
don't know if it applies to uuencode.  Lars?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
You know it's going to be a bad day when your twin brother forgot
your birthday.

Re: Inefficiency in mm-uu.el

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Do you mean to automatically setup mm-uu-decode-function by
> > searching uudecode on the system at loading time of mm-uu.el?
> 
> Yes.
> 
> > If so, please feel free to patch it.
> 
> Yes, if Lars will accept the patch.  I seem to recall he said
> something about "not trusting external programs" for base64, so I
> don't know if it applies to uuencode.  Lars?

Well, I, uhm (sorry, I'm watching _Schindler's List_ while listening
to _Dots and Loops_ and answering mail) er, uhm, I think that having
an external program to decode uuencoded things is probably fine.
(Ooo.  Who knew those dastardly Germans were so *naughty*.  I'm glad we 
have directors like Spielberg!)  External programs are a general cause 
of breakage, especially in Emacs 20.3 -- how many bug reports have we
had for NT-related metamail (etc.) breakages?  But I think it's fine
to give users an opportunity to use external programs as long as it's
not the default.  (Wow.  I'm write I lot more verbosely when I'm
watching telly while typing instead of watching what I type.  The lack 
of concentration might have something to do with it.  Nah.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Inefficiency in mm-uu.el

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > Do you mean to automatically setup mm-uu-decode-function by
> > > searching uudecode on the system at loading time of mm-uu.el?
> > 
> > Yes.
> > 
> > > If so, please feel free to patch it.
> > 
> > Yes, if Lars will accept the patch.  I seem to recall he said
> > something about "not trusting external programs" for base64, so I
> > don't know if it applies to uuencode.  Lars?
> 
> Well, I, uhm (sorry, I'm watching _Schindler's List_ while listening
> to _Dots and Loops_ and answering mail) er, uhm, I think that having
> an external program to decode uuencoded things is probably fine.
> (Ooo.  Who knew those dastardly Germans were so *naughty*.  I'm glad we 
> have directors like Spielberg!)  External programs are a general cause 
> of breakage, especially in Emacs 20.3 -- how many bug reports have we
> had for NT-related metamail (etc.) breakages?  But I think it's fine
> to give users an opportunity to use external programs as long as it's
> not the default.

So my imaginary patch would not be accepted.

Because, we already have what you describe.  The following piece of
code in .emacs will enable the use of an external program:

    (setq mm-uu-decode-function 'uudecode-decode-region-external)

does it.  What I wanted to do is something along the lines of:

    (defvar mm-uu-decode-function (if (locate-file "uudecode" exec-path)
				      'uudecode-decode-region-external
				    'uudecode-decode-region))


P.S.
The latest XEmacs 21.2 has native base64 support.  Let us all
rejoice.  Sending flowers is optional.

P.S.
Fortunately, I *didn't* watch _Saving Private Ryan_ while typing this.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
AMAZING BUT TRUE: There is so much sand in Northern Africa that if
it were spread out it would completely cover the Sahara Desert.

Re: Inefficiency in mm-uu.el

[Jan Vroonhof]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (Ooo.  Who knew those dastardly Germans were so *naughty*.  I'm glad we 
> have directors like Spielberg!)

Independent of whether this is sarcastic or not let me continue the fine
tradition of "cultural" messages being on-topic here with a
recommendation for "La vita e bella" that one got to me much more than 
Schindler's list.

Jan

Re: Inefficiency in mm-uu.el

[Steinar Bang]

>>>>> Jan Vroonhof <vroonhof@math.ethz.ch>:

> Independent of whether this is sarcastic or not let me continue the
> fine tradition of "cultural" messages being on-topic here with a
> recommendation for "La vita e bella" that one got to me much more
> than Schindler's list.

"(The) Life is Beautilful"...?
	http://www.imdb.com/Details?Vita+%E8+bella,+La+(1997)

Ah!  Roberto Benigni!  Hm... from the plot summary this seems to be
quite a way from Robertos usual characters (ref. the italian taxi
driver from "Night on Earth"...).

Re: Inefficiency in mm-uu.el

[Jean-Yves Perrier]

>>>>> "Steinar" == Steinar Bang <sb@metis.no> writes:
    Steinar> Ah!  Roberto Benigni!  Hm... from the plot summary this seems to be
    Steinar> quite a way from Robertos usual characters (ref. the italian taxi
    Steinar> driver from "Night on Earth"...).
It seems but no. He always speaks so much.


-- 
Jean-Yves

Re: Inefficiency in mm-uu.el

[Jan Vroonhof]

Steinar Bang <sb@metis.no> writes:

> Ah!  Roberto Benigni!  Hm... from the plot summary this seems to be
> quite a way from Robertos usual characters (ref. the italian taxi
> driver from "Night on Earth"...).

Not really. Actually the plot summaries are pretty bad. The first part
is actually a quite funny typically Benigni style film that for some
reason plays in Mussolini-era italy and basically introduces the
character Benigni is playing, always making fun of things etc. The
second part is about "to convince [his son] [the concentration camp]
is an elaborate game, a special contest to win a tank" which the
second summary has more like an afterthought. This is based on a
comment by Primo Levi who said that his first two weeks in Auswitz
were like being in a film. This attempt to pass it off as something
unreal made the grim reality all the more heavy to me.

Jan

Re: Inefficiency in mm-uu.el

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> +	(setq test (caddar alist))
> +	(when (consp test)
> +	  (setq test (eval test))
> +	  (setf (caddar alist) test))
> +	(setq alist nil))

No, this can't be done this way, because the tests in
`mm-inline-media-tests' aren't static, but test (for instance) whether 
the image in question will fit into the window.  And stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Inefficiency in mm-uu.el

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> 
> > +	(setq test (caddar alist))
> > +	(when (consp test)
> > +	  (setq test (eval test))
> > +	  (setf (caddar alist) test))
> > +	(setq alist nil))
> 
> No, this can't be done this way, because the tests in
> `mm-inline-media-tests' aren't static, but test (for instance)
> whether the image in question will fit into the window.  And stuff.

I think you should at least cache the created glyph somewhere, so you
don't create it twice.  In the current implementation, display of
messages with attached images is dog-slow, apparently for no good
reason.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Unspeakable horrors from outer space paralyze the living and
resurrect the dead!

Re: Inefficiency in mm-uu.el

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> I think you should at least cache the created glyph somewhere, so you
> don't create it twice.

Yup.  Fix in Pterodactyl Gnus v0.57.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen