From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: [PATCH] build: pull: Compile .scm files in one process. Date: Mon, 09 Nov 2015 09:07:38 +0000 Message-ID: <874mgvr15x.fsf@igalia.com> References: <87si4kxtge.fsf@T420.taylan> <87611frtsx.fsf@igalia.com> <87d1vnxepw.fsf@T420.taylan> <87lha7r557.fsf@igalia.com> <87611bwo6b.fsf@T420.taylan> 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]:39458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZviQU-0006Un-Il for guix-devel@gnu.org; Mon, 09 Nov 2015 04:07:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZviQQ-0007xH-SZ for guix-devel@gnu.org; Mon, 09 Nov 2015 04:07:46 -0500 Received: from pb-sasl0.int.icgroup.com ([208.72.237.25]:60012 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZviQQ-0007wq-Mq for guix-devel@gnu.org; Mon, 09 Nov 2015 04:07:42 -0500 In-Reply-To: <87611bwo6b.fsf@T420.taylan> ("Taylan Ulrich =?utf-8?Q?=5C=22Bay=C4=B1rl=C4=B1=2FKammer=5C=22=22's?= message of "Mon, 09 Nov 2015 09:51:40 +0100") 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: Taylan Ulrich =?utf-8?Q?=22Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer=22?= Cc: guix-devel@gnu.org On Mon 09 Nov 2015 08:51, taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1= rl=C4=B1/Kammer") writes: >> I do not understand what you mean by "degenerate" modules :) An >> interpreted module should act the same as a compiled module. I am >> interested to hear what difference you can perceive between the two. > > 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. Andy