From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107469 invoked by alias); 18 Sep 2017 08:29:28 -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 107195 invoked by uid 89); 18 Sep 2017 08:29:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Sep 2017 08:29:26 +0000 Received: by mail-wm0-f41.google.com with SMTP id a137so11906540wma.0 for ; Mon, 18 Sep 2017 01:29:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W6fWwvMSmfYGOsRxBlIj+Tqvb/L0EDsOOcxJEuIyDdE=; b=lXZkpT2lTFhhyDGJd4PTgcdMTQy+GCuko2SvGqXTFk1AkIiqnlAB/ZvXNbSZoJ/3rg BmhqrEoZA+qWDdzdaBS4kWAQMR/+9hZkLouCkesi6gZNogLoa/TZMTBVCWD7DfHbLut6 C3gS8fBc4E6POiRarlpj9tjnR+JFZ7BuMTmhIpN22XakVmZxfHbLKbPyaGyZL59nLuZF WQkzFWPk1pcFva7zZDGZv3aWyiWy9oAhTw6L0VZcV/iVYbiZFd4GqO1Pw/ISFgiDIN3h ZTSgiEGpLE6foQ5hCY4o+X2m6tw4dde2fkhk3tqqSaFAH5NPDyCZlBulwS/m93/dOLye A4/A== X-Gm-Message-State: AHPjjUjClgwyR8jsyWA08wDpBWY0m/1SBM6y2SLoXj0JZaHgINDep95W BtnMrFRBZ1tNJxl4B4aSI2PtJ+V5Aivk1ucl7xXOTeFN X-Google-Smtp-Source: AOwi7QC76N+wLUYNGHG1zkH8N9sZXdg3PpgOEhqsbK0aasnDVAshCHm4lk/wgx0TMcImiF7Kj20BzH+M+A1e/VRkC3w= X-Received: by 10.28.128.215 with SMTP id b206mr3920823wmd.152.1505723364324; Mon, 18 Sep 2017 01:29:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.200.2 with HTTP; Mon, 18 Sep 2017 01:29:23 -0700 (PDT) In-Reply-To: References: From: Sonny To Date: Mon, 18 Sep 2017 08:29:00 -0000 Message-ID: Subject: Re: scoping rules To: Per Bothner Cc: Kawa mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00063.txt.bz2 I was able to reproduce strange behavior with symbol scope on the jvm: (define (run-in-ui-thread fn) (let ((t :: java.lang.Thread (java.lang.Thread (object (java.lang.Runnable) ((run)::void (fn)))))) (t:start))) (run-in-ui-thread (lambda () (let ( (a 1) (b 2) (c (+ a b))) (display c)))) here's the stacktrace /dev/stdin:37:15: warning - no declaration seen for b #|kawa:39|# Exception in thread "Thread-4" /dev/stdin:37:13: unbound location: a at gnu.mapping.DynamicLocation.get(DynamicLocation.java:36) at atInteractiveLevel$Mn5.lambda1(stdin:37) at atInteractiveLevel$Mn5.lambda1$check(stdin:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at gnu.mapping.CallContext$ReflectMethodHandle.invokeExact(CallContext.java:726) at gnu.mapping.Procedure.applyToConsumerDefault(Procedure.java:75) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at gnu.mapping.CallContext$ReflectMethodHandle.invokeExact(CallContext.java:726) at gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at gnu.mapping.CallContext$ReflectMethodHandle.invokeExact(CallContext.java:726) at gnu.mapping.CallContext.runUntilDone(CallContext.java:586) at gnu.mapping.CallContext.runUntilValue(CallContext.java:669) at gnu.mapping.Procedure.apply1(Procedure.java:148) at atInteractiveLevel$Mn1$0.run(stdin:5) at java.lang.Thread.run(Thread.java:745) This however works: (run-in-ui-thread (lambda () (let ( (a 1) (b 2)) (display (+ a b))))) On Sun, Sep 17, 2017 at 9:49 PM, Sonny To wrote: > ok let me see if i can reproduce this outside of android > > On Sun, Sep 17, 2017 at 10:45 AM, Per Bothner wrote: >> On 09/17/2017 09:51 AM, Sonny To wrote: >>> >>> sorry for the newb question but i find this behavior odd >>> >>> (let ((handler (android.os.Handler (android.os.Looper:getMainLooper))) >>> (c context)) >>> (handler:post (lambda () >>> (let ((t (android.widget.Toast:makeText (as >>> android.app.Application c) "foobar" 1000))) >>> (t:show)) >>> ))) >>> >>> To get this example to work I had to bind c context in the top level let >>> in the second let, I have to use c instead of context directly. >>> (android.widget.Toast:makeText (as android.app.Application context) >>> will complain >>> >>> /dev/stdin:45:93: unbound location: context >>> >>> it could not see the context binding. >>> Should it not look in the environment? context is definitely in the >>> environment because the c binding works >> >> >> That does sound like a bug. Probably the interaction of dynamic >> (environment) name-lookup >> combined with the use of the anonymous class. >> >> If you can create a simple non-Android test-case I'll take a look. >> >> It is recommended to include the line: >> >> (define-variable context) >> >> as that tells the compiler to look for 'context' in the dynamic environment, >> and avoids warnings when using --warn-undefined-variable. >> -- >> --Per Bothner >> per@bothner.com http://per.bothner.com/