headers
Mark Evenson | 1 Dec 2010 17:44
Picon
Favicon

Re: [armedbear-devel] is there a good method to read/write java byte arrays?

On 3/17/10 5:32 PM, Alessio Stalla wrote:
> On Wed, Mar 17, 2010 at 5:22 PM, Mark Evenson<evenson <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Evenson | 1 Dec 2010 23:52
Picon
Favicon

Re: [armedbear-devel] CFFI support for the previous example

On 11/30/10 9:44 PM, Mark Evenson wrote:
[…]
 > As of [r13071 on ABCL trunk][1], with help from
> Erik I've enabled the new classwriter to create dynamic interfaces.

The definitions of interfaces created by r13071 couldn't be loaded 
properly by the JVM.  [svn r13078 on ABCL trunk][1] fixes this as can be 
verified by the [working sample code of dynamically creating Java 
interfaces with JVM posted to the ABCL technical wiki][2].

[2]: http://trac.common-lisp.net/armedbear/changeset/13078
[3]: http://trac.common-lisp.net/armedbear/wiki/UsingClassWriter

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 2 Dec 2010 10:11
Picon
Gravatar

Re: [armedbear-devel] [armedbear-cvs] r13078 - in trunk/abcl: nbproject src/org/armedbear/lisp

Hi Mark,

On Wed, Dec 1, 2010 at 11:44 PM, Mark Evenson <mevenson <at> common-lisp.net> wrote:
> Author: mevenson
> Date: Wed Dec  1 17:44:34 2010
> New Revision: 13078
>
> Log:
> The classfile writer now handles the creation of interfaces.

> Modified:
>   trunk/abcl/nbproject/build-impl.xml
>   trunk/abcl/nbproject/genfiles.properties

^^^^

Did you intend to commit the NB project file changes?

>   trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp

Bye,

Erik.

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 2 Dec 2010 13:18
Picon
Gravatar

[armedbear-devel] [ANNOUNCE] ABCL 0.23.1: Fix for loading ABCL from a path with spaces

The ABCL community released version 0.23.1 of its lisp-on-the-jvm.
This release fixes the ability to run ABCL from paths with one or more
spaces in them.

Source distribution archives can be downloaded in ZIP or gzipped tar form:

 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-src-0.23.1.tar.gz
 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-src-0.23.1.zip

Signatures are available under:
 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-src-0.23.1.tar.gz.asc
 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-src-0.23.1.zip.asc

In addition, binaries are also available:

 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-bin-0.23.1.tar.gz
 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-bin-0.23.1.zip

With associated signatures:
 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-bin-0.23.1.tar.gz.asc
 http://common-lisp.net/project/armedbear/releases/0.23.1/abcl-bin-0.23.1.zip.asc
Permalink | Reply | 0 comments |
headers
Mark Evenson | 3 Dec 2010 09:21
Picon
Favicon

Re: [armedbear-devel] [armedbear-cvs] r13078 - in trunk/abcl: nbproject src/org/armedbear/lisp

On 12/2/10 10:11 AM, Erik Huelsmann wrote:
[…]
> Did you intend to commit the NB project file changes?
>
>>    trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp

Nope.  But after I noticed them, I tested loading them in 
netbeans-6.5.1, so I didn't try to revert them.

If anyone has problems with the new Netbeans project files due to my 
inadvertent update, please let me know.

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply | 0 comments |
headers
Mark Evenson | 3 Dec 2010 15:08
Picon
Favicon

Re: [armedbear-devel] ASDF 2.011

On 11/29/10 7:28 AM, Faré wrote:
=
> I'm pleased to announce the release of ASDF 2.011. As compared to ASDF
> 2.010, it only sports a series of minor changes, which I think is sign
> of ASDF 2 becoming mature:

[…]

> It would be very nice of vendors to update the version of ASDF they
> ship with their respective implementations, or to start shipping it
> when they don't do it yet (LispWorks, SCL; Corman, GCL - if they are
> still being developed).

ABCL upgraded to ASDF-2.011 in [svn r13087][1].

[1]: http://trac.common-lisp.net/armedbear/changeset/13087

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Mark Evenson | 4 Dec 2010 21:38
Picon
Favicon

Re: [armedbear-devel] Patch for ABCL against BORDEAUX-THREADS-0.8.0

On 12/3/10 4:56 PM, Martin Simmons wrote:
>>>>>> On Fri, 03 Dec 2010 14:37:52 +0100, Mark Evenson said:
>>
>> Implement CONDITION-WAIT and CONDITION-NOTIFY for ABCL.
>
> That version of CONDITION-WAIT won't work properly:

Indeed it won't:  thanks for the comments, and the kick in the butt.

After studying the needed abstractions in more detail I've 
[reimplemented most of the BORDEAUX-THREADS interfaces for ABCL based on 
the java.util.concurrent.ReentrantLock][1].  This code should now 
correctly implement the POSIX-style condition variables, the recursively 
held locks, and the form of lock acquisition that returns immediately.

Please consider the referenced patch for inclusion in BORDEAUX-THREADS.

[1]: 
http://slack.net/~evenson/abcl/hunchentoot/bordeaux-threads-abcl-20101204a.diff

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
David Kirkman | 5 Dec 2010 06:25
Favicon

[armedbear-devel] bug in RandomAccessCharacterFile.java

The problem is that in the while loop (line 549), if only part of the byte
array is written to the buffer, the position is updated but the length
is not.  I'm attaching a patch.

Here is some code that fails in r13087, and works with the patch.  I ran into
this while serializing mixed lisp/java objects, which is pretty well reflected
in this snippet.

Cheers,

-david k.

(let* ((len 5000)
       (big-object (jnew-array "double" len)))
  (dotimes (i len)
    (setf (jarray-ref big-object i) (+ i 0.1)))

  (with-open-file (stream "foo.dat"
                          :direction :output
                          :element-type 'unsigned-byte)
    (let ((p (jnew
              (jconstructor "java.io.ObjectOutputStream" "java.io.OutputStream")
              (jcall (jmethod "org.armedbear.lisp.Stream"
                              "getWrappedOutputStream")
                     stream))))

      (jcall (jmethod "java.io.ObjectOutputStream" "writeObject"
                      "java.lang.Object")
             p
             big-object)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Evenson | 5 Dec 2010 08:50
Picon
Favicon

Re: [armedbear-devel] bug in RandomAccessCharacterFile.java

On 12/5/10 6:25 AM, David Kirkman wrote:
> The problem is that in the while loop (line 549), if only part of the byte
> array is written to the buffer, the position is updated but the length
> is not.  I'm attaching a patch.

Applied in [svn r13088][1].  Thanks for the patch!

[1]: http://trac.common-lisp.net/armedbear/changeset/13088

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 5 Dec 2010 11:16
Picon
Gravatar
Subject: [armedbear-devel] Idiomatic conversion of file: URLs to file-paths

[armedbear-devel] Idiomatic conversion of file: URLs to file-paths

Hi Mark,

To get back to our earlier (irc) discussion of converting
URL.getPath() / URI.getPath() to (Windows) pathnames:

I found this page:
http://weblogs.java.net/blog/2007/04/25/how-convert-javaneturl-javaiofile

which contains code on how to do the conversion. I just checked on
Windows it even strips the leading '/' which you get from
URL.getPath().

My reaction to these findings is to propose a new static function to
be added to the Utilities class, which should be used to convert
file:/ urls to paths. Our code should then be searched for invocations
of URL/URI.getPath() on file urls, changing it to the utility
function.

Regards,

Erik.
Permalink | Reply | 0 comments |

Gmane