Mark Evenson | 1 Sep 09:01 2009
Picon

Re: [armedbear-devel] eol-style problem with abcl-src-0.15.tar.gz

On 8/31/09 11:30 PM, Erik Huelsmann wrote:
[…]
>> The svn:eol-style is now set to 'LF' in SVN for 'abcl.in', which does
>> the "right thing" when building the source tar balls, so abcl-0.16
>> should be ok, as long as whoever builds the release doesn't somehow
>> override this local SVN setting
>
> Well, I haven't changed the local settings while creating any of the
> releases, but abcl.in is part of the abcl.dist.misc target, which is
> part of one of the FIXCRLF elements. Could that be the issue?

Unless you run the build with the 'abcl.source.eol' property set to 
something other than 'asis' there should be no change of eol from whst 
comes out of SVN.  Currently, the 'fixcrlf' command in the 
'abcl.source.prepare' runs with the 'abcl.source.eol' set to 'asis' 
which does nothing in the transformation.  As I remember the 
implementation history here, I developed this target around the same 
time we moved to SVN, so we ended up fixing everything in the SVN 
properties, instead of relying on Ant.

I think the EOL setting in the repository can be overridden by 
configuration options in the SVN client, so this might be another source 
of error.  And I think using the cygwin SVN client under win32 gets you 
UNIX line-endings 'LF' for files with svn:eol-style set to 'native', 
while using the native SVN release (or TortoiseSVN) gets you 'CRLF'.

On the basis of so much possible variation, I guess I would recommend we 
start using <fixcrlf> with more restrictive defensive settings.

Would these be:
(Continue reading)

Erik Huelsmann | 1 Sep 09:28 2009
Picon

Re: [armedbear-devel] eol-style problem with abcl-src-0.15.tar.gz

On Tue, Sep 1, 2009 at 9:01 AM, Mark Evenson<evenson <at> panix.com> wrote:
> On 8/31/09 11:30 PM, Erik Huelsmann wrote:
> […]
>>> The svn:eol-style is now set to 'LF' in SVN for 'abcl.in', which does
>>> the "right thing" when building the source tar balls, so abcl-0.16
>>> should be ok, as long as whoever builds the release doesn't somehow
>>> override this local SVN setting
>>
>> Well, I haven't changed the local settings while creating any of the
>> releases, but abcl.in is part of the abcl.dist.misc target, which is
>> part of one of the FIXCRLF elements. Could that be the issue?
>
> Unless you run the build with the 'abcl.source.eol' property set to
> something other than 'asis' there should be no change of eol from whst
> comes out of SVN.  Currently, the 'fixcrlf' command in the
> 'abcl.source.prepare' runs with the 'abcl.source.eol' set to 'asis'
> which does nothing in the transformation.  As I remember the
> implementation history here, I developed this target around the same
> time we moved to SVN, so we ended up fixing everything in the SVN
> properties, instead of relying on Ant.

Which is nice :-)

> I think the EOL setting in the repository can be overridden by
> configuration options in the SVN client, so this might be another source
> of error.  And I think using the cygwin SVN client under win32 gets you
> UNIX line-endings 'LF' for files with svn:eol-style set to 'native',
> while using the native SVN release (or TortoiseSVN) gets you 'CRLF'.

Right. The Subversion release manager uses a command line option to
(Continue reading)

Mark Evenson | 1 Sep 11:19 2009
Picon

[armedbear-devel] Behavior of 'abcl.source.{tar, zip}' targets changed

On 9/1/09 9:28 AM, Erik Huelsmann wrote:
[…]
> I think I'd like the value of ?? to be dependent on the distribution
> archive (CRLF for zip and LF for tar.gz). How difficult would it be to
> build that into build.xml?

I've implemented this behavior in [svn 12127][1].  Please test when you 
get a chance.

'abcl.source.{tar,zip}' now explicit changes the EOL for most files to
'lf' (UNIX) for the tar, and to 'crf' (DOS) for the zip.  The current
exception is that the 'abcl.in' script always gets 'lf' EOL, and the
'abcl.bat.in' always get 'crlf' EOL.

The 'abcl.source.eol' property has been removed.

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

-- 
"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
Mark Evenson | 2 Sep 12:09 2009
Picon

[armedbear-devel] [REVISED 20090902a] Loading Lisp from JAR Files

Attached is a further revision of the patch for loading Lisp from JAR 
files.  This version works in about all the cases we need to support. 
This feature will be one of the first to hit to 0.17 trunk when we 
branch, because I don't want to commit such a potentially destabilizing 
change in the week before 0.16.

This patch includes additions to the ABCL test suite for this change, 
since there are enough corner cases that I seem to miss testing them 
occasionally in writing this code.  Working with our test suite via ASDF 
is not currently the most obvious thing in the world, so some notes on 
that:  To get the tests to work, get a REPL that loads the ASDF 
"abcl-test-lisp" system, and run the tests once (needed to bind 
*this-directory* variable).  Often one must tell the ASDF methods that 
they must be 'forced' to get to work, so use the 'force-system-test' via 
SLIME or pass the ':force t' option if you are issuing commands directly 
from the REPL.  After the "abcl-test-lisp" system has run once, issue na 
(ABCL-TEST:REM-ALL-TESTS) in that REPL then load the 
"test/lisp/abcl/load.lisp" file, which will create a JAR ('baz.jar') 
that the tests work on (only works under *NIX for the moment, sorry). 
Then, one get issue (ABCL-TEST:DO-TESTS) to run the testing of LOAD 
specific tests.

Some notes on our use RT package, the basis for the ABCL Lisp test 
suite:  RT lacks a mechanism for expressing "build-up/tear-down" 
abstractions that I am familiar with in test suites.  Included in this 
would be an easy way to specify a value for *DEFAULT-PATHNAME-DEFAULTS* 
when the tests are run (I provide this in the ABCL-TEST-LISP:RUN method, 
but there should be a way to specify per test so that individual tests 
can be run easier when developing).

(Continue reading)

Erik Huelsmann | 4 Sep 17:23 2009
Picon

[armedbear-devel] Branching 0.16.x

With the recent changes to our Ant build to create ZIP files with CRLF
line endings and LF line endings in the TAR archive, I think we have
enough basis to create a branch for release management of our 0.16.x
release line.

Should further fixes be required, they can be backported. Creating the
release branch now frees up the trunk for further development.

Are there any last minute fixes that need to be applied? From the
silence on the list this last week I concluded there probably are not.

I hope to be able to create a release before the end of the weekend,
however, no guarantees!

Bye,

Erik.
Mark Evenson | 4 Sep 19:16 2009
Picon

Re: [armedbear-devel] Branching 0.16.x

On 9/4/09 5:23 PM, Erik Huelsmann wrote:

> Are there any last minute fixes that need to be applied? From the
> silence on the list this last week I concluded there probably are not.

Everything I've tested on the trunk seems to work fine.

Just make the release with Java6 to include the JSR-223 support, ok?

Mark

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Erik Huelsmann | 6 Sep 10:46 2009
Picon

[armedbear-devel] [ANNOUNCE] ABCL 0.16.0

On behalf of the developers of ABCL (Armed Bear Common Lisp) - a lisp
implementation running on the JVM - I'm glad to be able to announce
the 0.16.0 release.

This release features - among lots of other things - performance improvements,
better type checking for the THE form and ANSI tests fixes. You can find the
release notes at:

  http://common-lisp.net/project/armedbear/release-notes-0.16.shtml

If you have questions regarding its license or use, or you find issues, please
report back to the development list:

  armedbear-devel at common-lisp dot net

The sources can be downloaded in ZIP or .tar.gz form from SourceForge:

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

Signatures are available under:

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

Bye,

Erik.
logicmoo | 6 Sep 23:14 2009
Picon

(no subject)


Passing PRINT-LENGTH.INIT.1 

Index: src/org/armedbear/lisp/top-level.lisp
===================================================================
--- src/org/armedbear/lisp/top-level.lisp (revision 12140)
+++ src/org/armedbear/lisp/top-level.lisp (working copy)
 <at>  <at>  -406,13 +406,12  <at>  <at> 
 (defparameter *repl-read-form-fun* #'repl-read-form-fun)

 (defun repl (&optional (in *standard-input*) (out *standard-output*))
-  (let* ((*print-length* 10))
     (loop
        (let* ((form (funcall *repl-read-form-fun* in out))
               (results (multiple-value-list (sys:interactive-eval form))))
          (dolist (result results)
            (fresh-line out)
-           (prin1 result out))))))
+           (prin1 result out)))))

 (defun top-level-loop ()
   (fresh-line)
Attachment (PRINT-LENGTH.INIT.1.patch): application/octet-stream, 935 bytes
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
(Continue reading)

logicmoo | 6 Sep 23:29 2009
Picon

Passing FORMAT.C.4A and FORMATTER.C.4A

Passing FORMAT.C.4A and FORMATTER.C.4A

Index: src/org/armedbear/lisp/LispCharacter.java
===================================================================
--- src/org/armedbear/lisp/LispCharacter.java (revision 12140)
+++ src/org/armedbear/lisp/LispCharacter.java (working copy)
 <at>  <at>  -32,6 +32,8  <at>  <at> 
  */

 package org.armedbear.lisp;
+import java.util.HashMap;
+import java.util.Map;

 public final class LispCharacter extends LispObject
 {
 <at>  <at>  -44,7 +46,7  <at>  <at> 
   }

   public final char value;
-
+  private String name;
   public static LispCharacter getInstance(char c)
   {
     try
 <at>  <at>  -256,8 +258,11  <at>  <at> 
           case 127:
             sb.append("Rubout");
             break;
-          default:
-            sb.append(value);
(Continue reading)

logicmoo | 6 Sep 23:29 2009
Picon

[armedbear-devel] Passing FORMAT.C.4A and FORMATTER.C.4A

Passing FORMAT.C.4A and FORMATTER.C.4A

Index: src/org/armedbear/lisp/LispCharacter.java
===================================================================
--- src/org/armedbear/lisp/LispCharacter.java (revision 12140)
+++ src/org/armedbear/lisp/LispCharacter.java (working copy)
 <at>  <at>  -32,6 +32,8  <at>  <at> 
  */

 package org.armedbear.lisp;
+import java.util.HashMap;
+import java.util.Map;

 public final class LispCharacter extends LispObject
 {
 <at>  <at>  -44,7 +46,7  <at>  <at> 
   }

   public final char value;
-
+  private String name;
   public static LispCharacter getInstance(char c)
   {
     try
 <at>  <at>  -256,8 +258,11  <at>  <at> 
           case 127:
             sb.append("Rubout");
             break;
-          default:
-            sb.append(value);
(Continue reading)


Gmane