David Reitter | 1 May 01:02 2010
Picon

bug#6069: 23.1.96; sxhash, big uints and overflow-error in custom-file

Not sure if this is an error of Emacs, or if the fault is mine:

- `sxhash' of some object produced a 32-bit unsigned integer, which was represented just fine in Lisp.

- I stored it in a customization variable, which was subsequently saved to my custom-file.

- When reading back the file, I got an overflow error, as in

(read-from-string "2475893479")
--> overflow error

Due to the nature of hashes, it appears unreasonable hard for me to make a test case.  But looking at the code, 
sxhash is designed to produce an unsigned int and make a (signed?) Lisp integer from it.

 INTMASK is 0xffffffff at least on my system.

Artihmetic operations, OTOH convert big ints to floats in arith_driver():

(let ((bigint (+ 1475893479 1000000000)))
  (floatp bigint))

(Would sxhash in that case produce a negative value if its result is printed? I don't know.
Somewhere along the way to `custom-save-variables', some info about the meaning of bit #31 gets lost, and
Emacs produces string representation that can't be read.)

In GNU Emacs 23.1.96.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
of 2010-04-30 on braeburn.aquamacs.org - Aquamacs Distribution 2.0preview6
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns' '--without-x' 'CFLAGS=-arch i386 -arch ppc' 'LDFLAGS=-arch
i386 -arch ppc''
(Continue reading)

Glenn Morris | 1 May 01:51 2010
Picon

bug#6065: Emacs Trunk Build Failure on Mac OS X 10.6


Please update from Bazaar and try again.

Leo | 1 May 03:41 2010
Picon

bug#6070: 23.1.96; delete-by-moving-to-trash

While experimenting some of the new features, I quite like to use
delete-by-moving-to-trash to double protect deleting files by accident.

However, with (setq delete-by-moving-to-trash t), a lot of (internal)
temporary files are also moved to the trash bin. See the attached file
for an output of `ls' in the .Trash directory after roughly two hours of
emacs.

To reproduce, just (setq delete-by-moving-to-trash t) and carry on with
normal Emacs editing. After a while you should notice the trash bin
heavily populated.

The trash bin is a buffer area to rescue a lost file. Flood it with many
internal temp files makes it very difficult to do so. Before emptying
the trash bin (or remove files permanently) I (I guess many will do the
same) often have a quick look at the files. This is now almost
impossible if delete-by-moving-to-trash has been used.

Could someone take a look at this issue? Thank you.

Leo

leo <at> Victoria ~/.Trash$ ls
!Users!leo!GNUS!.newsrc.eld.~106~ diff16258KRU                      diff26258KKg                      emacsca2LL8                       jka-com6258xvm
#%2Ascratch%2A#88815TN#           diff16258LEz                      diff26258WaT                      emacsgM68Dw                       jka-com8881_hQ
#%2Ascratch%2A#8969WYO#           diff16258XUm                      diff26258WhH                      emacsmgCrUd                       jka-com8881yXK
#*message*-20100308-115723#       diff16258jrN                      diff26258XNy                      emacsqCMK1i                       jka-com89692BS
#.newsrc-dribble#                 diff16258v7A                      diff26258Xba                      emacsvlXg3W                       jka-com8969ctF
(Continue reading)

Chong Yidong | 1 May 04:19 2010

bug#6070: 23.1.96; delete-by-moving-to-trash

Leo <sdl.web <at> gmail.com> writes:

> While experimenting some of the new features, I quite like to use
> delete-by-moving-to-trash to double protect deleting files by accident.
>
> However, with (setq delete-by-moving-to-trash t), a lot of (internal)
> temporary files are also moved to the trash bin. See the attached file
> for an output of `ls' in the .Trash directory after roughly two hours of
> emacs.

Good point.  I have commited a change that inhibits trashing for
jka-compr, server, diff, and epg.  Probably more such changes are
required.

David Reitter | 1 May 04:31 2010
Picon

bug#6069: INTMASK on 32/64 bit machines

I have one post-scriptum.

I just noticed that the large `sxhash' integer was produced on a 64-bit machine with INTMASK 0xffffffff,
but that the read failure occurred with a binary compiled for 32-bit architectures.  In that Emacs, INTMASK
is 0x3fffffff.

I think that explains what I'm seeing.

Would it be sensible to make `sxhash' use a lower common denominator for modern machines, such as 0x3fffffff?

Or, should the lower INTMASK be used on 64-bit architectures as well?

It's less than ideal that printed Lisp expressions, especially those in customization files, are not
interchangeable between different builds of the same version of Emacs.

Lennart Borgman | 1 May 05:40 2010
Picon

bug#6071: cc-(basic-)common-init not called in js-mode

I have a bug report that I believe is due to that cc-basic-common-init
is not called in js-mode. Due to this jus-mode modifies default values
instead of buffer local values:

  https://bugs.launchpad.net/nxhtml/+bug/572664

Could this please be fixed in js.el before the release?

Leo | 1 May 06:00 2010
Picon

bug#6070: 23.1.96; delete-by-moving-to-trash

On 2010-05-01 03:19 +0100, Chong Yidong wrote:
>> However, with (setq delete-by-moving-to-trash t), a lot of (internal)
>> temporary files are also moved to the trash bin. See the attached file
>> for an output of `ls' in the .Trash directory after roughly two hours of
>> emacs.
>
> Good point.  I have commited a change that inhibits trashing for
> jka-compr, server, diff, and epg.  Probably more such changes are
> required.

Thank you for the quick fix. I will be using it and let you if there are
other cases need fixing.

Leo

Leo | 1 May 06:44 2010
Picon

bug#6070: 23.1.96; delete-by-moving-to-trash

On 2010-05-01 05:00 +0100, Leo wrote:
>> Good point.  I have commited a change that inhibits trashing for
>> jka-compr, server, diff, and epg.  Probably more such changes are
>> required.
>
> Thank you for the quick fix. I will be using it and let you if there are
> other cases need fixing.

delete-auto-save-file-if-necessary still creates a lot temp files in the
trash bin. Any idea where names like emacs6ljgy9 or emacsXWkc8c come
from? They look like temp file. Is it from with-temp-file?

Cheers,

Leo

Noah Lavine | 1 May 08:19 2010
Picon

bug#6065: Emacs Trunk Build Failure on Mac OS X 10.6

I built it successfully from the latest trunk.

I should mention that I did 'make' and not 'make bootstrap'. I don't
imagine that would make a difference for this particular error, but if
you'd like to know what 'make bootstrap' does, I'll test that too.

On Fri, Apr 30, 2010 at 7:51 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>
> Please update from Bazaar and try again.
>

Eli Zaretskii | 1 May 08:09 2010
Picon

bug#5984: Crash displaying composed characters

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
> Date: Fri, 30 Apr 2010 16:47:43 -0400
> 
> >   . Emacs then enters redisplay to display the echo area.  As part of
> [...]
> >   . Further down, autocmp_chars calls the value of
> >     auto-composition-function:
> [...]
> >   . Now the " *Echo Area0*" buffer holds a totally different text,
> >     unbeknownst to autocmp_chars, which still passes the old values 32
> >     and 33 to TEMP_SET_PT_BOTH:
> 
> More generally, this Lisp code could modify any buffer, so preventing
> the load-messages is not a sufficiently reliable solution (tho it might
> be desirable in any case).

I think the patch suggested by Andreas (now installed on the release
branch) does what's necessary.  It's unfortunate minor side-effect is
that the original message from Edebug gets lost; it would be good to
fix that on the trunk.


Gmane