public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* Building for Android
@ 2022-10-18 14:57 Panicz Maciej Godek
  2022-10-18 15:25 ` Per Bothner
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-18 14:57 UTC (permalink / raw)
  To: kawa

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

Hi,
I've been trying to build a stub for GRASP running in the Android
environment.

My earlier prototype was written in Java, based on the scripts from a
github project called 'buildAPKs', that lets one build Android projects on
Android (using the Termux app).

Also, I found a github project that showd how to build apps written in Kawa
for Android, and even managed to build and run an example application:

https://github.com/abarbu/android-kawa

However, the caveat is that it comes with a kawa.jar file with version
1.13, which is quite old (and there are many features from the more recent
Kawa releases that GRASP relies on).

But when I try to build the KawaHello example using a kawa.jar built from
the most recent version, I get an error from the Android's ''dexer" tool
(which translates JVM bytecode to Dalvik/ART):

PARSE ERROR:
 unsupported class file version 61.0
...while parsing gnu/bytecode/Access.class

So, what I suppose happens, is that the javac which builds Kawa emits byte
code that is unsupported by dx.

I tried building Kawa having passed --with-java-source=7 to the 'configure'
script, but that didn't help. I also tried cosplaying javac by ecj (which
is the compiler that the buildAPKs uses), but this results with a bunch of
warnings and some errors:

180. WARNING in
/data/data/com.termux/files/home/Kawa2/gnu/kawa/util/AbstractHashTable.java
(at line 243)                                                     static
class AbstractEntrySet<Entry extends Map.Entry<K,V>, K, V> extends
AbstractSet<Entry>
                              ^^^^^                                The type
parameter Entry is hiding the type Map.Entry<K,V>
 ----------
181. ERROR in
/data/data/com.termux/files/home/Kawa2/gnu/kawa/util/AbstractHashTable.java
(at line 287)
 nextEntry = htable.table[nextIndex];
             ^^^^^^^^^^^^^^^^^^^^^^^                                Type
mismatch: cannot convert from Map.Entry to Entry
----------
182. ERROR in
/data/data/com.termux/files/home/Kawa2/gnu/kawa/util/AbstractHashTable.java
(at line 298)
 nextEntry = htable.getEntryNext(currentEntry);
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                      Type
mismatch: cannot convert from Map.Entry to Entry
----------


I'm not really sure where these errors stem from - I suppose ecj supports a
different subset of Java than the one that was used to write Kawa (I was
forcing source and tarfet

I also tried aliasing javac as javac -release 7, but it still seens to
produce the class file version 61.0.

Does anyone know how to produce a kawa.jar that would satisfy the dexer?
(The dexer version from the termux repo is 1.16)

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

* Re: Building for Android
  2022-10-18 14:57 Building for Android Panicz Maciej Godek
@ 2022-10-18 15:25 ` Per Bothner
  2022-10-18 18:25   ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Per Bothner @ 2022-10-18 15:25 UTC (permalink / raw)
  To: Panicz Maciej Godek, kawa



On 10/18/22 07:57, Panicz Maciej Godek via Kawa wrote:
> PARSE ERROR:
>   unsupported class file version 61.0
> ...while parsing gnu/bytecode/Access.class
> 
> So, what I suppose happens, is that the javac which builds Kawa emits byte
> code that is unsupported by dx.

Try specifying the --release to javac. This may be helpful:
https://stackoverflow.com/questions/43102787/what-is-the-release-flag-in-the-java-9-compiler

> I tried building Kawa having passed --with-java-source=7 to the 'configure'
> script, but that didn't help.

Yes, IIRC (if I recall correctly) that doesn't change teh options passed to javac.

You can pass the --target option to the kawa command when compiling Scheme to class files,
but that currently defaults to 52 (Java 8), which hopefuly dexer will handle.

> I also tried aliasing javac as javac -release 7, but it still seens to
> produce the class file version 61.0.

Hm. That is weird.  You can try an exlicit 'javac --target 8' (say).
According to https://en.wikipedia.org/wiki/Java_version_history
class file version 61.0 is Java 17.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

* Re: Building for Android
  2022-10-18 15:25 ` Per Bothner
@ 2022-10-18 18:25   ` Panicz Maciej Godek
  2022-10-19  9:15     ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-18 18:25 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]

wt., 18 paź 2022, 17:25 użytkownik Per Bothner <per@bothner.com> napisał:

>
>
> On 10/18/22 07:57, Panicz Maciej Godek via Kawa wrote:
> > PARSE ERROR:
> >   unsupported class file version 61.0
> > ...while parsing gnu/bytecode/Access.class
> >
> > So, what I suppose happens, is that the javac which builds Kawa emits
> byte
> > code that is unsupported by dx.
>
> Try specifying the --release to javac. This may be helpful:
>
> https://stackoverflow.com/questions/43102787/what-is-the-release-flag-in-the-java-9-compiler
>
> > I tried building Kawa having passed --with-java-source=7 to the
> 'configure'
> > script, but that didn't help.
>
> Yes, IIRC (if I recall correctly) that doesn't change teh options passed
> to javac.
>
> You can pass the --target option to the kawa command when compiling Scheme
> to class files,
> but that currently defaults to 52 (Java 8), which hopefuly dexer will
> handle.
>
> > I also tried aliasing javac as javac -release 7, but it still seens to
> > produce the class file version 61.0.
>
> Hm. That is weird.  You can try an exlicit 'javac --target 8' (say).
>

It seems that aliasing doesn't work with make. So I did the same thing as I
did with ecj -- wrote a shell script under prioritized $PATH which invoked
javac with --release N flag.

For N=7, I got a compilation error:


RuntimeParameterAnnotationsAttr.java:81: error: incompatible types:
ArrayList<Object> cannot be converted to List<AnnotationEntry>
                  attr.parameterEntries.add(new ArrayList<>());
                                            ^
      RuntimeParameterAnnotationsAttr.java:85: error: incompatible types:
ArrayList<Object> cannot be converted to List<AnnotationEntry>
                  attr.parameterEntries.add(new ArrayList<>());
                                            ^
      RuntimeParameterAnnotationsAttr.java:110: error: incompatible types:
ArrayList<Object> cannot be converted to List<AnnotationEntry>
                 parameterEntries.add(new ArrayList<>());
                                      ^

Fortunately, for N=8 the process completes successfully, and dexer no
longer complains on the class file version.

However, the dexing process now seems to be taking forever (ie. over 5
minutes), and the only way it managed to terminate so far was either by
throwing out-of-memory exception, or by complaining that it is unable to
allocate sufficiently large memory block due to fragmentation.

I've been doing it on my phone, which has 6GB of RAM -- I'd thought that's
sufficient -- but I'll also try it on a larger machine (still, I find that
behavior surprising: the jar for kawa 1.13 has 2.2MB, whereas the latest
one - 2.9MB, so it doesn't seem that much larger - yet dexing the old
version takes about 30 seconds and doesn't blow anything up)


According to https://en.wikipedia.org/wiki/Java_version_history
> class file version 61.0 is Java 17.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

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

* Re: Building for Android
  2022-10-18 18:25   ` Panicz Maciej Godek
@ 2022-10-19  9:15     ` Panicz Maciej Godek
  2022-10-19 16:05       ` Per Bothner
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-19  9:15 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

I have a small update.
I found that Android has replaced its dx tool with another tool called d8.
I managed to plug it into my build script, and my findings are the
following:
- the .jar with Kawa version 1.13 still builds correctly
- when I try the latest Kawa built with javac --release 8 or --release 9,
the d8 complains:

Error: Field name '1+' cannot be represented in dex format.

I tried fixing that by renaming this function as add1 in the
gnu/commonlisp/lisp/primitives.lisp. Actually, there were several other
issues in that file (and it would probably be easier to be able to compile
Kawa without CommonLisp).

However, even after fixing that, I get another error:

Error: Field name '\=android\,view\,View' cannot be represented in dex
format.

I really don't know how to overcome that one (IIRC Kawa 1.13 used $Dt as a
replacement for a dot)

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

* Re: Building for Android
  2022-10-19  9:15     ` Panicz Maciej Godek
@ 2022-10-19 16:05       ` Per Bothner
  2022-10-19 17:09         ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Per Bothner @ 2022-10-19 16:05 UTC (permalink / raw)
  To: Panicz Maciej Godek; +Cc: kawa



On 10/19/22 02:15, Panicz Maciej Godek wrote:
> However, even after fixing that, I get another error:
> 
> Error: Field name '\=android\,view\,View' cannot be represented in dex format.
> 
> I really don't know how to overcome that one (IIRC Kawa 1.13 used $Dt as a replacement for a dot)

There is still logic in Kawa to use-old style mangling (such as "$Dt" for ".") when Kawa
is build for Android.  Notice the /* #ifdef Android */ in gnu/expr/Magling.java.

This code is supposed to be enable by the gnu/kawa/util/PreProcess.java helper,
specifically if you configure --with-android.

So the first step is to make sure your working copy of Mangling.java actually does have the USE_SYMBOLIC
set to false.  If it doesn't, delete the file selected-java-source, and re-run configure and make.
Check the PreProcess in the 'make' log.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

* Re: Building for Android
  2022-10-19 16:05       ` Per Bothner
@ 2022-10-19 17:09         ` Panicz Maciej Godek
  2022-10-20  5:35           ` Panicz Maciej Godek
  2022-10-21 18:00           ` Per Bothner
  0 siblings, 2 replies; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-19 17:09 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

So, I did check, and USE_SYMBOLIC is set to true.

I followed your instruction: I removed selected-java-source, make clean,
and then I typed this:

./configure --prefix=$HOME/usr --without-awt --without-swt --without-sax2
--without-swing --with-java-source=8 --without-httpserver --disable-xquery
--disable-echo2 --disable-jemacs --disable-brl
--with-android=/data/data/com.termux/files/usr/share/java/android.jar

(I also tried --disable-xml, but then make reported an error while
attempting to compile some scm module)

But despite that, USE_SYMBOLIC is still set to true in Mangle.java

The output of make that I think might be relevant:

javac -d . -g gnu/kawa/util/PreProcess.java
CLASSPATH=".:$CLASSPATH" java gnu.kawa.util.PreProcess \
 %java8 -use:com.sun.net.httpserver +enable:XML -with:jline3 -with:lsp4j
-use:java.awt \
   `sed -e 's|\([^ ]*\)|./\1|' < ./patch-source-list`
 (variant java8 maps to: +JAVA5 +JAVA2 +use:java.util.IdentityHashMap
+use:java.lang.CharSequence +use:java.lang.Throwable.getCause
+use:java.net.URI +use:java.util.regex +SAX2 +use:java.nio
+use:org.w3c.dom.Node +use:javax.xml.transform +JAXP-1.3 -JAXP-QName +JAVA6
+JAVA7 +JAVA8 -JAVA9 -JAVA6COMPAT5 +use:java.text.Normalizer
+use:javax.lang.model +use:java.lang.invoke -Android)
                                                make[1]: Leaving directory
'/data/data/com.termux/files/home/Kawa2'        echo "%java8
-use:com.sun.net.httpserver +enable:XML -with:jline3 -with:lsp4j
-use:java.awt" >selected-java-source


śr., 19 paź 2022, 18:05 użytkownik Per Bothner <per@bothner.com> napisał:

>
>
> On 10/19/22 02:15, Panicz Maciej Godek wrote:
> > However, even after fixing that, I get another error:
> >
> > Error: Field name '\=android\,view\,View' cannot be represented in dex
> format.
> >
> > I really don't know how to overcome that one (IIRC Kawa 1.13 used $Dt as
> a replacement for a dot)
>
> There is still logic in Kawa to use-old style mangling (such as "$Dt" for
> ".") when Kawa
> is build for Android.  Notice the /* #ifdef Android */ in
> gnu/expr/Magling.java.
>
> This code is supposed to be enable by the gnu/kawa/util/PreProcess.java
> helper,
> specifically if you configure --with-android.
>
> So the first step is to make sure your working copy of Mangling.java
> actually does have the USE_SYMBOLIC
> set to false.  If it doesn't, delete the file selected-java-source, and
> re-run configure and make.
> Check the PreProcess in the 'make' log.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

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

* Re: Building for Android
  2022-10-19 17:09         ` Panicz Maciej Godek
@ 2022-10-20  5:35           ` Panicz Maciej Godek
  2022-10-20 20:48             ` Panicz Maciej Godek
  2022-10-21 18:00           ` Per Bothner
  1 sibling, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-20  5:35 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 4756 bytes --]

After modifying gnu/expr/Mangle.java and running 'make clean; make' it
seems to work properly. The d8 tool reports the folowing issues:

Stripped invalid locals information from 5 methods.
In libs/kawa.jar:gnu/kawa/slib/syntaxutils.class:
  Methods with invalid locals information:
 java.lang.Object
gnu.kawa.slib.syntaxutils.unrewriteQuote(gnu.expr.QuoteExp)
                                                          Type information
in locals-table is inconsistent. Cannot constrain type: BOTTOM (empty) for
value: v39(val) by constraint INT.                      In
libs/kawa.jar:kawa/lib/bytevectors.class:
  Methods with invalid locals information:
  java.lang.Object
kawa.lib.bytevectors.bytevectorAppend(gnu.lists.U8Vector[])
  Attempt to define local of type int as result:gnu.lists.U8Vector
 In libs/kawa.jar:kawa/lib/kawa/mstrings.class:
  Methods with invalid locals information:
 java.lang.CharSequence kawa.lib.kawa.mstrings.stringMap(java.lang.Object,
java.lang.CharSequence, java.lang.CharSequence[])
  Type information in locals-table is inconsistent. Cannot constrain type:
INT for value: v126 by constraint OBJECT.
In libs/kawa.jar:kawa/lib/numbers.class:
  Methods with invalid locals information:
  boolean kawa.lib.numbers.isInteger(java.lang.Object)
  Type information in locals-table is inconsistent. Cannot constrain type:
BOTTOM (empty) for value: v50 by constraint INT.
In libs/kawa.jar:kawa/lib/strings.class:
  Methods with invalid locals information:
  void kawa.lib.strings.stringForEach(java.lang.Object,
java.lang.CharSequence, java.lang.Object[])
  Type information in locals-table is inconsistent. Cannot constrain type:
INT for value: v164 by constraint OBJECT.
Some warnings are typically a sign of using an outdated Java toolchain. To
fix, recompile the source with an updated toolchain.


But other than that, the build finishes, and the example program runs
properly.

Thanks.

śr., 19 paź 2022, 19:09 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> So, I did check, and USE_SYMBOLIC is set to true.
>
> I followed your instruction: I removed selected-java-source, make clean,
> and then I typed this:
>
> ./configure --prefix=$HOME/usr --without-awt --without-swt --without-sax2
> --without-swing --with-java-source=8 --without-httpserver --disable-xquery
> --disable-echo2 --disable-jemacs --disable-brl
> --with-android=/data/data/com.termux/files/usr/share/java/android.jar
>
> (I also tried --disable-xml, but then make reported an error while
> attempting to compile some scm module)
>
> But despite that, USE_SYMBOLIC is still set to true in Mangle.java
>
> The output of make that I think might be relevant:
>
> javac -d . -g gnu/kawa/util/PreProcess.java
> CLASSPATH=".:$CLASSPATH" java gnu.kawa.util.PreProcess \
>  %java8 -use:com.sun.net.httpserver +enable:XML -with:jline3 -with:lsp4j
> -use:java.awt \
>    `sed -e 's|\([^ ]*\)|./\1|' < ./patch-source-list`
>  (variant java8 maps to: +JAVA5 +JAVA2 +use:java.util.IdentityHashMap
> +use:java.lang.CharSequence +use:java.lang.Throwable.getCause
> +use:java.net.URI +use:java.util.regex +SAX2 +use:java.nio
> +use:org.w3c.dom.Node +use:javax.xml.transform +JAXP-1.3 -JAXP-QName +JAVA6
> +JAVA7 +JAVA8 -JAVA9 -JAVA6COMPAT5 +use:java.text.Normalizer
> +use:javax.lang.model +use:java.lang.invoke -Android)
>                                                 make[1]: Leaving directory
> '/data/data/com.termux/files/home/Kawa2'        echo "%java8
> -use:com.sun.net.httpserver +enable:XML -with:jline3 -with:lsp4j
> -use:java.awt" >selected-java-source
>
>
> śr., 19 paź 2022, 18:05 użytkownik Per Bothner <per@bothner.com> napisał:
>
>>
>>
>> On 10/19/22 02:15, Panicz Maciej Godek wrote:
>> > However, even after fixing that, I get another error:
>> >
>> > Error: Field name '\=android\,view\,View' cannot be represented in dex
>> format.
>> >
>> > I really don't know how to overcome that one (IIRC Kawa 1.13 used $Dt
>> as a replacement for a dot)
>>
>> There is still logic in Kawa to use-old style mangling (such as "$Dt" for
>> ".") when Kawa
>> is build for Android.  Notice the /* #ifdef Android */ in
>> gnu/expr/Magling.java.
>>
>> This code is supposed to be enable by the gnu/kawa/util/PreProcess.java
>> helper,
>> specifically if you configure --with-android.
>>
>> So the first step is to make sure your working copy of Mangling.java
>> actually does have the USE_SYMBOLIC
>> set to false.  If it doesn't, delete the file selected-java-source, and
>> re-run configure and make.
>> Check the PreProcess in the 'make' log.
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/
>>
>

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

* Re: Building for Android
  2022-10-20  5:35           ` Panicz Maciej Godek
@ 2022-10-20 20:48             ` Panicz Maciej Godek
  2022-10-21  5:14               ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-20 20:48 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

I've noticed several more issues with the kawa.jar that I produced by
manually changing gnu/expr/Mangle.java:
when I try to run the terminal version of GRASP, I get a bunch of warnings
like:

"no declaration seen for shift-left"
"no declaration seen for shift-top"

etc.

Those identifiers are names of fields in a superclass. The superclass in
this case is CharPainter:
https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/text-painter.scm#L16

I use a "define-object" macro which - rather trivially - expands to
"define-class":
https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/define-object.scm

(define-object (ClassName constructor-args ...)::Interface
  (define name :: type value)
  (define (method args ...) ...)
  (SuperClass super-constructor-args ...)
  init-code ...)

expands to something like

(define-class ClassName (Interface SuperClass)
  (name :: type init: value)
  ((method args ...) ...)
  ((*init* constructor-args ...)
   (invoke-special SuperClass (this) '*init super-constructor-args ...)
   init-code ...))

(and it certainly worked with the previous kawa.jar)

Anyway, it seems that the code of the subclass is unable to see the slots
defined in its parent class.
I suspect that this might have something to do with mangling/unmangling.

I will try to verify this tomorrow by replacing the identifiers like
shift-left with something more like shiftLeft
to see if that helps.

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

* Re: Building for Android
  2022-10-20 20:48             ` Panicz Maciej Godek
@ 2022-10-21  5:14               ` Panicz Maciej Godek
  2022-10-21 13:59                 ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-21  5:14 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

I can confirm this:

when I replaced the superclass' member identifiers shift-left, shift-top,
clip-left, clip-top, clip-width, clip-height, selection-drawing-mode?, with
- respectively - shiftLeft, shiftTop, clipLeft, clipTop, clipWidth,
clipHeight and selectionDrawingMode, they are again visible in the subclass.


czw., 20 paź 2022, 22:48 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> I've noticed several more issues with the kawa.jar that I produced by
> manually changing gnu/expr/Mangle.java:
> when I try to run the terminal version of GRASP, I get a bunch of warnings
> like:
>
> "no declaration seen for shift-left"
> "no declaration seen for shift-top"
>
> etc.
>
> Those identifiers are names of fields in a superclass. The superclass in
> this case is CharPainter:
>
> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/text-painter.scm#L16
>
> I use a "define-object" macro which - rather trivially - expands to
> "define-class":
>
> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/define-object.scm
>
> (define-object (ClassName constructor-args ...)::Interface
>   (define name :: type value)
>   (define (method args ...) ...)
>   (SuperClass super-constructor-args ...)
>   init-code ...)
>
> expands to something like
>
> (define-class ClassName (Interface SuperClass)
>   (name :: type init: value)
>   ((method args ...) ...)
>   ((*init* constructor-args ...)
>    (invoke-special SuperClass (this) '*init super-constructor-args ...)
>    init-code ...))
>
> (and it certainly worked with the previous kawa.jar)
>
> Anyway, it seems that the code of the subclass is unable to see the slots
> defined in its parent class.
> I suspect that this might have something to do with mangling/unmangling.
>
> I will try to verify this tomorrow by replacing the identifiers like
> shift-left with something more like shiftLeft
> to see if that helps.
>

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

* Re: Building for Android
  2022-10-21  5:14               ` Panicz Maciej Godek
@ 2022-10-21 13:59                 ` Panicz Maciej Godek
  2022-10-21 18:11                   ` Per Bothner
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-21 13:59 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

I found out (by analyzing the somewhat messy gnu/kawa/util/PreProcess.java)
that the reason why I hand to edit gnu/expr/Mangling.java by hand was that
- in addition to --with-android -- I was also using --with-java-source to
./configure.

The jar produced without that flag was able to build the HelloKawa project
(provided that I did the trick with injecting --release 8 to javac).

However, the d8 tool still issues its warnings, and the member field names
containing 'mangled' characters are still invisible from the subclasses.

While this isn't something I can't live with - because I don't have that
many such use cases - I wanted to ask about the chances of resolving that
issue?

If it's a problem that would take a lot of time, I can just rename those
few identifiers that are in my code and carry on with the development.

pt., 21 paź 2022, 07:14 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> I can confirm this:
>
> when I replaced the superclass' member identifiers shift-left, shift-top,
> clip-left, clip-top, clip-width, clip-height, selection-drawing-mode?, with
> - respectively - shiftLeft, shiftTop, clipLeft, clipTop, clipWidth,
> clipHeight and selectionDrawingMode, they are again visible in the subclass.
>
>
> czw., 20 paź 2022, 22:48 użytkownik Panicz Maciej Godek <
> godek.maciek@gmail.com> napisał:
>
>> I've noticed several more issues with the kawa.jar that I produced by
>> manually changing gnu/expr/Mangle.java:
>> when I try to run the terminal version of GRASP, I get a bunch of
>> warnings like:
>>
>> "no declaration seen for shift-left"
>> "no declaration seen for shift-top"
>>
>> etc.
>>
>> Those identifiers are names of fields in a superclass. The superclass in
>> this case is CharPainter:
>>
>> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/text-painter.scm#L16
>>
>> I use a "define-object" macro which - rather trivially - expands to
>> "define-class":
>>
>> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/define-object.scm
>>
>> (define-object (ClassName constructor-args ...)::Interface
>>   (define name :: type value)
>>   (define (method args ...) ...)
>>   (SuperClass super-constructor-args ...)
>>   init-code ...)
>>
>> expands to something like
>>
>> (define-class ClassName (Interface SuperClass)
>>   (name :: type init: value)
>>   ((method args ...) ...)
>>   ((*init* constructor-args ...)
>>    (invoke-special SuperClass (this) '*init super-constructor-args ...)
>>    init-code ...))
>>
>> (and it certainly worked with the previous kawa.jar)
>>
>> Anyway, it seems that the code of the subclass is unable to see the slots
>> defined in its parent class.
>> I suspect that this might have something to do with mangling/unmangling.
>>
>> I will try to verify this tomorrow by replacing the identifiers like
>> shift-left with something more like shiftLeft
>> to see if that helps.
>>
>

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

* Re: Building for Android
  2022-10-19 17:09         ` Panicz Maciej Godek
  2022-10-20  5:35           ` Panicz Maciej Godek
@ 2022-10-21 18:00           ` Per Bothner
  1 sibling, 0 replies; 22+ messages in thread
From: Per Bothner @ 2022-10-21 18:00 UTC (permalink / raw)
  To: Panicz Maciej Godek; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]



On 10/19/22 10:09, Panicz Maciej Godek wrote:
> So, I did check, and USE_SYMBOLIC is set to true.

Let's fix that first.

> I followed your instruction: I removed selected-java-source, make clean, and then I typed this:
> 
> ./configure --prefix=$HOME/usr --without-awt --without-swt --without-sax2 --without-swing --with-java-source=8 --without-httpserver --disable-xquery --disable-echo2 --disable-jemacs --disable-brl --with-android=/data/data/com.termux/files/usr/share/java/android.jar

I figured it out: The --with-java-source=8 overrides the --with-android flag in terms of PreProcess arguments.

Please try the attached patch. It should force '+Android' as a PreProcess argument.
It seems to work even if you use --with-java-source, in the sense of setting USE_SYMBOLIC to false.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

[-- Attachment #2: mk-patch.txt --]
[-- Type: text/plain, Size: 925 bytes --]

diff --git a/Makefile.am b/Makefile.am
index 062b9b7e7..b77e4d0e3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -368,6 +368,11 @@ endif
 
 JAVA_SOURCE = @JAVA_SOURCE@
 
+if WITH_ANDROID
+PREPROCESS_ANDROID = +Android
+else
+PREPROCESS_ANDROID = -Android
+endif
 if WITH_HTTPSERVER
 PREPROCESS_HTTPSERVER = +use:com.sun.net.httpserver
 else
@@ -405,7 +410,7 @@ kawa/Version.class: kawa/Version.java
 gnu/kawa/util/PreProcess.class: gnu/kawa/util/PreProcess.java
 	$(JAVAC) -d . $(JAVACFLAGS) $^
 
-JAVA_PREPROCESS_OPTIONS = @JAVA_SOURCE_SELECTOR@ $(PREPROCESS_HTTPSERVER) $(PREPROCESS_XML) $(PREPROCESS_JLINE3) $(PREPROCESS_LSP4J) $(PREPROCESS_AWT)
+JAVA_PREPROCESS_OPTIONS = @JAVA_SOURCE_SELECTOR@ $(PREPROCESS_HTTPSERVER) $(PREPROCESS_XML) $(PREPROCESS_JLINE3) $(PREPROCESS_LSP4J) $(PREPROCESS_AWT) $(PREPROCESS_ANDROID)
 
 selected-java-source: Makefile $(srcdir)/patch-source-list
 	if test ! -e selected-java-source -o \

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

* Re: Building for Android
  2022-10-21 13:59                 ` Panicz Maciej Godek
@ 2022-10-21 18:11                   ` Per Bothner
  2022-10-21 19:19                     ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Per Bothner @ 2022-10-21 18:11 UTC (permalink / raw)
  To: Panicz Maciej Godek; +Cc: kawa



On 10/21/22 06:59, Panicz Maciej Godek wrote:
> I found out (by analyzing the somewhat messy gnu/kawa/util/PreProcess.java) that the reason why I hand to edit gnu/expr/Mangling.java by hand was that - in addition to --with-android -- I was also using --with-java-source to ./configure.

I didn't see this until I figured it out independently ...

> 
> The jar produced without that flag was able to build the HelloKawa project (provided that I did the trick with injecting --release 8 to javac).
> 
> However, the d8 tool still issues its warnings, and the member field names containing 'mangled' characters are still invisible from the subclasses.
> 
> While this isn't something I can't live with - because I don't have that many such use cases - I wanted to ask about the chances of resolving that issue?

Well, if the fix in my previous sets USE_SYMBOLIC to false for you,
the part of the problem is solved.

If you're still getting invalidly mangled field names, we should figure out why.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

* Re: Building for Android
  2022-10-21 18:11                   ` Per Bothner
@ 2022-10-21 19:19                     ` Panicz Maciej Godek
  2022-10-21 19:31                       ` Per Bothner
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-21 19:19 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

pt., 21 paź 2022, 20:12 użytkownik Per Bothner <per@bothner.com> napisał:

>
>
> > While this isn't something I can't live with - because I don't have that
> many such use cases - I wanted to ask about the chances of resolving that
> issue?
>
> Well, if the fix in my previous sets USE_SYMBOLIC to false for you,
> the part of the problem is solved.
>
> If you're still getting invalidly mangled field names, we should figure
> out why.
>

The patch does solve the issue with the interference between --with-android
and --with-java-source (I tested it with version 9 to see whether the d8
tool would stop complaining - but it didn't help, although it didn't break
anything either)

However, the issue with accessing superclass properties with mangled names
from a subclass remains unsolved.

When I run javap on the compiled superclass, it gives the following result
(I'm pasting only the problematic identifiers):

public abstract class CharPainter implements Painter {
              public gnu.math.RealNum shift$Mnleft;
                           public gnu.math.RealNum shift$Mntop;
                                        public gnu.math.RealNum
clip$Mnleft;                                                    public
gnu.math.RealNum clip$Mntop;
     public gnu.math.RealNum clip$Mnwidth;
                 public gnu.math.RealNum clip$Mnheight;
                              public Position marked$Mncursor$Mnposition;
                                           public boolean
selection$Mndrawing$Mnmode$Qu;
...
}

This doesn't look incorrect to me - I'd suspect that the problem might be
on the side of the subclass.

>

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

* Re: Building for Android
  2022-10-21 19:19                     ` Panicz Maciej Godek
@ 2022-10-21 19:31                       ` Per Bothner
  2022-10-21 19:45                         ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Per Bothner @ 2022-10-21 19:31 UTC (permalink / raw)
  To: Panicz Maciej Godek; +Cc: kawa



On 10/21/22 12:19, Panicz Maciej Godek wrote:

> However, the issue with accessing superclass properties with mangled names from a subclass remains unsolved.

Can you come up with a test-case that doesn't require Android,
but fails if you force USE_SYMBOLIC to force?  Comment out the /* #ifdef */ etc.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

* Re: Building for Android
  2022-10-21 19:31                       ` Per Bothner
@ 2022-10-21 19:45                         ` Panicz Maciej Godek
  2022-10-21 20:13                           ` Panicz Maciej Godek
  2022-10-22  6:26                           ` Per Bothner
  0 siblings, 2 replies; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-21 19:45 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa


[-- Attachment #1.1: Type: text/plain, Size: 677 bytes --]

Attached.

During its compilation, Kawa issues the following warning:

subclass-refering-to-mangled-superclass-property.scm:6:4: warning - no
declaration seen for mangled-name

pt., 21 paź 2022, 21:31 użytkownik Per Bothner <per@bothner.com> napisał:

>
>
> On 10/21/22 12:19, Panicz Maciej Godek wrote:
>
> > However, the issue with accessing superclass properties with mangled
> names from a subclass remains unsolved.
>
> Can you come up with a test-case that doesn't require Android,
> but fails if you force USE_SYMBOLIC to force?  Comment out the /* #ifdef
> */ etc.
>
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

[-- Attachment #2: subclass-refering-to-mangled-superclass-property.scm --]
[-- Type: application/octet-stream, Size: 156 bytes --]

(define-simple-class SuperClass ()
  (mangled-name ::boolean init: #f))

(define-simple-class SubClass (SuperClass)
  ((*init*)
   (set! mangled-name #t)))

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

* Re: Building for Android
  2022-10-21 19:45                         ` Panicz Maciej Godek
@ 2022-10-21 20:13                           ` Panicz Maciej Godek
  2022-10-22  6:26                           ` Per Bothner
  1 sibling, 0 replies; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-21 20:13 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

By the way, I think it's also worth condsidering to add "--release
<version>" flag to javac in Makefile when Kawa is configured with
--with-java-source=<version> option

pt., 21 paź 2022, 21:45 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> Attached.
>
> During its compilation, Kawa issues the following warning:
>
> subclass-refering-to-mangled-superclass-property.scm:6:4: warning - no
> declaration seen for mangled-name
>
> pt., 21 paź 2022, 21:31 użytkownik Per Bothner <per@bothner.com> napisał:
>
>>
>>
>> On 10/21/22 12:19, Panicz Maciej Godek wrote:
>>
>> > However, the issue with accessing superclass properties with mangled
>> names from a subclass remains unsolved.
>>
>> Can you come up with a test-case that doesn't require Android,
>> but fails if you force USE_SYMBOLIC to force?  Comment out the /* #ifdef
>> */ etc.
>>
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/
>>
>

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

* Re: Building for Android
  2022-10-21 19:45                         ` Panicz Maciej Godek
  2022-10-21 20:13                           ` Panicz Maciej Godek
@ 2022-10-22  6:26                           ` Per Bothner
  2022-10-22  9:31                             ` Panicz Maciej Godek
  1 sibling, 1 reply; 22+ messages in thread
From: Per Bothner @ 2022-10-22  6:26 UTC (permalink / raw)
  To: Panicz Maciej Godek; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]



On 10/21/22 12:45, Panicz Maciej Godek wrote:
> During its compilation, Kawa issues the following warning:
> 
> subclass-refering-to-mangled-superclass-property.scm:6:4: warning - no declaration seen for mangled-name

The attached patch seems to fix it.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

[-- Attachment #2: tr-diff.txt --]
[-- Type: text/plain, Size: 823 bytes --]

diff --git a/kawa/lang/Translator.java b/kawa/lang/Translator.java
index d01e83618..745b23d78 100644
--- a/kawa/lang/Translator.java
+++ b/kawa/lang/Translator.java
@@ -877,9 +877,8 @@ public class Translator extends Compilation
                     } else {
                         gnu.expr.SourceName snameAnn =
                             part.getAnnotation(gnu.expr.SourceName.class);
-                        String pname = snameAnn == null ? part.getName()
-                            : snameAnn.name();
-                        if (! dname.equals(pname))
+                        // If SourceName annotation, require exact match.
+                        if (snameAnn != null && ! dname.equals(snameAnn.name()))
                             continue;
                     }
                     Expression part1;

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

* Re: Building for Android
  2022-10-22  6:26                           ` Per Bothner
@ 2022-10-22  9:31                             ` Panicz Maciej Godek
  2022-10-22 12:08                               ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-22  9:31 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

This is weird.
Without the patch, the only complaint concerns the identifiers - and if I
rename them to legal Java identifiers, everything works fine.

However, when I apply the patch and try to run the editor, I get the
following:

java.lang.RuntimeException: wrong number of indexes 0 to 1-rank array
                     at
gnu.lists.AbstractSequence.badRank(AbstractSequence.java:55)
         at gnu.lists.AbstractSequence.checkRank(AbstractSequence.java:51)
                     at
gnu.lists.AbstractSequence.effectiveIndex(AbstractSequence.java:84)
          at gnu.lists.AbstractSequence.getInt(AbstractSequence.java:173)
                       at cons.hashCode(primitive.scm:156)
                                   at
java.base/java.util.WeakHashMap.hash(WeakHashMap.java:303)
         at java.base/java.util.WeakHashMap.getEntry(WeakHashMap.java:432)
                     at
java.base/java.util.WeakHashMap.containsKey(WeakHashMap.java:423)
          at hash$Mntable.hashRef$Pl$V(hash-table.scm:21)
                       at hash$Mntable.hashRef$Pl$check(hash-table.scm:20)
                                   at
gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
          at gnu.mapping.Procedure.apply3(Procedure.java:167)
                       at space.getter$2(space.scm:504)
                                    at space.getter$2$check(space.scm:504)
                                                at
gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
          at gnu.mapping.Procedure.apply1(Procedure.java:154)
                       at
gnu.kawa.functions.ApplyToArgs.apply2(ApplyToArgs.java:52)
         at parse$frame1.lambda5addElement$Ex(parse.scm:183)
                     at parse.readList(parse.scm:275)
                                  at parse.readList(parse.scm)
                                              at
parse.readList(parse.scm:223)
          at parse.readList(parse.scm)
                      at parse.readList$check(parse.scm:165)
                                  at
gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
          at gnu.mapping.Procedure.apply0(Procedure.java:148)
                       at parse.parseDocument(parse.scm:291)
                                   at parse.parseDocument(parse.scm:289)
                                               at
parse.parseDocument$check(parse.scm:288)
         at
gnu.mapping.Procedure.applyToConsumerDefault(Procedure.java:75)
          at
gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
          at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
                       at
gnu.mapping.CallContext.runUntilValue(CallContext.java:669)
          at gnu.mapping.Procedure.apply1(Procedure.java:154)
                       at conversions$frame0.lambda2(conversions.scm:14)
                                   at
conversions$frame0.lambda2$check(conversions.scm:12)
         at gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
                      at gnu.mapping.Procedure.apply1(Procedure.java:154)
                                   at
kawa.lib.ports.callWithInputString(ports.scm:154)
          at conversions.withInputFromString(conversions.scm:12)
                      at
conversions.withInputFromString$check(conversions.scm:10)
          at gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
                      at gnu.mapping.Procedure.apply2(Procedure.java:160)
                                   at
atInteractiveLevel$Mn3.run(primitive-terminal-client.scm:48)
         at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:290)
                     at kawa.Shell.run(Shell.java:300)
                                 at kawa.Shell.runFile(Shell.java:562)
                                             at
kawa.Shell.runFileOrClass(Shell.java:485)
          at kawa.repl.processArgs(repl.java:298)
                       at kawa.repl.main(repl.java:830)

The exception clearly comes from my code. It's a bit convoluted to explain
what's going in there, but if you'd like to take a glimpse, you can find it
here:

https://github.com/panicz/grasp-android/tree/master/stages/retreat/GRASP/src

Android isn't required to run any of these. You can either try running
./grasp-terminal (in vt100-compatible terminal with unicode)
./grasp-desktop (with AWT)
or
./primitive-terminal-client (in terminal)


sob., 22 paź 2022, 08:26 użytkownik Per Bothner <per@bothner.com> napisał:

>
>
> On 10/21/22 12:45, Panicz Maciej Godek wrote:
> > During its compilation, Kawa issues the following warning:
> >
> > subclass-refering-to-mangled-superclass-property.scm:6:4: warning - no
> declaration seen for mangled-name
>
> The attached patch seems to fix it.
>
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/

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

* Re: Building for Android
  2022-10-22  9:31                             ` Panicz Maciej Godek
@ 2022-10-22 12:08                               ` Panicz Maciej Godek
  2022-10-24  7:22                                 ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-22 12:08 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 5481 bytes --]

It perhaps might have something to do with the fact, that I override the
"cons" operator with my own one, which uses eq? as equals, and Java's
default hash functions for objects:


https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/primitive.scm#L151

sob., 22 paź 2022, 11:31 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> This is weird.
> Without the patch, the only complaint concerns the identifiers - and if I
> rename them to legal Java identifiers, everything works fine.
>
> However, when I apply the patch and try to run the editor, I get the
> following:
>
> java.lang.RuntimeException: wrong number of indexes 0 to 1-rank array
>                      at
> gnu.lists.AbstractSequence.badRank(AbstractSequence.java:55)
>          at gnu.lists.AbstractSequence.checkRank(AbstractSequence.java:51)
>                      at
> gnu.lists.AbstractSequence.effectiveIndex(AbstractSequence.java:84)
>           at gnu.lists.AbstractSequence.getInt(AbstractSequence.java:173)
>                        at cons.hashCode(primitive.scm:156)
>                                    at
> java.base/java.util.WeakHashMap.hash(WeakHashMap.java:303)
>          at java.base/java.util.WeakHashMap.getEntry(WeakHashMap.java:432)
>                      at
> java.base/java.util.WeakHashMap.containsKey(WeakHashMap.java:423)
>           at hash$Mntable.hashRef$Pl$V(hash-table.scm:21)
>                        at hash$Mntable.hashRef$Pl$check(hash-table.scm:20)
>                                    at
> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>           at gnu.mapping.Procedure.apply3(Procedure.java:167)
>                        at space.getter$2(space.scm:504)
>                                     at space.getter$2$check(space.scm:504)
>                                                 at
> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>           at gnu.mapping.Procedure.apply1(Procedure.java:154)
>                        at
> gnu.kawa.functions.ApplyToArgs.apply2(ApplyToArgs.java:52)
>          at parse$frame1.lambda5addElement$Ex(parse.scm:183)
>                      at parse.readList(parse.scm:275)
>                                   at parse.readList(parse.scm)
>                                               at
> parse.readList(parse.scm:223)
>           at parse.readList(parse.scm)
>                       at parse.readList$check(parse.scm:165)
>                                   at
> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>           at gnu.mapping.Procedure.apply0(Procedure.java:148)
>                        at parse.parseDocument(parse.scm:291)
>                                    at parse.parseDocument(parse.scm:289)
>                                                at
> parse.parseDocument$check(parse.scm:288)
>          at
> gnu.mapping.Procedure.applyToConsumerDefault(Procedure.java:75)
>           at
> gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
>           at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
>                        at
> gnu.mapping.CallContext.runUntilValue(CallContext.java:669)
>           at gnu.mapping.Procedure.apply1(Procedure.java:154)
>                        at conversions$frame0.lambda2(conversions.scm:14)
>                                    at
> conversions$frame0.lambda2$check(conversions.scm:12)
>          at gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>                       at gnu.mapping.Procedure.apply1(Procedure.java:154)
>                                    at
> kawa.lib.ports.callWithInputString(ports.scm:154)
>           at conversions.withInputFromString(conversions.scm:12)
>                       at
> conversions.withInputFromString$check(conversions.scm:10)
>           at gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>                       at gnu.mapping.Procedure.apply2(Procedure.java:160)
>                                    at
> atInteractiveLevel$Mn3.run(primitive-terminal-client.scm:48)
>          at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:290)
>                      at kawa.Shell.run(Shell.java:300)
>                                  at kawa.Shell.runFile(Shell.java:562)
>                                              at
> kawa.Shell.runFileOrClass(Shell.java:485)
>           at kawa.repl.processArgs(repl.java:298)
>                        at kawa.repl.main(repl.java:830)
>
> The exception clearly comes from my code. It's a bit convoluted to explain
> what's going in there, but if you'd like to take a glimpse, you can find it
> here:
>
>
> https://github.com/panicz/grasp-android/tree/master/stages/retreat/GRASP/src
>
> Android isn't required to run any of these. You can either try running
> ./grasp-terminal (in vt100-compatible terminal with unicode)
> ./grasp-desktop (with AWT)
> or
> ./primitive-terminal-client (in terminal)
>
>
> sob., 22 paź 2022, 08:26 użytkownik Per Bothner <per@bothner.com> napisał:
>
>>
>>
>> On 10/21/22 12:45, Panicz Maciej Godek wrote:
>> > During its compilation, Kawa issues the following warning:
>> >
>> > subclass-refering-to-mangled-superclass-property.scm:6:4: warning - no
>> declaration seen for mangled-name
>>
>> The attached patch seems to fix it.
>>
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/
>
>

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

* Re: Building for Android
  2022-10-22 12:08                               ` Panicz Maciej Godek
@ 2022-10-24  7:22                                 ` Panicz Maciej Godek
  2022-10-24 10:48                                   ` Per Bothner
  0 siblings, 1 reply; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-24  7:22 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 6270 bytes --]

I've noticed that, in my code, I've been using the names "hash-code" and
"java.lang.System:identity-hash-code".

So, I replaced them with "hashCode" and "identityHashCode", respectively -
because it would make sense that the hash function wasn't properly
overridden.

But that didn't help: everything is exactly the same. It also puzzles me:
why, instead of actually calling java.lang.System's static method, the
methods of gnu.list.AbstractSequence are being called? (The line numbers
seem to match, but the top of the stack trace is a mystery)

sob., 22 paź 2022, 14:08 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> It perhaps might have something to do with the fact, that I override the
> "cons" operator with my own one, which uses eq? as equals, and Java's
> default hash functions for objects:
>
>
>
> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/primitive.scm#L151
>
> sob., 22 paź 2022, 11:31 użytkownik Panicz Maciej Godek <
> godek.maciek@gmail.com> napisał:
>
>> This is weird.
>> Without the patch, the only complaint concerns the identifiers - and if I
>> rename them to legal Java identifiers, everything works fine.
>>
>> However, when I apply the patch and try to run the editor, I get the
>> following:
>>
>> java.lang.RuntimeException: wrong number of indexes 0 to 1-rank array
>>                        at
>> gnu.lists.AbstractSequence.badRank(AbstractSequence.java:55)
>>          at gnu.lists.AbstractSequence.checkRank(AbstractSequence.java:51)
>>                      at
>> gnu.lists.AbstractSequence.effectiveIndex(AbstractSequence.java:84)
>>           at gnu.lists.AbstractSequence.getInt(AbstractSequence.java:173)
>>                        at cons.hashCode(primitive.scm:156)
>>                                    at
>> java.base/java.util.WeakHashMap.hash(WeakHashMap.java:303)
>>          at java.base/java.util.WeakHashMap.getEntry(WeakHashMap.java:432)
>>                      at
>> java.base/java.util.WeakHashMap.containsKey(WeakHashMap.java:423)
>>           at hash$Mntable.hashRef$Pl$V(hash-table.scm:21)
>>                        at hash$Mntable.hashRef$Pl$check(hash-table.scm:20)
>>                                    at
>> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>>           at gnu.mapping.Procedure.apply3(Procedure.java:167)
>>                        at space.getter$2(space.scm:504)
>>                                     at space.getter$2$check(space.scm:504)
>>                                                 at
>> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>>           at gnu.mapping.Procedure.apply1(Procedure.java:154)
>>                        at
>> gnu.kawa.functions.ApplyToArgs.apply2(ApplyToArgs.java:52)
>>          at parse$frame1.lambda5addElement$Ex(parse.scm:183)
>>                      at parse.readList(parse.scm:275)
>>                                   at parse.readList(parse.scm)
>>                                               at
>> parse.readList(parse.scm:223)
>>           at parse.readList(parse.scm)
>>                       at parse.readList$check(parse.scm:165)
>>                                   at
>> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>>           at gnu.mapping.Procedure.apply0(Procedure.java:148)
>>                        at parse.parseDocument(parse.scm:291)
>>                                    at parse.parseDocument(parse.scm:289)
>>                                                at
>> parse.parseDocument$check(parse.scm:288)
>>          at
>> gnu.mapping.Procedure.applyToConsumerDefault(Procedure.java:75)
>>           at
>> gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
>>           at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
>>                        at
>> gnu.mapping.CallContext.runUntilValue(CallContext.java:669)
>>           at gnu.mapping.Procedure.apply1(Procedure.java:154)
>>                        at conversions$frame0.lambda2(conversions.scm:14)
>>                                    at
>> conversions$frame0.lambda2$check(conversions.scm:12)
>>          at gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>>                       at gnu.mapping.Procedure.apply1(Procedure.java:154)
>>                                    at
>> kawa.lib.ports.callWithInputString(ports.scm:154)
>>           at conversions.withInputFromString(conversions.scm:12)
>>                       at
>> conversions.withInputFromString$check(conversions.scm:10)
>>           at gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
>>                       at gnu.mapping.Procedure.apply2(Procedure.java:160)
>>                                    at
>> atInteractiveLevel$Mn3.run(primitive-terminal-client.scm:48)
>>          at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:290)
>>                      at kawa.Shell.run(Shell.java:300)
>>                                  at kawa.Shell.runFile(Shell.java:562)
>>                                              at
>> kawa.Shell.runFileOrClass(Shell.java:485)
>>           at kawa.repl.processArgs(repl.java:298)
>>                        at kawa.repl.main(repl.java:830)
>>
>> The exception clearly comes from my code. It's a bit convoluted to
>> explain what's going in there, but if you'd like to take a glimpse, you can
>> find it here:
>>
>>
>> https://github.com/panicz/grasp-android/tree/master/stages/retreat/GRASP/src
>>
>> Android isn't required to run any of these. You can either try running
>> ./grasp-terminal (in vt100-compatible terminal with unicode)
>> ./grasp-desktop (with AWT)
>> or
>> ./primitive-terminal-client (in terminal)
>>
>>
>> sob., 22 paź 2022, 08:26 użytkownik Per Bothner <per@bothner.com>
>> napisał:
>>
>>>
>>>
>>> On 10/21/22 12:45, Panicz Maciej Godek wrote:
>>> > During its compilation, Kawa issues the following warning:
>>> >
>>> > subclass-refering-to-mangled-superclass-property.scm:6:4: warning - no
>>> declaration seen for mangled-name
>>>
>>> The attached patch seems to fix it.
>>>
>>> --
>>>         --Per Bothner
>>> per@bothner.com   http://per.bothner.com/
>>
>>

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

* Re: Building for Android
  2022-10-24  7:22                                 ` Panicz Maciej Godek
@ 2022-10-24 10:48                                   ` Per Bothner
  2022-10-24 12:01                                     ` Panicz Maciej Godek
  0 siblings, 1 reply; 22+ messages in thread
From: Per Bothner @ 2022-10-24 10:48 UTC (permalink / raw)
  To: Panicz Maciej Godek; +Cc: kawa



On 10/24/22 00:22, Panicz Maciej Godek wrote:
> I've noticed that, in my code, I've been using the names "hash-code" and "java.lang.System:identity-hash-code".

I think it is best to use Java names (such as identityHashCode) for things that come from Java.
(I haven't always been consistent about that.)

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

* Re: Building for Android
  2022-10-24 10:48                                   ` Per Bothner
@ 2022-10-24 12:01                                     ` Panicz Maciej Godek
  0 siblings, 0 replies; 22+ messages in thread
From: Panicz Maciej Godek @ 2022-10-24 12:01 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

pon., 24 paź 2022 o 12:48 Per Bothner <per@bothner.com> napisał(a):

>
>
> On 10/24/22 00:22, Panicz Maciej Godek wrote:
> > I've noticed that, in my code, I've been using the names "hash-code" and
> "java.lang.System:identity-hash-code".
>
> I think it is best to use Java names (such as identityHashCode) for things
> that come from Java.
> (I haven't always been consistent about that.)
>

It seems reasonable in principle.
When I was writing that code, I read about name mangling in Kawa's
documentation,
and I didn't know whether I'm supposed to use Java names, mangled names
or whether both forms were acceptable. So I made a guess, it worked and I
left it the way it was.

And, it would be reasonable to expect hash-code to be mangled as hash$Mncode
in the Android build. And it would be reasonable to expect that replacing
hash-code
with hashCode would fix the issue - but it doesn not.

It seems that:
- Kawa's stack trace points to the proper hashCode function's position
- but instead of simply calling the overridden hashCode method (which is
implemented as (java.lang.System:identityHashCode (this))), it calls some
methods from gnu.lists.AbstractSequence. I suppose there might be some
inlining occurring along the way. My current bets are that either Kawa
doesn't actually override the hashCode function and uses the one from
AbstractSequence, or it treats some of my code as an application of the
"cons" cell, and inserts a call to AbstractSequence's "get" method.

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

end of thread, other threads:[~2022-10-24 12:01 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-18 14:57 Building for Android Panicz Maciej Godek
2022-10-18 15:25 ` Per Bothner
2022-10-18 18:25   ` Panicz Maciej Godek
2022-10-19  9:15     ` Panicz Maciej Godek
2022-10-19 16:05       ` Per Bothner
2022-10-19 17:09         ` Panicz Maciej Godek
2022-10-20  5:35           ` Panicz Maciej Godek
2022-10-20 20:48             ` Panicz Maciej Godek
2022-10-21  5:14               ` Panicz Maciej Godek
2022-10-21 13:59                 ` Panicz Maciej Godek
2022-10-21 18:11                   ` Per Bothner
2022-10-21 19:19                     ` Panicz Maciej Godek
2022-10-21 19:31                       ` Per Bothner
2022-10-21 19:45                         ` Panicz Maciej Godek
2022-10-21 20:13                           ` Panicz Maciej Godek
2022-10-22  6:26                           ` Per Bothner
2022-10-22  9:31                             ` Panicz Maciej Godek
2022-10-22 12:08                               ` Panicz Maciej Godek
2022-10-24  7:22                                 ` Panicz Maciej Godek
2022-10-24 10:48                                   ` Per Bothner
2022-10-24 12:01                                     ` Panicz Maciej Godek
2022-10-21 18:00           ` Per Bothner

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).