From: Donna a. D. S. <dan...@ie...> - 2004-11-30 13:16:32
|
I made a small modification to one of the files, so that the module now builds with 2.33.2. Dan Stanger |
From: Reini U. <ru...@x-...> - 2004-11-30 13:48:54
|
Donna and Dan Stanger schrieb: > I made a small modification to one of the files, so that the module > now builds with 2.33.2. great! how about my inclusion request into clisp? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Sam S. <sd...@gn...> - 2004-11-30 14:35:06
|
> * Reini Urban <eh...@k-...> [2004-11-30 14:48:53 +0100]: > > Donna and Dan Stanger schrieb: >> I made a small modification to one of the files, so that the module >> now builds with 2.33.2. > > how about my inclusion request into clisp? I am willing to include any general-interest module that builds OOTB. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Save your burned out bulbs for me, I'm building my own dark room. |
From: Reini U. <ru...@x-...> - 2006-08-13 17:33:28
|
Donna and Dan Stanger schrieb: > I made a small modification to one of the files, so that the module > now builds with 2.33.2. > Dan Stanger Hi Dan, I made some small modifications, so that your latest and abandoned gdi module from 2004-12-01 builds under the latest clisp-2.39 cygwin. mingw probably also. I'll provide a seperate clisp-fullgui cygwin package then, with just a new linkset fullgui, containing new-clx and gdi. I want to take gdi over now and submit it to clisp CVS. Ok for you Sam? The functions in the xml are missing and a lot of tests and higher-level functions. I want to generate function list for the xml automatically. Is there already a util somewhere? Todo: Fix warnings. Test existing code. Some coverage. Add more message handling code. Finish the process*, output* routines. Write more examples, and documentation. Download: http://xarch.tu-graz.ac.at/publ/cygwin/release/clisp/gdi-0.2.tar.bz2 -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
From: Jack U. <jd...@gm...> - 2006-08-13 18:34:05
|
On 8/13/06, Reini Urban <ru...@x-...> wrote: > Donna and Dan Stanger schrieb: > > I made a small modification to one of the files, so that the module > > now builds with 2.33.2. > > Dan Stanger > > Hi Dan, > I made some small modifications, so that your latest and abandoned gdi > module from 2004-12-01 builds under the latest clisp-2.39 cygwin. > mingw probably also. > > I'll provide a seperate clisp-fullgui cygwin package then, with just a > new linkset fullgui, containing new-clx and gdi. Just FYI, but I have implemented a binding for GDI as part of Graphic-Forms, with some abstractions on top of that. I'm not arguing against including a GDI module in CLISP, just pointing out that my library is available for CLISP, too. http://common-lisp.net/project/graphic-forms -- Jack Unrue |
From: Sam S. <sd...@po...> - 2006-08-13 18:34:16
|
> * Reini Urban <eh...@k-...> [2006-08-13 19:34:01 +0200]: > > I'll provide a seperate clisp-fullgui cygwin package then, with just a > new linkset fullgui, containing new-clx and gdi. please go ahead, it would be interesting to see if people actually use the GDI module. unless there is evidence that people find this module useful, there is no reason to include it in the distribution. > I want to take gdi over now and submit it to clisp CVS. > Ok for you Sam? What I do not like about the GDI module, as it is right now (leaving alone the packaging issue that all files are executable): 1. why modprep and not FFI? http://clisp.cons.org/impnotes/modules.html#mod-ffi-vs-c since this module is woe32-only, the only argument for modprep is speed. are the gdi functions tiny, computationally trivial, and frequently called in a loop for the FFI overhead to matter? 2. the generated code is broken in some ways. e.g.: arg = popSTACK(); check_sint(arg); int1 = I_to_sint32(arg); should be int1 = I_to_sint32(check_sint32(popSTACK())) because check_sint32() actually returns value. also, #define encoding (C_terminal_encoding(),value1) in gdi.m (why ".m"?!) is wrong, use GLO(terminal_encoding) instead. there are quite a few smaller issues, e.g.: * argumentum_inritum() should be replaced with appropriate check_* functions. * functions should be named in the Lisp style: CREATE-ENH-METAFILE instead of CREATEENHMETAFILEA and CREATE-ELLIPTIC-RGN-INDIRECT instead of CREATEELLIPTICRGNINDIRECT. * "RECT* lpcrect = alloca(sizeof(RECT));" should be "RECT rect, lpcrect=▭" * "return;" at the end of each function should be eliminated * VALUES1, VALUES2 &c should be used * the "return" idiom appears to be: if(!bool0){ DWORD e; begin_system_call(); e = GetLastError(); end_system_call(); value1 = NIL; value2 = uint32_to_I(e); mv_count=2; } else { value1 = T; mv_count=1; } it should be abstracted to a function for ease of reading and code size; also, I would prefer a symbollic rather than numeric return value, you can use DEFCHECKER for that; also, you do not need to use 2 values to indicate the error: success means T, failure means everything else. 3. I am not sure awk is the right tool to parse C headers. Maybe SWIG could be used instead? It already can generate CLISP FFI, and adding functionality to generate C would be useful too. -- Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux) http://openvotingconsortium.org http://palestinefacts.org http://israelnorthblog.livejournal.com http://honestreporting.com MS DOS: Keyboard not found. Press F1 to continue. |
From: Sam S. <sd...@gn...> - 2006-08-14 14:09:41
|
Sam Steingold wrote: > * the "return" idiom appears to be: > > if(!bool0){ > DWORD e; > begin_system_call(); > e = GetLastError(); > end_system_call(); > value1 = NIL; > value2 = uint32_to_I(e); > mv_count=2; > } > else > { > value1 = T; > mv_count=1; > } > > it should be abstracted to a function for ease of reading and code > size; also, I would prefer a symbollic rather than numeric return > value, you can use DEFCHECKER for that; also, you do not need to use > 2 values to indicate the error: success means T, failure means > everything else. actually, the first branch should just signal an error instead of returning a value. |