From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: XCB and 32- vs 64-bit 'long' Date: Sat, 14 Nov 2015 05:33:06 -0500 Message-ID: <9842181B-2CA9-4DC9-BD98-26DDF2387C6D@raeburn.org> References: <56462675.80908@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447513355 5696 80.91.229.3 (14 Nov 2015 15:02:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Nov 2015 15:02:35 +0000 (UTC) Cc: Emacs development discussions To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 14 16:02:25 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZxcLQ-0005yA-US for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 16:02:25 +0100 Original-Received: from localhost ([::1]:35154 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxcLQ-0005rB-9W for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 10:02:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxY8u-0005sF-IV for emacs-devel@gnu.org; Sat, 14 Nov 2015 05:33:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxY8r-0002Ub-Cg for emacs-devel@gnu.org; Sat, 14 Nov 2015 05:33:12 -0500 Original-Received: from mail-vk0-x243.google.com ([2607:f8b0:400c:c05::243]:33625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxY8r-0002UQ-3O for emacs-devel@gnu.org; Sat, 14 Nov 2015 05:33:09 -0500 Original-Received: by vkbs1 with SMTP id s1so639421vkb.0 for ; Sat, 14 Nov 2015 02:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn_org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SVtO686lqml9CXhsm9+SsrDJ+KVFZl2mKD1Y6t33jeM=; b=lzQ5MXrFBnqH/G9Q4SLb78aD7X7zGtok9BwXURHHi2VrJQ9ZDek504rYyY/E/XJB4T pFRfq/mPv6+lOs20w3sBEhfd3JmJzVYhmI733wuhu6U6OdvwOUQiDeICZsrbpjTmMxeP 5eLFIp/TPblilGcq/xp144i4vWlnnTtBXChobFSU4wMbvK5jgGcfh/dxNyNXy1Ag8TpK TJ4W1c8Rrs+AhPUfdLt9IatZ4xjhjC5I4uAhL3gSrra3xRMD8eNK55L1Byttq6RyDWzE lcnM020ODwc7Gl0DJh0Ijd+fzzCTnyRrIs2WtEJ3w+paulwKdko9AT07hNsbur/VDxiH C/yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SVtO686lqml9CXhsm9+SsrDJ+KVFZl2mKD1Y6t33jeM=; b=LzpF+HVsFDDw9JtE1jrzJOvy6zW8QI//WCjug8MNEgEYnw+dSl4okULbgZd9GY2+fU 7QMO2yGCc/IxcoxJpTQupFmCTHOC1v+esxFe+MhviDQ58LbDx1UkL5bvTLv65XbZ7z9G dTmtC8GrGB93cYm1wG008C5H32ami6Wp7O+nhPtUvk+YrcNaJXMwEBRAyaqUVHSpBM5N oLbU3UkeOYT2DLWRpHIprNFENuBDXHzlge5/OIJNKmGC3gLE3ZVtNkFhc9By5/zRgThY Gz2N6lzbSC1c5gbuYpUFO5wlyKyr5j0p1Jls6PitZXIs12EmataVLzCaddn77aVdOeNQ Z4cg== X-Gm-Message-State: ALoCoQlmHewWvE3Rm/jFKw2OP+weJwuZlxsqlkE+Uu7I9KKUp+tS+js9rixhBtUksQbnQFPziAcb X-Received: by 10.31.150.68 with SMTP id y65mr2156630vkd.35.1447497188349; Sat, 14 Nov 2015 02:33:08 -0800 (PST) Original-Received: from [192.168.17.111] (c-66-31-203-101.hsd1.ma.comcast.net. [66.31.203.101]) by smtp.gmail.com with ESMTPSA id k76sm2987738vki.5.2015.11.14.02.33.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 02:33:07 -0800 (PST) In-Reply-To: <56462675.80908@cs.ucla.edu> X-Mailer: Apple Mail (2.3096.5) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c05::243 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194452 Archived-At: > On Nov 13, 2015, at 13:05, Paul Eggert wrote: >=20 > Valgrind pointed out a bug in recent XCB-related changes, in that Xlib = converts 32-bit quantities to 'long' but XCB does not. The distinction = matters on platforms like x86-64 where 'long' is 64 bits. Also, on my = platform at least, xcb_get_property_value_length returns a byte count, = not a word count; unfortunately this does not appear to be documented = anywhere. Yes, I found the documentation to be rather poor in that area. I did = find a discussion in an old bug report at freedesktop.org about how it = was supposed to and supposedly did return a count of values rather than = of bytes. But poking around on the net at other applications using the = routine, it does appear that the byte count is what=E2=80=99s expected, = consistent with what you=E2=80=99re seeing. Thanks for catching these. > I just now installed a patch that I hope fixes this: >=20 > = http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D4c4b520520cf6b99ce= 7128331a4e108e58095705 >=20 > Ken, could you please check this patch? I am by no means an expert in = XCB. Thanks. It looks good to me. And I=E2=80=99ve run a few tests to confirm that = it=E2=80=99s getting the right lengths for me. It also turns out that = the two properties in question are set very rarely in my testing setup, = which surprised me. So I do want to look at that a little more closely. = I=E2=80=99m no expert either. > While we're on the subject, I assume that the goal is to replace all = Xlib calls with XCB calls, on platforms that have XCB. Can Emacs start = assuming XCB, and drop the old Xlib-only code? That would simplify Emacs = maintenance. My immediate goal was to speed up certain Emacs activities on = moderate-latency networks; my connection from home to work has about a = 30ms round trip time, and the non-pipelined requests for information and = the synchronization calls to check for errors really added up. It=E2=80=99= s still slower than I=E2=80=99d like =E2=80=94 takes about a second to = create a new frame remotely =E2=80=94 but it=E2=80=99s better than it = was. It would certainly simplify things if we could just pick one version to = support, but I don=E2=80=99t know if it=E2=80=99s reasonable to assume = that all the systems we want to support have moved to XCB. Ken=