gnu.math.UByte does not implement Externalizable

[Panicz Maciej Godek]

I've found a workaround: it turned out that the function that caused
trouble during the compilation called the 'length' function on its argument
of type string. Replacing that call with string-length helped resolve the
issue.

śr., 24 lip 2024, 16:21 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> I have a follow-up of this story.
> I'm doing some undocumented things based on my shallow analysis of Kawa's
> compilation process.
>
> When I invoke my script, I get the following error:
>
> Exception in thread "main" java.lang.Error: gnu.expr.PrimProcedure does
> not implement
> Externalizable
> at
> gnu.expr.LitTable.error(LitTable.java:122)
> at
> gnu.expr.LitTable.writeObject(LitTable.java:282)
> at
> gnu.expr.LitTable.emit(LitTable.java:85)
> at
> gnu.expr.Compilation.generateBytecode(Compilation.java:2039)
> at
> gnu.expr.Compilation.process(Compilation.java:1832)
> at
> gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:310)
> at
> gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:292)
> at
> utils.build.buildFile$check(build.scm:151)
> at jdk.internal.reflect.GeneratedMethodAccessor95.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> gnu.mapping.CallContext$ReflectMethodHandle.invokeExact(CallContext.java:726)
> at
> gnu.mapping.CallContext.runUntilValue(CallContext.java:656)
> at
> gnu.mapping.Procedure.apply1(Procedure.java:154)
> at
> atInteractiveLevel$Mn49.run(build.scm:165)
> 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 program crashes on the invocation of module-info:loadByStages (line
> 151 marked with a comment)
>
> (define (build-file source ::string
>                     #!key
>                     (target-directory ::string "build/cache")
>                     (package #!null)
>                     (top-class-name #!null))
>   (let* ((messages ::gnu.text.SourceMessages
>                    (gnu.text.SourceMessages))
>          (parse-options ::int (+ gnu.expr.Language:PARSE_PROLOG
>                                  gnu.expr.Language:PARSE_EXPLICIT))
>          (language ::gnu.expr.Language
>                    (gnu.expr.Language:getDefaultLanguage))
>          (module-manager ::gnu.expr.ModuleManager
>                          (gnu.expr.ModuleManager:getInstance))
>          (module-info ::gnu.expr.ModuleInfo
>                       (module-manager:findWithSourcePath source))
>          (input ::gnu.kawa.io.InPort
>                 (open-input-file source))
>          (class-prefix-default ::String
>                                gnu.expr.Compilation:classPrefixDefault))
>     (try-finally
>      (begin
>        (when package
>          (set! gnu.expr.Compilation:classPrefixDefault package))
>        (when top-class-name
>          (module-info:setClassName
>           (string-append
>            (or gnu.expr.Compilation:classPrefixDefault "")
>            (gnu.expr.Mangling:mangleNameIfNeeded top-class-name))))
>        (module-manager:setCompilationDirectory target-directory)
>        (let ((compilation ::gnu.expr.Compilation
>                           (language:parse input messages
>                                           parse-options
>                                           module-info)))
>          (if (messages:seenErrors)
>              (primitive-throw (gnu.text.SyntaxException messages)))
>          (module-info:loadByStages gnu.expr.Compilation:CLASS_WRITTEN) ;151
>          (if (messages:seenErrors)
>              (primitive-throw (gnu.text.SyntaxException messages)))))
>      (set! gnu.expr.Compilation:classPrefixDefault class-prefix-default))))
>
> (It's based on my analysis of kawa.repl and translation of it to Kawa)
>
>
> Is there any way to figure out what exactly is going on in here?
>
> (And would it make sense to implement Externalizable for PrimProcedure?)
>
> wt., 11 cze 2024, 00:05 użytkownik Per Bothner <per@bothner.com> napisał:
>
>>
>>
>> On 6/10/24 9:28 AM, Panicz Maciej Godek via Kawa wrote:
>> > Exception in thread "main" java.lang.Error: gnu.math.UByte does not
>> > implement Externalizable
>> >        at gnu.expr.LitTable.error(LitTable.java:122)
>> >    at gnu.expr.LitTable.writeObject(LitTable.java:282)
>>   at
>> >
>> > I consider that weird, given that the old script works without
>> complaint.
>>
>> I have no idea why "the old script works without complaint".
>>
>> > How can I figure out what is going on in here, and how to fix it?
>>
>> The cleanest fix is to emhance UByte to implement Externaliable.
>> Something like:
>>
>>    public void writeExternal(ObjectOutput out) throws IOException
>>    {
>>      out.writeByte(ival);
>>    }
>>
>>    public void readExternal(ObjectInput in)
>>      throws IOException, ClassNotFoundException
>>    {
>>      ival = in.readByte();
>>    }
>>
>> If you fix UByte, you should also fix UShort, UInt, and Ulong.
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/
>>
>