From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Reconsideration of MinGW work Date: Tue, 23 Mar 2010 02:59:46 -0400 Message-ID: <4469B46C-7256-49EF-A2AE-8542F95B8D7F@raeburn.org> References: <87fx3tjt3r.fsf@ossau.uklinux.net> <11640D11-A8D6-4C58-86FA-EF79F4D60770@raeburn.org> <87ljdjlx8q.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269327618 23784 80.91.229.12 (23 Mar 2010 07:00:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Mar 2010 07:00:18 +0000 (UTC) Cc: Guile User List , Guile Development To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 23 08:00:14 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nty61-0004L2-8R for guile-devel@m.gmane.org; Tue, 23 Mar 2010 08:00:13 +0100 Original-Received: from localhost ([127.0.0.1]:49927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nty5y-0003m6-UW for guile-devel@m.gmane.org; Tue, 23 Mar 2010 03:00:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nty5w-0003m0-9Z for guile-devel@gnu.org; Tue, 23 Mar 2010 03:00:08 -0400 Original-Received: from [140.186.70.92] (port=47795 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nty5s-0003lR-1h for guile-devel@gnu.org; Tue, 23 Mar 2010 03:00:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nty5p-0006pS-DT for guile-devel@gnu.org; Tue, 23 Mar 2010 03:00:03 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:55211 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nty5d-0006o2-Dk; Tue, 23 Mar 2010 03:00:01 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o2N6xkdZ006239; Tue, 23 Mar 2010 02:59:47 -0400 (EDT) In-Reply-To: <87ljdjlx8q.fsf@ossau.uklinux.net> X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10075 gmane.lisp.guile.user:7720 Archived-At: On Mar 22, 2010, at 20:04, Neil Jerram wrote: > Ken Raeburn writes: >> Yes... you then also need to decide if Guile is exposing GNU/POSIX >> functionality, whatever the native OS functionality is, or some >> abstraction... >=20 > Ideally, yes, I think. In other words, I think it's preferable if = Guile > provides the same function to applications on all platforms. (Emacs > shows how fantastically useful this is.) But is that POSIX, or something more abstract, when POSIX and other = platforms differ in significant ways? >> Having just bought a Lemote Yeelong notebook at LibrePlanet [...] >=20 > Aside: I was wondering about buying one of those too, but haven't yet > because of performance concerns. Can it compile Guile successfully, = and > if so how long does it take? Don't know yet; I've been having network problems until tonight. But I = plan to try it out, maybe later this week. >> You *are* reporting these bugs, aren't you? :-) >=20 > Err... not yet. So thanks for the reminder. But I just checked, and > their (i.e. Wine's) bugzilla requires creating an account, so I'm not > sure I'll bother. (Is that really irresponsible of me?) It is kind of a pain, isn't it? But with all the spam flying around = these days, it seems to me that fewer and fewer projects/sites accept = anonymous email or web submissions. > I agree that this is useful, but it is, as you say, difficult to set = up. > Personally, to the extent that I continue working on this, I think I'm > happy to limit myself to what can be achieved with emulation (i.e. = with > Wine) on a single Linux box. At least so far as regular builds are > concerned; of course I'd also expect occasionally to copy the built = DLLs > over to Windows and try them there. I believe NetBSD (and maybe some of the GNU/Linux distros?) has made = progress in cross-compiling for the OS on one architecture, hosted on = the OS running on another architecture. (And I'm not just talking about = 32-bit and 64-bit variants of the same architecture -- this might be x86 = to sparc, for example.) So a first cut at something like this might = just take as little on the Guile side as setting up the test suite to = copy binaries and test scripts over to the target machine with scp, then = run a test over ssh. Hmm.... >> One nagging concern I've got about my Guile-Emacs project is the >> seemingly narrow focus of active Guile developers as far as platforms >> are concerned. I'm one of, what, two or three people testing the >> development versions on Mac OS X now and then, and most of the rest = of >> the work is on x86 or x86-64 GNU/Linux systems, it seems? >=20 > Yes, but this isn't intentional, just a matter of limited resources. I'm glad to see the other non-Linux people were paying attention. ;-) I = guess I overstated the situation, but I have on occasion gotten the = feeling that only GNU/Linux systems were getting tested as part of the = main development work, with "porting" back to other systems happening = later, when Greg or I or someone else found problems. (I can certainly = understand not trying on every system on the planet. But *occasionally* = it feels like only one is really used.) But, we are paying attention, = when we've got time, and those of you doing most of the core development = work are doing awesome stuff, and listening to us when platform issues = come up, so I shouldn't be complaining too much.... The build farms are a good improvement; we should try to get as much = variety there as we can. And maybe some sort of alert (bot messages to = #guile ?) when a build fails... > On the other hand, in the Windows case, it seems there is independent > effort being put in to the problem downstream. I wonder why that's > downstream - perhaps because we're not good enough at accepting = patches > when they're offered? We could ask and see. And maybe get someone to figure out how to fit = Cygwin and/or MinGW into the build farm (or some automatic = build-and-test setup), and keep an eye on things, while we help them get = their porting changes integrated. > On the MacOS side I haven't been closely involved recently, but I = think > - for all platforms other than the really mainstream ones that you've > mentioned above - we need people who are authoritative about what the > solution for a given problem is. If I see a patch for MacOS that = seems > to be done at the right place in the build, and obviously doesn't > inappropriately impact other platforms, and the submitter is > authoritative about it being the right solution for MacOS, it's easy = to > say "OK, I believe you, and there's no risk, so let's commit it". But > in the conversations that I remember there hasn't been that > authoritative tone; it's more like I've needed to work out half of the > solution myself, which I'm not in a position to do. So then things = get > left sitting, etc. And similarly for other less mainstream platforms. I don't mind trying to sound authoritative sometimes. :-) And I deal = pretty well with the UNIXy bits of Mac OS X. But sometimes I'm unsure = how things are intended to work on the Guile side. >> and probably not just supporting whatever subset can be mapped into >> POSIX functions via Gnulib. >=20 > I don't think I understand your point here. Gnulib isn't a fixed = point. > If we can add emulation code into Guile, can't we just as easily add = it > into Gnulib? I had the impression that Gnulib was about emulating the GNU/Linux/POSIX = type API on other platforms, not providing an abstraction. But it looks = like I'm wrong; at the very least, there are non-POSIX utility functions = as well as replacements for missing POSIX routines. Maybe that is the = way to go, then.... Ken=