From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: [PATCH] build: pull: Compile .scm files in one process. Date: Mon, 09 Nov 2015 10:50:38 +0100 Message-ID: <871tbzwlg1.fsf@T420.taylan> References: <87si4kxtge.fsf@T420.taylan> <87611frtsx.fsf@igalia.com> <87d1vnxepw.fsf@T420.taylan> <87lha7r557.fsf@igalia.com> <87611bwo6b.fsf@T420.taylan> <874mgvr15x.fsf@igalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvj62-0001st-Q9 for guix-devel@gnu.org; Mon, 09 Nov 2015 04:50:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zvj61-0002UB-GG for guix-devel@gnu.org; Mon, 09 Nov 2015 04:50:42 -0500 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:38257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvj61-0002U6-48 for guix-devel@gnu.org; Mon, 09 Nov 2015 04:50:41 -0500 Received: by wicli17 with SMTP id li17so11779056wic.1 for ; Mon, 09 Nov 2015 01:50:40 -0800 (PST) In-Reply-To: <874mgvr15x.fsf@igalia.com> (Andy Wingo's message of "Mon, 09 Nov 2015 09:07:38 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andy Wingo Cc: guix-devel@gnu.org Andy Wingo writes: > On Mon 09 Nov 2015 08:51, taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4= =B1rl=C4=B1/Kammer") writes: > >> The relevant bug report is . >> >> According to Ludo's explanation, compiling a module file leads to the >> module being created in the runtime, but with syntax bindings only, and >> runtime bindings missing. That's what I mean with "degenerate" module >> for lack of a better term. Loading the same file explicitly afterwards >> (or using load-compiled on the generated .go) seems to solve the issue. > > Ah, I see. Well, one workaround for this issue, if you wanted to work > around it, would be to load the file before compiling it. In that way > the module would already be loaded at the right phase. This wouldn't > cost very much AFAIU. Yeah, loading before compiling also seems to work. Neither solves the other error I got, so I guess that one is really unrelated to this. I'm still clueless on that one. Taylan