XEmacs builds failing - gnus-spec.el

XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

  Hi.


It looks like the XEmacs runs on the buildbot:

 * http://www.randomsample.de:4456/waterfall

have been failing since a21954c3 "Prefer UTF-8 when the encoding
shouldn't matter and changes are small".

The 21.5 build fails with:

    Compiling /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el...
    While compiling gnus-parse-complex-format in file /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el:
      !! error (("reference to free variable �"))

while the 21.4 compile times out after 1200 seconds, ending with:

    Generating autoloads for lisp/gnus-spec.el...
    command timed out: 1200 seconds without output, attempting to kill
    process killed by signal 9

The commit looks quite innocent:

 * http://git.gnus.org/cgit/gnus.git/diff/lisp/gnus-spec.el?id=a21954c3

I have tried reproducing the problem with the XEmacs 21.5 I happen to
have installed (XEmacs 21.5  (beta31) "ginger" 10f179710250+), but I
don't seem to be able to.

Any ideas?


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[Mike Kupfer]

Hi Adam!

Adam Sjøgren wrote:

> It looks like the XEmacs runs on the buildbot:
> 
>  * http://www.randomsample.de:4456/waterfall
> 
> have been failing since a21954c3 "Prefer UTF-8 when the encoding
> shouldn't matter and changes are small".
> 
> The 21.5 build fails with:
> 
>     Compiling /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el...
>     While compiling gnus-parse-complex-format in file /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el:
>       !! error (("reference to free variable �"))

I expect this has something to do with the guillemet quote, maybe the
comparison with ``delim'':

		  (= delim ?\«))

(I hope that came out okay; I'm copying it from a Latin-1 file to a
UTF-8 email message, and I don't know if XEmacs will do the conversion
properly.)

a21954c3 changed the source encoding of gnus-spec.el from Latin-1 to
UTF-8.

Were the involved XEmacsen (the buildbot one and yours) configured with
--with-mule?  IIRC, it's not the default.

mike

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

  Hi Mike!


Mike Kupfer <mike.kupfer@xemacs.org> writes:

>>     Compiling /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el...
>>     While compiling gnus-parse-complex-format in file /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el:
>>       !! error (("reference to free variable �"))

> I expect this has something to do with the guillemet quote, maybe the
> comparison with ``delim'':
>
> 		  (= delim ?\«))

Ok - do you have any suggestions for how to fix it?

(I wanted to tinker with it myself, but failing to make it fail made me
write here instead :-))

> Were the involved XEmacsen (the buildbot one and yours) configured with
> --with-mule?  IIRC, it's not the default.

Good question. I don't know about the buildbot, I think my local one
was, because the binary is called "xemacs-21.5-b31-mule".

So if the buildbot's binary is non-mule, it might be a problem only for
non-mule XEmacsen...

                                 o o o

Oh, I just realized that I also have an XEmacs 21.4 installed (Debian
package). "make EMACS=/usr/bin/xemacs-21.4.22-mule" in a fresh Gnus
checkout fails like this:

  Generating autoloads for lisp/gnus-spec.el...
  Unbalanced parentheses
  xemacs exiting

If I roll back the changes to gnus-spec.el, it completes the 'make'
without error.

Interesting, now I have something to tinker with, even though it only is
the old version.


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Mike Kupfer <mike.kupfer@xemacs.org> writes:

>> 		  (= delim ?\«))

I wonder if simply changing that to (= delim ?\u00AB)) would do the
trick. It gets rid of this error:

>   Generating autoloads for lisp/gnus-spec.el...
>   Unbalanced parentheses
>   xemacs exiting

on the XEmacs 21.4 (mule) on my machine.


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

asjo@koldfront.dk (Adam Sjøgren) writes:

> I wonder if simply changing that to (= delim ?\u00AB)) would do the
> trick.

That made the 21.5 buildbot go green:

 * http://www.randomsample.de:4456/waterfall

Cool!

Now the 21.4 fails somewhere after yenc.el instead of on gnus-spec.el,
so that's progress as well:

 * http://www.randomsample.de:4456/builders/xemacs21.4-linux/builds/963/steps/compile/logs/stdio


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[David Engster]

Adam Sjøgren writes:
> asjo@koldfront.dk (Adam Sjøgren) writes:
>
>> I wonder if simply changing that to (= delim ?\u00AB)) would do the
>> trick.
>
> That made the 21.5 buildbot go green:
>
>  * http://www.randomsample.de:4456/waterfall
>
> Cool!

Thanks for fixing this. The XEmacs on the Buildbot is indeed build with
default specs, i.e., without Mule.

> Now the 21.4 fails somewhere after yenc.el instead of on gnus-spec.el,
> so that's progress as well:
>
>  * http://www.randomsample.de:4456/builders/xemacs21.4-linux/builds/963/steps/compile/logs/stdio

No, it fails before with

While compiling gnus-parse-complex-format in file /var/lib/buildbot/slaves/debian/build-xemacs21.4/build/lisp/gnus-spec.el:
  !! error (("reference to free variable 00AB"))

XEmacs 21.4 behaves strangely with the Buildbot. If there is an error,
it stalls at the end until the Buildbot kills the process; yenc.el is
simply the last file that is compiled. It works fine on the command
line, so I've no idea why it does not work when called from the
Buildbot.

-David

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

David Engster <deng@randomsample.de> writes:

> Adam Sjøgren writes:

>> Now the 21.4 fails somewhere after yenc.el instead of on
>> gnus-spec.el, so that's progress as well:

>>  * http://www.randomsample.de:4456/builders/xemacs21.4-linux/builds/963/steps/compile/logs/stdio

> No, it fails before with

> While compiling gnus-parse-complex-format in file
> /var/lib/buildbot/slaves/debian/build-xemacs21.4/build/lisp/gnus-spec.el:
>   !! error (("reference to free variable 00AB"))

Ah, I overlooked that. It failed when generating the autoloads on
gnus-spec.el before:

 * http://www.randomsample.de:4456/builders/xemacs21.4-linux/builds/962/steps/compile/logs/stdio

                                 o o o

I wonder why I can't reproduce the problem on my own machine. Hm.


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

asjo@koldfront.dk (Adam Sjøgren) writes:

> I wonder why I can't reproduce the problem on my own machine. Hm.

Oh, I can - evaluating:

  (message (format "%s" ?\u00AB))

in both mule and nomule XEmacs 21.4.22 gives me:

  Symbol's value as variable is void: 00AB

I wonder if it would work to simply replace ?\u00AB with 171.


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[Katsumi Yamaoka]

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

Adam Sjøgren wrote:
> Oh, I can - evaluating:

>   (message (format "%s" ?\u00AB))

> in both mule and nomule XEmacs 21.4.22 gives me:

>   Symbol's value as variable is void: 00AB

Yes, XEmacs 21.4 doesn't support such read sequence.

> I wonder if it would work to simply replace ?\u00AB with 171.

?\« is ok for XEmacs 21.4 if it loads the Mule-UCS package that
provides the utf-8 coding system.  To use it, do:

(require 'un-define)

But as for loading gnus-spec.el, there's another problem for
XEmacs 21.4; the coding cookie, put in the `Local Variables'
section at the end of the file, won't be effective.  So,
gnus-spec.el will not necessarily be loaded as a utf-8 file.
AFAIK, the only effective coding cookie is the one put at
the beginning of a file.

A patch that involves those consideration is below.

BTW, isn't it possible for Gnus to drop the XEmacs 21.4 support?


[-- Attachment #2: Type: text/x-patch, Size: 1110 bytes --]

--- dgnushack.el~	2013-01-06 22:08:11 +0000
+++ dgnushack.el	2013-05-20 23:53:55 +0000
@@ -24,6 +24,13 @@
 
 ;;; Code:
 
+(if (and (featurep 'xemacs)
+	 (fboundp 'find-coding-system)
+	 (not (find-coding-system 'utf-8)))
+    (condition-case nil
+	(require 'un-define)
+      (error nil)))
+
 (defvar dgnushack-default-load-path (copy-sequence load-path))
 
 (defalias 'facep 'ignore)
--- gnus-spec.el~	2013-05-20 22:12:26 +0000
+++ gnus-spec.el	2013-05-20 23:53:57 +0000
@@ -1,4 +1,4 @@
-;;; gnus-spec.el --- format spec functions for Gnus
+;;; gnus-spec.el --- format spec functions for Gnus -*- coding: utf-8 -*-
 
 ;; Copyright (C) 1996-2013 Free Software Foundation, Inc.
 
@@ -441,7 +441,7 @@
 	      (delim (aref (match-string 2) 0)))
 	  (if (or (= delim ?\()
 		  (= delim ?\{)
-		  (= delim ?\u00AB)) ; «
+		  (= delim ?\«))
 	      (replace-match (concat "\"("
 				     (cond ((= delim ?\() "mouse")
 					   ((= delim ?\{) "face")
@@ -732,8 +732,4 @@
 
 (provide 'gnus-spec)
 
-;; Local Variables:
-;; coding: utf-8
-;; End:
-
 ;;; gnus-spec.el ends here

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

  Hi Katsumi.


Katsumi Yamaoka <yamaoka@jpl.org> writes:

> ?\« is ok for XEmacs 21.4 if it loads the Mule-UCS package that
> provides the utf-8 coding system.

But wouldn't just "171" work as well? Then we don't have to worry about
Mule-UCS etc.

I am probably putting my ignorance on display here... :-)

> BTW, isn't it possible for Gnus to drop the XEmacs 21.4 support?

I don't know - I was just checking to see if I could make the buildbot
go green. It feels like a waste to have a buildbot if red builds are
ignored for longer periods of time.

I guess XEmacs 21.5 won't be released this decade either... O:-)


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[Katsumi Yamaoka]

Adam Sjøgren wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> ?\« is ok for XEmacs 21.4 if it loads the Mule-UCS package that
>> provides the utf-8 coding system.

> But wouldn't just "171" work as well? Then we don't have to worry about
> Mule-UCS etc.
> I am probably putting my ignorance on display here... :-)

Oh, sorry.  I did misread the gnus-spec.el code as it does:

(eq delim 171)

By this way XEmacs doesn't recognize these operands are equal:

(eq (aref "«" 0) 171) -> nil
;; Whereas
(eq (aref "«" 0) ?\«) -> t

However, the op is `=', not `eq'.  (= (aref "«" 0) 171) returns t
in XEmacs 21.4/21.5, I verified.  Could you commit 171?

>> BTW, isn't it possible for Gnus to drop the XEmacs 21.4 support?

> I don't know - I was just checking to see if I could make the buildbot
> go green. It feels like a waste to have a buildbot if red builds are
> ignored for longer periods of time.

> I guess XEmacs 21.5 won't be released this decade either... O:-)

Ah, that is the point.  I forgot there's no stable XEmacs 21.5.
But please let me say, the fact is that some new Gnus features
no longer work on XEmacs (even if the code is compiled with no
error).  Typical ones are the features that use url.el.  As for
XEmacs 21.4, I feel it like old GNU Emacsen that Gnus dropped
the support long ago.  I used to have fun to make Gnus of the
bleeding edge work for XEmacs, but I gave it up someday.

Re: XEmacs builds failing - gnus-spec.el

[Mike Kupfer]

Katsumi Yamaoka wrote:

> But please let me say, the fact is that some new Gnus features
> no longer work on XEmacs (even if the code is compiled with no
> error).  Typical ones are the features that use url.el.  

Hi Katsumi, is this true for XEmacs 21.5, or just 21.4?  Are these all
new features in Ma Gnus, or are older versions of Gnus also affected?
Are there any bug reports that you can point me at?

> As for
> XEmacs 21.4, I feel it like old GNU Emacsen that Gnus dropped
> the support long ago.

Yes, 21.4 is quite old.  If it's too much of a hassle for the Gnus
developers to support, then maybe it's best to drop support for it.
Then whatever time is available for XEmacs support can be focused on
21.5.

best regards,
mike
(Gnus package maintainer for XEmacs)

Re: XEmacs builds failing - gnus-spec.el

[Mike Kupfer]

David Engster wrote:

> The XEmacs on the Buildbot is indeed build with
> default specs, i.e., without Mule.

Would it be possible to change that, so that --with-mule is used?  If
Gnus is using UTF-8 in its source code, it seems likely that non-mule
XEmacs will continue to have problems in the future.

mike

Re: XEmacs builds failing - gnus-spec.el

[Katsumi Yamaoka]

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

Hi Mike,

mike.kupfer@xemacs.org wrote:
> Katsumi Yamaoka wrote:

>> But please let me say, the fact is that some new Gnus features
>> no longer work on XEmacs (even if the code is compiled with no
>> error).  Typical ones are the features that use url.el.

> Hi Katsumi, is this true for XEmacs 21.5, or just 21.4?  Are these all
> new features in Ma Gnus,

As for url.el originated in W3, the code is too old to use with
Gnus for both 21.5 and 21.4.  I don't think `url-retrieve' that
gnus-compat.el redefines helps.  A workaround attached below is
the one I used to use, but I'm not sure if they are still useful
since I haven't been using XEmacs for a couple of years.  For
the same reason, and since I failed to have taken notes, I don't
recall other matters I faced.  But it is not hard to imagine
there are inconsistencies here and there, since most Gnus
developers are GNU Emacs users and they like to use Emacs' new
features (also it sometimes causes Gnus not to work for old GNU
Emacsen).

> or are older versions of Gnus also affected?

If it is the Gnus XEmacs package, I believe it's safe.  I have
no basis for it, though.

> Are there any bug reports that you can point me at?

I'm no longer suitable for doing it, sorry.  The foremost reason
I got not to use XEmacs is that now I'm using Cygwin for almost
daytime (in the office).  On that platform, I was unable to build
XEmacs 21.5 that works normally.  It frequently crashes.
(Even so, I kept building it periodically keeping track of hg.
 However, it stopped months ago because it got unable to build
 on the latest Cygwin.)

>> As for
>> XEmacs 21.4, I feel it like old GNU Emacsen that Gnus dropped
>> the support long ago.

> Yes, 21.4 is quite old.  If it's too much of a hassle for the Gnus
> developers to support, then maybe it's best to drop support for it.
> Then whatever time is available for XEmacs support can be focused on
> 21.5.

That's good to here from the XEmacs team. :)  The only matter is
that there might be no Gnus developers who use 21.5.

Regards,


[-- Attachment #2: Type: application/emacs-lisp, Size: 1194 bytes --]

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> However, the op is `=', not `eq'.  (= (aref "«" 0) 171) returns t
> in XEmacs 21.4/21.5, I verified.  Could you commit 171?

Yep, I have just done so. Let's see what the buildbot says.

> Ah, that is the point.  I forgot there's no stable XEmacs 21.5.
> But please let me say, the fact is that some new Gnus features
> no longer work on XEmacs (even if the code is compiled with no
> error).  Typical ones are the features that use url.el.

Yeah... Lars writing shr.el and the lacklustre performance of XEmacs
21.5 on X on slow(ish) connections was the straw that made me switch to
GNU Emacs.

Paradoxically, I have yet to get used to "emacsclient" not Just Working™
over ssh (-X).

> As for XEmacs 21.4, I feel it like old GNU Emacsen that Gnus dropped
> the support long ago. I used to have fun to make Gnus of the bleeding
> edge work for XEmacs, but I gave it up someday.

You hung in there longer than could be expected of anyone, and I enjoyed
the XEmacs-specific fruits of your labour for many years, so thanks for
that!


  :-),

   Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[David Engster]

Mike Kupfer writes:
> David Engster wrote:
>
>> The XEmacs on the Buildbot is indeed build with
>> default specs, i.e., without Mule.
>
> Would it be possible to change that, so that --with-mule is used? 

Sure, but IMO Gnus should try to build fine on XEmacsen that are build
with the defaults. The Buildbot is running a rather old version (b29),
but I don't think --with-mule has become default yet?

-David

Re: XEmacs builds failing - gnus-spec.el

[Adam Sjøgren]

asjo@koldfront.dk (Adam Sjøgren) writes:

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

>> However, the op is `=', not `eq'.  (= (aref "«" 0) 171) returns t
>> in XEmacs 21.4/21.5, I verified.  Could you commit 171?

> Yep, I have just done so. Let's see what the buildbot says.

It worked!

 * http://www.randomsample.de:4456/waterfall

How small changes are supposed to be ChangeLog'ed? (I didn't write
anything for this, or for the follow up commit I did to another commit
shortly after a change.)


  Cheers all around,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: XEmacs builds failing - gnus-spec.el

[David Engster]

Katsumi Yamaoka writes:
> But please let me say, the fact is that some new Gnus features
> no longer work on XEmacs (even if the code is compiled with no
> error).  Typical ones are the features that use url.el.

Another example is the registry, which is not persistent under XEmacs
because it lacks a printed representation for hash tables.

-David

Re: XEmacs builds failing - gnus-spec.el

[Mike Kupfer]

Katsumi Yamaoka wrote:
> mike.kupfer@xemacs.org wrote:

[...]
> As for url.el originated in W3, the code is too old to use with
> Gnus for both 21.5 and 21.4.  I don't think `url-retrieve' that
> gnus-compat.el redefines helps.  A workaround attached below is
> the one I used to use, but I'm not sure if they are still useful
> since I haven't been using XEmacs for a couple of years.  For
> the same reason, and since I failed to have taken notes, I don't
> recall other matters I faced.  

That's okay--I appreciate the information about the url code and the
sample workaround code.  Thanks.

> > Are there any bug reports that you can point me at?
> 
> I'm no longer suitable for doing it, sorry.  The foremost reason
> I got not to use XEmacs is that now I'm using Cygwin for almost
> daytime (in the office).  On that platform, I was unable to build
> XEmacs 21.5 that works normally.  It frequently crashes.
> (Even so, I kept building it periodically keeping track of hg.
>  However, it stopped months ago because it got unable to build
>  on the latest Cygwin.)

Hmm.  I don't use Cygwin, so I don't know what the current status is for
XEmacs on Cygwin.  Looking in the hg log, I do see this fix, so maybe
it's worth trying again...?

    changeset:   5716:1003acd5a4b8
    user:        Vin Shelton <acs@xemacs.org>
    date:        Mon Feb 04 20:03:04 2013 -0500
    summary:     Fix cygwin build on new win32api.

> > Yes, 21.4 is quite old.  If it's too much of a hassle for the Gnus
> > developers to support, then maybe it's best to drop support for it.
> > Then whatever time is available for XEmacs support can be focused on
> > 21.5.
> 
> That's good to here from the XEmacs team. :)  The only matter is
> that there might be no Gnus developers who use 21.5.

Understood.  I'm hoping to get my packaging workflow running smoothly so
that I can track and lightly test development releases of Gnus.  (Though
I can't say when I'll get to this.)

best wishes,
mike

Re: XEmacs builds failing - gnus-spec.el

[Mike Kupfer]

David Engster wrote:

> Mike Kupfer writes:
> > David Engster wrote:
> >
> >> The XEmacs on the Buildbot is indeed build with
> >> default specs, i.e., without Mule.
> >
> > Would it be possible to change that, so that --with-mule is used? 
> 
> Sure, but IMO Gnus should try to build fine on XEmacsen that are build
> with the defaults. 

Okay, fair enough.

> The Buildbot is running a rather old version (b29),
> but I don't think --with-mule has become default yet?

Not yet, though there's been some discussion about making it the
default.

cheers,
mike

Re: XEmacs builds failing - gnus-spec.el

[Mike Kupfer]

David Engster wrote:

> Katsumi Yamaoka writes:
> > But please let me say, the fact is that some new Gnus features
> > no longer work on XEmacs (even if the code is compiled with no
> > error).  Typical ones are the features that use url.el.
> 
> Another example is the registry, which is not persistent under XEmacs
> because it lacks a printed representation for hash tables.

Interesting; thanks.  It looks like 21.5 has a printed representation,
but the output from #'print can't be fed back to #'read.  I'll file an
XEmacs bug.

mike

Re: XEmacs builds failing - gnus-spec.el

[Mats Lidell]

>>>>> Mike Kupfer <mike.kupfer@xemacs.org> writes:

> Hmm.  I don't use Cygwin, so I don't know what the current status is
> for XEmacs on Cygwin.  Looking in the hg log, I do see this fix, so
> maybe it's worth trying again...?

Latest beta should be OK. I'm using it ;-)

... but there is some problem with processes run within XEmacs. Like
if I do M-x shell I get the *shell* buffer with the text: "Process
bash stopped (tty output)" (Anyone who reads this and has a clue what
is going on here please drop me a line since I'm stuck in solving
this.)

Yours
-- 
%% Mats

XEmacs hash table representation (was XEmacs builds failing - gnus-spec.el)

[Mike Kupfer]

Mike Kupfer wrote:

> David Engster wrote:
> > Another example is the registry, which is not persistent under XEmacs
> > because it lacks a printed representation for hash tables.
> 
> Interesting; thanks.  It looks like 21.5 has a printed representation,
> but the output from #'print can't be fed back to #'read.  I'll file an
> XEmacs bug.

I looked into this some more.  It turns out that #'print et al can be
told to use a read-able representation for hash tables; it's just not
the default.  To get a read-able representation, you first have to bind
print-readably to t, as in

  (setq myhash (make-hash-table))
  (let ((print-readably t)) (prin1-to-string myhash))

I suggested making the read-able representation the default, but that
was rejected.

Does Gnus need to preserve the hash table metadata (rehash-size et al)?
I was wondering if it would work just as well for Gnus to use an alist
as the external representation for a hash table.

regards,
mike

Re: XEmacs hash table representation (was XEmacs builds failing - gnus-spec.el)

[David Engster]

Mike Kupfer writes:
> Does Gnus need to preserve the hash table metadata (rehash-size et al)?
> I was wondering if it would work just as well for Gnus to use an alist
> as the external representation for a hash table.

It's not about the hash table metadata but about speed. Before Ted
rewrote the code, the registry used to do a conversion to/from an alist,
and I remember that writing/reading the registry this way was annoyingly
slow, at least on slow machines in combination with big registries (mine
has about 100.000 entries).

Of course, one could still do that specially for XEmacs. I guess all it
takes is to define a proper ':printer' slot for the registry
object. Someone just has to do it.

-David

Re: XEmacs hash table representation (was XEmacs builds failing - gnus-spec.el)

[Mike Kupfer]

David Engster wrote:

> It's not about the hash table metadata but about speed. Before Ted
> rewrote the code, the registry used to do a conversion to/from an alist,
> and I remember that writing/reading the registry this way was annoyingly
> slow, at least on slow machines in combination with big registries (mine
> has about 100.000 entries).

Ah, okay.  Thanks for the clarification.

> Of course, one could still do that specially for XEmacs. I guess all it
> takes is to define a proper ':printer' slot for the registry
> object. 

For the sake of interoperability, I think that it'd be better to print
the hash table for XEmacs (with print-readably set to t).  I did some
(very) limited testing, and it looked like the printed representations
of hash tables are compatible between Emacs and XEmacs.

best regards,
mike

Re: XEmacs hash table representation (was XEmacs builds failing - gnus-spec.el)

[Ted Zlatanov]

On Sun, 02 Jun 2013 09:22:34 -0700 Mike Kupfer <mike.kupfer@xemacs.org> wrote: 

MK> David Engster wrote:
>> It's not about the hash table metadata but about speed. Before Ted
>> rewrote the code, the registry used to do a conversion to/from an alist,
>> and I remember that writing/reading the registry this way was annoyingly
>> slow, at least on slow machines in combination with big registries (mine
>> has about 100.000 entries).

MK> Ah, okay.  Thanks for the clarification.

I've been wondering (in my free time) whether it would make sense to
provide an even faster binary backend for the registry file.

BSON looks pretty good.  Its C implementation is pretty simple.

https://github.com/casualjim/emacs.d/blob/master/elpa/mongo-20120826.14/bson.el
provides a pure ELisp implementation we could use if a C implementation
was not available (in older Emacsen/XEmacsen).

Right now all this is just idle wondering...

>> Of course, one could still do that specially for XEmacs. I guess all it
>> takes is to define a proper ':printer' slot for the registry
>> object. 

MK> For the sake of interoperability, I think that it'd be better to print
MK> the hash table for XEmacs (with print-readably set to t).  I did some
MK> (very) limited testing, and it looked like the printed representations
MK> of hash tables are compatible between Emacs and XEmacs.

They are not, unfortunately...  I forget the exact issues because this
was years ago but there were some annoying cases with the data, both
with the metadata and with the string encodings.

Ted

Re: XEmacs hash table representation (was XEmacs builds failing - gnus-spec.el)

[Mike Kupfer]

Ted Zlatanov wrote:

> On Sun, 02 Jun 2013 09:22:34 -0700 Mike Kupfer <mike.kupfer@xemacs.org> wrote: 
> MK> I did some
> MK> (very) limited testing, and it looked like the printed representations
> MK> of hash tables are compatible between Emacs and XEmacs.
> 
> They are not, unfortunately...  I forget the exact issues because this
> was years ago but there were some annoying cases with the data, both
> with the metadata and with the string encodings.

Rats.  Okay, thanks for the information.

mike