ELisp-based uncompface

ELisp-based uncompface

[Katsumi Yamaoka]

Hi,

I've merged the ELisp-based uncompface program into compface.el.
This was written by TAKAI Kousuke (`Kousuke' is his personal
name), he is now working on the paper to assign the copyright to
FSF.  It makes it possible to show X-Face images without the
external uncompface and icontopbm programs or the libcompface
library.  It won't be activated for almost users but you can
test it by setting nil to the uncompface-use-external variable
if you are interested in it:

(setq uncompface-use-external nil)

Even if you are an XEmacs user and the libcompface library is
available, you can seal it off and test the ELisp-based
uncompface program with the following:

(setq uncompface-use-external nil
      features (delq 'xface features))

The original code[1] TAKAI Kousuke wrote used the bool vector
feature of Emacs.  However, inlined bool vector tables (i.e.,
inlined binary data) in the elc file will be broken or
incompatible between Emacs versions, and that feature is not
available in XEmacs (or should be replaced with the bit vector
feature).  So, we replaced them with the simple vectors.
Although it makes the elc file fatten, I've confirmed it doesn't
degrade the performance.

Regards,

[1] http://www.kmc.gr.jp/~tak/sources/el/uncompface.el-1.2.gz
You need to fix the mis-inlined binary data by Emacs 21 in the
uncompface.elc file using

http://www.kmc.gr.jp/~tak/sources/el/fix-boolvec.el-1.1.gz

as

emacs -batch -l fix-boolvec.el -f batch-fix-bool-vectors uncompface.elc
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: ELisp-based uncompface

[Jesper Harder]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I've merged the ELisp-based uncompface program into compface.el.
> This was written by TAKAI Kousuke (`Kousuke' is his personal
> name), he is now working on the paper to assign the copyright to
> FSF.  It makes it possible to show X-Face images without the
> external uncompface and icontopbm programs or the libcompface
> library.

Excellent.

> It won't be activated for almost users but you can test it by
> setting nil to the uncompface-use-external variable if you are
> interested in it:
>
> (setq uncompface-use-external nil)

It works fine for me and it's fast enough (I guess a lot of effort was
spent on making it fast).

If no problems turn up I think the internal decoder should be the
default.  The reason is that I trust Lisp code much more than C to not
have nasty and possibly exploitable buffer overflows.


Incidentally, I was just discussing attachments and viruses in another
group, and challenged them to think of any attachment that would be
unsafe for me to open.

The only thing they could come up with until now is the temporary file
bug in x-face-el (which a. hasn't been part of Gnus, b. can't really
be used for a virus since it was only a local exploit).

But anyway, it does point to the fact that it would be unpleasant if
someone found an exploitable flaw in uncompface or icontopbm.

Re: ELisp-based uncompface

[Katsumi Yamaoka]

I'm not sure whether TAKAI Kousuke subscribes this list, so I Cc
this message to him with the whole quotations.

>>>>> In <m37jytugpx.fsf@defun.localdomain>
>>>>>	Jesper Harder <harder@ifa.au.dk> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> I've merged the ELisp-based uncompface program into compface.el.
>> This was written by TAKAI Kousuke (`Kousuke' is his personal
>> name), he is now working on the paper to assign the copyright to
>> FSF.  It makes it possible to show X-Face images without the
>> external uncompface and icontopbm programs or the libcompface
>> library.

> Excellent.

Thanks.  All praise should go to TAKAI Kousuke.

>> It won't be activated for almost users but you can test it by
>> setting nil to the uncompface-use-external variable if you are
>> interested in it:
>>
>> (setq uncompface-use-external nil)

> It works fine for me and it's fast enough (I guess a lot of effort was
> spent on making it fast).

> If no problems turn up I think the internal decoder should be the
> default.

It's fast enough for me too, however I heard it takes seconds
per image in the slow machine.  But now I've changed the default
value for uncompface-use-external to nil.  If you aren't
satisfied with the speed, please alter the value.  Otherwise, we
can add the caching images mechanism if it is requested.

> The reason is that I trust Lisp code much more than C to not
> have nasty and possibly exploitable buffer overflows.

> Incidentally, I was just discussing attachments and viruses in another
> group, and challenged them to think of any attachment that would be
> unsafe for me to open.

> The only thing they could come up with until now is the temporary file
> bug in x-face-el (which a. hasn't been part of Gnus, b. can't really
> be used for a virus since it was only a local exploit).

> But anyway, it does point to the fact that it would be unpleasant if
> someone found an exploitable flaw in uncompface or icontopbm.

Oh, I see.  I hadn't considered problems with external programs.
Thanks again.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: ELisp-based uncompface

[Jesper Harder]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> It's fast enough for me too, however I heard it takes seconds
> per image in the slow machine.

It takes around 0.3 s (versus 0.03 s for the external decoder) on my
233 MHz pentium box, which I think is a rather low-end machine by
today's standards.

It's not used in a loop, so don't think many will notice any
difference even on a slow machine.

Re: ELisp-based uncompface

[Katsumi Yamaoka]

>>>>> In <m3isicu9l6.fsf@defun.localdomain>
>>>>>	Jesper Harder <harder@ifa.au.dk> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> It's fast enough for me too, however I heard it takes seconds
>> per image in the slow machine.

> It takes around 0.3 s (versus 0.03 s for the external decoder) on my
> 233 MHz pentium box, which I think is a rather low-end machine by
> today's standards.

That is quite fast than my imagination. :)

> It's not used in a loop, so don't think many will notice any
> difference even on a slow machine.

Indeed.  Thanks.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: ELisp-based uncompface

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On 12 Feb 2004, Katsumi Yamaoka told this:

> Hi,

Yo,
 
> I've merged the ELisp-based uncompface program into compface.el.
> This was written by TAKAI Kousuke (`Kousuke' is his personal
> name), he is now working on the paper to assign the copyright to
> FSF.  It makes it possible to show X-Face images without the
> external uncompface and icontopbm programs or the libcompface
> library.  It won't be activated for almost users but you can
> test it by setting nil to the uncompface-use-external variable
> if you are interested in it:
> 
> (setq uncompface-use-external nil)

I have tried and must say it is excellent :) Congratulations to TAKAI
and you.

zeDek
-- 
GnusFR  (http://www.gnusfr.org)
EmacsFR (http://www.emacsfr.org)

.emacs: Because customisation is fun!


[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: ELisp-based uncompface

[Reiner Steib]

On Thu, Feb 12 2004, Jesper Harder wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>> It's fast enough for me too, however I heard it takes seconds
>> per image in the slow machine.
>
> It takes around 0.3 s (versus 0.03 s for the external decoder) on my
> 233 MHz pentium box, which I think is a rather low-end machine by
> today's standards.
>
> It's not used in a loop, so don't think many will notice any
> difference even on a slow machine.

Hm, the delay is notable on my P200 and P266 I'm using at home.  (I
didn't benchmark it, though.)

Is there a (portable) way in lisp to find out if the machine is slow?
Maybe it's enough to mention `uncompface-use-external' in (info
"(gnus)Slow Machine").

If we just want to provide support for installations missing the
external "uncompface" (this was the initial motivation, if I
understood correctly), we could use something like this:

(defcustom uncompface-use-external (and (executable-find "uncompface")
					(executable-find "icontopbm")
					t)
[...])

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: ELisp-based uncompface

[Katsumi Yamaoka]

>>>>> In <v98yj33yty.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:

> Hm, the delay is notable on my P200 and P266 I'm using at home.  (I
> didn't benchmark it, though.)

Sorry for inconvenience.

> Is there a (portable) way in lisp to find out if the machine is slow?

I've implemented the autodetection.  If the value of
uncompface-use-external is `undecided' (now which is the
default) and the internal decoder takes a long time to decode
an X-Face at the first time, uncompface-use-external will be
altered to t.  The threshold is currently 0.1-sec by default
which is specified by the uncompface-use-external-threshold
variable, although I'm not sure whether the value is suitable.
Could you test it?

> Maybe it's enough to mention `uncompface-use-external' in (info
> "(gnus)Slow Machine").

Also I'll do it later.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: ELisp-based uncompface

[Reiner Steib]

On Tue, Feb 17 2004, Katsumi Yamaoka wrote:

>>>>>> In <v98yj33yty.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:
>
>> Hm, the delay is notable on my P200 and P266 I'm using at home.  (I
>> didn't benchmark it, though.)
>
> Sorry for inconvenience.

No problem.  This was just a remark, not a complaint. :-)

> If the value of uncompface-use-external is `undecided' (now which is
> the default) and the internal decoder takes a long time to decode an
> X-Face at the first time, uncompface-use-external will be altered to
> t.  The threshold is currently 0.1-sec by default which is specified
> by the uncompface-use-external-threshold variable, although I'm not
> sure whether the value is suitable.  Could you test it?

It works fine and I think 0.1 seconds is suitable.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: ELisp-based uncompface

[Ted Zlatanov]

On Tue, 17 Feb 2004, yamaoka@jpl.org wrote:

>>>>>> In <v98yj33yty.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:
> 
>> Hm, the delay is notable on my P200 and P266 I'm using at home.  (I
>> didn't benchmark it, though.)
> 
> Sorry for inconvenience.

Can you use the gnus-registry to cache the parsed faces?  You can
just make up a fake message ID, maybe a MD5 hash of the face itself,
and then put the face in as extra data.  The only requirement is that
every entry in the registry have a group, so you can use whatever
group name you want for this.  Can a face be stored this way?

Ted

Re: ELisp-based uncompface

[Katsumi Yamaoka]

>>>>> In <4nsmh8xpwj.fsf@collins.bwh.harvard.edu>
>>>>>	Ted Zlatanov <tzz@lifelogs.com> wrote:

> Can you use the gnus-registry to cache the parsed faces?  You can
> just make up a fake message ID, maybe a MD5 hash of the face itself,
> and then put the face in as extra data.  The only requirement is that
> every entry in the registry have a group, so you can use whatever
> group name you want for this.  Can a face be stored this way?

> Ted

Thanks.  That's a good idea.  Hm, however, I am quite satisfied
with TAKAI's ELisp uncompface.:)  If there are much slow machines
more than I imagine, I'm not stingy to take it into consideration,
though.  Storing faces itself seems easy.

Another way is to embed the libcompface library into Emacs.:)
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: ELisp-based uncompface

[Katsumi Yamaoka]

>>>>> In <b9y8yj9p1kc.fsf@jpl.org> Katsumi Yamaoka wrote:

> I've merged the ELisp-based uncompface program into compface.el.
> This was written by TAKAI Kousuke (`Kousuke' is his personal
> name), he is now working on the paper to assign the copyright to
> FSF.

I inquired to FSF and noticed TAKAI Kousuke hasn't completed the
paper work yet although it passed more than half a year.  I asked
his senior to persuade him repeatedly, but he doesn't respond so
far.  I'm perplexed.  Sigh.

Although it is a real disappointment, I think I should remove the
change or move it to the contrib directory.  Any ideas?