From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Sickel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <6B31614E-5719-4042-B334-727EC7C3F8A4@corpus-callosum.com> Date: Thu, 3 Apr 2014 01:15:47 -0500 References: <5332c061.924ab40a.15cc.55a2@mx.google.com> <20140402071913.72076a71@zinc.9fans.fr> <2968a2c260ea9a1c5c75c91ec9f1ea84@brasstown.quanstro.net> <20140403075006.0ab35e51@zinc.9fans.fr> <4e95272faa3b0b38eec77c00bc56bc2d@brasstown.quanstro.net> In-Reply-To: <4e95272faa3b0b38eec77c00bc56bc2d@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Python/Mercurial error Topicbox-Message-UUID: d4ecd23a-ead8-11e9-9d60-3106f5b1d025 On Apr 3, 2014, at 12:58 AM, erik quanstrom wrote: > > On Thu Apr 3 01:51:59 EDT 2014, 0intro@gmail.com wrote: >>> the script itself reminds me of gcc fixincludes. >> >> This is probably not ideal, but the alternative would be >> to split libc.h in three parts: libc.h, fmt.h and utf.h >> and only include libc.h in Go (because Go has his own >> variants of libfmt and libutf). > > why is the alternative to modify plan 9, and why can't they > live with the system fmt/rune routines? Go will likely require its own libraries for everything in the near future. The Plan 9 variants will have to accept that as it is just too time consuming to try and keep the headers clean and still use the original Plan 9 libraries that started the core Go implementation. - jas