- cxml-devel - mailman3.common-lisp.net

[cxml-devel] cxml:doctype function
by Nunez Steve 20 Jun '09

20 Jun '09

Greetings All, Does anyone have an example of using the cxml:doctype function? The code indicates that the last argument is of type puri:uri, which I think I have in the following: (cxml:doctype "suite" "suite" (puri:uri "http://testng.org/testng-1.0.dtd")) however any use of this generates an error in CCL: value #http://testng.org/testng-1.0.dtd> is not of the expected type SEQUENCE. I'm using slime, but not sure if this is related. The same error occurs at the command line. Unfortunately, the documentation for puri seems to have moved, so beyond looking at the code (that I'm unfamiliar with), the best I can do is guess. I know this function is relatively new, so am wondering if it's been widely tested. Are there any alternatives to writing a XML doctype? I need to write quite a few, sometimes large, XML test suites for testng. Cheers, - SteveN

2 5

[cxml-devel] [ELS 2009] Call for participation
by Marco Antoniotti 20 May '09

20 May '09

Apologies for multiple postings.... ************************************************************************ 2nd European Lisp Symposium (ELS 2009) Milan, Italy, May 27-29, 2009 Universita` degli Studi di Milano-Bicocca www.european-lisp-symposium.org ************************************************************************ CALL FOR PARTICIPATION ********************** REGISTRATION IS OPEN AT www.european-lisp-symposium.org. Check out the updated program. Scope and Program Highlights: ***************************** The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2009 program includes presentations of high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. The European Lisp Symposium will feature the following highlights: - Scott McKay of ITA Software will talk about how Lisp use has evolved in his circannual industry work. - Mark Tarver of Lambda Associates will talk about Qi as a viral mutation of the Lisp DNA. - Mauro Pezze` of University of Milan-Bicocca will host a panel on Programmers' Productivity from a Software Engineering point of view. - Joao Pavao Martins and Ernesto Morgado of SISCOG will talk about the role of LISP in the success of SISCOG - Christophe Rhodes will give an unportable tutorial. - Michele Simionato will give a tutorial on Scheme module system and Scheme libraries portability issues across implementations. Social Events: ************** Friday 29th evening, Conference Banquet Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in the center of Milan; 2009 marks the 100th anniversary of the Futurism Manifesto; stretching it, the harbinger of Lisp 50 years later. Program Chair: ************** * Antonio Leitao, Technical University of Lisbon, Portugal Local Chair: ************ * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy Program committee: ****************** * Giuseppe Attardi, Universita` di Pisa , Italy * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Irene Durand, Universite` Bordeaux 1, France * Marc Feeley, Universite` de Montreal, Canada * Ron Garret, Amalgamated Widgets Unlimited, USA * Gregor Kiczales, University of British Columbia, Canada * Scott McKay, ITA Software, Inc., USA * Peter Norvig, Google Inc., USA * Julian Padget, University of Bath, UK * Kent Pitman, HyperMeta, USA * Christian Queinnec, Universite` Pierre et Marie Curie, France * Christophe Rhodes, Goldsmiths College, University of London, UK * Robert Strandh, Universite` Bordeaux 1, France * Mark Tarver, Lambda Associates, UK * Didier Verna, EPITA Research and Development Laboratory, France * JonL White, TheGingerIceCreamFactory of Palo Alto, USA * Taiichi Yuasa, Kyoto University, Japan Registration Fees: ****************** * Students EU100, regular EU220. Registration will include the proceedings, coffee breaks, the symposium dinner and other amenities. Accommodation is not included.

1 0

[cxml-devel] ELS 2009 in Milan, Italy: Call for Participation
by Marco Antoniotti 15 Apr '09

15 Apr '09

Apologies for multiple postings.... ************************************************************************ 2nd European Lisp Symposium (ELS 2009) Milan, Italy, May 27-29, 2009 Universita` degli Studi di Milano-Bicocca www.european-lisp-symposium.org ************************************************************************ CALL FOR PARTECIPATION ********************** REGISTRATION IS NOW OPEN AT www.european-lisp-symposium.org. Take advantage of the early bird registration fee. Scope and Program Highlights: ***************************** The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2009 program includes presentations of high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. Kent Pitman will give the keynote address on Thursday, May 28. The presentations will be divided into two categories. * Original contributions. * Work in progress describing ongoing work that will be discussed in the form of a "writers' workshop". The writers' workshops will take place at the symposium in Milan on May 28, 2008. Social Events: ************** Friday 29th evening, Conference Banquet Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in the center of Milan; 2009 marks the 100th anniversary of the Futurism Manifesto; stretching it, the harbinger of Lisp 50 years later. Program Chair: ************** * Antonio Leitao, Technical University of Lisbon, Portugal Local Chair: ************ * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy Program committee: ****************** * Giuseppe Attardi, Universita`† di Pisa , Italy * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Irene Durand, Universite` Bordeaux 1, France * Marc Feeley, Universit` de Montreal, Canada * Ron Garret, Amalgamated Widgets Unlimited, USA * Gregor Kiczales, University of British Columbia, Canada * Scott McKay, ITA Software, Inc., USA * Peter Norvig, Google Inc., USA * Julian Padget, University of Bath, UK * Kent Pitman, PTC, USA * Christian Queinnec, Universite` Pierre et Marie Curie, France * Christophe Rhodes, Goldsmiths College, University of London, UK * Robert Strandh, Universite` Bordeaux 1, France * Mark Tarver, Lambda Associates, UK * Didier Verna, EPITA Research and Development Laboratory, France * JonL White, TheGingerIceCreamFactory of Palo Alto, USA * Taiichi Yuasa, Kyoto University, Japan Registration Fees: ****************** * Early registration before April 25, 2008: Students EU60, regular EU120. * Late registration before May 16, 2008: Students EU80, regular EU160. * Onsite registration: Students EU100, regular EU220. Registration will include the proceedings, coffee breaks, the symposium dinner and other amenities. Accommodation is not included.

1 0

[cxml-devel] Clozure Unicode v.s. cxml-rng
by Ben Hyde 15 Apr '09

15 Apr '09

In clozure code-char returns nil for two ranges: (loop with in = t for i below 1114110 as c = (code-char i) do (cond ((and in (not c)) (setf in nil) (format t "~&gap: #x~X" i)) ((and (not in) c) (setf in t) (format t " .. #x~X" (1- i) )))) gap: #xD800 .. #xDFFF gap: #xFFFE .. #xFFFF NIL Searching on phrases like: "Range: D800–DBFF. The High Surrogate Area does not contain any character" "the value FFFE ! is guaranteed not to be a. Unicode character at all" will throw some additional light on that, and it seems related to this discussion: <http://thread.gmane.org/gmane.lisp.babel.devel/15> These cause the file unicode.lisp in cxml-rng to error when compiling. The following let's it compile; but I doubt this is how anybody who knew what this code was doing would recommend doing this. It reorders the system's components, so I have the range functions from clex available. It then modifies massage-ranges to cut out these gaps from any ranges which pass thru. But my interest is limited to getting the file to compile so my current project, which doesn't need cxml-rng, can get back on track as I experiment with ccl. So I'll admit I haven't tried testing this patch at all. - ben bash-3.2$ git diff diff --git a/cxml-rng.asd b/cxml-rng.asd index e64adff..64582ca 100644 --- a/cxml-rng.asd +++ b/cxml-rng.asd @@ -17,12 +17,12 @@ :components ((:file "package") (:file "floats") + (:file "clex") (:file "unicode") (:file "nppcre") (:file "types") (:file "parse") (:file "validate") (:file "test") - (:file "clex") (:file "compact")) :depends-on (:cxml :cl-ppcre :yacc :parse-number :cl-base64)) diff --git a/unicode.lisp b/unicode.lisp index 42b686a..c5ea17f 100644 --- a/unicode.lisp +++ b/unicode.lisp @@ -57,6 +57,8 @@ `(defranges ,name ',ranges))) (defun massage-ranges (l) + #+ccl (setf l (cxml-clex::ranges- l '((#xd800 #xDFFF) + (#xFFFE #x10000)))) (mapcan (lambda (x) (let ((a (code-char (car x))) (b (code-char (cadr x)))) bash-3.2$

1 0

[cxml-devel] testsuite build fails
by Marco Antoniotti 27 Jan '09

27 Jan '09

Hi this is not CXML per se, but I get the following error while building the test suite. I think it is on the dom2-dtd. Do you have any idea about it? Cheers -- Marco Antoniotti dom2-interfaces: [style] Warning: the task name <style> is deprecated. Use <xslt> instead. [style] Processing /Users/marcoxa/Projects/Lang/CL/cxml/2001/DOM- Test-Suite/lib/specs/Level-2/xml/core/dom-spec.xml to /Users/marcoxa/ Projects/Lang/CL/cxml/2001/DOM-Test-Suite/build/dom2-interfaces.xml [style] Loading stylesheet /Users/marcoxa/Projects/Lang/CL/cxml/ 2001/DOM-Test-Suite/transforms/dom2-combine.xsl [style] : Error! file:/Users/marcoxa/Projects/Lang/CL/cxml/2001/ DOM-Test-Suite/transforms/dom2-combine.xsl: line 137: Attribute 'name' outside of element. [xmlvalidate] /Users/marcoxa/Projects/Lang/CL/cxml/2001/DOM-Test-Suite/ build/dom2-interfaces.xml:417:109: The prefix "xml" cannot be bound to any namespace other than its usual namespace; neither can the namespace for "xml" be bound to any prefix other than "xml". BUILD FAILED /Users/marcoxa/Projects/Lang/CL/cxml/2001/DOM-Test-Suite/build.xml: 1456: Could not validate document /Users/marcoxa/Projects/Lang/CL/cxml/ 2001/DOM-Test-Suite/build/dom2-interfaces.xml

2 1

[cxml-devel] Fwd: [Openmcl-devel] (setf (find-class ...) ...) problem
by Cyrus Harmon 01 Dec '08

01 Dec '08

Pascal's reading of the spec would seem to say that cxml-stp needs an explicit deftype. Thoughts? thanks, cyrus Begin forwarded message: > From: Pascal Costanza <pc(a)p-cos.net> > Date: December 1, 2008 12:20:55 AM PST > To: Cyrus Harmon <ch-openmcl(a)bobobeach.com> > Cc: openmcl-devel Devel <openmcl-devel(a)clozure.com> > Subject: Re: [Openmcl-devel] (setf (find-class ...) ...) problem > > Hi there, > > Section 4.3.1 defines what a proper name of a class is. The > restriction is there because otherwise you could have ambiguities in > the type system. (Two different classes can have the same name, but > only one can have that name as a proper name.) > > > Pascal > > On 1 Dec 2008, at 06:04, Cyrus Harmon wrote: > >> Gary, >> >> Thanks for the thoughtful explanation. Explicitly deftype'ing the >> class first sounds reasonable to me. I've asked the cxml-stp >> developers for their opinion as well. >> >> thanks again, >> >> cyrus >> >> On Nov 30, 2008, at 6:12 PM, Gary Byers wrote: >> >>> >>> >>> On Sun, 30 Nov 2008, Cyrus Harmon wrote: >>> >>>> I'm trying to use david lichteblau's cxml-stp with ccl and am >>>> getting >>>> errors about undefined types. It seems that ccl doesn't like the >>>> following: >>>> >>>> (setf (find-class 'document-type) (find-class 'cxml-stp:document- >>>> type)) >>>> >>> >>> I assume that you mean something like: >>> >>> (defclass fruit () ()) >>> >>> (defclass orange (fruit) ()) >>> >>> (setf (find-class 'tangerine) (find-class 'fruit)) >>> >>> (typep (make-instance 'orange) 'tangerine) complains that TANGERINE >>> isn't a valid type-specifier. >>> >>> My first reaction was to think that that was a bug, but after >>> looking >>> at the spec for a while I haven't yet found anything that confirms >>> that and have found at least one passage that (weakly) contradicts >>> that intuition, but it's a bit unclear. >>> >>> The second paragraph of CLHS 4.3.7 says that "the PROPER name of >>> every class is a valid type specifier.", then discusses the use >>> of class objects as type specifiers and notes TYPE-OF's behavior >>> wrt instances of properly and improperly-named classes. >>> >>> The next paragraph says "Because the names of classes and class >>> objects are type specifiers, they can be used in special form THE >>> and >>> in type declarations." I think that the clearest reading of that is >>> something like "Based on what was established in the preceding >>> paragraph, the PROPER names of classes ... can be used in THE forms >>> and as type specifiers." I'd feel better about making that claim >>> if the language in the third paragraph was a little stronger, but I >>> find it hard to parse the "because" qualifier as referring to >>> anything >>> but what's established in the preceding paragraph. >>> >>> I couldn't find anything else in the spec that was any clearer; the >>> other things that I found referred to things like "symbols naming >>> classes defined by DEFCLASS" and their relation to the type system. >>> (I didn't find anything analogous discussing "symbols established >>> as class names via (SETF FIND-CLASS).") >>> >>> I don't see anything in the spec that says that improper class names >>> -can't- be treated as type specifiers, and it's hard to imagine that >>> anyone's code would break if CCL's (SETF FIND-CLASS) stopped >>> checking >>> for proper-namedness in this case, though it's not quite impossible >>> imagine that. I'm also perfectly willing to believe that there's >>> something else in the spec that's more definitive and that >>> contradicts >>> the interpretation above, but in the absence of that I have to >>> conclude >>> that code that assumes that (SETF (FIND-CLASS a) c) S into a valid >>> type specifier is incorrect (even though it likely "works" in most/ >>> all >>> other implementations.) >>> >>> I think that there actaully are reasons for the spec's (seeming) >>> insistence >>> on only considering properly-named classes to be type specifiers >>> (and >>> that those reasons probably have to do with the compilation model.) >>> I'm >>> not sure that those reasons are fully developed, but I don't think >>> that >>> the spec's distinctions between proper and improper class names are >>> arbitrary and accidental, either. >>> >>> >>> >>> >>> If we all strongly believed that (SETF FIND-CLASS) only made S into >>> a type specifier if S was the class name of C, then a portable way >>> of doing this would be something like: >>> >>> (setf (find-class s) c) >>> (deftype s () 'c) ; whatever the "proper name" of C is >>> >>> CCL actually errs in the expansion of DEFTYPE, because S names a >>> class >>> (even though it doesn't properly name it and even though it's >>> therefore >>> not a type-specifier; it'd be more consistent if the expansion of >>> DEFTYPE >>> did the same kind of check for proper-namedness that (SETF FIND- >>> CLASS) does. >>> >>> It -does- work to do the DEFTYPE first: >>> >>> (deftype tangerine () 'orange) >>> (setf (find-class 'tangerine) (find-class 'orange)) >>> >>> I'm not entirely comfortable in saying that I think that CCL's >>> "right" >>> about this (at least in trying to adhere to the letter of the spec) >>> and >>> that other implementations are all wrong. At the moment, let's just >>> say >>> that I'm not entirely comfortable (though I think that I'd be a >>> little >>> closer to comfort if CCL was more consistent, e.g., if DEFTYPE's >>> expansion >>> only rejected attempts to redefine class-names that the >>> implementation >>> considered to be type specifiers.) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> a similar problem was discussed a while back where this problem >>>> arose >>>> with GSharp, but I'm not sure what the resolution was. Any >>>> suggestions? >>>> >>>> thanks, >>>> >>>> Cyrus >>>> >>>> _______________________________________________ >>>> Openmcl-devel mailing list >>>> Openmcl-devel(a)clozure.com >>>> http://clozure.com/mailman/listinfo/openmcl-devel >>>> >>>> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel(a)clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > -- > Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net > Vrije Universiteit Brussel, Programming Technology Lab > Pleinlaan 2, B-1050 Brussel, Belgium > > > > > > > >

1 0

[cxml-devel] cxml-stp patch for ccl
by Cyrus Harmon 01 Dec '08

01 Dec '08

the following patch allows cxml-stp to compile under ccl: diff --git a/classes.lisp b/classes.lisp index 026cfc3..db70b47 100644 --- a/classes.lisp +++ b/classes.lisp @@ -86,6 +86,9 @@ @see-slot{system-id} @see-slot{public-id} @see-slot{internal-subset}")) +#+ccl +(deftype document-type () 'cxml-stp:document-type) + (setf (find-class 'document-type) (find-class 'cxml-stp:document- type)) (defclass cxml-stp:document (parent-node) () The problem is that (setf (find-class ...) ...) doesn't create the type under ccl. Arguably, this shouldn't be necessary. But, as Gary Byers has pointed out on openmcl-devel, that point is arguable and he makes a decent case as to why this shouldn't work. thoughts? thanks, Cyrus

1 0

[cxml-devel] closure-common fix to work with simple-base-string's
by Attila Lendvai 20 Nov '08

20 Nov '08

dear list, please find a patch attached that fixes a problem that (subtypep 'simple-base-string '(simple-array character (*))) NIL T therefore string-rod needs to make new simple-array's to keep the rest of the codebase happy. -- attila

1 1

[cxml-devel] Problems compiling Xuriella
by Chaitanya Gupta 19 Nov '08

19 Nov '08

Hi, I have encountered a few problems while compiling Xuriella on both Allegro CL and SBCL. On compiling Xuriella on ACL, I get the following warnings: Warning: While compiling these undefined functions were referenced: (SETF XURIELLA::TEMPLATE-MODE) from position 50393 in /home/chaitanya/lisp/libs/site/xuriella/dev/xslt.lisp (SETF XURIELLA::TEMPLATE-BASE-URI) from position 50393 in /home/chaitanya/lisp/libs/site/xuriella/dev/xslt.lisp (SETF XURIELLA::TEMPLATE-STYLESHEET) from position 50393 in /home/chaitanya/lisp/libs/site/xuriella/dev/xslt.lisp (SETF XURIELLA::SINK-ELEMENT-USED-PREFIXES) from position 4861 in /home/chaitanya/lisp/libs/site/xuriella/dev/unparse.lisp (SETF XURIELLA::SINK-ELEMENT-ACTUAL-QNAME) from position 3094 in /home/chaitanya/lisp/libs/site/xuriella/dev/unparse.lisp XURIELLA::*UNPARSE-XML-COUNTER* from position 2860 in /home/chaitanya/lisp/libs/site/xuriella/dev/unparse.lisp, 7305 in /home/chaitanya/lisp/libs/site/xuriella/dev/unparse.lisp, 10553 in /home/chaitanya/lisp/libs/site/xuriella/dev/unparse.lisp, 11725 in /home/chaitanya/lisp/libs/site/xuriella/dev/unparse.lisp The first five warnings (SETF XURIELLA::...) all seem to be related to ACL using defsetf instead of setf functions for structure slots. This has been discussed before on the list too [1]. The last issue (XURIELLA::*UNPARSE-XML-COUNTER*) causes problems on both ACL and SBCL. This, to me, seems because the WITH-PROFILE-COUNTER macro is defined in xslt.lisp whereas it is also used in unparse.lisp, which is loaded before xslt.lisp. Chaitanya 1. http://common-lisp.net/pipermail/cxml-devel/2008-July/000437.html

1 1

[cxml-devel] reading an ignored variable
by Cyrus Harmon 06 Nov '08

06 Nov '08

the following patch fixes a warning about reading an ignored variable. thanks, cyrus diff --git a/xml/xmlns-normalizer.lisp b/xml/xmlns-normalizer.lisp index b4f4444..06f03e2 100644 --- a/xml/xmlns-normalizer.lisp +++ b/xml/xmlns-normalizer.lisp @@ -131,6 +131,5 @@ (sax:start-element (proxy-chained-handler handler) uri lname qname attrs)) (defmethod sax:end-element ((handler namespace-normalizer) uri lname qname) - (declare (ignore qname)) (pop (xmlns-stack handler)) (sax:end-element (proxy-chained-handler handler) (or uri #"") lname qname))

1 0