From timo.myyra at wickedbsd.net Sun May 3 05:48:13 2015 From: timo.myyra at wickedbsd.net (Timo =?utf-8?Q?Myyr=C3=A4?=) Date: Sun, 03 May 2015 08:48:13 +0300 Subject: Bug in path handling on 1.3.2 In-Reply-To: (Ville Voutilainen's message of "Wed, 29 Apr 2015 23:43:21 +0300") References: <87wq0u4rb9.fsf@mandrake.wickedbsd.net> Message-ID: <87lhh69ppe.fsf@mandrake.wickedbsd.net> Ville Voutilainen writes: > On 29 April 2015 at 23:23, Timo Myyr? wrote: > >> Hi, >> >> Just tried to update ABCL to 1.3.2 but got error when I tried to load >> hunchentoot. The actual error case can reduced to this: >> >> (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar") >> >> I tried above with sbcl, ecl and clisp. All those return nil as result. >> With ABCL I get: >> Bad place for a wild pathname. >> [Condition of type FILE-ERROR] > > > Ok, the diagnostic is overly-strict, because the NAME component should > be interpreted > as a string, as it's not a wildcard component. But, I trust you are > aware that an ANSI > Common Lisp implementation doesn't necessarily support wildcard-globbing of > files? SBCL does, so perhaps we should add such an extension to abcl as well. Sorry for slow response, got little mail server issues. I'm not that familiar with how ANSI CL should work in these cases so I just compare each oddity how other implementations handle them. But I looked a bit further into this and noticed that issue seems to only affect OpenBSD-current I run on my laptop. When I evaluated `(DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar")' with ABCL 1.3.2 on my OpenBSD 5.6 server, it returns nil. After updating my server to 5.7 and rebuilding ABCL, it still returns nil. I'm a bit curious why my laptop running OpenBSD-current behaves differently. I tried to manually build the ABCL from the source distribution without using OpenBSD ports framework and I still hit the issue. Here's the lisp implementation, its same on 5.7 and -current. CL-USER(3): (LISP-IMPLEMENTATION-VERSION) "1.3.2" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_71-b14" "amd64-OpenBSD-5.7" CL-USER(4): Here's package info if its relevant: $ pkg_info jdk jdk-1.7.0.71v0 abcl-1.3.2 apache-ant-1.9.4 maven-3.2.3 Timo From evenson at panix.com Sun May 3 09:17:39 2015 From: evenson at panix.com (Mark Evenson) Date: Sun, 03 May 2015 11:17:39 +0200 Subject: Java version 1.5? In-Reply-To: References: Message-ID: <5545E7B3.20506@panix.com> On 2015/4/20 03:53, Blake McBride wrote: > Looking over the ant build (build.xml), it seems like the target and source > are set to Java 1.5. Isn't it time we changed it to at least 1.7? Currently, ABCL targets JRE 5 onwards, which is why we build with these flags set. Despite the [as of May 2015 Oracle end-of-life pronouncement][1] for all versions of Java prior to JRE 8, many organizations are still using these supposedly EOL platforms for production, so I believe it is important to continue to support them as long it doesn't penalize ABCL somehow on newer JRE platforms. [1]: http://www.oracle.com/technetwork/java/eol-135779.html As far as I can determine from reading available documentation, changing the target and source compiler options would not produce any more efficient code for the newer Java platforms. Such a change would only prevent our binary releases from running on EOL platforms. When we rewrite the compiler to target the JRE 6 verifier or the JRE 7 bytecode support for dynamic method dispatch (aka JSR 292) in the Lisp compiler, then I think it makes sense to revisit this position. One is of course free to change these options in your local compilations. If anyone can show any changes with different targets, please let us know. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From evenson at panix.com Sun May 3 09:27:24 2015 From: evenson at panix.com (Mark Evenson) Date: Sun, 03 May 2015 11:27:24 +0200 Subject: Bug in path handling on 1.3.2 In-Reply-To: <87lhh69ppe.fsf@mandrake.wickedbsd.net> References: <87wq0u4rb9.fsf@mandrake.wickedbsd.net> <87lhh69ppe.fsf@mandrake.wickedbsd.net> Message-ID: <5545E9FC.9080502@panix.com> On 2015/5/3 07:48, Timo Myyr? wrote: >>> Just tried to update ABCL to 1.3.2 but got error when I tried to load >>> hunchentoot. The actual error case can reduced to this: >>> >>> (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar") >>> >>> I tried above with sbcl, ecl and clisp. All those return nil as result. >>> With ABCL I get: >>> Bad place for a wild pathname. >>> [Condition of type FILE-ERROR] [?] > But I looked a bit further into this and noticed that issue seems to only affect > OpenBSD-current I run on my laptop. When I evaluated `(DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar")' > with ABCL 1.3.2 on my OpenBSD 5.6 server, it returns nil. > After updating my server to 5.7 and rebuilding ABCL, it still returns nil. > > I'm a bit curious why my laptop running OpenBSD-current behaves differently. > I tried to manually build the ABCL from the source distribution without using > OpenBSD ports framework and I still hit the issue. > > Here's the lisp implementation, its same on 5.7 and -current. > CL-USER(3): (LISP-IMPLEMENTATION-VERSION) > "1.3.2" > "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_71-b14" > "amd64-OpenBSD-5.7" > CL-USER(4): [?] Indeed mysterious, but at least there is a potential difference in that you are encountering the difference between OpenBSD 5.7 and CURRENT (although now that CURRENT has become 5.7, we'd have to examine your local notion of CURRENT.) If you have the time, you could build another CURRENT instance from the same source to see if you can duplicate the error on a machine (or virtualization instance) other than your laptop. But that is probably more effort than the problem warrants. Wild-assed-guess: does the argument you are passing to DIRECTORY fail to exist on both machines from the view of the kernel? i.e. from a shell with globbing, does openbsd$ ls -l /usr/local/bin/../lib/maven-core-*.jar return no results on all your machines? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From timo.myyra at wickedbsd.net Sun May 3 10:20:21 2015 From: timo.myyra at wickedbsd.net (Timo =?utf-8?Q?Myyr=C3=A4?=) Date: Sun, 03 May 2015 13:20:21 +0300 Subject: Bug in path handling on 1.3.2 In-Reply-To: <5545E9FC.9080502@panix.com> (Mark Evenson's message of "Sun, 03 May 2015 11:27:24 +0200") References: <87wq0u4rb9.fsf@mandrake.wickedbsd.net> <87lhh69ppe.fsf@mandrake.wickedbsd.net> <5545E9FC.9080502@panix.com> Message-ID: <87h9ru9d3u.fsf@mandrake.wickedbsd.net> Mark Evenson writes: > On 2015/5/3 07:48, Timo Myyr? wrote: > >>>> Just tried to update ABCL to 1.3.2 but got error when I tried to load >>>> hunchentoot. The actual error case can reduced to this: >>>> >>>> (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar") >>>> >>>> I tried above with sbcl, ecl and clisp. All those return nil as result. >>>> With ABCL I get: >>>> Bad place for a wild pathname. >>>> [Condition of type FILE-ERROR] > > [?] > >> But I looked a bit further into this and noticed that issue seems to only affect >> OpenBSD-current I run on my laptop. When I evaluated `(DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar")' >> with ABCL 1.3.2 on my OpenBSD 5.6 server, it returns nil. >> After updating my server to 5.7 and rebuilding ABCL, it still returns nil. >> >> I'm a bit curious why my laptop running OpenBSD-current behaves differently. >> I tried to manually build the ABCL from the source distribution without using >> OpenBSD ports framework and I still hit the issue. >> >> Here's the lisp implementation, its same on 5.7 and -current. >> CL-USER(3): (LISP-IMPLEMENTATION-VERSION) >> "1.3.2" >> "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_71-b14" >> "amd64-OpenBSD-5.7" >> CL-USER(4): > > [?] > > Indeed mysterious, but at least there is a potential difference in that > you are encountering the difference between OpenBSD 5.7 and CURRENT > (although now that CURRENT has become 5.7, we'd have to examine your > local notion of CURRENT.) If you have the time, you could build another > CURRENT instance from the same source to see if you can duplicate the > error on a machine (or virtualization instance) other than your laptop. > But that is probably more effort than the problem warrants. > > Wild-assed-guess: does the argument you are passing to DIRECTORY fail > to exist on both machines from the view of the kernel? i.e. from a > shell with globbing, does > > openbsd$ ls -l /usr/local/bin/../lib/maven-core-*.jar > > return no results on all your machines? Actually I tested the ABCL with my desktop after upgrading it to latest snapshot. And ABCL worked just fine on it so the problem seems to exist only on my laptop. I tried the 'ls -l ...' command and my laptop and server both return "no such file or directory". I'll continue to see whats causing the problems on my laptop but it seems to related to some local configuration I have. Though I don't know what it could be. I have .abclrc but it just loads quicklisp. I checked I don't have any quicklisp local-projects (had old cffi version but I deleted it), I removed ~/.cache/common-lisp/* directories. I also upgraded quicklisp and quicklisp dists to latest versions. I don't know what else could affect it on my laptop. Timo From jshrager at stanford.edu Thu May 7 00:53:53 2015 From: jshrager at stanford.edu (Jeff Shrager) Date: Thu, 7 May 2015 00:53:53 +0000 (UTC) Subject: Running embedded ABCL in J on Windows Message-ID: I'm sure that this is a common question, so please feel free to tell me to RTFM as long as you point me to the right place in the M. I have downloaded and can separately run ABCL and J on my Win7 box, but I don't know how to tell J where ABCL is in order to run either the embedded or along-the-side ABCL from J. Can someone tell me how to do this in a Win7 env? Thanks, 'Jeff From evenson at panix.com Thu May 7 07:42:18 2015 From: evenson at panix.com (Mark Evenson) Date: Thu, 07 May 2015 09:42:18 +0200 Subject: Running embedded ABCL in J on Windows In-Reply-To: References: Message-ID: <554B175A.7060001@panix.com> On 5/7/15 02:53, Jeff Shrager wrote: > I'm sure that this is a common question, so please feel free to tell me to RTFM > as long as you point me to the right place in the M. > > I have downloaded and can separately run ABCL and J on my Win7 box, but I don't > know how to tell J where ABCL is in order to run either the embedded or > along-the-side ABCL from J. > > Can someone tell me how to do this in a Win7 env? is a pretty ABCL-specific mailing list, as most of us tend to use SLIME from Emacs to run the implementation. For questions related to use of the J Editor, you might have better luck with [the J Editor mailing lists][1]. [1]: http://sourceforge.net/p/armedbear-j/mailman/ regards, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From Scott at sympoiesis.com Mon May 25 18:38:53 2015 From: Scott at sympoiesis.com (Scott L. Burson) Date: Mon, 25 May 2015 11:38:53 -0700 Subject: (require 'jna) failing in 1.3.2 Message-ID: Hi armed bears, I'm getting a DependencyCollectionException from org.eclipse.aether.internal.impl.DefaultRepositorySystem: "failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0". This is ABCL 1.3.2, JDK 1.8.0_40, on Linux. ... I just tried JDK 1.7.0_71 and 1.6.0_25, and they both fail the same way. Any ideas? -- Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From evenson at panix.com Tue May 26 06:39:41 2015 From: evenson at panix.com (Mark Evenson) Date: Tue, 26 May 2015 08:39:41 +0200 Subject: (require 'jna) failing in 1.3.2 In-Reply-To: References: Message-ID: <1FF1B493-06D4-4D0D-9FB3-BE87B0DA63FE@panix.com> > On 25 May 2015, at 20:38, Scott L. Burson wrote: > > Hi armed bears, > > I'm getting a DependencyCollectionException from org.eclipse.aether.internal.impl.DefaultRepositorySystem: "failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0". This is ABCL 1.3.2, JDK 1.8.0_40, on Linux. > > ... I just tried JDK 1.7.0_71 and 1.6.0_25, and they both fail the same way. > > Any ideas? I believe you are using a version of Maven that is currently incompatible with ABCL. You may check the version of Maven that ABCL is using by inspecting the values of ABCL-ASDF:ENSURE-MVN-VERSION. As noted in ticket [#390][], usage with Maven versions greater that 3.2.3 is not currently working. Maven Aether doesn?t seem to have a stable API to code against or perhaps we just don?t understand it well enough, so even supposedly minor changes like from 3.2.3 to 3.2.5 break our usage. We thought we had coded around the latest change to the Maven Aether contract, but it turns out post Maven 3.2.3, ABCL can only load Maven dependencies that have already been cached locally. Current workarounds: 1) Use [maven-3.2.3][] 2) Install the necessary dependencies [locally via the mvn commandline][1] mvn dependency:get -Dartifact=net.java.dev.jna:jna:4.1.0:jar [#390]: http://abcl.org/trac/ticket/390 [maven-3.2.3]: https://archive.apache.org/dist/maven/maven-3/3.2.3/binaries/ [1]: http://stackoverflow.com/questions/1895492/how-can-i-download-a-specific-maven-artifact-in-one-command-line From Scott at sympoiesis.com Tue May 26 19:54:20 2015 From: Scott at sympoiesis.com (Scott L. Burson) Date: Tue, 26 May 2015 12:54:20 -0700 Subject: (require 'jna) failing in 1.3.2 In-Reply-To: <1FF1B493-06D4-4D0D-9FB3-BE87B0DA63FE@panix.com> References: <1FF1B493-06D4-4D0D-9FB3-BE87B0DA63FE@panix.com> Message-ID: I downgraded Maven to 3.2.3, and that works. Thanks!! (I hardly know anything about Maven; I installed it only to build something.) -- Scott On Mon, May 25, 2015 at 11:39 PM, Mark Evenson wrote: > > > On 25 May 2015, at 20:38, Scott L. Burson wrote: > > > > Hi armed bears, > > > > I'm getting a DependencyCollectionException from > org.eclipse.aether.internal.impl.DefaultRepositorySystem: "failed to read > artifact descriptor for net.java.dev.jna:jna:jar:4.1.0". This is ABCL > 1.3.2, JDK 1.8.0_40, on Linux. > > > > ... I just tried JDK 1.7.0_71 and 1.6.0_25, and they both fail the same > way. > > > > Any ideas? > > I believe you are using a version of Maven that is currently incompatible > with > ABCL. You may check the version of Maven that ABCL is using by inspecting > the > values of ABCL-ASDF:ENSURE-MVN-VERSION. > > As noted in ticket [#390][], usage with Maven versions greater that 3.2.3 > is > not currently working. Maven Aether doesn?t seem to have a stable API to > code > against or perhaps we just don?t understand it well enough, so even > supposedly > minor changes like from 3.2.3 to 3.2.5 break our usage. We thought we had > coded around the latest change to the Maven Aether contract, but it turns > out > post Maven 3.2.3, ABCL can only load Maven dependencies that have already > been > cached locally. > > Current workarounds: > > 1) Use [maven-3.2.3][] > > 2) Install the necessary dependencies [locally via the mvn commandline][1] > > mvn dependency:get -Dartifact=net.java.dev.jna:jna:4.1.0:jar > > > [#390]: http://abcl.org/trac/ticket/390 > > [maven-3.2.3]: > https://archive.apache.org/dist/maven/maven-3/3.2.3/binaries/ > > [1]: > http://stackoverflow.com/questions/1895492/how-can-i-download-a-specific-maven-artifact-in-one-command-line -------------- next part -------------- An HTML attachment was scrubbed... URL: