Commit 0030b89b2eb24b0b63b5f1ca4d4c9a7644eea02d breaks the maven JNA resolution:
(sly@cyruss-mbp):~/src/abcl$ ./abcl Armed Bear Common Lisp 1.4.0-dev Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.351 seconds. Startup completed in 1.786 seconds. Loading /Users/sly/.abclrc completed in 9.51 seconds. Type ":help" for a list of available commands. CL-USER(1): (require 'abcl-contrib) Using probed value of abcl-contrib: '/Users/sly/src/abcl/dist/abcl-contrib.jar'. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. ("ABCL-CONTRIB") CL-USER(2): (require 'jna) ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 (/Users/sly/.m2/repository/net/java/dev/jna/jna/4.1.0/jna-4.1.0.pom) @ central (http://repo1.maven.org/maven2/, releases+snapshots) jnaASDF could not load because Java exception 'java.lang.NullPointerException'.. #<THREAD "interpreter" {4323B3D5}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.NullPointerException'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: TOP-LEVEL Return to top level. [1] CL-USER(3):
[1] CL-USER(4): :bt
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<JAVA-EXCEPTION java.lang.NullPointerException {1DA02950}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Java$pf_jnew.execute(Java.java:581) 4: org.armedbear.lisp.Primitive.execute(Primitive.java:135) 5: (JNEW #<java class org.eclipse.aether.resolution.DependencyRequest> #<org.eclipse.aether.graph.DefaultDependencyNode net.java.dev.jna:jna:jar:4.1.0 (.... {60206C1}> #<null {6F096BFB}>) 6: (ABCL-ASDF:RESOLVE-DEPENDENCIES "net.java.dev.jna" "jna" "4.1.0") 7: (#<FUNCTION {28D8442C}> (#<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">))
Any clues?
thanks,
Cyrus
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 17 Apr 2014, at 19:46, Cyrus Harmon ch-lisp@bobobeach.com wrote:
Commit 0030b89b2eb24b0b63b5f1ca4d4c9a7644eea02d breaks the maven JNA resolution:
(sly@cyruss-mbp):~/src/abcl$ ./abcl Armed Bear Common Lisp 1.4.0-dev Java 1.7.0_51 Oracle Corporation
Is this still broken in the latest builds for you?
If so, lets file a [ticket](http://abcl.org/trac/ticket).
Why do we have?
(wild-pathname-p #P"*-blah") -> T (wild-pathname-p #P"*-blah" :name) -> NIL
This is inconsistent (and non-conforming). Actually wild-pathname-p returns NIL for all fields:
(mapcar (lambda (field) (wild-pathname-p #P"*-blah" field)) (list :host :device :directory :name :type :version))' --> (NIL NIL NIL NIL NIL NIL)
If that was true, then (wild-pathname-p #P"*-blah" nil) should return NIL, not true.
If field-key is not supplied or nil, wild-pathname-p returns true if pathname has any wildcard components, nil if pathname has none. If field-key is non-nil, wild-pathname-p returns true if the indicated component of pathname is a wildcard, nil if the component is not a wildcard.
So we should have:
(defun wild-pathname-p (path &optional field-key) (if (null field-key) (some (lambda (field-key) (wild-pathname-p path field-key)) '(:host :device :directory :name :type :version)) …))
(This bug is found in 1.0.1 and 1.3.1).
[pjb@kuiper :0.0 languages]$ abcl --noinit Armed Bear Common Lisp 1.3.1 Java 1.7.0_25 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.326 seconds. Startup completed in 2.088 seconds. Type ":help" for a list of available commands. CL-USER(1): (mapcar (lambda (field) (wild-pathname-p #P"*-blah" field)) (list :host :device :directory :name :type :version nil)) (NIL NIL NIL NIL NIL NIL T) CL-USER(2): (quit) [pjb@kuiper :0.0 languages]$
On 24 Sep 2014, at 06:05, Pascal J. Bourguignon pjb@informatimago.com wrote:
Why do we have?
(wild-pathname-p #P"*-blah") -> T (wild-pathname-p #P"*-blah" :name) -> NIL
This is inconsistent (and non-conforming).
[…]
Indeed problematic; filed as [ticket #371][1].
The [implementation of CL:WILD-PATHNAME-P turns out to be in Java][2] so fixing this bug should be the fairly easy task of cleaning up the logic in pf_wild_pathname_p().
Thanks for the detailed report.
[1]: http://abcl.org/trac/ticket/371 [2]: http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/Pathname.java...
On 24 September 2014 08:59, Mark Evenson evenson@panix.com wrote:
On 24 Sep 2014, at 06:05, Pascal J. Bourguignon pjb@informatimago.com wrote:
Why do we have?
(wild-pathname-p #P"*-blah") -> T (wild-pathname-p #P"*-blah" :name) -> NIL
This is inconsistent (and non-conforming).
[…]
Indeed problematic; filed as [ticket #371][1].
The [implementation of CL:WILD-PATHNAME-P turns out to be in Java][2] so fixing this bug should be the fairly easy task of cleaning up the logic in pf_wild_pathname_p().
Thanks for the detailed report.
Looking at the java code, it seems a bit naive/lazy. The memq for the directory does catch directories like foo/bar/*/baz (which _are_ wild), but it also seemingly catches other cases like foo/bar/baz*baz/otherstuff. I'm not convinced this is non-conforming, though, since implementations are allowed to support implementation-dependent strings that contain wildcard characters, which is what we do.
Having said that, in such cases I usually prefer doing what sbcl does, as far as possible. :)
From SRS0=ak0sLa/f=EO=lrde.epita.fr=didier@common-lisp.net Wed Apr 01 09:45:10 2015 Received: from smtp.lrde.epita.fr ([163.5.55.2] helo=kaboul.lrde.epita.fr) by common-lisp.net with esmtp (Exim 4.80) (envelope-from didier@lrde.epita.fr) id 1YdFCr-0004pR-VZ for armedbear-devel@common-lisp.net; Wed, 01 Apr 2015 09:45:10 +0000 Received: from scofield.lrde.epita.fr.lrde.epita.fr (scofield.lrde.epita.fr [192.168.101.167]) by kaboul.lrde.epita.fr (Postfix) with ESMTPS id 064B046510 for armedbear-devel@common-lisp.net; Wed, 1 Apr 2015 11:45:00 +0200 (CEST) Sender: didier@lrde.epita.fr From: Didier Verna didier@lrde.epita.fr To: armedbear-devel@common-lisp.net Date: Wed, 01 Apr 2015 11:16:16 +0200 Message-ID: m1pp7oqkdb.fsf@lrde.epita.fr User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEW2Px9vPDa9S0vw5dTO pa7QhFIxHiGNJhTBjISNWmLbCJ0yAAACQklEQVQ4jW2TTYvbMBCGVdOgs7IlaW/KQGp6VqC9lqiQ Y3ExpEdTkLc3OQfP9thNAs7R2bK1/m1HH0522eoSM4/emXlHE6Z199/DLnG3VpvhCRg/7hSdzUvw ZqsJrF6At2W5XatP6lg+B1UBUJR7tSqWz8DvM7Aly76p9XESJQcdgDvnTGb8tVpvyijRmrlTd3Jn jnPLJgf9pYCtv++Bc71Af3ZQdseCujiMwGEE3OYZEKVEAfRiHsDCGP9jB52AqDxoZsZE0vwZQVCE uKkRWzOCSogR+I9GJNCLAFpjbkN3F8UjgXkzT5KaLnigPOiFJZBqmJkhGysCfS/6Kc5qUwmPoDL6 Mz2BN/hOTKlPE8/d+6pfqwD6ftb4mlU0svipV2sVUlViGtsJBuGX1kHRPwoHeRiK92cnCx1SDX9x 9wE495Lajwq++7hi513egGQhV5ihhH0EdscAJKZj6cpDAkiPIDkLIsyR8RGQAIDbCDK0ryJwOyyK DBhjvj7y2jaxhsswkzJLmcg/JjAULQLYeD+YHBWS5XDJ5CdWJTBYucto3Thyr0DTpOJDl4faPo7e e3MTgRuAe4exX9qLUeHcsSwubflXHBWn7r6YSIssNFXX7Qhcdw+hL4y5xKXGCGLD9bV4d5QTyWSy iM2PJyCTQdC29IpJcRrozy25BOtrU2m8GiRA93lqahxiUHxlMmfeRHCuroqCSWbj/tQoIjh13f5W Rhe0c+2srRJwDx+XlCqLI6eFv4lgUGq6hNBsE5Y3xtU/ACuSOWasJ7wAAAAASUVORK5CYIIX-Attribution: dvl X-Url: http://www.lrde.epita.fr/~didier X-Web: http://www.lrde.epita.fr/~didier X-Home-Page: http://www.lrde.epita.fr/~didier Mail-Copies-To: never MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 163.5.55.2 X-SA-Exim-Mail-From: didier@lrde.epita.fr X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lisp.not.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests�YES_00,SPF_PASS, T_RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.0 Subject: [CfPart] ELS 2015, April 20-21 2015, London X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on common-lisp.net) X-SRS: Sender address rewritten from didier@lrde.epita.fr to SRS0=ak0sLa/f=EO=lrde.epita.fr=didier@common-lisp.net by common-lisp.net. X-BeenThere: armedbear-devel@common-lisp.net X-Mailman-Version: 2.1.15 Precedence: list List-Id: <armedbear-devel.common-lisp.net> List-Unsubscribe: https://mailman.common-lisp.net/options/armedbear-devel, mailto:armedbear-devel-request@common-lisp.net?subject=unsubscribe List-Archive: https://mailman.common-lisp.net/pipermail/armedbear-devel/ List-Post: mailto:armedbear-devel@common-lisp.net List-Help: mailto:armedbear-devel-request@common-lisp.net?subject=help List-Subscribe: https://mailman.common-lisp.net/listinfo/armedbear-devel, mailto:armedbear-devel-request@common-lisp.net?subject=subscribe X-List-Received-Date: Wed, 01 Apr 2015 09:45:10 -0000
ELS'15 - 8th European Lisp Symposium Goldsmiths College, London, UK
April 20-21, 2015
http://www.european-lisp-symposium.org/
Sponsored by EPITA, Goldsmiths University of London, Franz Inc., Lispworks Ltd., Clozure Associates and Google
Recent news:
- A few seats left, still time to register! - Programme now online (schedule may still change a little) - Invited speakers announced: Zach Beane, Bodil Stokke, Martin Cracauer
The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate.
The 8th European Lisp Symposium features 3 invited talks, one tutorial, 4 technical sessions and 2 lightning talks slots. The full programme is now available on the website: http://www.european-lisp-symposium.org/.
Programme chair: Julian Padget, University of Bath, UK
Local chair: Christophe Rhodes, Goldsmiths, University of London, UK
Programme committee: Sacha Chua — Toronto, Canada Edmund Weitz — University of Applied Scicences, Hamburg, Germany Rainer Joswig — Hamburg, Germany Henry Lieberman — MIT, USA Matthew Flatt — University of Utah, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Giuseppe Attardi — University of Pisa, Italy Marc Feeley — University of Montreal, Canada Stephen Eglen — University of Cambridge, UK Robert Strandh — University of Bordeaux, France Nick Levine — RavenPack, Spain
Search Keywords:
#els2015, ELS 2015, ELS '15, European Lisp Symposium 2015, European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium, European Lisp Conference 2015, European Lisp Conference '15
On 24 Sep 2014, at 08:13, Ville Voutilainen ville.voutilainen@gmail.com wrote:
On 24 September 2014 08:59, Mark Evenson evenson@panix.com wrote:
On 24 Sep 2014, at 06:05, Pascal J. Bourguignon pjb@informatimago.com wrote:
Why do we have?
(wild-pathname-p #P"*-blah") -> T (wild-pathname-p #P"*-blah" :name) -> NIL
This is inconsistent (and non-conforming).
Looking at the java code, it seems a bit naive/lazy. The memq for the directory does catch directories like foo/bar/*/baz (which _are_ wild), but it also seemingly catches other cases like foo/bar/baz*baz/otherstuff. I'm not convinced this is non-conforming, though, since implementations are allowed to support implementation-dependent strings that contain wildcard characters, which is what we do.
Having said that, in such cases I usually prefer doing what sbcl does, as far as possible. :)
I’m not sure this is advisable with respect to pathnames. sbcl is strongly influenced by cmucl, and cmucl is not the best implementation about pathnames, IMO.
That said, the wild-pathname-p implementation should rather be consensual, CLHS doesn’t seem to leave much to implementation choice in it.
Only, it shall depend on how the implementation supports wild components.
For logical pathnames, there are :wild components and wildcard-word (or also wild-inferior-words for directories) components (they must be both supported).
For physical pathnames, only :wild or :wild-inferiors components must be supported, but of course, it is highly advisable to document and support wildcards in physical components too.
And since we also want to support POSIX paths as physical pathnames, which may contain any sequence of byte, we want to distinguish physical pathname syntax, from plain POSIX paths. (Let’s also keep in mind that POSIX paths may contain any control character and any sequence of byte that is *invalid* UTF-8 (apart from 0)).
I’m reminding all this, because foo/bar/baz*baz/otherstuff is ambiguous: - it may be a physical pathname syntax with a wildcard-word component using a syntax similar to logical pathnames, ( #P"foo/bar/baz*baz/otherstuff” ), or - it may be a native pathname string representation of the POSIX path #(102 111 111 47 98 97 114 47 98 97 122 42 98 97 122 47 111 116 104 101 114 115 116 117 102 102).
In the first case, it’d be a wild-pathname, in the later case, it wouldn’t be.
— __Pascal Bourguignon__
armedbear-devel@common-lisp.net
-
Cyrus Harmon -
Mark Evenson -
Pascal J. Bourguignon -
Ville Voutilainen