From jonny at drugphish.ch Sat Oct 1 13:02:25 2005 From: jonny at drugphish.ch (Jonathan Heusser) Date: Sat, 01 Oct 2005 15:02:25 +0200 Subject: [fetter-devel] gccxml version Message-ID: <433E88E1.7060803@drugphish.ch> [since there's no fetter-user yet I'm posting here] Hello, I would love to generate some bindings with verrazano. I've downloaded the cvs version and tried to generate the vfun demo with cmucl, cvs vzn, gccxml 0.6 linux. I've put the gccxml binary in /tmp. /tmp/verrazano$ lisp -load testsuite/vfun/generate.lisp which generates the following error: File-error in function LISP::FD-OPEN: Error opening #p"/tmp/vzntemp.xml", No such file or directory. [Condition of type KERNEL:SIMPLE-FILE-ERROR] Is that because I'm using gccxml 0.6 and not 0.7-cvs? Anyone tried to run vzn with 0.6? Thank you Jonathan Heusser -- From rayiner at gmail.com Sat Oct 1 19:56:06 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 1 Oct 2005 15:56:06 -0400 Subject: [fetter-devel] gccxml version In-Reply-To: <433E88E1.7060803@drugphish.ch> References: <433E88E1.7060803@drugphish.ch> Message-ID: > I would love to generate some bindings with verrazano. I've downloaded > the cvs version and tried to > generate the vfun demo with cmucl, cvs vzn, gccxml 0.6 linux. I've put > the gccxml binary in /tmp. > > /tmp/verrazano$ lisp -load testsuite/vfun/generate.lisp > > which generates the following error: > File-error in function LISP::FD-OPEN: > Error opening #p"/tmp/vzntemp.xml", No such file or directory. > [Condition of type KERNEL:SIMPLE-FILE-ERROR] The tests in the testsuite aren't self-contained. The vfun test depends on having vfun.h and libvfun installed in the global $INCLUDE path. You can do this by running "make install" in the vfun directory, but that'll leave a small header file and library on your system. The easier thing to do is to use one of the other tests, like Cairo or FLTK. Just make sure you have the libraries and header files installed on your system. If you really want to run the vfun test, you can also edit vfun.binding and add "I/tmp/verrazano/testsuite/vfun" as the "flags" argument in the defbinding. Sincerely, Rayiner Hashem > > Is that because I'm using gccxml 0.6 and not 0.7-cvs? Anyone tried to > run vzn with 0.6? > > Thank you > Jonathan Heusser > > -- > > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From rayiner at gmail.com Sun Oct 2 21:20:03 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sun, 2 Oct 2005 17:20:03 -0400 Subject: [fetter-devel] gccxml version In-Reply-To: <433FC6FE.5040007@drugphish.ch> References: <433E88E1.7060803@drugphish.ch> <433FC6FE.5040007@drugphish.ch> Message-ID: > >The tests in the testsuite aren't self-contained. The vfun test > >depends on having > >vfun.h and libvfun installed in the global $INCLUDE path. You can do > >this by running > >"make install" in the vfun directory, but that'll leave a small header > >file and library > >on your system. The easier thing to do is to use one of the other > >tests, like Cairo or FLTK. > >Just make sure you have the libraries and header files installed on > >your system. If you really > >want to run the vfun test, you can also edit vfun.binding and add > >"I/tmp/verrazano/testsuite/vfun" > >as the "flags" argument in the defbinding. > > > > > yes, that's clear. I've installed vfun and now also cairo2-dev > but I keep getting the same error message for both testsuits. That's quite odd. The error message you're getting is the result of Verrazano not being able to run GCC-XML properly. Try this: Go into verrazano/testsuite/cairo/generate.lisp, and add a "t" argument to the end of the call to create-binding (after the :cffi-backend argument). This will enable debug mode (hmm, I should really make that a keyword argument, shouldn't I?) Anyway, try running: "lisp -load testsuite/cairo/generate.lisp" Again. When it fails, you'll have a file called /tmp/vzntemp.cpp. Try running: "gccxml -fxml=/tmp/vzntemp.xml /tmp/vzntemp.cpp" That should fail, and that will give you an idea of what exactly is the problem. Perhaps you don't have write access to /tmp? If that's the case, you can change the "/tmp" in generate.lisp to whatever temporary directory you want to use. On the other hand, if it does work, then there are some deeper problems. I don't think its a GCC-XML version problem, because I use GCC-XML 0.60 to test the Windows port. By the way, what's your system configuration (distro, compiler, etc?) Sincerely, Rayiner Hashem > Thanks > jonathan > > -- > > > > From jonny at drugphish.ch Sun Oct 2 11:39:42 2005 From: jonny at drugphish.ch (Jonathan Heusser) Date: Sun, 02 Oct 2005 13:39:42 +0200 Subject: [fetter-devel] gccxml version In-Reply-To: References: <433E88E1.7060803@drugphish.ch> Message-ID: <433FC6FE.5040007@drugphish.ch> >The tests in the testsuite aren't self-contained. The vfun test >depends on having >vfun.h and libvfun installed in the global $INCLUDE path. You can do >this by running >"make install" in the vfun directory, but that'll leave a small header >file and library >on your system. The easier thing to do is to use one of the other >tests, like Cairo or FLTK. >Just make sure you have the libraries and header files installed on >your system. If you really >want to run the vfun test, you can also edit vfun.binding and add >"I/tmp/verrazano/testsuite/vfun" >as the "flags" argument in the defbinding. > > yes, that's clear. I've installed vfun and now also cairo2-dev but I keep getting the same error message for both testsuits. Maybe it's really a gccxml version problem? Thanks jonathan -- From jonny at drugphish.ch Sun Oct 2 21:53:35 2005 From: jonny at drugphish.ch (Jonathan Heusser) Date: Sun, 02 Oct 2005 23:53:35 +0200 Subject: [fetter-devel] gccxml version In-Reply-To: References: <433E88E1.7060803@drugphish.ch> <433FC6FE.5040007@drugphish.ch> Message-ID: <434056DF.1050306@drugphish.ch> >That's quite odd. The error message you're getting is the result of >Verrazano not being able to run GCC-XML properly. Try this: > > That's was the point. Now I removed gccxml from /tmp and put it in $PATH. It worked. It generated the bindings and I could run the tests, lisp.png! Fantastic! Looks great... Why don't you merge verrazano-support into verrazano? My setup is debian 3.1, cmucl 19a-release-20040728, gccxml 0.6.0. Thank you Jonathan Heusser -- From rayiner at gmail.com Mon Oct 3 00:37:10 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sun, 2 Oct 2005 20:37:10 -0400 Subject: [fetter-devel] gccxml version In-Reply-To: <434056DF.1050306@drugphish.ch> References: <433E88E1.7060803@drugphish.ch> <433FC6FE.5040007@drugphish.ch> <434056DF.1050306@drugphish.ch> Message-ID: Great! Glad to see it worked for you. I've added some error-handling infrastructure to Verrazano now, so instead of a cryptic "file not found" condition, you get a proper error message. One more step towards being less user-hostile :) With regards to merging verrazano-support into verrazano, the original thinking was that verrazano-support, being runtime support, would be needed on any machine using software that uses a verrazano-generated binding, while verrazano itself would only be needed on machines that wished to generate bindings. Kenny has suggested emitting the code in verrazano-support directly into each generated binding, since its so small. That's likely what I'll do. Sincerely, Rayiner Hashem On 10/2/05, Jonathan Heusser wrote: > > >That's quite odd. The error message you're getting is the result of > >Verrazano not being able to run GCC-XML properly. Try this: > > > > > That's was the point. Now I removed gccxml from /tmp and put it in $PATH. > It worked. It generated the bindings and I could run the tests, lisp.png! > Fantastic! Looks great... > Why don't you merge verrazano-support into verrazano? > > My setup is debian 3.1, cmucl 19a-release-20040728, gccxml 0.6.0. > > Thank you > Jonathan Heusser > > -- > > > > From joesb.coe9 at gmail.com Mon Oct 3 15:47:16 2005 From: joesb.coe9 at gmail.com (Pisin Bootvong) Date: Mon, 03 Oct 2005 22:47:16 +0700 Subject: [fetter-devel] "errors.lisp" not found in cvs Message-ID: <43415284.1090000@gmail.com> Hi, I was going to try out Verrazano. But CVS doesn't have a file named error.lisp in frontend directory. It seemed that you forgot to add the file when you have updated the asd file. Keep up the good works, Regards, From rayiner at gmail.com Mon Oct 3 17:56:07 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 3 Oct 2005 13:56:07 -0400 Subject: [fetter-devel] "errors.lisp" not found in cvs In-Reply-To: <43415284.1090000@gmail.com> References: <43415284.1090000@gmail.com> Message-ID: Ack. Good catch! I'll fix that as soon as I get back to my computer. Sincerely, Rayiner Hashem On 10/3/05, Pisin Bootvong wrote: > Hi, > > I was going to try out Verrazano. But CVS doesn't have a file named > error.lisp in frontend directory. > It seemed that you forgot to add the file when you have updated the asd > file. > > Keep up the good works, > > Regards, > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From rayiner at gmail.com Mon Oct 3 18:53:15 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 3 Oct 2005 14:53:15 -0400 Subject: [fetter-devel] "errors.lisp" not found in cvs In-Reply-To: References: <43415284.1090000@gmail.com> Message-ID: Fixed in CVS. Thanks again. Sincerely, Rayiner Hashem On 10/3/05, Rayiner Hashem wrote: > Ack. Good catch! I'll fix that as soon as I get back to my computer. > > Sincerely, > Rayiner Hashem > > On 10/3/05, Pisin Bootvong wrote: > > Hi, > > > > I was going to try out Verrazano. But CVS doesn't have a file named > > error.lisp in frontend directory. > > It seemed that you forgot to add the file when you have updated the asd > > file. > > > > Keep up the good works, > > > > Regards, > > _______________________________________________ > > fetter-devel mailing list > > fetter-devel at common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > > From ktilton at nyc.rr.com Tue Oct 4 05:22:45 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 04 Oct 2005 01:22:45 -0400 Subject: [fetter-devel] VC++ support Message-ID: <434211A5.3030805@nyc.rr.com> What exactly is it going to take to get support for virtual functions under VC++. It turns out my first requirement is to get more access to font info from FTGL, and if Verrazano cannot handle it I will have to keep going with my C glue. Not the end of the world, but if I can help on the VC++ thing that would be a better place to spend my energy. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 From luismbo at gmail.com Tue Oct 4 08:13:40 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Tue, 4 Oct 2005 09:13:40 +0100 Subject: [fetter-devel] VC++ support In-Reply-To: <434211A5.3030805@nyc.rr.com> References: <434211A5.3030805@nyc.rr.com> Message-ID: On 4/out/2005, at 06:22, Kenny Tilton wrote: > What exactly is it going to take to get support for virtual functions > under VC++. It turns out my first requirement is to get more access to > font info from FTGL, and if Verrazano cannot handle it I will have to > keep going with my C glue. Not the end of the world, but if I can help > on the VC++ thing that would be a better place to spend my energy. I know very little about C++ and I don't remember what virtual functions are, but if this is what requires the abbility to funcall foreign pointers, initial support for that is already in CFFI. I just need to add a declarative interface in order to support Lispworks. If this is necessary, I'll put this feature on top of my TODO stack. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From rayiner at gmail.com Tue Oct 4 13:46:06 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 4 Oct 2005 09:46:06 -0400 Subject: [fetter-devel] VC++ support In-Reply-To: <434211A5.3030805@nyc.rr.com> References: <434211A5.3030805@nyc.rr.com> Message-ID: On 10/4/05, Kenny Tilton wrote: > What exactly is it going to take to get support for virtual functions > under VC++. It turns out my first requirement is to get more access to > font info from FTGL, and if Verrazano cannot handle it I will have to > keep going with my C glue. Not the end of the world, but if I can help > on the VC++ thing that would be a better place to spend my energy. I've been reading over the Visual C++ docs, and I think I can probably get something running in a couple of days. The format is slightly simpler than the GCC format. The main holdup right now is that I've got midterms until Thursday, so I'm unable to do much more than fix bugs until then. After that, I've got little work until after Fall break (a week and a half later), so I should be able to spend some time with VZN. Sincerely, Rayiner Hashem > > -- > Kenny > > Why Lisp? http://wiki.alu.org/RtL_Highlight_Film > > "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." > Elwood P. Dowd, "Harvey", 1950 > > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From ktilton at nyc.rr.com Fri Oct 7 04:34:00 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 07 Oct 2005 00:34:00 -0400 Subject: [fetter-devel] Picking up SWIG definitions for different libraries Message-ID: <4345FAB8.5050702@nyc.rr.com> I noticed an announcement for wxCL on c.l.l today. That is a C++ library bound to Lisp the old-fashioned way, with C glue. Quite a large project and obvious effort. My first thought was that vzn seems to obsolete the whole effort. i almost hope not for the sake of the wxCL developer's sanity. My second thought was that we need to pick up SWIG definitions somehow and use those to build binding definitions that capture semantics of parameters, such as a pointer being specifically a pointer to a C-string. Doable? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 From ktilton at nyc.rr.com Fri Oct 7 09:58:28 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 07 Oct 2005 05:58:28 -0400 Subject: [fetter-devel] Possible solution for multiple includes Message-ID: <434646C4.50202@nyc.rr.com> I have joked before about the downside of generating bindings only for symbols mentioned in include files actually listed in a binding definition, as opposed to files reached via nested includes: large libraries customarily break their apis up into multiple includes, so these have to be listed in the binding definition to get bindings generated. I just ran into an egregious case of this as I look to see if vzn can handle wxWidgets: > #include "wx/defs.h" > #include "wx/object.h" > #include "wx/dynarray.h" > #include "wx/list.h" > #include "wx/hash.h" > #include "wx/string.h" > #include "wx/intl.h" > #include "wx/log.h" > #include "wx/event.h" > #include "wx/app.h" > #include "wx/utils.h" > #include "wx/stream.h" > > #if wxUSE_GUI > > #include "wx/window.h" > #include "wx/panel.h" > #include "wx/frame.h" > #include "wx/dc.h" > #include "wx/dcclient.h" > #include "wx/dcmemory.h" > #include "wx/dcprint.h" > #include "wx/dcscreen.h" > #include "wx/button.h" > #include "wx/menu.h" > #include "wx/pen.h" > #include "wx/brush.h" > #include "wx/palette.h" > #include "wx/icon.h" > #include "wx/cursor.h" > #include "wx/dialog.h" > #include "wx/timer.h" > #include "wx/settings.h" > #include "wx/msgdlg.h" > #include "wx/cmndata.h" > > #include "wx/control.h" > #include "wx/ctrlsub.h" > #include "wx/bmpbuttn.h" > #include "wx/checkbox.h" > #include "wx/checklst.h" > #include "wx/choice.h" > #include "wx/scrolbar.h" > #include "wx/stattext.h" > #include "wx/statbmp.h" > #include "wx/statbox.h" > #include "wx/listbox.h" > #include "wx/radiobox.h" > #include "wx/radiobut.h" > #include "wx/textctrl.h" > #include "wx/slider.h" > #include "wx/gauge.h" > #include "wx/scrolwin.h" > #include "wx/dirdlg.h" > #include "wx/toolbar.h" > #include "wx/combobox.h" > #include "wx/layout.h" > #include "wx/sizer.h" > #include "wx/memory.h" > #include "wx/mdi.h" > #include "wx/statusbr.h" > #include "wx/scrolbar.h" > #include "wx/choicdlg.h" > #include "wx/textdlg.h" > #include "wx/filedlg.h" > > #include "wx/validate.h" > > #include "wx/valtext.h" Well, it is not that hard to paste the same list into a binding defintion, but it occurred to me that there is a natural solution to this minor annoyance. What if vzn generated bindings for any include found in the same directory tree as any listed include? There is a gotcha here, perhaps. I gave up fighting VC++ at one point and just copied the headers for a package into /vc++/vc98/include. So one would now be back to pulling in every symbol ala windows.h. But! In this case, the source all includes "wx/wx....h", so I will be creating a "wx" subdirectory under the vc++ include directory, and the scheme I propose would thus work. But! number two is that maybe I gave up too fast on vc++. It does allow specification of other search paths for includes. I tried that without success on something or other, but probably that could have been made to work, and again this scheme would hold up. I have not thought this through exhaustively. Can anyone see an objection? Obviously the big one would be: vzn cannot see the paths! Can it? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 From ktilton at nyc.rr.com Fri Oct 7 14:56:42 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 07 Oct 2005 10:56:42 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> Message-ID: <43468CAA.3080203@nyc.rr.com> Andy Cristina wrote: >On 10/7/05, Kenny Tilton wrote: > > >>I have joked before about the downside of generating bindings only for >>symbols mentioned in include files actually listed in a binding >>definition, as opposed to files reached via nested includes: large >>libraries customarily break their apis up into multiple includes, so >>these have to be listed in the binding definition to get bindings generated. >> >>I just ran into an egregious case of this as I look to see if vzn can >>handle wxWidgets: >> >> >> >> >>Well, it is not that hard to paste the same list into a binding >>defintion, but it occurred to me that there is a natural solution to >>this minor annoyance. What if vzn generated bindings for any include >>found in the same directory tree as any listed include? >> >>There is a gotcha here, perhaps. I gave up fighting VC++ at one point >>and just copied the headers for a package into /vc++/vc98/include. So >>one would now be back to pulling in every symbol ala windows.h. But! In >>this case, the source all includes "wx/wx....h", so I will be creating a >>"wx" subdirectory under the vc++ include directory, and the scheme I >>propose would thus work. >> >>But! number two is that maybe I gave up too fast on vc++. It does allow >>specification of other search paths for includes. I tried that without >>success on something or other, but probably that could have been made to >>work, and again this scheme would hold up. >> >>I have not thought this through exhaustively. Can anyone see an >>objection? Obviously the big one would be: vzn cannot see the paths! Can it? >> >> >> > >Please PLEASE make this an option in the binding if you go this route. > Creating a binding file isn't something you do very often, and I >think spending the time to list every header you want included isn't >that high a cost. Especially if you've commited to a library that >would make you do the same thing in a C program. > No, a C program can include "wx.h". For example, the Life demo in wx includes just wx.h and minifram.h, which latter I guess is an oddball widget that gets left out of wx.h to avoid bloat. So it turns out I am the one arguing for having vzn work the same as a C program, while forcing us to dive into wx.h, pull out its innards, and splat them all over the binding definition is the unreliable, unnatural, and more unwieldy approach. What happens when wx.h changes? With my scheme, one just regenerates the bindings. With yours, we now have to start over and re-rip out the contents of wx.h. Obviously suboptimal. > If it is really a >problem, why not allow something like (include "wx/*.h") ? That way >you don't do something that smells bad just to avoid typing. > No, this is wrong. A wildcard (as you know) picks up every last thing in the directory, whether or not it gets navigated to via nested includes. So this is a "dumb" solution, in that it is not actually driven by the source which specifies exactly what to include. VZN ends up chewing on headers the C compielr would never look at. Ouch. > Or >perhaps we can have a vzn utilities package that can make bindings for >libraries... maybe put a fancy gui on it, point it at a directory, and >it can give you a list control to select which headers to bind. > But an automatic solution is possible and trivial (iff vzn can see paths), so why throw up your hands and force a totally error-prone and tedious manual selection? > I >haven't really thought this out; I have been awake a very short time >and don't really have the ability to hold a thought for more than a >minute or so. > Noted. :) > But the idea of silently including things smells really >bad to me. > "Silently"? That is exactly what every build of a C application does, and it guarantees that the right things get pulled in in the right order. You make it sound bad. What is bad is reaching into the wx internals instead of just listing the same includes a wx app would include in the .c files. kt From acristin at gmail.com Fri Oct 7 14:35:00 2005 From: acristin at gmail.com (Andy Cristina) Date: Fri, 7 Oct 2005 09:35:00 -0500 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <434646C4.50202@nyc.rr.com> References: <434646C4.50202@nyc.rr.com> Message-ID: <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> On 10/7/05, Kenny Tilton wrote: > I have joked before about the downside of generating bindings only for > symbols mentioned in include files actually listed in a binding > definition, as opposed to files reached via nested includes: large > libraries customarily break their apis up into multiple includes, so > these have to be listed in the binding definition to get bindings generated. > > I just ran into an egregious case of this as I look to see if vzn can > handle wxWidgets: > > > > > Well, it is not that hard to paste the same list into a binding > defintion, but it occurred to me that there is a natural solution to > this minor annoyance. What if vzn generated bindings for any include > found in the same directory tree as any listed include? > > There is a gotcha here, perhaps. I gave up fighting VC++ at one point > and just copied the headers for a package into /vc++/vc98/include. So > one would now be back to pulling in every symbol ala windows.h. But! In > this case, the source all includes "wx/wx....h", so I will be creating a > "wx" subdirectory under the vc++ include directory, and the scheme I > propose would thus work. > > But! number two is that maybe I gave up too fast on vc++. It does allow > specification of other search paths for includes. I tried that without > success on something or other, but probably that could have been made to > work, and again this scheme would hold up. > > I have not thought this through exhaustively. Can anyone see an > objection? Obviously the big one would be: vzn cannot see the paths! Can it? > Please PLEASE make this an option in the binding if you go this route. Creating a binding file isn't something you do very often, and I think spending the time to list every header you want included isn't that high a cost. Especially if you've commited to a library that would make you do the same thing in a C program. If it is really a problem, why not allow something like (include "wx/*.h") ? That way you don't do something that smells bad just to avoid typing. Or perhaps we can have a vzn utilities package that can make bindings for libraries... maybe put a fancy gui on it, point it at a directory, and it can give you a list control to select which headers to bind. I haven't really thought this out; I have been awake a very short time and don't really have the ability to hold a thought for more than a minute or so. But the idea of silently including things smells really bad to me. My two cents, Andy From rayiner at gmail.com Sat Oct 8 02:33:40 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Fri, 7 Oct 2005 22:33:40 -0400 Subject: [fetter-devel] Request for comments on new interface Message-ID: The user interface for Verrazano is a bit of a kludge at the moment, and I've been working recently on refactoring the code to both enable a more sensical and straightforward UI, and also to refactor the internals to allow better user control in certain places. This work is a prerequisite for things like Visual C++ support and multiple backend support. Moreover, I consder a rework of the UI to be a prerequisite for a 1.0 release. Right now, what I have is a procedural interface to the generator's internals. What I need is a good way of allowing the user to specify a configuration. The idea is to dump the special .binding file, as Kenny suggested, and go with a set of macros. My first thoughts are to make generate.lisp look like this: (verrazano:defbinding cairo (:name "cairo-library") (:nicknames "cairo") (:include "cairo/cairo.h" "cairo/cairo-pdf.h")) (verrazano:defhost winvc++ (:compiler :vc++) ; or :g++ (:gccxml-path "") (:gccxml-command "gccxml") (:temp-directory "/tmp")) (verrazano:deftarget cffi-lispy (:backend :cffi) (:name-style :lisp-style) ; or :c-style (:search-mode :strict)) ; or :helpful (better name???) (verrazano:create-binding :binding cairo :host winvc++ :target cffi-lispy "testsuite/cairo/cairo-library.lisp") Basically, the specification of the configuration is split up into a binding describing the header files to incorporate, a host describing the host platform, and a target describing what backend to use and what code generation options to enable. Common hosts like "winvc++" or "lingcc" would be built into Verrazano, so you could pass something like "verrazano:winvc++" to CREATE-BINDING, without having to redefine it each time. I'd love to recieve any comments that would help me make this interface better (or suggest to me to scrap it entirely and do something else :) Sincerely, Rayiner Hashem From rayiner at gmail.com Sat Oct 8 02:34:31 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Fri, 7 Oct 2005 22:34:31 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <43468CAA.3080203@nyc.rr.com> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> Message-ID: First, a technical point: yes, VZN can see the full path of each header. Second, the solution is probably fine on Windows, where each library typically has its include files installed to a seperate directory, but is possibly suboptimal on *NIX, where everything is in /usr/include. So for cases like zlib, or libelf (just to name things that I can see in my /usr/include), there does need to be some sort of option to use the strict semantics. However, I don't have a problem making the directory-searching behavior the default. Even on UNIX, most libraries are well-behaved enough to create a subdirectory under /usr/include. Sincerely, Rayiner Hashem On 10/7/05, Kenny Tilton wrote: > > > Andy Cristina wrote: > > >On 10/7/05, Kenny Tilton wrote: > > > > > >>I have joked before about the downside of generating bindings only for > >>symbols mentioned in include files actually listed in a binding > >>definition, as opposed to files reached via nested includes: large > >>libraries customarily break their apis up into multiple includes, so > >>these have to be listed in the binding definition to get bindings generated. > >> > >>I just ran into an egregious case of this as I look to see if vzn can > >>handle wxWidgets: > >> > >> > >> > >> > >>Well, it is not that hard to paste the same list into a binding > >>defintion, but it occurred to me that there is a natural solution to > >>this minor annoyance. What if vzn generated bindings for any include > >>found in the same directory tree as any listed include? > >> > >>There is a gotcha here, perhaps. I gave up fighting VC++ at one point > >>and just copied the headers for a package into /vc++/vc98/include. So > >>one would now be back to pulling in every symbol ala windows.h. But! In > >>this case, the source all includes "wx/wx....h", so I will be creating a > >>"wx" subdirectory under the vc++ include directory, and the scheme I > >>propose would thus work. > >> > >>But! number two is that maybe I gave up too fast on vc++. It does allow > >>specification of other search paths for includes. I tried that without > >>success on something or other, but probably that could have been made to > >>work, and again this scheme would hold up. > >> > >>I have not thought this through exhaustively. Can anyone see an > >>objection? Obviously the big one would be: vzn cannot see the paths! Can it? > >> > >> > >> > > > >Please PLEASE make this an option in the binding if you go this route. > > Creating a binding file isn't something you do very often, and I > >think spending the time to list every header you want included isn't > >that high a cost. Especially if you've commited to a library that > >would make you do the same thing in a C program. > > > No, a C program can include "wx.h". For example, the Life demo in wx > includes just wx.h and minifram.h, which latter I guess is an oddball > widget that gets left out of wx.h to avoid bloat. So it turns out I am > the one arguing for having vzn work the same as a C program, while > forcing us to dive into wx.h, pull out its innards, and splat them all > over the binding definition is the unreliable, unnatural, and more > unwieldy approach. > > What happens when wx.h changes? With my scheme, one just regenerates the > bindings. With yours, we now have to start over and re-rip out the > contents of wx.h. Obviously suboptimal. > > > If it is really a > >problem, why not allow something like (include "wx/*.h") ? That way > >you don't do something that smells bad just to avoid typing. > > > No, this is wrong. A wildcard (as you know) picks up every last thing in > the directory, whether or not it gets navigated to via nested includes. > So this is a "dumb" solution, in that it is not actually driven by the > source which specifies exactly what to include. VZN ends up chewing on > headers the C compielr would never look at. Ouch. > > > Or > >perhaps we can have a vzn utilities package that can make bindings for > >libraries... maybe put a fancy gui on it, point it at a directory, and > >it can give you a list control to select which headers to bind. > > > But an automatic solution is possible and trivial (iff vzn can see > paths), so why throw up your hands and force a totally error-prone and > tedious manual selection? > > > I > >haven't really thought this out; I have been awake a very short time > >and don't really have the ability to hold a thought for more than a > >minute or so. > > > Noted. :) > > > But the idea of silently including things smells really > >bad to me. > > > "Silently"? That is exactly what every build of a C application does, > and it guarantees that the right things get pulled in in the right > order. You make it sound bad. What is bad is reaching into the wx > internals instead of just listing the same includes a wx app would > include in the .c files. > > kt > > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From fgoenninger at prion.de Sat Oct 8 08:48:12 2005 From: fgoenninger at prion.de (Frank Goenninger - PRION Consulting) Date: Sat, 8 Oct 2005 10:48:12 +0200 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: Message-ID: Rayiner, Am 08.10.2005 um 04:33 schrieb Rayiner Hashem: > The user interface for Verrazano is a bit of a kludge at the moment, > and I've been working recently on refactoring the code to both enable > a more sensical and straightforward UI, and also to refactor the > internals to allow better user control in certain places. This work is > a prerequisite for things like Visual C++ support and multiple backend > support. Moreover, I consder a rework of the UI to be a prerequisite > for a 1.0 release. > > Right now, what I have is a procedural interface to the generator's > internals. What I need is a good way of allowing the user to specify a > configuration. The idea is to dump the special .binding file, as Kenny > suggested, and go with a set of macros. My first thoughts are to make > generate.lisp look like this: > > (verrazano:defbinding cairo > (:name "cairo-library") > (:nicknames "cairo") > (:include "cairo/cairo.h" > "cairo/cairo-pdf.h")) > > (verrazano:defhost winvc++ > (:compiler :vc++) ; or :g++ > (:gccxml-path "") > (:gccxml-command "gccxml") > (:temp-directory "/tmp")) > > (verrazano:deftarget cffi-lispy > (:backend :cffi) > (:name-style :lisp-style) ; or :c-style > (:search-mode :strict)) ; or :helpful (better name???) > > (verrazano:create-binding > :binding cairo > :host winvc++ > :target cffi-lispy > "testsuite/cairo/cairo-library.lisp") > > Basically, the specification of the configuration is split up into a > binding describing the header files to incorporate, a host describing > the host platform, and a target describing what backend to use and > what code generation options to enable. Common hosts like "winvc++" or > "lingcc" would be built into Verrazano, so you could pass something > like "verrazano:winvc++" to CREATE-BINDING, without having to redefine > it each time. > > I'd love to recieve any comments that would help me make this > interface better (or suggest to me to scrap it entirely and do > something else :) I actually like it. It's clean and precise IMHO. I often do things this way also: (verrazano:create-binding :binding ((:name "cairo-library") (:nicknames "cairo") (:include "cairo/cairo.h" "cairo/cairo-pdf.h")) :host (( ...))) - you get the idea, I assume. As this should be supported by your macros already I'd love to go with it. Thanks! Cheers, Frank From fgoenninger at prion.de Sat Oct 8 09:26:47 2005 From: fgoenninger at prion.de (Frank Goenninger - PRION Consulting) Date: Sat, 8 Oct 2005 11:26:47 +0200 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> Message-ID: <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> Am 08.10.2005 um 04:34 schrieb Rayiner Hashem: > First, a technical point: yes, VZN can see the full path of each > header. > Second, the solution is probably fine on Windows, where each library > typically has its include files installed to a seperate directory, but > is possibly suboptimal on *NIX, where everything is in /usr/include. > So for cases like zlib, or libelf (just to name things that I can see > in my /usr/include), there does need to be some sort of option to use > the strict semantics. However, I don't have a problem making the > directory-searching behavior the default. Even on UNIX, most libraries > are well-behaved enough to create a subdirectory under /usr/include. > This last statement is (or should be) true only for system libs or close-to-system libs. One of the big advantages of the Unixes on this planet is that you are not forced to put all the libs under a pre- defined directory. For all my own software I have opted to install these under "/opt". So, my software package "tuba" creates/has directories like: /opt/tuba /opt/tuba/bin /opt/tuba/include /opt/tuba/lib /opt/tuba/man /opt/tuba/etc And yes, your are guessing correctly that all the include files are put under /opt/tuba/include - there are sub-dirs in there, too. I have a subcomponent CORE that has its own include files: "core/ core.h". Then the whole path is of course: "/opt/tuba/include/core/ core.h". Now, I would want to do something like (verrazano:defbinding (:name "tuba-library") (:nicknames "tuba") (:include-path "/opt/tuba/include") (:include "tuba.h")) In file tuba.h, there is the #include directive for core/core.h. Then, there is IMO no need to do a full directory search and go through each file in a directory. This is not what the C compilers (or the precompilers) do and might actually introduce inconsistencies. A real example for this: I have a lib (not my own, a commercial software product) that provides several alternatives for a lib with a corresponding include file for each lib all in the same include directory. The libs represent different threading support (one without multi- threading support and the other one with it) and they actually differ in the API: (void) getContextID (Context *context, Thread *thread); and (void) getContextID (Context *context); ... Same name, different parameters - and it's plain C. How to decide which is the correct one? The files are named differently so if you explicitely say "include this file but not the other" then you are save. I'd really be careful also with different versions of an include file / a lib. The same problem applies there, too. The only solution for me is to traverse all include files for further includes in them and pull in the definitions while watching out for already included definitions. This should happen automagically with just providing the top include (see my tuba example above) and all definitions are seen then. At least this is my understanding how the C pre-compiler / compiler combo works. We should mimic that as close as possible to not introduce effects the C environment does not see and which causes unwanted behavior then on the VZN / Lisp side. Ooookkaaayyyyy..... Great work so far! Please keep going! Thanks! > Sincerely, > Rayiner Hashem > Cheers, Frank > On 10/7/05, Kenny Tilton wrote: > >> >> >> Andy Cristina wrote: >> >> >>> On 10/7/05, Kenny Tilton wrote: >>> >>> >>> >>>> I have joked before about the downside of generating bindings >>>> only for >>>> symbols mentioned in include files actually listed in a binding >>>> definition, as opposed to files reached via nested includes: large >>>> libraries customarily break their apis up into multiple >>>> includes, so >>>> these have to be listed in the binding definition to get >>>> bindings generated. >>>> >>>> I just ran into an egregious case of this as I look to see if >>>> vzn can >>>> handle wxWidgets: >>>> >>>> >>>> >>>> >>>> Well, it is not that hard to paste the same list into a binding >>>> defintion, but it occurred to me that there is a natural >>>> solution to >>>> this minor annoyance. What if vzn generated bindings for any >>>> include >>>> found in the same directory tree as any listed include? >>>> >>>> There is a gotcha here, perhaps. I gave up fighting VC++ at one >>>> point >>>> and just copied the headers for a package into /vc++/vc98/ >>>> include. So >>>> one would now be back to pulling in every symbol ala windows.h. >>>> But! In >>>> this case, the source all includes "wx/wx....h", so I will be >>>> creating a >>>> "wx" subdirectory under the vc++ include directory, and the >>>> scheme I >>>> propose would thus work. >>>> >>>> But! number two is that maybe I gave up too fast on vc++. It >>>> does allow >>>> specification of other search paths for includes. I tried that >>>> without >>>> success on something or other, but probably that could have been >>>> made to >>>> work, and again this scheme would hold up. >>>> >>>> I have not thought this through exhaustively. Can anyone see an >>>> objection? Obviously the big one would be: vzn cannot see the >>>> paths! Can it? >>>> >>>> >>>> >>>> >>> >>> Please PLEASE make this an option in the binding if you go this >>> route. >>> Creating a binding file isn't something you do very often, and I >>> think spending the time to list every header you want included isn't >>> that high a cost. Especially if you've commited to a library that >>> would make you do the same thing in a C program. >>> >>> >> No, a C program can include "wx.h". For example, the Life demo in wx >> includes just wx.h and minifram.h, which latter I guess is an oddball >> widget that gets left out of wx.h to avoid bloat. So it turns out >> I am >> the one arguing for having vzn work the same as a C program, while >> forcing us to dive into wx.h, pull out its innards, and splat them >> all >> over the binding definition is the unreliable, unnatural, and more >> unwieldy approach. >> >> What happens when wx.h changes? With my scheme, one just >> regenerates the >> bindings. With yours, we now have to start over and re-rip out the >> contents of wx.h. Obviously suboptimal. >> >> >>> If it is really a >>> problem, why not allow something like (include "wx/*.h") ? That way >>> you don't do something that smells bad just to avoid typing. >>> >>> >> No, this is wrong. A wildcard (as you know) picks up every last >> thing in >> the directory, whether or not it gets navigated to via nested >> includes. >> So this is a "dumb" solution, in that it is not actually driven by >> the >> source which specifies exactly what to include. VZN ends up >> chewing on >> headers the C compielr would never look at. Ouch. >> >> >>> Or >>> perhaps we can have a vzn utilities package that can make >>> bindings for >>> libraries... maybe put a fancy gui on it, point it at a >>> directory, and >>> it can give you a list control to select which headers to bind. >>> >>> >> But an automatic solution is possible and trivial (iff vzn can see >> paths), so why throw up your hands and force a totally error-prone >> and >> tedious manual selection? >> >> >>> I >>> haven't really thought this out; I have been awake a very short time >>> and don't really have the ability to hold a thought for more than a >>> minute or so. >>> >>> >> Noted. :) >> >> >>> But the idea of silently including things smells really >>> bad to me. >>> >>> >> "Silently"? That is exactly what every build of a C application does, >> and it guarantees that the right things get pulled in in the right >> order. You make it sound bad. What is bad is reaching into the wx >> internals instead of just listing the same includes a wx app would >> include in the .c files. >> >> kt >> >> >> >> _______________________________________________ >> fetter-devel mailing list >> fetter-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel >> >> > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > From tomi.neste at netikka.fi Sat Oct 8 09:00:06 2005 From: tomi.neste at netikka.fi (Tomi K Neste) Date: Sat, 08 Oct 2005 12:00:06 +0300 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: Message-ID: On Sat, 08 Oct 2005 05:33:40 +0300, Rayiner Hashem wrote: > > (verrazano:deftarget cffi-lispy > (:backend :cffi) > (:name-style :lisp-style) ; or :c-style > (:search-mode :strict)) ; or :helpful (better name???) > > I'd love to recieve any comments that would help me make this > interface better (or suggest to me to scrap it entirely and do > something else :) > Since most C (and some C++) libs have some prefixes ("gl", "fl" etc.) that aren't really necessary in CL it would be nice if the user could provide his own function for the :name-style to do the lispification of names. Simple :strip-prefix option might work but letting the user decide the exact naming scheme would be more flexible and keep Verrazano agnostic about the issues of c-style vs. lisp-style vs some-other-style. Thought maybe it wouldn't be that simple because of the way Vzn handles the naming of c++ methods. The naming function would probably also need some extra information to keep the generated names consistent with the c++ method signatures. From ktilton at nyc.rr.com Sat Oct 8 14:14:47 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 08 Oct 2005 10:14:47 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: Message-ID: <4347D457.8000602@nyc.rr.com> Rayiner Hashem wrote: >The user interface for Verrazano is a bit of a kludge at the moment, >and I've been working recently on refactoring the code to both enable >a more sensical and straightforward UI, and also to refactor the >internals to allow better user control in certain places. This work is >a prerequisite for things like Visual C++ support and multiple backend >support. Moreover, I consder a rework of the UI to be a prerequisite >for a 1.0 release. > >Right now, what I have is a procedural interface to the generator's >internals. What I need is a good way of allowing the user to specify a >configuration. The idea is to dump the special .binding file, as Kenny >suggested, and go with a set of macros. My first thoughts are to make >generate.lisp look like this: > General observation: we should think ahead to using ASDF or mk:defystem. This may already be doable, i have not stared at it nor am I a whiz on either system builder. But I should be able to put the create-binding invocation in, say, and ASDF definition, list "cairo.h" etc as dependencies/components/modules/whatever and just use ASDF (while maintaining not cl-cairo/generate.lisp but merely cl-cairo/defbinding.lisp which would have everything below except the create-binding call). Note that this sounds like but is not the same as having a cairo.binding file parsed by create-binding. > >(verrazano:defbinding cairo > (:name "cairo-library") > (:nicknames "cairo") > (:include "cairo/cairo.h" > "cairo/cairo-pdf.h")) > >(verrazano:defhost winvc++ > (:compiler :vc++) ; or :g++ > (:gccxml-path "") > (:gccxml-command "gccxml") > (:temp-directory "/tmp")) > As usual, I have not thought this thru, but why do we need this host parameter? It seems to me that it would be nice to end up with a *-library.lisp that could be used unchanged when I build on Win32 or *nix, or (on Win32) when I toss a VC++-built library and decide to use a G++-built library. Does the vzn host change the vzn support code to be embedded in the *library.lisp? If so, is there some way that one universal albeit host-parameterized vzn support code can be embedded, and the load library call take a host parameter? I do not know how that could be used to select the right vzn support library by library (on win32, i can imagine DLLs from both g++ and vc++ being used by one application), but if we can see the diff vzn support code (if my guess is right) I might have some ideas. Achieving this eliminates a parameter and makes a single source file universal, and lets me change from VC++ to G++ for a particular library without regenerating bindings. The latter would not happen often, but the fact that, should it happen, I would have to regenerate the bindings suggests to me that we are building in needless inflexibility. > >(verrazano:deftarget cffi-lispy > (:backend :cffi) > (:name-style :lisp-style) ; or :c-style > With another recent poster, I would like to see /in addition/ the option of supplying here a user function. > (:search-mode :strict)) ; or :helpful (better name???) > Better name for what? :) I mean, what is "search-mode"? Is this the issue of "from which include files are symbols to have bindings generated?". What are the options you are now considering (and their semantics)? > >(verrazano:create-binding > :binding cairo > :host winvc++ > :target cffi-lispy > "testsuite/cairo/cairo-library.lisp") > >Basically, the specification of the configuration is split up into a >binding describing the header files to incorporate, a host describing >the host platform, and a target describing what backend to use and >what code generation options to enable. Common hosts like "winvc++" or >"lingcc" would be built into Verrazano, so you could pass something >like "verrazano:winvc++" to CREATE-BINDING, without having to redefine >it each time. > >I'd love to recieve any comments that would help me make this >interface better (or suggest to me to scrap it entirely and do >something else :) > Aside from my above comments, I think this is close enough that you can just go with it. I am guessing we are at such a high level here that revision/refinement in the light of experience will be easy, and the best ideas will come from trying to live with the scheme, so it is better to push something reasonable out the door and see how it does in the wild than to get bogged down in a debate where people are really only guessing at what the ideal UI would be. kt From rayiner at gmail.com Sat Oct 8 19:18:13 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 8 Oct 2005 15:18:13 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: Message-ID: On 10/8/05, Tomi K Neste wrote: > On Sat, 08 Oct 2005 05:33:40 +0300, Rayiner Hashem > wrote: > > > > > (verrazano:deftarget cffi-lispy > > (:backend :cffi) > > (:name-style :lisp-style) ; or :c-style > > (:search-mode :strict)) ; or :helpful (better name???) > > > > > I'd love to recieve any comments that would help me make this > > interface better (or suggest to me to scrap it entirely and do > > something else :) > > > Since most C (and some C++) libs have some prefixes ("gl", "fl" etc.) that > aren't really necessary in CL it would be nice if the user could provide > his own function for the :name-style to do the lispification of names. > Simple :strip-prefix option might work but letting the user decide the > exact naming scheme would be more flexible and keep Verrazano agnostic > about the issues of c-style vs. lisp-style vs some-other-style. Thought > maybe it wouldn't be that simple because of the way Vzn handles the naming > of c++ methods. The naming function would probably also need some extra > information to keep the generated names consistent with the c++ method > signatures. Allowing the user to specify their own naming was my original intention. Naming of various elements in the generated output is broken out into a set of generic functions. These should be parameterized on the :name-style parameter, so the user can add a method to the GF, and pass Verrazano a custom naming style. > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From rayiner at gmail.com Sat Oct 8 19:44:29 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 8 Oct 2005 15:44:29 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: <4347D084.9030404@nyc.rr.com> References: <4347D084.9030404@nyc.rr.com> Message-ID: > >The user interface for Verrazano is a bit of a kludge at the moment, > >and I've been working recently on refactoring the code to both enable > >a more sensical and straightforward UI, and also to refactor the > >internals to allow better user control in certain places. This work is > >a prerequisite for things like Visual C++ support and multiple backend > >support. Moreover, I consder a rework of the UI to be a prerequisite > >for a 1.0 release. > > > >Right now, what I have is a procedural interface to the generator's > >internals. What I need is a good way of allowing the user to specify a > >configuration. The idea is to dump the special .binding file, as Kenny > >suggested, and go with a set of macros. My first thoughts are to make > >generate.lisp look like this: > > > General observation: we should think ahead to using ASDF or mk:defystem. > This may already be doable, i have not stared at it nor am I a whiz on > either system builder. But I should be able to put the create-binding > invocation in, say, and ASDF definition, list "cairo.h" etc as > dependencies/components/modules/whatever and just use ASDF (while > maintaining not cl-cairo/generate.lisp but merely > cl-cairo/defbinding.lisp which would have everything below except the > create-binding call). Note that this sounds like but is not the same as > having a cairo.binding file parsed by create-binding. I like the idea of integrating with ASDF, except I don't have the foggiest idea where to start extending it. I suppose that's what the internet is for :) > > > > >(verrazano:defbinding cairo > > (:name "cairo-library") > > (:nicknames "cairo") > > (:include "cairo/cairo.h" > > "cairo/cairo-pdf.h")) > > > >(verrazano:defhost winvc++ > > (:compiler :vc++) ; or :g++ > > (:gccxml-path "") > > (:gccxml-command "gccxml") > > (:temp-directory "/tmp")) > > > As usual, I have not thought this thru, but why do we need this host > parameter? It seems to me that it would be nice to end up with a > *-library.lisp that could be used unchanged when I build on Win32 or > *nix, or (on Win32) when I toss a VC++-built library and decide to use a > G++-built library. Thoe host parameter is necessary so Verrazano knows where to find GCC-XML, and what compiler to target. > Does the vzn host change the vzn support code to be embedded in the > *library.lisp? Changing the host causes the following changes (for C++ code): - All function and method symbols get changed because of name-mangling. - All class sizes and offsets change because of differing layout algorithms. - Constants embedded in virtual dispatch functions change for the same reason. > If so, is there some way that one universal albeit > host-parameterized vzn support code can be embedded, and the load > library call take a host parameter? I do not know how that could be used > to select the right vzn support library by library (on win32, i can > imagine DLLs from both g++ and vc++ being used by one application), but > if we can see the diff vzn support code (if my guess is right) I might > have some ideas. I'm sure things could theoretically be parameterized, but you'd basically just have multiple copies of the binding, one for each compiler. It'd look like: (cond ((eq compiler :vc++) ...cairo-library.lisp generated for vc++...) ((eq compiler :g++) ...cairo-library.lisp generated for g++...)) Pretty much the only declarations that could be hoisted outside that cond are enumerations, #define's, and simple structures. > > Achieving this eliminates a parameter and makes a single source file > universal, and lets me change from VC++ to G++ for a particular library > without regenerating bindings. The latter would not happen often, but > the fact that, should it happen, I would have to regenerate the bindings > suggests to me that we are building in needless inflexibility. > > > > >(verrazano:deftarget cffi-lispy > > (:backend :cffi) > > (:name-style :lisp-style) ; or :c-style > > > With another recent poster, I would like to see /in addition/ the option > of supplying here a user function. > > > (:search-mode :strict)) ; or :helpful (better name???) > > > Better name for what? :) I mean, what is "search-mode"? Is this the > issue of "from which include files are symbols to have bindings > generated?". What are the options you are now considering (and their > semantics)? Yes, it's the issue of "from which include files are symbols to have bindings generated". The current options I'm considering: :strict - Only consider headers explicitly listed :helpful - Consider headers in the same directory as ones listed These are terrible names. I'm at a complete loss for anything both succinct and descriptive enough, though. > > > > >(verrazano:create-binding > > :binding cairo > > :host winvc++ > > :target cffi-lispy > > "testsuite/cairo/cairo-library.lisp") > > > >Basically, the specification of the configuration is split up into a > >binding describing the header files to incorporate, a host describing > >the host platform, and a target describing what backend to use and > >what code generation options to enable. Common hosts like "winvc++" or > >"lingcc" would be built into Verrazano, so you could pass something > >like "verrazano:winvc++" to CREATE-BINDING, without having to redefine > >it each time. > > > >I'd love to recieve any comments that would help me make this > >interface better (or suggest to me to scrap it entirely and do > >something else :) > > > Aside from my above comments, I think this is close enough that you can > just go with it. I am guessing we are at such a high level here that > revision/refinement in the light of experience will be easy, and the > best ideas will come from trying to live with the scheme, so it is > better to push something reasonable out the door and see how it does in > the wild than to get bogged down in a debate where people are really > only guessing at what the ideal UI would be. Okay then, let's do this. I'll add the features that have been requested (customizable naming), and clean up the naming of functions. That should be "reasonable enough". Moreover, any interface is going to be a thin veneer over the procedural interface, so most of the work implementing this isn't going to be wasted (and indeed can exist in parallel), if we make an ASDF interface. Sincerely, Rayiner Hashem > > kt > > > From ktilton at nyc.rr.com Sat Oct 8 21:11:13 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 08 Oct 2005 17:11:13 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: <4347D084.9030404@nyc.rr.com> Message-ID: <434835F1.7070108@nyc.rr.com> Rayiner Hashem wrote: >>>The user interface for Verrazano is a bit of a kludge at the moment, >>>and I've been working recently on refactoring the code to both enable >>>a more sensical and straightforward UI, and also to refactor the >>>internals to allow better user control in certain places. This work is >>>a prerequisite for things like Visual C++ support and multiple backend >>>support. Moreover, I consder a rework of the UI to be a prerequisite >>>for a 1.0 release. >>> >>>Right now, what I have is a procedural interface to the generator's >>>internals. What I need is a good way of allowing the user to specify a >>>configuration. The idea is to dump the special .binding file, as Kenny >>>suggested, and go with a set of macros. My first thoughts are to make >>>generate.lisp look like this: >>> >>> >>> >>General observation: we should think ahead to using ASDF or mk:defystem. >>This may already be doable, i have not stared at it nor am I a whiz on >>either system builder. But I should be able to put the create-binding >>invocation in, say, and ASDF definition, list "cairo.h" etc as >>dependencies/components/modules/whatever and just use ASDF (while >>maintaining not cl-cairo/generate.lisp but merely >>cl-cairo/defbinding.lisp which would have everything below except the >>create-binding call). Note that this sounds like but is not the same as >>having a cairo.binding file parsed by create-binding. >> >> > >I like the idea of integrating with ASDF, except I don't have the >foggiest idea where to start extending it. I suppose that's what the >internet is for :) > Funny you should mention that. I believe ASDF works the way you propose allowing user specification of an alternate naming scheme: one provides methods for this or that GF. That seems weird and user-hostile to me. if I see a parameter such as :lisp-name factory, I think "Bingo! What are the options?" ie, I know exactly where to look, even if it has been nine months since I generated bindings. Then I see that :lisp-naming-factory can be a function (as the name suggests) or one or two keywords specifying popular translation schemes (or nil for no translation). With ASDF I have to dive into the source, figure out how ASDF works, find the right GF, pray that i can safely override it, and put a defmethod in each ASD definition file (.asd) I want to get this special behavior. Ick. > > > >>>(verrazano:defbinding cairo >>> (:name "cairo-library") >>> (:nicknames "cairo") >>> (:include "cairo/cairo.h" >>> "cairo/cairo-pdf.h")) >>> >>>(verrazano:defhost winvc++ >>> (:compiler :vc++) ; or :g++ >>> (:gccxml-path "") >>> (:gccxml-command "gccxml") >>> (:temp-directory "/tmp")) >>> >>> >>> >>As usual, I have not thought this thru, but why do we need this host >>parameter? It seems to me that it would be nice to end up with a >>*-library.lisp that could be used unchanged when I build on Win32 or >>*nix, or (on Win32) when I toss a VC++-built library and decide to use a >>G++-built library. >> >> > >Thoe host parameter is necessary so Verrazano knows where to find >GCC-XML, and what compiler to target. > > > >>Does the vzn host change the vzn support code to be embedded in the >>*library.lisp? >> >> > >Changing the host causes the following changes (for C++ code): > >- All function and method symbols get changed because of name-mangling. >- All class sizes and offsets change because of differing layout algorithms. >- Constants embedded in virtual dispatch functions change for the same reason. > Oh. Never mind. :) > > > >>If so, is there some way that one universal albeit >>host-parameterized vzn support code can be embedded, and the load >>library call take a host parameter? I do not know how that could be used >>to select the right vzn support library by library (on win32, i can >>imagine DLLs from both g++ and vc++ being used by one application), but >>if we can see the diff vzn support code (if my guess is right) I might >>have some ideas. >> >> > >I'm sure things could theoretically be parameterized, but you'd >basically just have multiple copies of the binding, one for each >compiler. It'd look like: > >(cond > ((eq compiler :vc++) > ...cairo-library.lisp generated for vc++...) > ((eq compiler :g++) > ...cairo-library.lisp generated for g++...)) > OK. Well, I think this can be handled easily enough as a vzn user. There is enough flexibility in there. > >Pretty much the only declarations that could be hoisted outside that >cond are enumerations, #define's, and simple structures. > > > >>Achieving this eliminates a parameter and makes a single source file >>universal, and lets me change from VC++ to G++ for a particular library >>without regenerating bindings. The latter would not happen often, but >>the fact that, should it happen, I would have to regenerate the bindings >>suggests to me that we are building in needless inflexibility. >> >> >> >>>(verrazano:deftarget cffi-lispy >>> (:backend :cffi) >>> (:name-style :lisp-style) ; or :c-style >>> >>> >>> >>With another recent poster, I would like to see /in addition/ the option >>of supplying here a user function. >> >> >> >>> (:search-mode :strict)) ; or :helpful (better name???) >>> >>> >>> >>Better name for what? :) I mean, what is "search-mode"? Is this the >>issue of "from which include files are symbols to have bindings >>generated?". What are the options you are now considering (and their >>semantics)? >> >> > >Yes, it's the issue of "from which include files are symbols to have >bindings generated". The current options I'm considering: > >:strict - Only consider headers explicitly listed >:helpful - Consider headers in the same directory as ones listed > >These are terrible names. I'm at a complete loss for anything both >succinct and descriptive enough, though. > Howseabout making it include specific? (defbinding.... (include "just-me.h" ("my-tree.h" :process-nested t)) ...or just: (defbinding.... (include "just-me.h" ("my-tree.h" t)) with process-nested then being like an optional parameter? We might need file-specific control someday, and it saves making a new parameter. If "process-nested" sounds vague, call it "bind-nested". But making bindings /is/ what vzn does, so "process" works for me. kt From rayiner at gmail.com Sat Oct 8 21:43:49 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 8 Oct 2005 17:43:49 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> Message-ID: > At least this is my understanding how the C pre-compiler / compiler > combo works. We should mimic that as close as possible to not > introduce effects the C environment does not see and which causes > unwanted behavior then on the VZN / Lisp side. Yep, that's an apt description of how it works. However, Vzn doesn't need to mimic the process, as GCC-XML fully emulates the behavior of the C compiler. The way Vzn works is that it translates the defbinding form into a .cpp file which is compiled by GCC-XML. It doesn't do any of its own header-file searching (which makes :search-mode a painfully bad name for the pruning algorithm!), GCC-XML takes care of all that, simply telling Vzn what definitions it found and the names of the headers in which it found them. The result is that the XML file parsed by Vzn to generate its IR contains only the definitions that would be seen by the C compiler compiling the equivalent .cpp file. That means that no matter what magic is used to distinguish between various library versions or multi-threaded/single-threaded versions, GCC-XML has already taken care of it by the time Vzn ever sees any definitions. Eg: if a header file has an #ifdef PTHREADS that decides whether to include foo.h or foo-mt.h, Vzn will only get the definitions corresponding to the correct header. What this proposal is about is trying to figure out how to prune the original set of definitions to find the set to actually generate bindings for. The pruning process cannot introduce inconsistent definitions; it can merely preserve undesirable ones. Eg: expat.h resides in /usr/include and includes stdlib.h. You probably don't want declarations for stdlib.h in expat-library.lisp, but the directory-searching proposal will cause just that to happen. Fortunately, expat only needs three headers, so it is easy to use the "strict" mode and specify everything explicitly. Indeed, libraries that tend to have enough headers to make to directory-searching mode worthwhile also tend to have their own subdirectories in /usr/include. I hope that clarifies the issue, and that I didn't misunderstand your point completely :) > > Ooookkaaayyyyy..... > > Great work so far! Please keep going! Thanks a lot! Sincerely, Rayiner Hashem > > Thanks! > > > Sincerely, > > Rayiner Hashem > > > > Cheers, > Frank > > > On 10/7/05, Kenny Tilton wrote: > > > >> > >> > >> Andy Cristina wrote: > >> > >> > >>> On 10/7/05, Kenny Tilton wrote: > >>> > >>> > >>> > >>>> I have joked before about the downside of generating bindings > >>>> only for > >>>> symbols mentioned in include files actually listed in a binding > >>>> definition, as opposed to files reached via nested includes: large > >>>> libraries customarily break their apis up into multiple > >>>> includes, so > >>>> these have to be listed in the binding definition to get > >>>> bindings generated. > >>>> > >>>> I just ran into an egregious case of this as I look to see if > >>>> vzn can > >>>> handle wxWidgets: > >>>> > >>>> > >>>> > >>>> > >>>> Well, it is not that hard to paste the same list into a binding > >>>> defintion, but it occurred to me that there is a natural > >>>> solution to > >>>> this minor annoyance. What if vzn generated bindings for any > >>>> include > >>>> found in the same directory tree as any listed include? > >>>> > >>>> There is a gotcha here, perhaps. I gave up fighting VC++ at one > >>>> point > >>>> and just copied the headers for a package into /vc++/vc98/ > >>>> include. So > >>>> one would now be back to pulling in every symbol ala windows.h. > >>>> But! In > >>>> this case, the source all includes "wx/wx....h", so I will be > >>>> creating a > >>>> "wx" subdirectory under the vc++ include directory, and the > >>>> scheme I > >>>> propose would thus work. > >>>> > >>>> But! number two is that maybe I gave up too fast on vc++. It > >>>> does allow > >>>> specification of other search paths for includes. I tried that > >>>> without > >>>> success on something or other, but probably that could have been > >>>> made to > >>>> work, and again this scheme would hold up. > >>>> > >>>> I have not thought this through exhaustively. Can anyone see an > >>>> objection? Obviously the big one would be: vzn cannot see the > >>>> paths! Can it? > >>>> > >>>> > >>>> > >>>> > >>> > >>> Please PLEASE make this an option in the binding if you go this > >>> route. > >>> Creating a binding file isn't something you do very often, and I > >>> think spending the time to list every header you want included isn't > >>> that high a cost. Especially if you've commited to a library that > >>> would make you do the same thing in a C program. > >>> > >>> > >> No, a C program can include "wx.h". For example, the Life demo in wx > >> includes just wx.h and minifram.h, which latter I guess is an oddball > >> widget that gets left out of wx.h to avoid bloat. So it turns out > >> I am > >> the one arguing for having vzn work the same as a C program, while > >> forcing us to dive into wx.h, pull out its innards, and splat them > >> all > >> over the binding definition is the unreliable, unnatural, and more > >> unwieldy approach. > >> > >> What happens when wx.h changes? With my scheme, one just > >> regenerates the > >> bindings. With yours, we now have to start over and re-rip out the > >> contents of wx.h. Obviously suboptimal. > >> > >> > >>> If it is really a > >>> problem, why not allow something like (include "wx/*.h") ? That way > >>> you don't do something that smells bad just to avoid typing. > >>> > >>> > >> No, this is wrong. A wildcard (as you know) picks up every last > >> thing in > >> the directory, whether or not it gets navigated to via nested > >> includes. > >> So this is a "dumb" solution, in that it is not actually driven by > >> the > >> source which specifies exactly what to include. VZN ends up > >> chewing on > >> headers the C compielr would never look at. Ouch. > >> > >> > >>> Or > >>> perhaps we can have a vzn utilities package that can make > >>> bindings for > >>> libraries... maybe put a fancy gui on it, point it at a > >>> directory, and > >>> it can give you a list control to select which headers to bind. > >>> > >>> > >> But an automatic solution is possible and trivial (iff vzn can see > >> paths), so why throw up your hands and force a totally error-prone > >> and > >> tedious manual selection? > >> > >> > >>> I > >>> haven't really thought this out; I have been awake a very short time > >>> and don't really have the ability to hold a thought for more than a > >>> minute or so. > >>> > >>> > >> Noted. :) > >> > >> > >>> But the idea of silently including things smells really > >>> bad to me. > >>> > >>> > >> "Silently"? That is exactly what every build of a C application does, > >> and it guarantees that the right things get pulled in in the right > >> order. You make it sound bad. What is bad is reaching into the wx > >> internals instead of just listing the same includes a wx app would > >> include in the .c files. > >> > >> kt > >> > >> > >> > >> _______________________________________________ > >> fetter-devel mailing list > >> fetter-devel at common-lisp.net > >> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > >> > >> > > _______________________________________________ > > fetter-devel mailing list > > fetter-devel at common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > > > > > From rayiner at gmail.com Sat Oct 8 22:18:37 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 8 Oct 2005 18:18:37 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: <434835F1.7070108@nyc.rr.com> References: <4347D084.9030404@nyc.rr.com> <434835F1.7070108@nyc.rr.com> Message-ID: > Funny you should mention that. I believe ASDF works the way you propose > allowing user specification of an alternate naming scheme: one provides > methods for this or that GF. Yay! ASDF does it that way too. > That seems weird and user-hostile to me. Doh! > I see a parameter such as :lisp-name factory, I think "Bingo! What are > the options?" ie, I know exactly where to look, even if it has been nine > months since I generated bindings. Then I see that :lisp-naming-factory > can be a function (as the name suggests) or one or two keywords > specifying popular translation schemes (or nil for no translation). With > ASDF I have to dive into the source, figure out how ASDF works, find the > right GF, pray that i can safely override it, and put a defmethod in > each ASD definition file (.asd) I want to get this special behavior. Ick. Hmm. Any custom naming convention will have to understand the IR at some level. I see the complexity you're talking about, but I wonder if having to understand the IR wouldn't be a bigger source of complexity? > Howseabout making it include specific? > > (defbinding.... > (include "just-me.h" ("my-tree.h" :process-nested t)) > > ...or just: > > (defbinding.... > (include "just-me.h" ("my-tree.h" t)) > > with process-nested then being like an optional parameter? We might need > file-specific control someday, and it saves making a new parameter. If > "process-nested" sounds vague, call it "bind-nested". But making > bindings /is/ what vzn does, so "process" works for me. Hmm. How about: (defbinding (include "just-me.h" ("everyone.h" :bind-recursive t) ("just-siblings.h" :bind-siblings t) ("just-subtree.h" :bind-subtree t))) :bind-recursive would bind to all header files reachable from the given one, :bind-siblings would bind to all reachable header files in the same directory, and :bind-subtree would bind to all reachable header files in the same directory and any subdirectories thereof. Sincerely, Rayiner Hashem > > > kt > > > From ktilton at nyc.rr.com Sun Oct 9 00:07:26 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 08 Oct 2005 20:07:26 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: <4347D084.9030404@nyc.rr.com> <434835F1.7070108@nyc.rr.com> Message-ID: <43485F3E.80106@nyc.rr.com> Rayiner Hashem wrote: >>Funny you should mention that. I believe ASDF works the way you propose >>allowing user specification of an alternate naming scheme: one provides >>methods for this or that GF. >> >> > >Yay! ASDF does it that way too. > > > >>That seems weird and user-hostile to me. >> >> > >Doh! > > > >>I see a parameter such as :lisp-name factory, I think "Bingo! What are >>the options?" ie, I know exactly where to look, even if it has been nine >>months since I generated bindings. Then I see that :lisp-naming-factory >>can be a function (as the name suggests) or one or two keywords >>specifying popular translation schemes (or nil for no translation). With >>ASDF I have to dive into the source, figure out how ASDF works, find the >>right GF, pray that i can safely override it, and put a defmethod in >>each ASD definition file (.asd) I want to get this special behavior. Ick. >> >> > >Hmm. Any custom naming convention will have to understand the IR at >some level. I see the complexity you're talking about, but I wonder if >having to understand the IR wouldn't be a bigger source of complexity? > Well, this is Lisp, let's see what you come up with and live with it for a month. > > > >>Howseabout making it include specific? >> >> (defbinding.... >> (include "just-me.h" ("my-tree.h" :process-nested t)) >> >>...or just: >> >> (defbinding.... >> (include "just-me.h" ("my-tree.h" t)) >> >>with process-nested then being like an optional parameter? We might need >>file-specific control someday, and it saves making a new parameter. If >>"process-nested" sounds vague, call it "bind-nested". But making >>bindings /is/ what vzn does, so "process" works for me. >> >> > >Hmm. How about: > >(defbinding > (include "just-me.h" > ("everyone.h" :bind-recursive t) > ("just-siblings.h" :bind-siblings t) > ("just-subtree.h" :bind-subtree t))) > Or :bind with legal values nil, :recursive, :siblings, and :subtree? kt > >:bind-recursive would bind to all header files reachable from the >given one, :bind-siblings would bind to all reachable header files in >the same directory, and :bind-subtree would bind to all reachable >header files in the same directory and any subdirectories thereof. > >Sincerely, > Rayiner Hashem > > From ktilton at nyc.rr.com Sun Oct 9 03:01:35 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 08 Oct 2005 23:01:35 -0400 Subject: [fetter-devel] Request for comments on new interface In-Reply-To: References: <4347D084.9030404@nyc.rr.com> <434835F1.7070108@nyc.rr.com> <43485F3E.80106@nyc.rr.com> Message-ID: <4348880F.9010504@nyc.rr.com> Rayiner Hashem wrote: >On 10/8/05, Kenny Tilton wrote: > > > >>>Hmm. How about: >>> >>>(defbinding >>> (include "just-me.h" >>> ("everyone.h" :bind-recursive t) >>> ("just-siblings.h" :bind-siblings t) >>> ("just-subtree.h" :bind-subtree t))) >>> >>> >>> >>Or :bind with legal values nil, :recursive, :siblings, and :subtree? >> Hmmm, perhaps the keyword should be :scope or :extent or some other term indicating "whats-in-whats-out". Maybe a quibble, but with any luck we will be living with this until an asteroid hits, so let's get it right. :) -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 From fgoenninger at prion.de Sun Oct 9 08:15:30 2005 From: fgoenninger at prion.de (Frank Goenninger - PRION Consulting) Date: Sun, 9 Oct 2005 10:15:30 +0200 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> Message-ID: <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> Am 08.10.2005 um 23:43 schrieb Rayiner Hashem: >> At least this is my understanding how the C pre-compiler / compiler >> combo works. We should mimic that as close as possible to not >> introduce effects the C environment does not see and which causes >> unwanted behavior then on the VZN / Lisp side. >> > > Yep, that's an apt description of how it works. However, Vzn doesn't > need to mimic the process, as GCC-XML fully emulates the behavior of > the C compiler. > > The way Vzn works is that it translates the defbinding form into a > .cpp file which is compiled by GCC-XML. It doesn't do any of its own > header-file searching (which makes :search-mode a painfully bad name > for the pruning algorithm!), GCC-XML takes care of all that, simply > telling Vzn what definitions it found and the names of the headers in > which it found them. The result is that the XML file parsed by Vzn to > generate its IR contains only the definitions that would be seen by > the C compiler compiling the equivalent .cpp file. That means that no > matter what magic is used to distinguish between various library > versions or multi-threaded/single-threaded versions, GCC-XML has > already taken care of it by the time Vzn ever sees any definitions. > Eg: if a header file has an #ifdef PTHREADS that decides whether to > include foo.h or foo-mt.h, Vzn will only get the definitions > corresponding to the correct header. > > What this proposal is about is trying to figure out how to prune the > original set of definitions to find the set to actually generate > bindings for. The pruning process cannot introduce inconsistent > definitions; it can merely preserve undesirable ones. Eg: expat.h > resides in /usr/include and includes stdlib.h. You probably don't want > declarations for stdlib.h in expat-library.lisp, but the > directory-searching proposal will cause just that to happen. > Fortunately, expat only needs three headers, so it is easy to use the > "strict" mode and specify everything explicitly. Indeed, libraries > that tend to have enough headers to make to directory-searching mode > worthwhile also tend to have their own subdirectories in /usr/include. > > I hope that clarifies the issue, and that I didn't misunderstand your > point completely :) Seems as if I misunderstood a couple of things. Thanks for clarification! I will have to look into GCC-XML further, but I still don't see why you don't do what C does: All the includes are included. That, for me, means: Everything in every included include-file has to be declared/defined: functions, data types, constants, ... As for handling the declarations of stdlib.h in expat-library.lisp: Why not generating stdlib.lisp in a well-defined place (= repository) and then use ASDF to load the dependent file stdlib.lisp when loading expat-library.lisp. Each time a binding wants to use stdlib.h it checks (via time stamp) if the generated stdlib.lisp is still valid (= younger than the source file stdlib.h). If not, the stdlib.lisp file has to be regenerated, of course... Wrong path of thinking, this? Why? Thanks for commenting. Cheers Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht URL: From ktilton at nyc.rr.com Sun Oct 9 10:16:32 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 09 Oct 2005 06:16:32 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> Message-ID: <4348EE00.8080308@nyc.rr.com> Frank Goenninger - PRION Consulting wrote: > I will have to look into GCC-XML further, but I still don't see why > you don't do what C does: > > All the includes are included. That, for me, means: Everything in > every included include-file has to be declared/defined: functions, > data types, constants, ... The problem is on win32, where something like FreeGlut.h (IIRC) may include a little thing called "windows.h". Want to guess how big was the resulting freeglut-library.lisp? :) Now leave aside that problem (windows.h including everything under the sun whether freeglut needs it or not). How about stdlib.h, which Freeglut likely does need. Do we want bindings for that? Absolutely not if we are just trying to get to Freeglut. Freeglut has an API, and that is all we want. True, some C junkie might get off on having stdlib at their disposal from Lisp, but that is completely unrelated to getting bindings to Freeglut, and they should be getting those bindings by making stdlib-binding.lisp and using VZN on that. kt From fgoenninger at prion.de Sun Oct 9 17:39:18 2005 From: fgoenninger at prion.de (Frank Goenninger - PRION Consulting) Date: Sun, 9 Oct 2005 19:39:18 +0200 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <4348EE00.8080308@nyc.rr.com> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> <4348EE00.8080308@nyc.rr.com> Message-ID: <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> Yo, Kenny: Am 09.10.2005 um 12:16 schrieb Kenny Tilton: > > > Frank Goenninger - PRION Consulting wrote: > > >> I will have to look into GCC-XML further, but I still don't see >> why you don't do what C does: >> >> All the includes are included. That, for me, means: Everything in >> every included include-file has to be declared/defined: >> functions, data types, constants, ... >> > > The problem is on win32, where something like FreeGlut.h (IIRC) may > include a little thing called "windows.h". > > Want to guess how big was the resulting freeglut-library.lisp? :) A recall you said something about 700k ... Or even more ... > > Now leave aside that problem (windows.h including everything under > the sun whether freeglut needs it or not). How about stdlib.h, > which Freeglut likely does need. Do we want bindings for that? > Absolutely not if we are just trying to get to Freeglut. Freeglut > has an API, and that is all we want. I fully agree. This makes the "include challenge" some degrees more complex: Find out what Freeglut needs - recursively, because there might be a #define HAHA HEHE in file "a.h" and the #define HEHE HIHI in file "b.h" and then the #define HIHI 1 in file "c.h", each having more than just this #define in it and there bringing along more stuff and bindings. So, we need to cut away all the things that are "not requested" by Freeglut ... Doable, I think. But why? Speed? Size? Well, yes, of course. But a couple of more GB of main memory and we're done ;-) > > True, some C junkie might get off on having stdlib at their > disposal from Lisp, but that is completely unrelated to getting > bindings to Freeglut, and they should be getting those bindings by > making stdlib-binding.lisp and using VZN on that. Right. And VZN and ASDF may work together to do this. If VZN creates bindings for every single .h file / lib it finds and puts everything in a well-known place (a repository) then we're done. (see my other post on this). No? I wonder if I am still on the wrong thinking track ... > > kt Cheers Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht URL: From ktilton at nyc.rr.com Sun Oct 9 18:36:43 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 09 Oct 2005 14:36:43 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> <4348EE00.8080308@nyc.rr.com> <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> Message-ID: <4349633B.4070602@nyc.rr.com> >> >> The problem is on win32, where something like FreeGlut.h (IIRC) may >> include a little thing called "windows.h". >> >> Want to guess how big was the resulting freeglut-library.lisp? :) > > > A recall you said something about 700k ... Or even more ... > >> >> Now leave aside that problem (windows.h including everything under >> the sun whether freeglut needs it or not). How about stdlib.h, which >> Freeglut likely does need. Do we want bindings for that? Absolutely >> not if we are just trying to get to Freeglut. Freeglut has an API, >> and that is all we want. > > > I fully agree. This makes the "include challenge" some degrees more > complex: Find out what Freeglut needs - recursively, because there > might be a #define HAHA HEHE in file "a.h" and the #define HEHE HIHI > in file "b.h" and then the #define HIHI 1 in file "c.h", each having > more than just this #define in it and there bringing along more stuff > and bindings. So, we need to cut away all the things that are "not > requested" by Freeglut ... Doable, I think. But why? Speed? Size? > Well, yes, of course. But a couple of more GB of main memory and > we're done ;-) Because it is doable. And ACL takes 4-5 minutes to compile a 700k Lisp file. And I would like to open the thing and look at the API. It is bad enough that internals of Freeglut will end up in the binding file, but the entire Windows operating system? I /did/ open the 700k thing, and it was just hilarious to see what was in there (and impossible to see Freeglut). To be honest, I am not sure why I have to justify why it is bad to use a 700k Lisp file just to get to a terribly small API like Freeglut. What happened to the fine German tradition of precision engineering? > > >> >> True, some C junkie might get off on having stdlib at their disposal >> from Lisp, but that is completely unrelated to getting bindings to >> Freeglut, and they should be getting those bindings by making >> stdlib-binding.lisp and using VZN on that. > > > Right. And VZN and ASDF may work together to do this. If VZN creates > bindings for every single .h file / lib it finds and puts everything > in a well-known place (a repository) then we're done. (see my other > post on this). No? I wonder if I am still on the wrong thinking track > ... Yes, I think you are not thinking "API". The "I" stands for interface. Ideally, vzn would have access to something like the .DEF files which tells VC++ which functions go in the DLL -- well, maybe not. I like that vzn will get me into functions the author did not think to export, because I ran into that with FTGL. Anyway, what track are you on that tells you a Lisp binding to Freeglut should include strcat, even if it is neatly packaged in stdlib-library.lisp? Meanwhile, we already have a nice, easy solution to the 700k thing.... what problem are you trying to solve by arguing for a gross abuse of machine resources and binding readility? kenny From asimon at math.bme.hu Sun Oct 9 18:48:13 2005 From: asimon at math.bme.hu (Andras Simon) Date: Sun, 9 Oct 2005 20:48:13 +0200 (CEST) Subject: [fetter-devel] in-package Message-ID: I think that both support.lisp and the generated library file should start with an (in-package :cl-user) (or use cl:defpackage and cl:in-package). Andras From fgoenninger at prion.de Sun Oct 9 19:48:51 2005 From: fgoenninger at prion.de (Frank Goenninger - PRION Consulting) Date: Sun, 9 Oct 2005 21:48:51 +0200 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <4349633B.4070602@nyc.rr.com> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> <4348EE00.8080308@nyc.rr.com> <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> <4349633B.4070602@nyc.rr.com> Message-ID: <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> Am 09.10.2005 um 20:36 schrieb Kenny Tilton: > > >>> >>> The problem is on win32, where something like FreeGlut.h (IIRC) >>> may include a little thing called "windows.h". >>> >>> Want to guess how big was the resulting freeglut-library.lisp? :) >>> >> >> >> A recall you said something about 700k ... Or even more ... >> >> >>> >>> Now leave aside that problem (windows.h including everything >>> under the sun whether freeglut needs it or not). How about >>> stdlib.h, which Freeglut likely does need. Do we want bindings >>> for that? Absolutely not if we are just trying to get to >>> Freeglut. Freeglut has an API, and that is all we want. >>> >> >> >> I fully agree. This makes the "include challenge" some degrees >> more complex: Find out what Freeglut needs - recursively, because >> there might be a #define HAHA HEHE in file "a.h" and the #define >> HEHE HIHI in file "b.h" and then the #define HIHI 1 in file >> "c.h", each having more than just this #define in it and there >> bringing along more stuff and bindings. So, we need to cut away >> all the things that are "not requested" by Freeglut ... Doable, I >> think. But why? Speed? Size? Well, yes, of course. But a couple >> of more GB of main memory and we're done ;-) >> > > Because it is doable. And ACL takes 4-5 minutes to compile a 700k > Lisp file. And I would like to open the thing and look at the API. > It is bad enough that internals of Freeglut will end up in the > binding file, but the entire Windows operating system? I /did/ open > the 700k thing, and it was just hilarious to see what was in there > (and impossible to see Freeglut). > > To be honest, I am not sure why I have to justify why it is bad to > use a 700k Lisp file just to get to a terribly small API like > Freeglut. You don't have to justify it, of course! Being serious now: I am completely agreeing that a generated file has to be as lean as possible. I once had to debug machine generated code and it was a nightmare. And I am a fan of the KISS principle. > What happened to the fine German tradition of precision > engineering? Still trying to get my head away from the C scheme of thinking here. I am still so used to the fact that the CPP output (if you look at this directly, which you normally wouldn't do) is some Megabytes of C code in some of my projects. >>> >>> True, some C junkie might get off on having stdlib at their >>> disposal from Lisp, but that is completely unrelated to getting >>> bindings to Freeglut, and they should be getting those bindings >>> by making stdlib-binding.lisp and using VZN on that. >> >> Right. And VZN and ASDF may work together to do this. If VZN >> creates bindings for every single .h file / lib it finds and puts >> everything in a well-known place (a repository) then we're done. >> (see my other post on this). No? I wonder if I am still on the >> wrong thinking track ... >> > > Yes, I think you are not thinking "API". The "I" stands for > interface. Ideally, vzn would have access to something like > the .DEF files which tells VC++ which functions go in the DLL -- > well, maybe not. I like that vzn will get me into functions the > author did not think to export, because I ran into that with FTGL. > > Anyway, what track are you on that tells you a Lisp binding to > Freeglut should include strcat, even if it is neatly packaged in > stdlib-library.lisp? No, I do *not* want to have an all-in-one big file solution! I like VZN to generate the stdlib-library.lisp automatically because I said I want Freeglut and Freeglut depends on it. I thought it could work this way: 1. Look for dependencies in the bindings definition for the lib. 2. For all dependent libs generate the xxx-library.lisp file. Place them in a repository directory. 3. Generate ASDF code that insures dependencies are met and code is loaded when needed. This way, if I once have generated a stdlib-library.lisp file and I work on another project that also needs that lib, it is already there. > > Meanwhile, we already have a nice, easy solution to the 700k > thing.... what problem are you trying to solve by arguing for a > gross abuse of machine resources and binding readility? Well, partly because I have still not understood how VZN can find all dependent bindings and only those that are needed by the one lib I want to use. I still have that lib in my head that relies on 100 other libs where one particular type definition is specified in the 100th include file on the 20th include level. Reading VZN's code in detail certainly would help here but I have to admit I haven't done this yet. So, I beg pardon for being so stubborn or ignorant here. 73 (Ham radio code for: "best wishes and regards") Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht URL: From rayiner at gmail.com Sun Oct 9 20:35:02 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sun, 9 Oct 2005 16:35:02 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> References: <434646C4.50202@nyc.rr.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> <4348EE00.8080308@nyc.rr.com> <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> <4349633B.4070602@nyc.rr.com> <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> Message-ID: > No, I do *not* want to have an all-in-one big file solution! I like > VZN to generate the stdlib-library.lisp automatically because I said > I want Freeglut and Freeglut depends on it. I thought it could work > this way: > > 1. Look for dependencies in the bindings definition for the lib. > 2. For all dependent libs generate the xxx-library.lisp file. Place > them in a repository directory. > 3. Generate ASDF code that insures dependencies are met and code is > loaded when needed. > > This way, if I once have generated a stdlib-library.lisp file and I > work on another project that also needs that lib, it is already there. Yes, that would also work. Actually, Vzn has no way of knowing what constitutes a library, so you'd have to replace "lib" with "header file" in your algorithm, but the result would be the same. The question is whether the benefits are worth the tradeoff, the tradeoff being increased implementation complexity as well as tying users to ASDF. > Well, partly because I have still not understood how VZN can find all > dependent bindings and only those that are needed by the one lib I > want to use. I still have that lib in my head that relies on 100 > other libs where one particular type definition is specified in the > 100th include file on the 20th include level. Vzn's pruning pass makes sure that if the binding requires a definition from a header file that will not be included (as a whole) in the generated output, that at least the parts of the header that are required to make the binding work are still generated. Ie: if you want code generated for foo.h, and foo.h uses a typedef that is in bar.h (where bar.h is the aforementioned 100th include file, and is *not* going have bindings generated for it), then Vzn will still output that typedef from bar.h, even though bar.h will not be output as a whole into the binding. Code-wise, Vzn basically uses a tracing algorithm. It starts by taking the original set (the "everything" that the C compiler would see), and marking all definitions as "not reachable". It then goes through all the header files that the user wants bindings for (eg: gl.h, freeglut.h), and adds their definitions to a root set. It then recursively marks everything reachable from the root set. Finally, it prunes all definitions that weren't marked reachable. This does result in some duplicated definitions in library files (eg: most Windows libraries will define DWORD or something from the windows headers), but they are all in seperate packages, so the symbols don't conflict. Sincerely, Rayiner Hashem > > 73 (Ham radio code for: "best wishes and regards") > > Frank > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > > > From ktilton at nyc.rr.com Sun Oct 9 21:04:08 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 09 Oct 2005 17:04:08 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> References: <434646C4.50202@nyc.rr.com> <6043bfd00510070735j8461124u8bbde77671d67d4d@mail.gmail.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> <4348EE00.8080308@nyc.rr.com> <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> <4349633B.4070602@nyc.rr.com> <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> Message-ID: <434985C8.8070305@nyc.rr.com> Frank Goenninger - PRION Consulting wrote: > No, I do *not* want to have an all-in-one big file solution! I like > VZN to generate the stdlib-library.lisp automatically because I said > I want Freeglut and Freeglut depends on it. No, Freeglut.c (if you will) depends on stdlib.lib. Freeglut-library.lisp does not need anything in some stdlib.lisp, because of what I see Rayiner explained in another post: vzn navigates through everything to resolve typedefs. > Well, partly because I have still not understood how VZN can find all > dependent bindings and only those that are needed by the one lib I > want to use. VZN can do it because gccxml itself does the C thing and resolves everything. VZN then distills out just those things needed to generate the bindings. > I still have that lib in my head that relies on 100 other libs where > one particular type definition is specified in the 100th include file > on the 20th include level. Reading VZN's code in detail certainly > would help here but I have to admit I haven't done this yet. So, I > beg pardon for being so stubborn or ignorant here. No, we were just so far apart that it took a few iterations to get clear the point of confusion. I myself have not looked at Rayiner's code except to massage the run-command stuff to get error output so I can debug failures to generate XML. I recommend the design documents linked from the Fetter home page as a more approachable read. kt From rayiner at gmail.com Sun Oct 9 21:32:56 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sun, 9 Oct 2005 17:32:56 -0400 Subject: [fetter-devel] Possible solution for multiple includes In-Reply-To: <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> References: <434646C4.50202@nyc.rr.com> <43468CAA.3080203@nyc.rr.com> <9EC786EF-F3F5-40AE-B7EB-B8A8539C6F6B@prion.de> <30D13847-55BD-4274-97A1-2AF8DBFCDBD3@prion.de> <4348EE00.8080308@nyc.rr.com> <22AF6CF5-F3DB-411F-BD6D-DE802CF4AA9A@prion.de> <4349633B.4070602@nyc.rr.com> <11AEA5DE-A2D7-4982-8D2F-26DED932D01B@prion.de> Message-ID: > Well, partly because I have still not understood how VZN can find all > dependent bindings and only those that are needed by the one lib I > want to use. Oh, one thing I forgot to put in my original post. Vzn doesn't figure out the dependencies of each definition itself. Since the GCC-XML output is a dump of the GCC IR, dependencies between nodes have already been resolved and are explicit in the XML output. Consider a header like: #include BOOL DoSomething(LPCSTR fname); In the GCC-XML output, there would be several nodes, each with a unique ID and a marker identifying what file it is in. There would be, for example, a Typedef node for BOOL and a typedef node for LPCSTR, as well as a Function node for DoSomething. The DoSomething node will explicitly refer to the IDs of the BOOL and LPCSTR nodes. Therefore, when Vzn encounters the DoSomething node, and realizes it needs to emit definitions for BOOL or LPCSTR, Vzn knows exactly which definitions of BOOL and LPCSTR to use, and where to find them. > > 73 (Ham radio code for: "best wishes and regards") > > Frank > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > > > From joesb.coe9 at gmail.com Mon Oct 10 09:21:03 2005 From: joesb.coe9 at gmail.com (JoeSB COE9) Date: Mon, 10 Oct 2005 16:21:03 +0700 Subject: [fetter-devel] RE: Request for comments on new interface Message-ID: > Ideally, vzn would have access to something like the .DEF files > which tells VC++ which functions go in the DLL -- well, maybe not. I > like that vzn will get me into functions the author did not think to > export, because I ran into that with FTGL. I think this should be how the export was determined. We can use the combination of .h file and (.dll, .lib) file to determine what symbol to export. For example, instead of manually listing all the header files of wxWidgets as "wx.h" "wxframe.h" ... I could instead provide to .binding file with (include "wx.h" :bind :recursive) (export-lib "wxwidgets.dll") ;; Or may be this can be per-file option above. That way, VZN can see all the function declaration. (IMHO the format of dll export table is not too hard to parse.) Now what function will VZN export? It can determine what function it will export to wx.lisp by looking in wxwidgets.dll. If the function/class/type are in both wxwidgets.dll file and any .h files reachable from wx.h, then VZN should export it. For issue on a function that the orignal author didn't export, there you can have special option to do it; may be (include "wx.h" :bind :recursive :force-export ("unexported_func" "some_more_unexported_func")) But we should optimize for the general case. Also, to provide flexibility, we should also be able to generate a binding from just a header file. This is when we can fallback to the approach of manually listing all the header file we want the export symbol. Hope this is a sensible request. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayiner at gmail.com Mon Oct 10 18:04:31 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 10 Oct 2005 14:04:31 -0400 Subject: [fetter-devel] RE: Request for comments on new interface In-Reply-To: References: Message-ID: > That way, VZN can see all the function declaration. (IMHO the format of dll > export table is not too hard to parse.) > Now what function will VZN export? It can determine what function it will > export to wx.lisp by looking in > wxwidgets.dll. If the function/class/type are in both wxwidgets.dll file and any .h files > reachable from wx.h, then VZN should export it. The problem with doing this is that the .dll or the .so doesn't provide all of the information needed to determine what to export. It only contains information about exported functions and variables. It has no information on classes, structs, enumerations, #define's, etc. Provided with no other information, Vzn only has only one choice about what to do with any class, struct, etc, declarations: export them. So you're back to the situation where your freeglut.lisp includes every enumeration, struct and constant defined in windows.h. This will be a problem in practice. The original code in Vzn that pulled preprocessor declarations out of headers didn't subject them to the pruning pass, and the resultant files still took several minutes to compile with Allegro, even though the only extraneous items from windows.h were #define constants. So, even if you consult the .dll or .so to figure out what functions to export, the user will still have to specify from which headers to export all the other types of declarations, at which point you don't need to consult the .dll. Sincerely, Rayiner Hashem > > For issue on a function that the orignal author didn't export, there you can > have special option to do it; may be > > > (include "wx.h" :bind :recursive :force-export ("unexported_func" > "some_more_unexported_func")) > > But we should optimize for the general case. > > Also, to provide flexibility, we should also be able to generate a binding > from just a header file. > > This is when we can fallback to the approach of manually listing all the > header file we want the export symbol. > > Hope this is a sensible request. > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > > From ktilton at nyc.rr.com Thu Oct 13 22:18:23 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 13 Oct 2005 18:18:23 -0400 Subject: [fetter-devel] Paging VC++ gurus, or "C++ errors are soooo scrutable" Message-ID: <434EDD2F.8040204@nyc.rr.com> Recent discussion of wxCL had me wondering if Verrazano (vzn) could swallow wxWidgets. Here is the current state of the binding definition: (defbinding "wxWidgets-library" (nicknames "wx") (flags "-D__STDC__=0 -D__VISUALC__=1 -DWIN32 -D_DEBUG -D_CONSOLE -D_MBCS -I\\wxWidgets\\include -I\\wxWidgets\\lib\\vc_dll\\msw") (include "wx/wx.h")) [note to vzn cognoscenti: no, this will not produce any bindings until we get the new vzn which will have the option of binding recursively, but it fails the same way as when all the wx headers are listed so it will serve until I get a clean run.] [Aside: Bug report, probably obsolete: that long flags line causes an error from gccxml if broken across multiple lines. I say "obsolete" because the next release of vzn will make defbinding into a macro and the Lisp reader will be doing the parsing. Anywho...] Now wxWidgets is fine. I can build in VC++6 a wx demo such as Life without a problem. I have even created a VC++6 project for the intermediate vzntemp.cpp and /that/ compiles OK. What I learned along the way is to take the VC++ project options which produce a successful build (in this case:) /nologo /MLd /W3 /Gm /GX /ZI /Od /I "\wxwidgets\include" /I "\wxwidgets\lib\vc_dll\msw" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /FR"Debug/" /Fp"Debug/vzntemp.pch" /YX /Fo"Debug/" /Fd"Debug/" /FD /GZ /c ...and do my damnedest to recreate that in the flags option. This got me as far as a bunch of STRDUP undefined errors, which should bring no small delight to Frank , but a little digging in stdio.h suggested to me the additional define of __STDC__=0 would fix things, and it did nicely. (Ha! ) Apparently strdup is deprecated with extreme prejudice. Anyway, now I am down to this: In file included from /wxWidgets/include/wx/memory.h:20, from /wxWidgets/include/wx/object.h:25, from /wxWidgets/include/wx/wx.h:16, from C:/program files/acl70/vzntemp.cpp:1: /wxWidgets/include/wx/string.h:237: error: syntax error before `void' /wxWidgets/include/wx/string.h:242: error: semicolon missing after declaration of `wxStringData' /wxWidgets/include/wx/string.h:242: error: ISO C++ forbids defining types within return type /wxWidgets/include/wx/string.h:242: error: two or more data types in declaration of `Validate' /wxWidgets/include/wx/string.h:242: error: semicolon missing after declaration of `struct wxStringData' /wxWidgets/include/wx/string.h: In function `int Validate(bool)': /wxWidgets/include/wx/string.h:242: error: `nRefs' undeclared (first use this function) /wxWidgets/include/wx/string.h:242: error: (Each undeclared identifier is reported only once for each function it appears in.) /wxWidgets/include/wx/string.h: At global scope: /wxWidgets/include/wx/string.h:243: error: non-member function `bool IsValid()' cannot have `const' method qualifier /wxWidgets/include/wx/string.h:244: error: syntax error before `}' token /wxWidgets/include/wx/string.h: In member function `void wxStringBase::Reinit() ': /wxWidgets/include/wx/string.h:268: error: `Unlock' undeclared (first use this function) /wxWidgets/include/wx/string.h: In copy constructor ` wxStringBase::wxStringBase(const wxStringBase&)': /wxWidgets/include/wx/string.h:308: error: `IsValid' undeclared (first use this function) /wxWidgets/include/wx/string.h: In constructor ` wxStringBase::wxStringBase(const wxStringBase&, unsigned int, unsigned int) ': /wxWidgets/include/wx/string.h:333: error: `IsValid' undeclared (first use this function) /wxWidgets/include/wx/string.h: In destructor `wxStringBase::~wxStringBase()': /wxWidgets/include/wx/string.h:351: error: `Unlock' undeclared (first use this function) /wxWidgets/include/wx/string.h: In member function `wxStringBase& wxStringBase::insert(unsigned int, const wxStringBase&)': /wxWidgets/include/wx/string.h:443: error: `IsValid' undeclared (first use this function) /wxWidgets/include/wx/string.h: In member function `wxStringBase& wxStringBase::insert(unsigned int, const wxStringBase&, unsigned int, unsigned int)': /wxWidgets/include/wx/string.h:449: error: `IsValid' undeclared (first use this function) /wxWidgets/include/wx/string.h: In member function `wxString& wxString::operator<<(const wxString&)': /wxWidgets/include/wx/string.h:885: error: `IsValid' undeclared (first use this function) In file included from /wxWidgets/include/wx/window.h:1352, from /wxWidgets/include/wx/app.h:23, from /wxWidgets/include/wx/wx.h:24, from C:/program files/acl70/vzntemp.cpp:1: /wxWidgets/include/wx/msw/window.h: At global scope: /wxWidgets/include/wx/msw/window.h:54: error: class `wxWindow' is implicitly friends with itself Looking at string.h, well, "syntax error before void"? Any idea what flag I must be missing to get that? Two things I will be exploring: -- Is this a vzn known limitation in any way? ie, something on the to-do list? -- Do any of those project options translate to a define I have to add, a la __STDC__=0? I worked that one out by reading string.h, but "error before void" is not quite as helpful as "strdup undefined". Thx for even wild guesses at this point. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: STRING.H URL: From ktilton at nyc.rr.com Thu Oct 13 23:58:34 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 13 Oct 2005 19:58:34 -0400 Subject: [fetter-devel] Paging VC++ gurus, or "C++ errors are soooo scrutable" In-Reply-To: <434EDD2F.8040204@nyc.rr.com> References: <434EDD2F.8040204@nyc.rr.com> Message-ID: <434EF4AA.1050803@nyc.rr.com> It has been pointed out on c.l.l that I included the wrong string.h, that it is the wx string.h that is producing errors. I knew that . But the strdup problem was solved by staring at the sdtdlib string.h and that left my brain in the wrong gear when I made the post. kt Kenny Tilton wrote: > Recent discussion of wxCL had me wondering if Verrazano (vzn) could > swallow wxWidgets. Here is the current state of the binding definition: > > (defbinding "wxWidgets-library" > (nicknames "wx") > (flags "-D__STDC__=0 -D__VISUALC__=1 -DWIN32 -D_DEBUG -D_CONSOLE > -D_MBCS -I\\wxWidgets\\include -I\\wxWidgets\\lib\\vc_dll\\msw") > (include "wx/wx.h")) > > [note to vzn cognoscenti: no, this will not produce any bindings until > we get the new vzn which will have the option of binding recursively, > but it fails the same way as when all the wx headers are listed so it > will serve until I get a clean run.] > > [Aside: Bug report, probably obsolete: that long flags line causes an > error from gccxml if broken across multiple lines. I say "obsolete" > because the next release of vzn will make defbinding into a macro and > the Lisp reader will be doing the parsing. Anywho...] > > Now wxWidgets is fine. I can build in VC++6 a wx demo such as Life > without a problem. I have even created a VC++6 project for the > intermediate vzntemp.cpp and /that/ compiles OK. What I learned along > the way is to take the VC++ project options which produce a successful > build (in this case:) > > /nologo /MLd /W3 /Gm /GX /ZI /Od /I "\wxwidgets\include" /I > "\wxwidgets\lib\vc_dll\msw" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D > "_MBCS" /FR"Debug/" /Fp"Debug/vzntemp.pch" /YX /Fo"Debug/" /Fd"Debug/" > /FD /GZ /c > > ...and do my damnedest to recreate that in the flags option. This got > me as far as a bunch of STRDUP undefined errors, which should bring no > small delight to Frank , but a little digging in stdio.h suggested > to me the additional define of __STDC__=0 would fix things, and it did > nicely. (Ha! ) Apparently strdup is deprecated with extreme > prejudice. Anyway, now I am down to this: > > In file included from /wxWidgets/include/wx/memory.h:20, > from /wxWidgets/include/wx/object.h:25, > from /wxWidgets/include/wx/wx.h:16, > from C:/program files/acl70/vzntemp.cpp:1: > /wxWidgets/include/wx/string.h:237: error: syntax error before `void' > /wxWidgets/include/wx/string.h:242: error: semicolon missing after > declaration > of `wxStringData' > /wxWidgets/include/wx/string.h:242: error: ISO C++ forbids defining types > within return type > /wxWidgets/include/wx/string.h:242: error: two or more data types in > declaration of `Validate' > /wxWidgets/include/wx/string.h:242: error: semicolon missing after > declaration > of `struct wxStringData' > /wxWidgets/include/wx/string.h: In function `int Validate(bool)': > /wxWidgets/include/wx/string.h:242: error: `nRefs' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h:242: error: (Each undeclared identifier is > reported only once for each function it appears in.) > /wxWidgets/include/wx/string.h: At global scope: > /wxWidgets/include/wx/string.h:243: error: non-member function `bool > IsValid()' > cannot have `const' method qualifier > /wxWidgets/include/wx/string.h:244: error: syntax error before `}' token > /wxWidgets/include/wx/string.h: In member function `void > wxStringBase::Reinit() > ': > /wxWidgets/include/wx/string.h:268: error: `Unlock' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h: In copy constructor ` > wxStringBase::wxStringBase(const wxStringBase&)': > /wxWidgets/include/wx/string.h:308: error: `IsValid' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h: In constructor ` > wxStringBase::wxStringBase(const wxStringBase&, unsigned int, > unsigned int) > ': > /wxWidgets/include/wx/string.h:333: error: `IsValid' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h: In destructor > `wxStringBase::~wxStringBase()': > /wxWidgets/include/wx/string.h:351: error: `Unlock' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h: In member function `wxStringBase& > wxStringBase::insert(unsigned int, const wxStringBase&)': > /wxWidgets/include/wx/string.h:443: error: `IsValid' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h: In member function `wxStringBase& > wxStringBase::insert(unsigned int, const wxStringBase&, unsigned int, > unsigned int)': > /wxWidgets/include/wx/string.h:449: error: `IsValid' undeclared (first > use this > function) > /wxWidgets/include/wx/string.h: In member function `wxString& > wxString::operator<<(const wxString&)': > /wxWidgets/include/wx/string.h:885: error: `IsValid' undeclared (first > use this > function) > In file included from /wxWidgets/include/wx/window.h:1352, > from /wxWidgets/include/wx/app.h:23, > from /wxWidgets/include/wx/wx.h:24, > from C:/program files/acl70/vzntemp.cpp:1: > /wxWidgets/include/wx/msw/window.h: At global scope: > /wxWidgets/include/wx/msw/window.h:54: error: class `wxWindow' is > implicitly > friends with itself > > Looking at string.h, well, "syntax error before void"? > > Any idea what flag I must be missing to get that? Two things I will be > exploring: > > -- Is this a vzn known limitation in any way? ie, something on the > to-do list? > -- Do any of those project options translate to a define I have to > add, a la __STDC__=0? I worked that one out by reading string.h, but > "error before void" is not quite as helpful as "strdup undefined". > > Thx for even wild guesses at this point. > >------------------------------------------------------------------------ > >/*** >*string.h - declarations for string manipulation functions >* >* Copyright (c) 1985-1997, Microsoft Corporation. All rights reserved. >* >*Purpose: >* This file contains the function declarations for the string >* manipulation functions. >* [ANSI/System V] >* >* [Public] >* >****/ > >#if _MSC_VER > 1000 >#pragma once >#endif > >#ifndef _INC_STRING >#define _INC_STRING > >#if !defined(_WIN32) && !defined(_MAC) >#error ERROR: Only Mac or Win32 targets supported! >#endif > > >#ifdef __cplusplus >extern "C" { >#endif > > > >/* Define _CRTIMP */ > >#ifndef _CRTIMP >#ifdef _DLL >#define _CRTIMP __declspec(dllimport) >#else /* ndef _DLL */ >#define _CRTIMP >#endif /* _DLL */ >#endif /* _CRTIMP */ > >/* Define __cdecl for non-Microsoft compilers */ > >#if ( !defined(_MSC_VER) && !defined(__cdecl) ) >#define __cdecl >#endif > >/* Define _CRTAPI1 (for compatibility with the NT SDK) */ > >#ifndef _CRTAPI1 >#if _MSC_VER >= 800 && _M_IX86 >= 300 >#define _CRTAPI1 __cdecl >#else >#define _CRTAPI1 >#endif >#endif > > >#ifndef _SIZE_T_DEFINED >typedef unsigned int size_t; >#define _SIZE_T_DEFINED >#endif > > >#ifndef _MAC >#ifndef _WCHAR_T_DEFINED >typedef unsigned short wchar_t; >#define _WCHAR_T_DEFINED >#endif >#endif /* ndef _MAC */ > >#ifndef _NLSCMP_DEFINED >#define _NLSCMPERROR 2147483647 /* currently == INT_MAX */ >#define _NLSCMP_DEFINED >#endif > >/* Define NULL pointer value */ > >#ifndef NULL >#ifdef __cplusplus >#define NULL 0 >#else >#define NULL ((void *)0) >#endif >#endif > > >/* Function prototypes */ > >#ifdef _M_MRX000 >_CRTIMP void * __cdecl memcpy(void *, const void *, size_t); >_CRTIMP int __cdecl memcmp(const void *, const void *, size_t); >_CRTIMP void * __cdecl memset(void *, int, size_t); >_CRTIMP char * __cdecl _strset(char *, int); >_CRTIMP char * __cdecl strcpy(char *, const char *); >_CRTIMP char * __cdecl strcat(char *, const char *); >_CRTIMP int __cdecl strcmp(const char *, const char *); >_CRTIMP size_t __cdecl strlen(const char *); >#else > void * __cdecl memcpy(void *, const void *, size_t); > int __cdecl memcmp(const void *, const void *, size_t); > void * __cdecl memset(void *, int, size_t); > char * __cdecl _strset(char *, int); > char * __cdecl strcpy(char *, const char *); > char * __cdecl strcat(char *, const char *); > int __cdecl strcmp(const char *, const char *); > size_t __cdecl strlen(const char *); >#endif >_CRTIMP void * __cdecl _memccpy(void *, const void *, int, unsigned int); >_CRTIMP void * __cdecl memchr(const void *, int, size_t); >_CRTIMP int __cdecl _memicmp(const void *, const void *, unsigned int); > >#ifdef _M_ALPHA > /* memmove is available as an intrinsic in the Alpha compiler */ > void * __cdecl memmove(void *, const void *, size_t); >#else >_CRTIMP void * __cdecl memmove(void *, const void *, size_t); >#endif > > >_CRTIMP char * __cdecl strchr(const char *, int); >_CRTIMP int __cdecl _strcmpi(const char *, const char *); >_CRTIMP int __cdecl _stricmp(const char *, const char *); >_CRTIMP int __cdecl strcoll(const char *, const char *); >_CRTIMP int __cdecl _stricoll(const char *, const char *); >_CRTIMP int __cdecl _strncoll(const char *, const char *, size_t); >_CRTIMP int __cdecl _strnicoll(const char *, const char *, size_t); >_CRTIMP size_t __cdecl strcspn(const char *, const char *); >_CRTIMP char * __cdecl _strdup(const char *); >_CRTIMP char * __cdecl _strerror(const char *); >_CRTIMP char * __cdecl strerror(int); >_CRTIMP char * __cdecl _strlwr(char *); >_CRTIMP char * __cdecl strncat(char *, const char *, size_t); >_CRTIMP int __cdecl strncmp(const char *, const char *, size_t); >_CRTIMP int __cdecl _strnicmp(const char *, const char *, size_t); >_CRTIMP char * __cdecl strncpy(char *, const char *, size_t); >_CRTIMP char * __cdecl _strnset(char *, int, size_t); >_CRTIMP char * __cdecl strpbrk(const char *, const char *); >_CRTIMP char * __cdecl strrchr(const char *, int); >_CRTIMP char * __cdecl _strrev(char *); >_CRTIMP size_t __cdecl strspn(const char *, const char *); >_CRTIMP char * __cdecl strstr(const char *, const char *); >_CRTIMP char * __cdecl strtok(char *, const char *); >_CRTIMP char * __cdecl _strupr(char *); >_CRTIMP size_t __cdecl strxfrm (char *, const char *, size_t); > >#ifdef _MAC >unsigned char * __cdecl _c2pstr(char *); >char * __cdecl _p2cstr(unsigned char *); > >#if !__STDC__ >__inline unsigned char * __cdecl c2pstr(char *sz) { return _c2pstr(sz);}; >__inline char * __cdecl p2cstr(unsigned char *sz) { return _p2cstr(sz);}; >#endif >#endif > >#if !__STDC__ > >/* prototypes for oldnames.lib functions */ >_CRTIMP void * __cdecl memccpy(void *, const void *, int, unsigned int); >_CRTIMP int __cdecl memicmp(const void *, const void *, unsigned int); >_CRTIMP int __cdecl strcmpi(const char *, const char *); >_CRTIMP int __cdecl stricmp(const char *, const char *); >_CRTIMP char * __cdecl strdup(const char *); >_CRTIMP char * __cdecl strlwr(char *); >_CRTIMP int __cdecl strnicmp(const char *, const char *, size_t); >_CRTIMP char * __cdecl strnset(char *, int, size_t); >_CRTIMP char * __cdecl strrev(char *); > char * __cdecl strset(char *, int); >_CRTIMP char * __cdecl strupr(char *); > >#endif /* !__STDC__ */ > > >#ifndef _MAC >#ifndef _WSTRING_DEFINED > >/* wide function prototypes, also declared in wchar.h */ > >_CRTIMP wchar_t * __cdecl wcscat(wchar_t *, const wchar_t *); >_CRTIMP wchar_t * __cdecl wcschr(const wchar_t *, wchar_t); >_CRTIMP int __cdecl wcscmp(const wchar_t *, const wchar_t *); >_CRTIMP wchar_t * __cdecl wcscpy(wchar_t *, const wchar_t *); >_CRTIMP size_t __cdecl wcscspn(const wchar_t *, const wchar_t *); >_CRTIMP size_t __cdecl wcslen(const wchar_t *); >_CRTIMP wchar_t * __cdecl wcsncat(wchar_t *, const wchar_t *, size_t); >_CRTIMP int __cdecl wcsncmp(const wchar_t *, const wchar_t *, size_t); >_CRTIMP wchar_t * __cdecl wcsncpy(wchar_t *, const wchar_t *, size_t); >_CRTIMP wchar_t * __cdecl wcspbrk(const wchar_t *, const wchar_t *); >_CRTIMP wchar_t * __cdecl wcsrchr(const wchar_t *, wchar_t); >_CRTIMP size_t __cdecl wcsspn(const wchar_t *, const wchar_t *); >_CRTIMP wchar_t * __cdecl wcsstr(const wchar_t *, const wchar_t *); >_CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); > >_CRTIMP wchar_t * __cdecl _wcsdup(const wchar_t *); >_CRTIMP int __cdecl _wcsicmp(const wchar_t *, const wchar_t *); >_CRTIMP int __cdecl _wcsnicmp(const wchar_t *, const wchar_t *, size_t); >_CRTIMP wchar_t * __cdecl _wcsnset(wchar_t *, wchar_t, size_t); >_CRTIMP wchar_t * __cdecl _wcsrev(wchar_t *); >_CRTIMP wchar_t * __cdecl _wcsset(wchar_t *, wchar_t); > >_CRTIMP wchar_t * __cdecl _wcslwr(wchar_t *); >_CRTIMP wchar_t * __cdecl _wcsupr(wchar_t *); >_CRTIMP size_t __cdecl wcsxfrm(wchar_t *, const wchar_t *, size_t); >_CRTIMP int __cdecl wcscoll(const wchar_t *, const wchar_t *); >_CRTIMP int __cdecl _wcsicoll(const wchar_t *, const wchar_t *); >_CRTIMP int __cdecl _wcsncoll(const wchar_t *, const wchar_t *, size_t); >_CRTIMP int __cdecl _wcsnicoll(const wchar_t *, const wchar_t *, size_t); > >#if !__STDC__ > >/* old names */ >#define wcswcs wcsstr > >/* prototypes for oldnames.lib functions */ >_CRTIMP wchar_t * __cdecl wcsdup(const wchar_t *); >_CRTIMP int __cdecl wcsicmp(const wchar_t *, const wchar_t *); >_CRTIMP int __cdecl wcsnicmp(const wchar_t *, const wchar_t *, size_t); >_CRTIMP wchar_t * __cdecl wcsnset(wchar_t *, wchar_t, size_t); >_CRTIMP wchar_t * __cdecl wcsrev(wchar_t *); >_CRTIMP wchar_t * __cdecl wcsset(wchar_t *, wchar_t); >_CRTIMP wchar_t * __cdecl wcslwr(wchar_t *); >_CRTIMP wchar_t * __cdecl wcsupr(wchar_t *); >_CRTIMP int __cdecl wcsicoll(const wchar_t *, const wchar_t *); > >#endif /* !__STDC__ */ > >#define _WSTRING_DEFINED >#endif > >#endif /* ndef _MAC */ > >#ifdef __cplusplus >} >#endif > >#endif /* _INC_STRING */ > > >------------------------------------------------------------------------ > >_______________________________________________ >fetter-devel mailing list >fetter-devel at common-lisp.net >http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 From morrison at mak.com Wed Oct 19 04:08:40 2005 From: morrison at mak.com (John Morrison) Date: Wed, 19 Oct 2005 00:08:40 -0400 Subject: [fetter-devel] newbie question Message-ID: <200510190008.41003.morrison@mak.com> Short Version: Newbie trying to use verrazano on several MLOC C++ base and getting nil concrete-type-size. I will of course attempt to dive into the source and figure it out (I have read the documents). Is there anything else I should know that might save some time? Is there some instrumentation I should turn on to Get A Clue? Is this a surprising enough result that somebody wants the XML file? Longer Version: Verrazano from current CVS... Linux is FC2, kernel as below, SBCL 0.9.3-1. [jm at jmorrison jm]$ uname -a Linux jmorrison 2.6.10-1.771_FC2 #1 Mon Mar 28 00:50:14 EST 2005 i686 athlon i386 GNU/Linux [jm at jmorrison jm]$ rpm -qa sbcl sbcl-0.9.3-1 [jm at jmorrison jm]$ I turned on tracing of ANNOTATE-BASE-OFFSETS and CONCRETE-TYPE-SIZE, the latter of which seems to be returning a NIL to be added via incf. From what I can make out so far, nil is the :initform for the size slot of concrete-type. I guess it's not being set after initialize-instance time... Any hints for obvious places to look or routines to trace that might shed some light? In the absence of any suggestions, I will continue the obvious tactic of trying to retain the bug in an ever-smaller set of sources. While I have tried subsetting the source to the smallest subset that produces the error, the sources are vast and use darn near every dark corner of C++. Conversely, trying to reproduce it from tabula rasa seems like Not The Right Thing To Do. --- cut here [ several hundred lines of tracing snipped ] --- 0: (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 0: VERRAZANO::ANNOTATE-BASE-OFFSETS returned NIL 0: (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 0: VERRAZANO::ANNOTATE-BASE-OFFSETS returned NIL 0: (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 0: VERRAZANO::ANNOTATE-BASE-OFFSETS returned NIL 0: (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 0: VERRAZANO::ANNOTATE-BASE-OFFSETS returned NIL 0: (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 0: VERRAZANO::ANNOTATE-BASE-OFFSETS returned NIL 0: (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 1: (VERRAZANO::CONCRETE-TYPE-SIZE #) 1: VERRAZANO::CONCRETE-TYPE-SIZE returned NIL debugger invoked on a SIMPLE-ERROR in thread #: Error during processing of --eval option "(|LOAD| \"../genbind/foo.lisp\")": Argument Y is not a NUMBER: NIL Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Ignore and continue with next --eval option. 1: [ABORT ] Skip rest of --eval options. 2: Skip to toplevel READ/EVAL/PRINT loop. 3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((LAMBDA (SB-IMPL::E)) #) 0] :d ((LAMBDA (SB-IMPL::E)) #) 1] :d (SIGNAL #) 2] :d (ERROR SIMPLE-TYPE-ERROR) 3] :d (SB-KERNEL:TWO-ARG-+ 0 NIL) 4] :d (VERRAZANO::ANNOTATE-BASE-OFFSETS #) 5] (describe (sb-debug:arg 0)) # is an instance of class #. The following slots have :INSTANCE allocation: NAME "DtPduCallbackManager" C-NAME "20DtPduCallbackManager" NOTES # EDGES (# # # # # # # # # # # # ...) MARK T ORDER NIL SIZE 32800 ALIGN 32 --- cut here --- Thanks, -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 10 Fawcett Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm at mak.com From rayiner at gmail.com Wed Oct 19 06:13:38 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Wed, 19 Oct 2005 02:13:38 -0400 Subject: [fetter-devel] newbie question In-Reply-To: <200510190008.41003.morrison@mak.com> References: <200510190008.41003.morrison@mak.com> Message-ID: > Short Version: Newbie trying to use verrazano on several MLOC C++ base :-/ > and getting nil concrete-type-size. Hmm... > I will of course attempt to dive > into the source and figure it out (I have read the documents). Is > there anything else I should know that might save some time? The documentation on the IR and backend are fairly up-to-date, but there is little documentation for the simplifier. Basically, the code that handles C++ is at the end of simplifier.lisp, so if the problem is anywhere its there. I have a hunch that its related to virtual base classes being present in the inheritence graph. The current Vzn C++ code relies on GCC-XML to compute the sizes of classes so it can use them for object layout. The problem is that GCC-XML doesn't compute the sizes of "complicated" classes, specifically those that are the result of virtual inheritence. > Is there > some instrumentation I should turn on to Get A Clue? The create-binding call takes an optional parameter telling Vzn to dump all its internals to the terminal. This will dump the IR (pre and post simplification, I believe), as well as a lot of info about what Vzn things the class hierarchy looks like. > Is this a > surprising enough result that somebody wants the XML file? Is this particularly surprising? Not really. To tell the truth, the current C++ layout code is rather simplistic, and is being rewritten. It works okay for small libraries, but relies too much on GCC-XML to support certain cases. I don't regret the old code --- I think it was necessary to build something simple first before building something "proper", but I'm happy its going away. The new code is a very precise implementation of the GNU C++ and Visual C++ ABIs, and does all object and v-table layout itself, so it should fully support virtual inheritence. That said, I'm not a big fan of saying "the code is going away so let's not worry about its bugs". So go ahead and send me the XML file, and we'll see what we can see. The current version of Vzn's layout code won't allow access to virtually-inherited members, but it shouldn't crash either. Also, the XML file could be quite useful in testing the new layout code. > I turned on tracing of ANNOTATE-BASE-OFFSETS and CONCRETE-TYPE-SIZE, > the latter of which seems to be returning a NIL to be added via incf. > From what I can make out so far, nil is the :initform for the size > slot of concrete-type. I guess it's not being set after > initialize-instance time... Any hints for obvious places to look or > routines to trace that might shed some light? The only thing that sets the slot referred to by concrete-type-size is the with-concrete-type macro in parser.lisp. It's used for several node types in handlers.lisp (which is fairly self-explanatory --- there is one handler function for each IR type). If it doesn't get set in one of the handler functions (which might happen if the XML node has no "size" attribute --- Ie: GCC-XML doesn't compute it's size), then it'll be nil. So I'm pretty sure virtual inheritence is the case of the problems. Anyway, thanks for your detailed bug report and your interest in Vzn! Sincerely, Rayiner Hashem > ==== John Morrison > ==== MAK Technologies Inc. > ==== 10 Fawcett Street, Cambridge, MA 02138 > ==== http://www.mak.com/ > ==== vox:617-876-8085 x115 > ==== fax:617-876-9208 > ==== jm at mak.com > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From rayiner at gmail.com Wed Oct 19 06:46:55 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Wed, 19 Oct 2005 02:46:55 -0400 Subject: [fetter-devel] Status update for October 18 Message-ID: Hmm, the mailing list has been a little quiet lately, so for those curious about what's going on, here's a status update. Current development now is focused on a new framework for compiler-specific code. After familiarizing myself with the Visual C++ ABI, and comparing it to G++'s, I realized two things: 1) There are large similarities between the two that can lead to a lot of code-sharing; 2) The current code is in no shape to support either ABI completely, let alone both. Hence the need for the new framework, which basically amounts to a rewrite of Vzn's C++ support (the C support shouldn't be changed significantly, however). A lot of structural work that was necessary to implement this framework (specifically, isolating the frontend from the backend, isolating compiler-specific support, refactoring the CFFI backend) is done in my working copy. I can't put these into CVS until the new C++ code is done (it massively breaks the existing simplifier), so don't get worried that there hasn't been a CVS commit a couple of weeks :) Sincerely, Rayiner Hashem From john at synchromesh.com Wed Oct 19 09:00:29 2005 From: john at synchromesh.com (John Pallister) Date: Wed, 19 Oct 2005 22:00:29 +1300 Subject: [fetter-devel] Visual C++ ABI references In-Reply-To: References: Message-ID: <43560B2D.1000101@synchromesh.com> Hi Rayiner, I've been trying to learn about C++ ABIs on Windows for an FFI project of my own (for which Verrazano would be an almost ideal component). While the GCC interface is well-defined (cxxabi.h and a multi-vendor spec, what more could you ask for?), I haven't had as much luck with the Visual C++ ABI. I've found this MSDN article called "C++ Under the Hood" (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/jangrayhood.asp) from 1996 (i.e. Visual C++ 4.2), and a few nuggets from Raymond Chen's weblog (http://blogs.msdn.com/oldnewthing/default.aspx), but not much else. Can you suggest any additional references (preferably online)? I'm posting this to the list so that this can all be added to the general historical record. Trying out Vzn and CFFI on Corman Lisp is on my to-do list (http://johnp.net/blog/2005/10/16#corman-projects), but I don't know when I'll get to it... Thanks, and keep up the good work! John :^P -- John Pallister john at synchromesh.com From morrison at mak.com Wed Oct 19 13:29:20 2005 From: morrison at mak.com (John Morrison) Date: Wed, 19 Oct 2005 09:29:20 -0400 Subject: [fetter-devel] newbie question In-Reply-To: References: <200510190008.41003.morrison@mak.com> Message-ID: <200510190929.20746.morrison@mak.com> On Wednesday 19 October 2005 02:13 am, Rayiner Hashem wrote: > The documentation on the IR and backend are fairly up-to-date, but > there is little documentation for the simplifier. Basically, the code > that handles C++ is at the end of simplifier.lisp, so if the problem > is anywhere its there. I have a hunch that its related to virtual base > classes being present in the inheritence graph. The current Vzn C++ Oh, the source code uses just about every feature of the language to its, er, limits, so I should not be at all surprised if this were the case. However, while (using grep) I did not find any in the header files of the source code proper, it includes lots of 3rd party stuff (license management, STL, etc.). > code relies on GCC-XML to compute the sizes of classes so it can use > them for object layout. The problem is that GCC-XML doesn't compute > the sizes of "complicated" classes, specifically those that are the > result of virtual inheritence. FWIW, I asked Brad King about this (in the course of writing my own bindings generator), and he explained that due to such considerations as packing/padding, such sizes were computed/finalized in the processor-specific backend, so that they are not computable at GCC-XML's front-end location. > > Is there > > some instrumentation I should turn on to Get A Clue? > > The create-binding call takes an optional parameter telling Vzn to > dump all its internals to the terminal. This will dump the IR (pre and > post simplification, I believe), as well as a lot of info about what > Vzn things the class hierarchy looks like. I tried this, but since we land in the debugger before that is done at the end, it didn't get a chance to run, which is why I turned on the tracing... Is there something else I should have traced that would provide more info? > That said, I'm not a big fan of saying "the code is going away so > let's not worry about its bugs". So go ahead and send me the XML file, > and we'll see what we can see. The current version of Vzn's layout > code won't allow access to virtually-inherited members, but it > shouldn't crash either. Also, the XML file could be quite useful in > testing the new layout code. Thanks. I sent it under separate cover so as not to pollute inboxes around the globe. > The only thing that sets the slot referred to by concrete-type-size is > the with-concrete-type macro in parser.lisp. It's used for several > node types in handlers.lisp (which is fairly self-explanatory --- > there is one handler function for each IR type). If it doesn't get set > in one of the handler functions (which might happen if the XML node > has no "size" attribute --- Ie: GCC-XML doesn't compute it's size), > then it'll be nil. So I'm pretty sure virtual inheritence is the case > of the problems. OK. I will go look harder and see if I can find it -- today will suck, schedule-wise, so I will try to get to it within 24/48 hours or so. > Anyway, thanks for your detailed bug report and your interest in Vzn! As they say in geek-speak, I think you have the sign-bit flipped on that one -- thank *you* for Vzn! -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 10 Fawcett Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm at mak.com From joesb.coe9 at gmail.com Wed Oct 19 04:18:21 2005 From: joesb.coe9 at gmail.com (JoeSB COE9) Date: Wed, 19 Oct 2005 11:18:21 +0700 Subject: [fetter-devel] #define not exported Message-ID: Hi, I was trying to use VZN to make binding for SDL and Opengl. For SDL, VZN works fine, I can call function and get minimal window up. But when I tried to generate binding for OpenGL. I have gor some function but all value defined in #define are not exported; this is not the case with SDL. I come down to this minimal header file // includeme.h enum { aaa, bbb, } yoy; #define AN_DEF 1 And binding file ;; minimal.binding (defbinding "minimal-library" (flags "-ID:\\dev\\code\\lisp-systems\\sdl\\") (include "includeme.h") (export "") (override "")) And generate it with (verrazano:create-binding (verrazano:setup-build "d:\\dev\\tool\\gcc_xml\\bin\\gccxml.exe" #P"d:\\tmp\\") "minimal.binding" "minimal.lisp" :cffi-backend t) -------------------- What i get was ;; Minimal.lisp (defpackage "MINIMAL-LIBRARY" (:use #:CFFI) (:nicknames) (:export "$-0")) (in-package "MINIMAL-LIBRARY") (asdf:operate 'asdf:load-op 'verrazano-support) (cffi:defcenum $-0 (:aaa 0) (:bbb 1)) (cl:progn) ------------------- As you can see #define AN_DEF 1 is not in resulting binding code. Please help. From rayiner at gmail.com Sat Oct 22 22:37:37 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 22 Oct 2005 18:37:37 -0400 Subject: [fetter-devel] #define not exported In-Reply-To: References: Message-ID: It was a silly bug in the macro parser. It's fixed in CVS. Thanks for the report. Sincerely, Rayiner Hashem From rayiner at gmail.com Sat Oct 22 22:55:13 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sat, 22 Oct 2005 18:55:13 -0400 Subject: [fetter-devel] Re: Visual C++ ABI references In-Reply-To: <43560B2D.1000101@synchromesh.com> References: <43560B2D.1000101@synchromesh.com> Message-ID: > I've been trying to learn about C++ ABIs on Windows for an FFI project of my own > (for which Verrazano would be an almost ideal component). While the GCC > interface is well-defined (cxxabi.h and a multi-vendor spec, what more could you > ask for?), I haven't had as much luck with the Visual C++ ABI. > > I've found this MSDN article called "C++ Under the Hood" > (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/jangrayhood.asp) > from 1996 (i.e. Visual C++ 4.2), and a few nuggets from Raymond Chen's weblog > (http://blogs.msdn.com/oldnewthing/default.aspx), but not much else. Yes, this is the same article I'm using as my primary guide. > > Can you suggest any additional references (preferably online)? I'm posting this > to the list so that this can all be added to the general historical record. In theory the Visual C++ v-table format is the same as the COM one, but I can't seem to find the COM v-table spec clearly defined anywhere. Perhaps its in one of the MSDN references, but I haven't been able to find it online. What is tremendously useful is the WinDbg app, which has a command ("dt" for dump table), that dumps the virtual-table layout for any dynamic class. With a little consideration to the special cases of C++ v-table layout (specifically, simple multiple-inheritence, virtual inheritence, and empty-base-class or near-empty-base-class optimizations), a little fooling around in WinDbg should tell you everything you need to know. Sincerely, Rayiner Hashem > > Trying out Vzn and CFFI on Corman Lisp is on my to-do list > (http://johnp.net/blog/2005/10/16#corman-projects), but I don't know when I'll > get to it... > > Thanks, and keep up the good work! Thanks! Sincerely, Rayiner Hashem > > John :^P > -- > John Pallister > john at synchromesh.com > From immanuell at enfocus.be Thu Oct 27 14:06:56 2005 From: immanuell at enfocus.be (Immanuel Litzroth) Date: 27 Oct 2005 16:06:56 +0200 Subject: [fetter-devel] wrong code generated Message-ID: A header containing only: typedef long long unsigned int tp; generates: (defpackage "TEST" (:use #:CFFI) (:nicknames) (:export "TP")) (in-package "TEST") (asdf:operate 'asdf:load-op 'verrazano-support) (cffi:define-foreign-type tp () 'long long unsigned int) (cl:progn) which is nonsense to cffi. This is sbcl-0.9.6, fetter+cffi from cvs, linux. Immanuel *************************************************************************** I can, I can't. Tubbs Tattsyrup -- Immanuel Litzroth Software Development Engineer Enfocus Software Antwerpsesteenweg 41-45 9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Immanuell at enfocus.be web : www.enfocus.be *************************************************************************** From rayiner at gmail.com Thu Oct 27 17:38:22 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Thu, 27 Oct 2005 13:38:22 -0400 Subject: [fetter-devel] wrong code generated In-Reply-To: References: Message-ID: On 27 Oct 2005 16:06:56 +0200, Immanuel Litzroth wrote: > A header containing only: > typedef long long unsigned int tp; > generates: > (defpackage "TEST" (:use #:CFFI) (:nicknames) (:export "TP")) > > (in-package "TEST") > (asdf:operate 'asdf:load-op 'verrazano-support) > (cffi:define-foreign-type tp () 'long long unsigned int) > (cl:progn) > > which is nonsense to cffi. > This is sbcl-0.9.6, fetter+cffi from cvs, linux. Now, this is an interesting problem. There are a number of issues with "long long" that keep cropping up. To be pedantic, "long long" isn't a valid C++ type. This is not in and of itself a problem, because GCC-XML accepts it anyway and the only thing Vzn needs to do is have it in its type translation table (apparently, I've missed a few permutations of it, though). The bigger problem is that there is nothing sensible to map "long long" too, at least on a 32-bit system. On such a system, long long maps to a 64-bit word (a pair of 32-bit registers), and there is no way to express that in C-FFI. Anybody have any ideas? Sincerely, Rayiner Hashem > Immanuel > > *************************************************************************** > I can, I can't. > Tubbs Tattsyrup > > -- > Immanuel Litzroth > Software Development Engineer > Enfocus Software > Antwerpsesteenweg 41-45 > 9000 Gent > Belgium > Voice: +32 9 269 23 90 > Fax : +32 9 269 16 91 > Email: Immanuell at enfocus.be > web : www.enfocus.be > *************************************************************************** > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > From ktilton at nyc.rr.com Thu Oct 27 18:36:22 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 27 Oct 2005 14:36:22 -0400 Subject: [fetter-devel] wrong code generated In-Reply-To: References: Message-ID: <43611E26.6090702@nyc.rr.com> Rayiner Hashem wrote: >On 27 Oct 2005 16:06:56 +0200, Immanuel Litzroth wrote: > > >>A header containing only: >>typedef long long unsigned int tp; >>generates: >>(defpackage "TEST" (:use #:CFFI) (:nicknames) (:export "TP")) >> >>(in-package "TEST") >>(asdf:operate 'asdf:load-op 'verrazano-support) >>(cffi:define-foreign-type tp () 'long long unsigned int) >>(cl:progn) >> >>which is nonsense to cffi. >>This is sbcl-0.9.6, fetter+cffi from cvs, linux. >> >> > >Now, this is an interesting problem. There are a number of issues with >"long long" that keep cropping up. To be pedantic, "long long" isn't a >valid C++ type. This is not in and of itself a problem, because >GCC-XML accepts it anyway and the only thing Vzn needs to do is have >it in its type translation table (apparently, I've missed a few >permutations of it, though). The bigger problem is that there is >nothing sensible to map "long long" too, at least on a 32-bit system. >On such a system, long long maps to a 64-bit word (a pair of 32-bit >registers), and there is no way to express that in C-FFI. Anybody have >any ideas? > Sounds like CFFI needs an extension. What are other FFIs such as AllegroCL and CLisp doing? Will such a creature actually only work on a 64-bit system? If not, what do they become on 32-bit systems? Can they be treated benignly as 32-bit longs on 32-bit systems, failing only where runtime values actually exceed 32 bits? I am just hunting around for some imperfect solution that fails no more often than would using the library on a 32-but system even from a C client application. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950 From rayiner at gmail.com Thu Oct 27 19:55:28 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Thu, 27 Oct 2005 15:55:28 -0400 Subject: [fetter-devel] wrong code generated In-Reply-To: <43611E26.6090702@nyc.rr.com> References: <43611E26.6090702@nyc.rr.com> Message-ID: > Sounds like CFFI needs an extension. What are other FFIs such as > AllegroCL and CLisp doing? AllegroCL appears to have a long-long type that does the right thing. > Will such a creature actually only work on a 64-bit system? On a 64-bit system, "long long" can usually be mapped to the system's "long" type (which, in most OSs, is 64-bits). On Win64, the "long" type is still 32-bits, but from C-FFI's point of view, its still fairly simple to map it to an _int64 or whatever, since it'll still be a single machine word. > If not, what > do they become on 32-bit systems? They become a pair of words, stored in a pair of registers. For example, it'll be stored in EAX:EDX, then when it needs to be written to memory, two MOVDs will be issued, one for each register. > Can they be treated benignly as 32-bit > longs on 32-bit systems, failing only where runtime values actually > exceed 32 bits? It depends on the architecture, but at least on x86-32, the fact that arguments are passed on the stack will cause the FFI to have the wrong offsets for every parameter after the "long long". > I am just hunting around for some imperfect solution > that fails no more often than would using the library on a 32-but system > even from a C client application. The C client apps won't fail, simply because the compiler understands that "long longs" have to be treated specially. There are some hacks that could be done (transforming a single argument of type long long to a pair of arguments of type long), but they still can't handle return values properly (since there is no way to tell the FFI that a value is returned in two registers, not one). That said, I wonder if its worth more than just failing gracefully in this case. "Long long" is new to C99. Does that much code use it? > > > -- > Kenny > > Why Lisp? http://wiki.alu.org/RtL_Highlight_Film > > "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." > Elwood P. Dowd, "Harvey", 1950 > > > > From immanuell at enfocus.be Fri Oct 28 08:32:56 2005 From: immanuell at enfocus.be (Immanuel Litzroth) Date: Fri, 28 Oct 2005 09:32:56 +0100 Subject: [fetter-devel] wrong code generated In-Reply-To: (Rayiner Hashem's message of "Thu, 27 Oct 2005 15:55:28 -0400") References: <43611E26.6090702@nyc.rr.com> Message-ID: "Rayiner Hashem" writes: > That said, I wonder if its worth more than just failing gracefully in > this case. "Long long" is new to C99. Does that much code use it? This problem cropped up when I tried to create a binding to gtk+. Immanuel From jm at mak.com Fri Oct 28 20:50:27 2005 From: jm at mak.com (John Morrison) Date: Fri, 28 Oct 2005 16:50:27 -0400 Subject: [fetter-devel] wrong code generated In-Reply-To: <43611E26.6090702@nyc.rr.com> References: <43611E26.6090702@nyc.rr.com> Message-ID: <200510281650.27986.jm@mak.com> On Thursday 27 October 2005 02:36 pm, Kenny Tilton wrote: > Sounds like CFFI needs an extension. What are other FFIs such as That smells right to me, too. > AllegroCL and CLisp doing? > > Will such a creature actually only work on a 64-bit system? If not, what > do they become on 32-bit systems? Can they be treated benignly as 32-bit > longs on 32-bit systems, failing only where runtime values actually > exceed 32 bits? I am just hunting around for some imperfect solution > that fails no more often than would using the library on a 32-but system > even from a C client application. For what it's worth, on a 32-bit AMD Linux system, it seems like "long long" anything wants to be 8 bytes (see below)... I do vaguely remember doing an embedded system (JVM for a bare iron PC) where I ran into something like this, and I distantly recall gcc/g++ treating long longs as 8 byte quantities, and relying on runtime functions (libc?) to do operations on them (as opposed to using single x86 instructions as there were no 8 byte operand capable instructions available). I also distantly recall I had to reimplement them (licensing reasons). Of course, that was a couple of years (and several g++ revisions) ago. --- cut here --- [jm at jm4 tmp]$ cat sizes.cxx #include "stdio.h" int main(int argc, char *argv) { printf("sizeof(long)=%d\n", sizeof(long)); printf("sizeof(long long)=%d\n", sizeof(long long)); printf("sizeof(long long int)=%d\n", sizeof(long long int)); printf("sizeof(long long unsigned)=%d\n", sizeof(long long unsigned)); } [jm at jm4 tmp]$ g++ -o sizes sizes.cxx [jm at jm4 tmp]$ ./sizes sizeof(long)=4 sizeof(long long)=8 sizeof(long long int)=8 sizeof(long long unsigned)=8 [jm at jm4 tmp]$ --- cut here --- And the software I'm interested in bindings/calling via verrazano uses these various types... -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 10 Fawcett Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm at mak.com From morrison at mak.com Fri Oct 28 21:12:40 2005 From: morrison at mak.com (John Morrison) Date: Fri, 28 Oct 2005 17:12:40 -0400 Subject: [fetter-devel] wrong code generated In-Reply-To: <43611E26.6090702@nyc.rr.com> References: <43611E26.6090702@nyc.rr.com> Message-ID: <200510281712.40901.morrison@mak.com> Sorry if a duplicate -- first try, sent originally from not-subscribed email identity, bounced.. On Thursday 27 October 2005 02:36 pm, Kenny Tilton wrote: > Sounds like CFFI needs an extension. What are other FFIs such as That smells right to me, too. > AllegroCL and CLisp doing? > > Will such a creature actually only work on a 64-bit system? If not, what > do they become on 32-bit systems? Can they be treated benignly as 32-bit > longs on 32-bit systems, failing only where runtime values actually > exceed 32 bits? I am just hunting around for some imperfect solution > that fails no more often than would using the library on a 32-but system > even from a C client application. For what it's worth, on a 32-bit AMD Linux system, it seems like "long long" anything wants to be 8 bytes (see below)... I do vaguely remember doing an embedded system (JVM for a bare iron PC) where I ran into something like this, and I distantly recall gcc/g++ treating long longs as 8 byte quantities, and relying on runtime functions (libc?) to do operations on them (as opposed to using single x86 instructions as there were no 8 byte operand capable instructions available). I also distantly recall I had to reimplement them (licensing reasons). Of course, that was a couple of years (and several g++ revisions) ago. --- cut here --- [jm at jm4 tmp]$ cat sizes.cxx #include "stdio.h" int main(int argc, char *argv) { printf("sizeof(long)=%d\n", sizeof(long)); printf("sizeof(long long)=%d\n", sizeof(long long)); printf("sizeof(long long int)=%d\n", sizeof(long long int)); printf("sizeof(long long unsigned)=%d\n", sizeof(long long unsigned)); } [jm at jm4 tmp]$ g++ -o sizes sizes.cxx [jm at jm4 tmp]$ ./sizes sizeof(long)=4 sizeof(long long)=8 sizeof(long long int)=8 sizeof(long long unsigned)=8 [jm at jm4 tmp]$ --- cut here --- And the software I'm interested in bindings/calling via verrazano uses these various types... -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 10 Fawcett Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm at mak.com From john at synchromesh.com Fri Oct 28 22:33:09 2005 From: john at synchromesh.com (John Pallister) Date: Sat, 29 Oct 2005 11:33:09 +1300 Subject: [fetter-devel] Re: Visual C++ ABI references In-Reply-To: References: <43560B2D.1000101@synchromesh.com> Message-ID: <4362A725.60905@synchromesh.com> Rayiner Hashem wrote: >> I've found this MSDN article called "C++ Under the Hood" >> (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/jangrayhood.asp) >> from 1996 (i.e. Visual C++ 4.2), and a few nuggets from Raymond Chen's >> weblog (http://blogs.msdn.com/oldnewthing/default.aspx), but not much else. > > Yes, this is the same article I'm using as my primary guide. Curses, I was hoping you'd found something more recent. ;) >> Can you suggest any additional references (preferably online)? I'm posting >> this to the list so that this can all be added to the general historical >> record. > > In theory the Visual C++ v-table format is the same as the COM one, but I > can't seem to find the COM v-table spec clearly defined anywhere. Perhaps its > in one of the MSDN references, but I haven't been able to find it online. Raymond Chen discusses the layout of COM objects in his blog: http://blogs.msdn.com/oldnewthing/archive/2004/02/05/68017.aspx (requires Internet Explorer to view VML diagrams - couldn't just use SVG, oh no) With additional discussion of "adjustor thunks": http://blogs.msdn.com/oldnewthing/archive/2004/2/6.aspx Also, a good discussion of pointers to member functions: http://blogs.msdn.com/oldnewthing/archive/2004/02/09/70002.aspx > What is tremendously useful is the WinDbg app, which has a command ("dt" for > dump table), that dumps the virtual-table layout for any dynamic class. With > a little consideration to the special cases of C++ v-table layout > (specifically, simple multiple-inheritence, virtual inheritence, and > empty-base-class or near-empty-base-class optimizations), a little fooling > around in WinDbg should tell you everything you need to know. Excellent! That's great to know. In other news, I watched Herb Sutter's PDC talk (via http://www.gotw.ca/) and apparently lambda functions are coming to standard C++, "by the end of the decade." I think that's pretty cool. Cheers, John :^P -- John Pallister john at synchromesh.com From smustudent1 at yahoo.com Sun Oct 30 17:25:22 2005 From: smustudent1 at yahoo.com (C Y) Date: Sun, 30 Oct 2005 09:25:22 -0800 (PST) Subject: [fetter-devel] Couple of probably silly questions Message-ID: <20051030172522.90636.qmail@web31713.mail.mud.yahoo.com> Hi! I had a couple of questions about working with FFIs: a) If a library on (say) Windows has been compiled with Visual C++, and another with gcc in mingw, will I be able to access the functionality of both binary C++ libraries from Lisp and use both in the same application? b) Has anyone yet taken a crack at QT, or will that need the retooled C++ support? c) Does anybody know what the current status of GCL support? Is anybody still working on it or is GCL too far out of spec right now to be able to have any chance of handling it? Cheers, CY __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com