From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Fri, 2 Mar 2012 22:32:38 +0100 Message-ID: References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <83ty2ltep0.fsf@gnu.org> <4F4EEBC2.5070704@cs.ucla.edu> <4F4F3A1A.4020808@cs.ucla.edu> <83ty27bbmn.fsf@gnu.org> <4F512F1A.7080806@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015175dd7142b02a804ba49523a X-Trace: dough.gmane.org 1330724019 20788 80.91.229.3 (2 Mar 2012 21:33:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Mar 2012 21:33:39 +0000 (UTC) Cc: Eli Zaretskii , ajmr@ilovetortilladepatatas.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 02 22:33:37 2012 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 1S3a6W-0007QT-J8 for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2012 22:33:32 +0100 Original-Received: from localhost ([::1]:49019 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3a6V-0000R1-VO for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2012 16:33:31 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3a6S-0000Qw-CS for emacs-devel@gnu.org; Fri, 02 Mar 2012 16:33:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3a6Q-0004zA-FX for emacs-devel@gnu.org; Fri, 02 Mar 2012 16:33:27 -0500 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:62503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3a64-0004vO-NI; Fri, 02 Mar 2012 16:33:05 -0500 Original-Received: by bkwq16 with SMTP id q16so2357334bkw.0 for ; Fri, 02 Mar 2012 13:33:00 -0800 (PST) Received-SPF: pass (google.com: domain of fabrice.popineau@gmail.com designates 10.204.156.139 as permitted sender) client-ip=10.204.156.139; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fabrice.popineau@gmail.com designates 10.204.156.139 as permitted sender) smtp.mail=fabrice.popineau@gmail.com; dkim=pass header.i=fabrice.popineau@gmail.com Original-Received: from mr.google.com ([10.204.156.139]) by 10.204.156.139 with SMTP id x11mr4105761bkw.59.1330723980907 (num_hops = 1); Fri, 02 Mar 2012 13:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=TjMCKzOK1VIQwwzeLm3zB+XoJksY+4ThkFOT/4YHqLE=; b=zcYirZtUwP90Svlz5jl698JsbKX66TW0fmaUcid9pPIsLwarjEkVtWTI1IhaXExUJv 4dTSy0ijBpBywFjaBbS0R6abMxuwKte0VJg5nhven2+xiaKbj9L50xGqrIi998jbqvVn 65vO5+NG/4n4A/bkKYAxlqszV1HzF9fOoPBV9w7aCBhoe4I5BeJREZYOnap5DvELiP1h tmv6QssxTGgjTh0wCZLB6Y+igVfuVsnMZn/8xr/zctBvXb4YTeLKXPZtkdtbsvJb/G87 MbuEPsl9zJBTbqekC6yMSbDhqHdUP+00LzZvcDCZ1yFmwrpI6Rfgbx0JXAuBoa681tm8 tPqw== Original-Received: by 10.204.156.139 with SMTP id x11mr3293925bkw.59.1330723980771; Fri, 02 Mar 2012 13:33:00 -0800 (PST) Original-Received: by 10.204.37.196 with HTTP; Fri, 2 Mar 2012 13:32:38 -0800 (PST) In-Reply-To: <4F512F1A.7080806@cs.ucla.edu> X-Google-Sender-Auth: fPvGgBrlhXMWWXV47T2iolqs5NQ X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.41 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:148876 Archived-At: --0015175dd7142b02a804ba49523a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > > ABLOCKS_BUSY is sometimes a pointer and sometimes an integer > (converted to a pointer). At the point when this code is executed: > > So it is even worse than what I thought. > I'm not saying the code can't be cleaned up -- it's pretty > messy and this one line is just one corner of the mess. But > any cleanup can and should be done independently of the Windows 64 > port, and should be systematic rather than just fiddling > Ok. But in my defence, you may forget that I started from a point where emacs didn't compile, and when it compiled at least, it din't run. In this case, the obvious strategy is to remove all the compilation warnings, at least those related to int/long/pointers datatypes. And guess what ... once I did that, it worked. Ok, it is not enough, but I spent already quite a time on it, I didn't see myself testing the many combinations of what was actually needed and what was optional. Now, my patch may easily be split in as many parts as needed, and some of them definitely omitted. I never expected that it could be taken "as is"= . I only targeted a clean compile on my platform, and since I won't be able to test if it is harmless to other platforms, I'll let those who know judge what is acceptable and what needs to be rewritten. I can only easily report if it still compiles and run on the MS platform with their tools. Best regards, with this one line and making this line inconsistent with > the (ab)use of ABLOCKS_BUSY in the rest of the module. > > My compilation was an optimized one, not that this matters > much. > --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --0015175dd7142b02a804ba49523a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
ABLOCKS_BUSY is s= ometimes a pointer and sometimes an integer
(converted to a pointer). =A0At the point when this code is executed:


So it is even = worse than what I thought.
=A0
=A0
I'm not saying the code can't be cleaned up -- it= 's pretty
messy and this one line is just one corner of the mess. =A0But
any cleanup can and should be done independently of the Windows 64
port, and should be systematic rather than just fiddling

Ok. But in my defence, you may forget that= I started from a point
where emacs didn't compile, =A0and wh= en it compiled at least, it din't run.
In this case, the obvi= ous strategy is to remove all the compilation warnings, at least
those related to int/long/pointers datatypes.
And guess what= ... once I did that, it worked.=A0
Ok, it is not enough, but I s= pent=A0already quite a time on it, I didn't see myself testing the many= combinations
of what was actually needed and what was optional.=A0
Now, m= y patch may easily be split in as many parts as needed, and some
= of them definitely omitted. I never expected that it could be taken "a= s is".
I only targeted a clean compile on my platform, and since I won't = be able to test
if it is harmless to other platforms, I'll le= t those who know judge what is acceptable
and what needs to be re= written.
I can only easily report if it still compiles and run on the MS platfo= rm with their tools.

Best regards,

<= /div>
with this one line and making this line inconsistent with
the (ab)use of ABLOCKS_BUSY in the rest of the module.

My compilation was an optimized one, not that this matters
much.



--
Fabrice Popi= neau
-----------------------------
SUPELEC
D=E9part= ement Informatique
3, rue Joliot Curie
91192 Gif/Yvette= Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212<= /div>
------------------------------


--0015175dd7142b02a804ba49523a--