From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17635 invoked by alias); 14 May 2014 01:50:10 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 17089 invoked by uid 89); 14 May 2014 01:50:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: st11p02mm-asmtp001.mac.com Received: from st11p02mm-asmtpout001.mac.com (HELO st11p02mm-asmtp001.mac.com) (17.172.220.236) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 May 2014 01:50:05 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.75] (99-3-56-155.lightspeed.fyvlar.sbcglobal.net [99.3.56.155]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N5J003V3JR73020@st11p02mm-asmtp001.mac.com> for kawa@sourceware.org; Wed, 14 May 2014 01:50:03 +0000 (GMT) Subject: Re: the right way to compile and load modules From: mikel evins In-reply-to: <5372CA25.7050602@bothner.com> Date: Wed, 14 May 2014 01:50:00 -0000 Cc: mikel evins , kawa@sourceware.org Message-id: References: <9F312D97-98C6-4F47-BDD9-B6CAF3868A28@me.com> <5371CFD0.7070708@bothner.com> <7D1A5D60-5997-4B7A-9176-8F6FA315F016@me.com> <54132084-D633-4AAA-B2A4-9008FF37F779@me.com> <5372CA25.7050602@bothner.com> To: Per Bothner X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGBEKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hueREKQ04XSxsYGmJCH2luGlxlGXhzB x5vGhsfGhkYEQpYXBcZBBoEGxsHTU4fGBgYGUsFGx0EGx0YBBIZBBsdEBseGh8bEQpeWRdhW2J oRxEKTEYXYmtrEQpDWhcTEwQZBB8cBBsfHxEKRFgXGREKREkXGBEKQkUXaxNfH11ATxlsZFoRC kJOF2xwYHlAHWJSaRpiEQpCTBdmYXpbYW1oUl5eYBEKQmwXZEt5RHMBQx0dGh8RCkJAF2NhZwV EQ2RgSVNTEQpwaBdrWlJLYkwSbht7SBEKcGgXYHN/bV1Oaxt+fmYRCnBoF2x/YnpPS3lEEhlEE QpwaBdhU0FvTXlZQQEFHREKcGgXY2BCRW1+emVZfksRCnBsF29BSQFpfnATXhJuEQpwTBd6QG1 YcxpiG01tSRE= X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-05-13_07:2014-05-13,2014-05-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405140023 X-IsSubscribed: yes X-SW-Source: 2014-q2/txt/msg00053.txt.bz2 On May 13, 2014, at 8:43 PM, Per Bothner wrote: > On 05/13/2014 06:12 PM, mikel evins wrote: >> My question was in the subject line: what's the right way to compile and load modules. By "right" I mean a way that works both when batch-compiling kawa for packaging in a jar and when interactively loading sources for repl-session development. >> >> The answer appears to be that for interactive loading, one should use a load file that consists of a series of require forms, one for each source file, and the load file should reside in the same directory as the sources. That approach loads all of our code and silences the warnings I was previously seeing. (I still see warnings about symbols that are not visibly referenced anywhere, but that is an accurate and informative warning, so I have no complaint). > > Mixing load and require can be a bit fragile, but if it works for you that's ok. I'd rather not do anything that's not recommended, and I won't unless there's no other way to make things work. > In general I say it's best to avoid using either load and eval. > (People tend to overuse them.) > > I just checked in a fix to this problem: > > #|kawa:1|# (require "foo.scm") > /dev/stdin:1:1: not found: /dev/foo.scm (No such file or directory) > > This mysterious problem was because the filename of the default input port > is "/dev/stdin" and require resolves the specified filename against the > current filename. Ooops. Using require with a filename should work now. Yeo, that squares with the behavior I saw. > If you need to require multiple source files in the repl, you can use the -e option: > > $ kawa -e '(require "foo.scm")' -e '(require "bar.scm")' -- That seems like the way to go for my project. I use a project-specific shell script to launch kawa anyway. > You can also use ~/.kawarc.scm. Not as good. I don't necessarily want to limit use of kawa to this one project, so I don't necessarily want to require its sources every time I start kawa. > Even better is you put all the require forms in a file file, and require that. > However, in that case you need to add module-exports statements to re-export > the definitions you need. That also seems fine to me. Thanks for the advice. >> For compiling, the answer is that each source file must have a module-export form that exports each symbol that is used in some other source file. That's contrary to what the kawa docs say, but I found that in practice I saw a number of problems if I didn't use module-export forms to expose a file's definitions. In some cases kawa refused to complete the compile; in others it built everything without complaint, but crashed into a stack trace at runtime on an undefined location. >> >> Using module-export cures these symptoms. >> >> Since this is contrary to the kawa docs, I'm open to the possibility that I'm still doing something wrong that causes the unexpected behavior. > > I don't know. Sounds mysterious. If you have *no* module-exports it's supposed to be equivalent to > exporting everything that isn't define-private etc. There are some exceptions - for examples names that > are imported using require aren'r re-exported by default.Again, perhaps you can show us a simple test-case? Sure. In a few minutes.