On Wed, Mar 17, 2010 at 11:51 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Wed, Mar 17, 2010 at 7:36 PM, David Kirkman dkirkman@ucsd.edu wrote:
On Wed, Mar 17, 2010 at 9:55 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Wed, Mar 17, 2010 at 5:32 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Wed, Mar 17, 2010 at 5:22 PM, Mark Evenson evenson@panix.com wrote:
On 3/17/10 5:04 PM, Alessio Stalla wrote: […]
I wrote sys::%make-byte-array-output-stream in order to make the runtime compiler capable of generating bytecode without using temporary files; it wasn't meant to be used by the ABCL user, and as such it's not very polished (for example, the type of a byte-array-output-stream is simply STREAM). In any case, it's defined in the ByteArrayOutputStream Java class, and as you correctly noted, it explicitly sets the element type to (unsigned-byte 8). As a quick and dirty solution, you could more or less copy-paste that class and replace "output" with "input" :) (as well as update Autoload.java to make ABCL know of the new primitives).
We should probably polish it a bit and release it as an extension.
Well, at least we should quickly whip out the inverse version so David doesn't have to rely on hacking Stream.java (although I'm not sure when telling Stream that initAsBinaryStream() means a format of unsigned 8bit bytes will fail).
I think we can commit to the interface you've implemented in ByteArrayOutputStream, as those are the basic necessary operations.
Or maybe I am not seeing what potential problems there would be with this as a short-term strategy, Alessio?
No problem at all in the implementation per se; however, when we'll make it an "official" extension, the interface will change (if anything, symbols won't probably be in sys anymore and they won't be prefixed with %). Since this functionality will have approximately 1 user in the near future :), I think it's ok to commit a quick fix for David. I'm working on it right now.
Committed as r12557.
A.
Thanks for implementing the inverse function so quickly!
I ended up doing a bit more hacking last night. When I tried to serialize structures that contain raw java objects, I realized that I need a way to convert lisp streams into java streams so that I can use the java serialization system. I ended up writing:
public static OutputStream outputStreamFromABCLStream(final LispObject stream) {
if (stream instanceof org.armedbear.lisp.Stream) { return new OutputStream() { public void write(int b) { ((org.armedbear.lisp.Stream) stream)._writeByte(b); } }; } else { throw new RuntimeException("argument not an abcl stream"); } }
and another version for InputStream. Should something like these also go in as primitives?
For binary input/output streams only, I think accessing the Java streams wrapped by the Lisp stream is a better solution: no extra objects are allocated and no API mismatch is possible. Unfortunately those are private fields right now, but a couple of getters are not hard to add ;)
so, your outputStreamFromABCLStream would become:
public static OutputStream outputStreamFromABCLStream(final LispObject stream) {
if (stream instanceof org.armedbear.lisp.Stream) { return ((org.armedbear.lisp.Stream) stream).getOutputStream(); } else { throw new RuntimeException("argument not an abcl stream"); } }
or, if you don't mind getting a ClassCastException instead, simply
public static OutputStream outputStreamFromABCLStream(final LispObject stream) { return ((org.armedbear.lisp.Stream) stream).getOutputStream(); }
what do you think?
I think that's a much better solution! I don't mind ClassCastExceptions, my code had that structure because it started as something copy/pasted out of Stream.java. And I was using _readByte and _writeByte just because I didn't want to have to make changes to Stream.java and end up with my own version of abcl.
-david k.