(funcall (java:jfield org.armedbear.lisp.Function FUNCTION_CLASS_BYTE…#437
(funcall (java:jfield org.armedbear.lisp.Function FUNCTION_CLASS_BYTE…#437alanruttenberg wants to merge 1 commit intoarmedbear:masterfrom
Conversation
…S) function) vs (java:jcall getFunctionClassBytes classloader class), which didn't work in all cases
easye
left a comment
easye
left a comment
There was a problem hiding this comment.
-
Rework and move change to probing available disassemblers to a separate commit.
-
Explain/change why calling
getFunctionClassBytes()should be modified.
| (eval-when (:load-toplevel) | ||
| (defvar *available-disassemblers* | ||
| (let ((files | ||
| (directory (merge-pathnames |
There was a problem hiding this comment.
One cannot assume the presences of a the ABCL-INTROSPECT in the core implementation. Additionally, the presence of the function in a file does not necessarily mean the assembler is available, as it might have unsatisfied Maven load dependencies.
There was a problem hiding this comment.
If there aren't any disassemblers then available-disassemblers will be nil. It's a directory probe which simply fails. The require loads the appropriate system, which resolves the maven dependencies.
| (java:jinstance-of-p classloader "org.armedbear.lisp.FaslClassLoader")) | ||
| (disassemble-bytes | ||
| (java:jcall "getFunctionClassBytes" classloader class)) | ||
| (funcall (java:jfield "org.armedbear.lisp.Function" "FUNCTION_CLASS_BYTES") function) |
There was a problem hiding this comment.
Why this better than calling getFunctionClassBytes on the classloader? Perhaps it is an additional strategy, rather than a strict replacement?
There was a problem hiding this comment.
getFunctionClassBytes didn't work sometimes and I couldn't figure out why, but this works. Should be tracked down. By someone else ;-)
There was a problem hiding this comment.
So, we should modify by adding the strategy to an (or (ignore-errors [CASE A]) (ignore-errors … clause as it will break even less often…
There was a problem hiding this comment.
That's fine with me.
|
Contains changes from #43 |
Originally part of <armedbear#437>
|
I separated out the FUNCALL fallback into #462. The dependency on the ABCL-INTROSPECT contrib should not be present in the core ANSI code, so if you wish to rework that as part of a load of ABCL-INTROSPECT, I will consider such a patch separately. |
2 participants
…S) function) vs (java:jcall getFunctionClassBytes classloader class), which didn't work in all cases