Paul Eggert | 1 Oct 22:29 2014

Preferring ptrdiff_t to ssize_t

The Emacs C code prefers signed integer types to unsigned, so it 
typically uses ptrdiff_t for indexes that might not fit in 'int'. At 
first glance, another type ssize_t is a plausible alternative, as the 
two types are equivalent on typical platforms.  On less-common 
platforms, though, ptrdiff_t works better than ssize_t, so for 
size-related integers Emacs's portable C code should continue to prefer 
ptrdiff_t.

Here are some details about this:

1.  Historically, some 64-bit Unix-based platforms had 32-bit ssize_t 
even though size_t and ptrdiff_t were both 64-bit, because they had 
32-bit 'int' and wanted system calls like 'read' to support the 
traditional default API where 'read' returned 'int'. I don't know 
whether these platforms have died out entirely, but I suspect they haven't.

2.  A few platforms even now have ptrdiff_t wider than size_t, thus 
avoiding the problem of integer overflow when subtracting pointers.  
Using ptrdiff_t could therefore improve the quality of Emacs ports to 
these platforms, even if Emacs doesn't happen to run there now.

3.  ptrdiff_t is more ubiquitous and better-standardized than ssize_t, 
as ptrdiff_t is required by the C standard whereas ssize_t is required 
only by POSIX.

4.  There are standard printf formats for prtdiff_t (e.g, "%td") but not 
for ssize_t.

5.   To avoid problems with integer overflows in ptrdiff_t-related 
calculations, Emacs never allocates objects larger than PTRDIFF_MAX 
(Continue reading)

Leo Liu | 1 Oct 04:04 2014
Face
Picon

I wonder if the org community can pull together to fix bug#17724


I made a safe oneline change to easy-kill.el and now I am getting a
build error: https://travis-ci.org/leoliu/easy-kill Or is it a plan to
move org completely out of emacs in favour of ELPA?

Thanks,
Leo

Dmitry Antipov | 30 Sep 18:14 2014
Picon

Undefined reference to 'gtk_adjustment_configure'

Recently I tried to build trunk on a relatively mature system and got
"undefined reference to 'gtk_adjustment_configure'" error when linking.
This system has 2.12.0 so configure check was passed.  But, according to
https://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00023.html,
gtk_adjustment_configure was introduced in 2.13.6.  So I think that old
code should be resurrected under GTK_CHECK_VERSION.

Dmitry
Angelo Graziosi | 30 Sep 11:56 2014
Picon

Error compiling rmailmm.el

In trunk r. 117982 I find this error in the build log:

...
make[2]: ingresso nella directory "/tmp/emacs/lisp"
Compiling mail/rmailmm.el

In toplevel form:
mail/rmailmm.el:78:1:Error: Symbol's value as variable is void: 
rmail-spool-directory
Makefile:284: set di istruzioni per l'obiettivo "mail/rmailmm.elc" non 
riuscito
make[2]: *** [mail/rmailmm.elc] Errore 1
make[2]: uscita dalla directory "/tmp/emacs/lisp"
...

The build of trunk r. 117969 does not show that error.

Ciao,
Angelo.

martin rudalics | 30 Sep 10:25 2014
Picon
Picon

Current trunk aborts with MinGW

A MinGW build of current trunk aborts here as follows:

Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:361
361	  signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:361
#1  0x01173d6b in die (msg=0x14bb004 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14baf34
"lisp.h", line=926) at alloc.c:7111
#2  0x010f9651 in make_lisp_ptr (ptr=0x4a7fe0c, type=Lisp_String) at lisp.h:926
#3  0x0101b2a2 in x_get_arg (dpyinfo=0x206d800, alist=..., param=..., attribute=0x14de8e4 "left",
class=0x14de8df "Left", type=RES_TYPE_NUMBER) at frame.c:4152
#4  0x01202cc9 in w32_createwindow (f=0x16c70b8) at w32fns.c:1987
#5  0x01203b0e in w32_msg_pump (msg_buf=0x4a7ff54) at w32fns.c:2519
#6  0x01204067 in w32_msg_worker <at> 4 (arg=0x0) at w32fns.c:2724
#7  0x7c80b683 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll
#8  0x00000000 in ?? ()

Lisp Backtrace:
"x-create-frame" (0x82e7c8)
"x-create-frame-with-faces" (0x82eb18)
"make-frame" (0x82ee68)
"frame-initialize" (0x82f1b8)
"command-line" (0x82f53c)
"normal-top-level" (0x82f800)

Help welcome, martin

Richard Stallman | 29 Sep 22:49 2014
Picon
Picon

POP3 password in plaintext?

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

http://www.theguardian.com/technology/2014/sep/29/londoners-wi-fi-security-herod-clause

says that POP3 passwords are sometimes transmitted in plain text.

Is plaintext transmission of passwords inherent in POP3
or is it optional?

Is there something we can and should do
to encourage users to stop the plaintext transmission of their
POP3 passwords?

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Stefan Monnier | 29 Sep 19:19 2014
Picon

Version naming

OK, here's one of the favorite discussion topics.

So I'll keep it short to get the discussion started:

   The next release from trunk will be called 25.1 rather than 24.5

There, I said it.  For completeness, here's the motivation:
In retrospect 24.3 should have been named 25.1 and 24.4 should have been
named 26.1.  The ".N" thingy should really be kept only for bug-fix
releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
bug-fix releases.

I'll stop listening to this thread starting right about now, but don't
let that stop you wasting your time debating at length about this boring
subject,

        Stefan

Leo Liu | 29 Sep 12:08 2014
Face
Picon

should enable-recursive-minibuffers default to t?

As suggested in the title. Comments?

Leo

Dmitry Antipov | 29 Sep 09:09 2014
Picon

Stack-allocated objects again (+benchmark)

1) In r117971, I've made an attempt to follow KISS principle and
redesign this stuff for simplicity and speed rather than versatility.

2) I am constantly asked about benchmarks.  OK, running this code:

(defun put-property-benchmark ()
   (interactive)
   (setq buffer-undo-list t)
   (let ((oldgc gcs-done)
         (oldtime (float-time)))
     (while (re-search-forward "[a-f0-9]+" nil t)
       (put-text-property (match-beginning 0) (match-end 0)
			 'face 'font-lock-comment-face))
     (message "GCs: %d Elapsed time: %f seconds"
	     (- gcs-done oldgc) (- (float-time) oldtime))))

through a ~35M dump generated with

od -v -t x2 < glibc-2.19.tar.xz > glibc.txt

shows 55GCs/23.7s with USE_STACK_LISP_OBJECTS and 66GCs/27.9s
without them.  Hopefully this simple benchmark is "real enough".

Dmitry

Mike Kupfer | 29 Sep 06:21 2014
Picon

MH-E patch to support nmh 1.5

Attached is a Bazaar bundle for emacs-24, to fix MH-E to work with
nmh-1.5 and above.  This is my first Emacs submission, so apologies in
advance for any rookie mistakes.

mike
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: m.kupfer <at> acm.org-20140929040526-o9l4xz8v0cgv964w
# target_branch: bzr://bzr.savannah.gnu.org/emacs/emacs-24/
# testament_sha1: dae0aa9c4d55efb8fd1f70ddff82aa23c47c1f04
# timestamp: 2014-09-28 21:05:58 -0700
# base_revision_id: monnier <at> iro.umontreal.ca-20140927162553-\
#   hjq3w3mbdp5jwa4s
# 
# Begin patch
=== modified file 'lisp/mh-e/ChangeLog'
--- lisp/mh-e/ChangeLog	2014-03-17 00:50:05 +0000
+++ lisp/mh-e/ChangeLog	2014-09-29 04:05:26 +0000
 <at>  <at>  -1,3 +1,19  <at>  <at> 
+2014-09-28  Mike Kupfer  <m.kupfer <at> acm.org>
+
+	* mh-comp.el (mh-bare-components): Improve the temp folder and
+	file names as per a suggestion from Bill Wohler.  Also address
+	XEmacs compatibility issues: use mm-make-temp-file instead of
+	make-temp-file, and only pass one argument to delete-directory.
+
+2014-09-26  Mike Kupfer  <m.kupfer <at> acm.org>
+
+	* mh-comp.el (mh-insert-x-face): Ensure that mh-x-face-file is a
(Continue reading)

Thien-Thi Nguyen | 28 Sep 15:41 2014
Picon

Re: trunk r117969: Font-lock `cl-flet*', too.

() Leo Liu <sdl.web <at> gmail.com>
() Sun, 28 Sep 2014 16:13:38 +0800

   I noted this problem some time ago but decided not to fontify
   it so that this nonstandard macro doesn't get much use.

It's hard to judge the efficacy of such subtle negative feedback.

   cl-flet* should probably be removed. Common lisp doesn't have
   this macro. Personally I prefer cl-labels when needing
   something like cl-flet*.

Thanks for the tip (i am ignorant of most things Common Lisp).
I think until the time ‘cl-flet*’ is truly removed from Emacs,
there is no harm in it being fontified like the others, but if
you think otherwise and are willing to start the process for its
eventual removal, feel free to revert the change.

[cc added]

--

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

Gmane