<div dir="ltr">As released, this will not compile using Java 14.<div><br></div><div>File: <a href="http://abcl.properties.in">abcl.properties.in</a>, line 13, needs to be changed from</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>abcl.javac.source=1.6</div></blockquote><div>to</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>abcl.javac.source=1.8</div><div><br></div></blockquote>File src/org/armedbear/lisp/java/swing/REPLConsole.java, line 144, needs to be changed from<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>yield();</div></blockquote><div>to</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Thread.yield();</div></blockquote><br>because the compiler reports that the command "yield" is now a reserved word. Adding the class name makes it clear this is a function reference.<div><br></div><div>I apologize for not checking these in, but there are other reasons for my not becoming a member of the dev group.</div><div><br></div><div>G.A. Baryza<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 6:31 AM Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Congrats!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Jun 2020 at 12:28, Mark Evenson <<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We are pleased to announce the immediate availablity of the [ABCL<br>
1.7.0 release][].<br>
<br>
After consuming a steady diet of java.nio.ByteBuffer objects over the<br>
past month, the Bear has managed to incorporate the use of these<br>
abstractions for arrays specialized on the commonly used unsigned-byte<br>
types (or (unsigned-byte 8) (unsigned-byte 16) (unsigned-byte 32)).<br>
This replacement of the use arrays of primitive bytes is denoted by<br>
the presence of the :NIO keyword in CL:*FEATURES*.<br>
<br>
With this :NIO overhaul, we have extended our implementation of ANSI<br>
Common Lisp [CL:MAKE-ARRAY][] with two additional keywords,<br>
viz. :NIO-BUFFER and :NIO-DIRECT.<br>
<br>
The :NIO-BUFFER keyword argument allows one to construct a vector<br>
directly utilizing the contents of an already allocated<br>
java.nio.ByteBuffer object. When combined with the ability of JNA to<br>
allocate memory on the heap via a malloc() system call, we implemented<br>
shareable byte vectors in [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR][].<br>
<br>
(let* ((length 16)<br>
(byte-buffer (java:jstatic "allocate"<br>
"java.nio.ByteBuffer" length)))<br>
(make-array length :element-type ’(unsigned-byte 8) <br>
:nio-buffer byte-buffer))<br>
<br>
When the :NIO-DIRECT keyword argument is called with a non-NIL value,<br>
the implementation creates a byte vector with a "directly allocated"<br>
java.nio.ByteBuffer object. Such direct buffers typically have<br>
somewhat higher allocation and deallocation costs than non-direct<br>
buffers. The contents of direct buffers may reside outside of the<br>
normal garbage-collected heap, and so their impact upon the memory<br>
footprint of an application might not be obvious. It is therefore<br>
recommended that direct buffers be allocated primarily for large,<br>
long-lived buffers that are subject to the underlying system’s native<br>
I/O operations. In general it is best to allocate direct buffers only<br>
when they yield a measureable gain in program performance. In the near<br>
future, we intend to exploring the performance gains available CL:LOAD<br>
by accessing direct buffers memory mapped to our on-disk fasl<br>
representation. Our fasls, as zipped archives, currently require a<br>
new seek() from the beginning of the fasl for each component they<br>
contain. With a memory mapped direct buffer we should be able to<br>
simply read from the appropiate byte offset for each component.<br>
<br>
A complete overview of the accumulated fixes and changes since the<br>
previous release may be viewed in [CHANGES][].<br>
<br>
[ABCL 1.7.0 release]: <a href="https://abcl.org/releases/1.7.0/" rel="noreferrer" target="_blank">https://abcl.org/releases/1.7.0/</a><br>
[java.nio.ByteBuffer]: <a href="https://www.doc.ic.ac.uk/csg-old/java/jdk6docs/api/java/nio/ByteBuffer.html" rel="noreferrer" target="_blank">https://www.doc.ic.ac.uk/csg-old/java/jdk6docs/api/java/nio/ByteBuffer.html</a><br>
[CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR]: <a href="https://github.com/cffi/cffi/commit/47136ad9a97c2df98dbcd13a068e14489ced5b03" rel="noreferrer" target="_blank">https://github.com/cffi/cffi/commit/47136ad9a97c2df98dbcd13a068e14489ced5b03</a><br>
[CHANGES]: <a href="https://abcl.org/svn/tags/1.7.0/CHANGES" rel="noreferrer" target="_blank">https://abcl.org/svn/tags/1.7.0/CHANGES</a><br>
[CL:MAKE-ARRAY]: <a href="https://github.com/armedbear/abcl/commit/6c4b7f3c11b2c8151f4599c9bddf5c0991bc6154" rel="noreferrer" target="_blank">https://github.com/armedbear/abcl/commit/6c4b7f3c11b2c8151f4599c9bddf5c0991bc6154</a><br>
<br>
-- <br>
"A screaming comes across the sky. It has happened before but there is nothing <br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>