From christian.lynbech at tietoenator.com Mon Nov 5 11:34:58 2007 From: christian.lynbech at tietoenator.com (Lynbech Christian) Date: Mon, 05 Nov 2007 12:34:58 +0100 Subject: [fetter-devel] small bug in gccxml handling Message-ID: As far as I can tell, the check on gccxml version fails to take the registered path to gccxml into account. The attached patch attempts to fix that. -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 1140 bytes Desc: not available URL: -------------- next part -------------- ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic at hal.com (Michael A. Petonic) From attila.lendvai at gmail.com Tue Nov 6 08:23:51 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 6 Nov 2007 09:23:51 +0100 Subject: [fetter-devel] small bug in gccxml handling In-Reply-To: References: Message-ID: > As far as I can tell, the check on gccxml version fails to take the > registered path to gccxml into account. The attached patch attempts to > fix that. pushed, thanks! -- attila From attila.lendvai at gmail.com Mon Nov 12 09:16:58 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 12 Nov 2007 10:16:58 +0100 Subject: [fetter-devel] gccxml-config and virtual-funcall on the mac In-Reply-To: <192b23510710282108n73b5dfb7r476a462aefcb543e@mail.gmail.com> References: <192b23510710282108n73b5dfb7r476a462aefcb543e@mail.gmail.com> Message-ID: > My current environment is SBCL, OS X, x86, gcc; with gccxml 0.7.0, cffi > 0.9.2, and the darcs head revision of verrazano as of a couple of days ago. i've only used it with gccxml cvs HEAD, no idea about other versions. > 2. The next thing I noticed was that my test bindings would not load without > errors. The problem was in the use of VIRTUAL-FUNCALL. It seems that CFFI > has changed FOREIGN-FUNCALL and added FOREIGN-FUNCALL-POINTER. After a > little reading of the CFFI source, I came up with the following -- which > seems to work but is by no means well-tested or well-understood: > > > (defmacro virtual-funcall (pobj indx coff &body body) > `(foreign-funcall-pointer (vtable-lookup ,pobj ,indx ,coff) nil , at body)) the virtual funcall stuff is bitrotten (it was written back when even CFFI had a different interface) and was only a proof of concept even at its shiny days. the problem is that the vtable stuff is potentially different for each compiler kind and version. therefore it's kinda pointless to try creating an abstraction layer in verrazano. what should be done (imho) is to create some code in verrazano that can automatically generate C wrapper code around the needed C++ interfaces, then compile that and use it as a plain C lib. cffi-grovel should be studied to avoid code duplication. see the mail archives for details, there was a discussion about it recently. i think we should even drop verrazano-runtime that only exists for the vtable stuff. what do you think? if noone speaks up for long enough i'll have it on my todo and do it eventually. hth, -- attila From attila.lendvai at gmail.com Fri Nov 23 15:18:17 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 23 Nov 2007 16:18:17 +0100 Subject: [fetter-devel] Fwd: flexml: a new document model i'm playing with In-Reply-To: References: Message-ID: (i've sent this to cxml-devel, but it opens a door to a possible refactor of verrazano using method dispatch instead of fighting with sxml) hi! i've playing with an document builder that may be interesting for the list. the basic idea is to parse the xml into CLOS objects with their own class, so that method dispatch can be used to process the document. i need this for verrazano, to process the gccxml output. the first part of the file contains the generic flexml document builder and at the end there's some specialized code for gccxml. how it works: you can give it a default lisp package and also register namespace-uri->lisp-package mappings. when a node is encountered then a symbol is looked up in the appropriate package and make-instance is used to make the node. there's also a slot-missing specialization on it, so that it can store random slots (attributes) in a hashtable. features currently: - can resolve crossreferences, see cross-referenced-node slot type and friends - handles some slot types specially: cross-referenced-node, cross-referenced-nodes, integer, boolean, etc - can store attributes in a mixed slot/hashtable mode where simple attributes can go into the hashtable and special ones can be full-featured slots the code for now is only a proof of concept, but i wonder if there would be a place for it somewhere in a repo around cxml? it won't be bigger then a few pages so i think the most practical distribution would be to have its own .asd/package in the cxml repo/directory. but i don't want to run ahead... it even could be that i'm doing duplicate work with this. opinions? -- attila -------------- next part -------------- A non-text attachment was scrubbed... Name: xml-parsing.lisp Type: application/octet-stream Size: 10477 bytes Desc: not available URL: From attila.lendvai at gmail.com Fri Nov 23 15:20:43 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 23 Nov 2007 16:20:43 +0100 Subject: [fetter-devel] Re: flexml: a new document model i'm playing with In-Reply-To: References: Message-ID: hm, if someone wants to actually try this then it's also needed: (defpackage :gccxml (:export ;; classes #:node #:node-with-type #:externable-node #:gcc_xml #:namespace #:variable #:function #:argument #:ellipsis #:enumeration #:enumvalue #:struct #:union #:typedef #:fundamentaltype #:pointertype #:arraytype #:functiontype #:cvqualifiedtype #:referencetype #:field #:constructor #:file ;; slots #:members #:type #:returns #:file #:line #:extern #:context )) -- attila