public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* scoping rules
@ 2017-09-17 16:51 Sonny To
  2017-09-17 17:45 ` Per Bothner
  0 siblings, 1 reply; 6+ messages in thread
From: Sonny To @ 2017-09-17 16:51 UTC (permalink / raw)
  To: Kawa mailing list

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: scoping rules
  2017-09-17 16:51 scoping rules Sonny To
@ 2017-09-17 17:45 ` Per Bothner
  2017-09-17 18:49   ` Sonny To
  0 siblings, 1 reply; 6+ messages in thread
From: Per Bothner @ 2017-09-17 17:45 UTC (permalink / raw)
  To: kawa

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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: scoping rules
  2017-09-17 17:45 ` Per Bothner
@ 2017-09-17 18:49   ` Sonny To
  2017-09-18  8:29     ` Sonny To
  0 siblings, 1 reply; 6+ messages in thread
From: Sonny To @ 2017-09-17 18:49 UTC (permalink / raw)
  To: Per Bothner; +Cc: Kawa mailing list

ok let me see if i can reproduce this outside of android

On Sun, Sep 17, 2017 at 10:45 AM, Per Bothner <per@bothner.com> 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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: scoping rules
  2017-09-17 18:49   ` Sonny To
@ 2017-09-18  8:29     ` Sonny To
  2017-09-18  8:31       ` Sonny To
  2017-09-18 12:34       ` Sonny To
  0 siblings, 2 replies; 6+ messages in thread
From: Sonny To @ 2017-09-18  8:29 UTC (permalink / raw)
  To: Per Bothner; +Cc: Kawa mailing list

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 <son.c.to@gmail.com> wrote:
> ok let me see if i can reproduce this outside of android
>
> On Sun, Sep 17, 2017 at 10:45 AM, Per Bothner <per@bothner.com> 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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: scoping rules
  2017-09-18  8:29     ` Sonny To
@ 2017-09-18  8:31       ` Sonny To
  2017-09-18 12:34       ` Sonny To
  1 sibling, 0 replies; 6+ messages in thread
From: Sonny To @ 2017-09-18  8:31 UTC (permalink / raw)
  To: Per Bothner; +Cc: Kawa mailing list

forgot to mention this is from the master branch and the jar was built
using ant -Denable-android=true

On Mon, Sep 18, 2017 at 11:29 AM, Sonny To <son.c.to@gmail.com> wrote:
> 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 <son.c.to@gmail.com> wrote:
>> ok let me see if i can reproduce this outside of android
>>
>> On Sun, Sep 17, 2017 at 10:45 AM, Per Bothner <per@bothner.com> 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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: scoping rules
  2017-09-18  8:29     ` Sonny To
  2017-09-18  8:31       ` Sonny To
@ 2017-09-18 12:34       ` Sonny To
  1 sibling, 0 replies; 6+ messages in thread
From: Sonny To @ 2017-09-18 12:34 UTC (permalink / raw)
  To: Per Bothner; +Cc: Kawa mailing list

sorry the problem with this example is due to my ignorance on scheme's
let. I'm use to clojure's let
let* is what I should have used

On Mon, Sep 18, 2017 at 11:29 AM, Sonny To <son.c.to@gmail.com> wrote:
> 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 <son.c.to@gmail.com> wrote:
>> ok let me see if i can reproduce this outside of android
>>
>> On Sun, Sep 17, 2017 at 10:45 AM, Per Bothner <per@bothner.com> 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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-09-18 12:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-17 16:51 scoping rules Sonny To
2017-09-17 17:45 ` Per Bothner
2017-09-17 18:49   ` Sonny To
2017-09-18  8:29     ` Sonny To
2017-09-18  8:31       ` Sonny To
2017-09-18 12:34       ` Sonny To

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).