From: Philippe B. <ho...@fr...> - 2008-11-29 22:52:23
|
Hi, I've been able to run most of the McCLIM applications and my own CLIM application with clisp/new-clx. I've experienced a freeze on drag'n drop which can be solved on the McCLIM side. And a problem with keys input. The problem comes from XLIB:KEYSYM->CHARACTER. Here is a patch to solve this bug: -- 8< cut here ------------------------------------------------------- Index: modules/clx/new-clx/clx.f =================================================================== RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/clx.f,v retrieving revision 2.162 diff -u -w -p -r2.162 clx.f --- modules/clx/new-clx/clx.f 17 Nov 2008 18:47:11 -0000 2.162 +++ modules/clx/new-clx/clx.f 29 Nov 2008 22:41:16 -0000 @@ -7291,6 +7291,7 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke { Display *dpy; KeySym keysym; + object ret; /* FIXME for now we ignore the state argument: */ skipSTACK(1); @@ -7298,9 +7299,27 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke keysym = get_uint32 (popSTACK()); dpy = pop_display (); /* Too wired -- I have to browse some more in the manuals ... Back soon. */ - VALUES1(int_char(keysym)); /* how about just int_char ?! */ + + if (keysym >= 0x0020 && keysym <= 0x00ff) + ret = int_char (keysym); + else + switch (keysym) + { + case 0xFF08: ret = code_char(0x08); break; /* Backspace */ + case 0xFF09: ret = code_char(0x09); break; /* Tab */ + case 0xFF0A: ret = code_char(0x0A); break; /* Linefeed */ + case 0xFF0D: ret = code_char(0x0D); break; /* Return */ + case 0xFFFF: ret = code_char(0x7F); break; /* Delete, Rubout */ + default: ret = NIL; + } + + /* VALUES1(int_char (keysym & 0x00FF)); */ /* how about just int_char ?! */ + VALUES1(ret); } + + + DEFUN(XLIB:KEYSYM-NAME, keysym) { /* http://www.xfree86.org/current/XStringToKeysym.3.html */ KeySym keysym = get_uint32(popSTACK()); -- 8< cut here ------------------------------------------------------- And the associated test case: -- 8< cut here ------------------------------------------------------- (xlib:with-open-display (dpy) (list (xlib:keysym->character dpy 97) ; #\a (xlib:keysym->character dpy #xFF08) ; #\Backspace (xlib:keysym->character dpy #xFF09) ; #\Tab (xlib:keysym->character dpy #xFF0A) ; #\Newline (xlib:keysym->character dpy #xFF0D) ; #\Return (xlib:keysym->character dpy #xFFFF) ; #\Rubout (xlib:keysym->character dpy #xFF51))) ; #\Left (#\a #\Backspace #\Tab #\Newline #\Return #\Rubout NIL) -- 8< cut here ------------------------------------------------------- A thing to note: It seems that the optional state argument is not used in CLX any more. Regards, Philippe |
From: Sam S. <sd...@gn...> - 2008-11-30 04:13:35
|
Hi, > * Philippe Brochard <ub...@se...> [2008-11-29 23:52:16 +0100]: > > I've been able to run most of the McCLIM applications and my own > CLIM application with clisp/new-clx. great! > I've experienced a freeze on drag'n drop which can be solved on the > McCLIM side. And a problem with keys input. The problem comes from > XLIB:KEYSYM->CHARACTER. Here is a patch to solve this bug: > > -- 8< cut here ------------------------------------------------------- > Index: modules/clx/new-clx/clx.f > =================================================================== > RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/clx.f,v > retrieving revision 2.162 > diff -u -w -p -r2.162 clx.f > --- modules/clx/new-clx/clx.f 17 Nov 2008 18:47:11 -0000 2.162 > +++ modules/clx/new-clx/clx.f 29 Nov 2008 22:41:16 -0000 > @@ -7291,6 +7291,7 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke > { > Display *dpy; > KeySym keysym; > + object ret; > > /* FIXME for now we ignore the state argument: */ > skipSTACK(1); > @@ -7298,9 +7299,27 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke > keysym = get_uint32 (popSTACK()); > dpy = pop_display (); > /* Too wired -- I have to browse some more in the manuals ... Back soon. */ > - VALUES1(int_char(keysym)); /* how about just int_char ?! */ > + > + if (keysym >= 0x0020 && keysym <= 0x00ff) > + ret = int_char (keysym); > + else > + switch (keysym) > + { > + case 0xFF08: ret = code_char(0x08); break; /* Backspace */ > + case 0xFF09: ret = code_char(0x09); break; /* Tab */ > + case 0xFF0A: ret = code_char(0x0A); break; /* Linefeed */ > + case 0xFF0D: ret = code_char(0x0D); break; /* Return */ > + case 0xFFFF: ret = code_char(0x7F); break; /* Delete, Rubout */ > + default: ret = NIL; > + } I don't like this cruft. how did you come up with it? using xev(1)? or something lispy? I would much prefer name_char(XKeysymToString(keysym)) instead of this switch: --- clx.f.~2.162.~ 2008-11-17 23:02:32.000000000 -0500 +++ clx.f 2008-11-29 22:46:10.000000000 -0500 @@ -7287,6 +7287,16 @@ DEFUN(XLIB:KEYCODE->KEYSYM, display keyc and unicode?! I really want unicode support. */ +static object keysym2char (KeySym keysym) { + /* how about just int_char ?! - won't work for things like #xFFFF=#\Rubout */ + char *name; + X_CALL(name = XKeysymToString(keysym)); + if (name == NULL) return int_char(keysym); + else { + object ch = funcall1(L(name_char),asciz_to_string(name,GLO(misc_encoding))); + return nullp(ch) ? int_char(keysym) : ch; + } +} DEFUN(XLIB:KEYSYM->CHARACTER, display keysym &optional state) { Display *dpy; @@ -7298,7 +7308,7 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke keysym = get_uint32 (popSTACK()); dpy = pop_display (); /* Too wired -- I have to browse some more in the manuals ... Back soon. */ - VALUES1(int_char(keysym)); /* how about just int_char ?! */ + VALUES1(keysym2char(keysym)); } DEFUN(XLIB:KEYSYM-NAME, keysym) @@ -7378,7 +7388,7 @@ DEFUN(XLIB:KEYCODE->CHARACTER, display k skipSTACK(5); } /* state is ignored, just like in keysym->character */ - VALUES1(int_char(keycode2keysym(dpy,keycode,index))); + VALUES1(keysym2char(keycode2keysym(dpy,keycode,index))); } /* 14.5 Client Termination */ note that name_char is slow compared with int_char and this this patch is not suitable if keysym->character is performance-critical. > + /* VALUES1(int_char (keysym & 0x00FF)); */ /* how about just int_char ?! */ > + VALUES1(ret); > } > > -- 8< cut here ------------------------------------------------------- > > > And the associated test case: > > -- 8< cut here ------------------------------------------------------- > (xlib:with-open-display (dpy) > (list (xlib:keysym->character dpy 97) ; #\a > (xlib:keysym->character dpy #xFF08) ; #\Backspace > (xlib:keysym->character dpy #xFF09) ; #\Tab > (xlib:keysym->character dpy #xFF0A) ; #\Newline > (xlib:keysym->character dpy #xFF0D) ; #\Return > (xlib:keysym->character dpy #xFFFF) ; #\Rubout > (xlib:keysym->character dpy #xFF51))) ; #\Left > (#\a #\Backspace #\Tab #\Newline #\Return #\Rubout NIL) > -- 8< cut here ------------------------------------------------------- with my patch I get this: (#\a #\Backspace #\Tab #\Newline #\Return #\Rubout #\FULLWIDTH_LATIN_SMALL_LETTER_Q) this, of course, leaves much to be desired: home, end, page up/down, arrows, function keys... -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://israelunderattack.slide.com http://pmw.org.il http://memri.org http://thereligionofpeace.com http://openvotingconsortium.org Never trust a man who can count to 1024 on his fingers. |
From: Philippe B. <ho...@fr...> - 2008-11-30 12:43:36
|
Sam Steingold writes: > Hi, > > > * Philippe Brochard <ub...@se...> [2008-11-29 23:52:16 +0100]: > > > > I've been able to run most of the McCLIM applications and my own > > CLIM application with clisp/new-clx. > > great! > > > I've experienced a freeze on drag'n drop which can be solved on the > > McCLIM side. And a problem with keys input. The problem comes from > > XLIB:KEYSYM->CHARACTER. Here is a patch to solve this bug: > > > > -- 8< cut here ------------------------------------------------------- > > Index: modules/clx/new-clx/clx.f > > =================================================================== > > RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/clx.f,v > > retrieving revision 2.162 > > diff -u -w -p -r2.162 clx.f > > --- modules/clx/new-clx/clx.f 17 Nov 2008 18:47:11 -0000 2.162 > > +++ modules/clx/new-clx/clx.f 29 Nov 2008 22:41:16 -0000 > > @@ -7291,6 +7291,7 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke > > { > > Display *dpy; > > KeySym keysym; > > + object ret; > > > > /* FIXME for now we ignore the state argument: */ > > skipSTACK(1); > > @@ -7298,9 +7299,27 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke > > keysym = get_uint32 (popSTACK()); > > dpy = pop_display (); > > /* Too wired -- I have to browse some more in the manuals ... Back soon. */ > > - VALUES1(int_char(keysym)); /* how about just int_char ?! */ > > + > > + if (keysym >= 0x0020 && keysym <= 0x00ff) > > + ret = int_char (keysym); > > + else > > + switch (keysym) > > + { > > + case 0xFF08: ret = code_char(0x08); break; /* Backspace */ > > + case 0xFF09: ret = code_char(0x09); break; /* Tab */ > > + case 0xFF0A: ret = code_char(0x0A); break; /* Linefeed */ > > + case 0xFF0D: ret = code_char(0x0D); break; /* Return */ > > + case 0xFFFF: ret = code_char(0x7F); break; /* Delete, Rubout */ > > + default: ret = NIL; > > + } > > I don't like this cruft. > how did you come up with it? > using xev(1)? > or something lispy? > I take it from modules/clx/mit-clx/keysyms.lisp. Those values are hardcoded in this file. In fact McCLIM expect that there is a very fiew number of 'special keys' (return, tab, linefeed,...) that have an associated character. It attempt that all others (Left, Home,...) return a NIL value. > I would much prefer name_char(XKeysymToString(keysym)) instead of this > switch: > This will work but you have to limit it to the 5 specials keysyms defined in my switch to make it work with the current McCLIM. In fact, what are the unicode characters associated with Left, Home, function keys...? [...] > > And the associated test case: > > > > -- 8< cut here ------------------------------------------------------- > > (xlib:with-open-display (dpy) > > (list (xlib:keysym->character dpy 97) ; #\a > > (xlib:keysym->character dpy #xFF08) ; #\Backspace > > (xlib:keysym->character dpy #xFF09) ; #\Tab > > (xlib:keysym->character dpy #xFF0A) ; #\Newline > > (xlib:keysym->character dpy #xFF0D) ; #\Return > > (xlib:keysym->character dpy #xFFFF) ; #\Rubout > > (xlib:keysym->character dpy #xFF51))) ; #\Left > > (#\a #\Backspace #\Tab #\Newline #\Return #\Rubout NIL) > > -- 8< cut here ------------------------------------------------------- > > with my patch I get this: > > (#\a #\Backspace #\Tab #\Newline #\Return #\Rubout > #\FULLWIDTH_LATIN_SMALL_LETTER_Q) > This will not work with the current McCLIM since #\FULLWIDTH_LATIN_SMALL_LETTER_Q is not related to the Left arrow. A NIL value is required or maybe a #\Left-Arrow. > this, of course, leaves much to be desired: home, end, page up/down, > arrows, function keys... > They're not needed by the current McCLIM. But maybe there is a need to change McCLIM to accept unicode characters associated to keysyms. |
From: Sam S. <sd...@gn...> - 2008-11-30 16:31:28
|
> * Philippe Brochard <ub...@se...> [2008-11-30 13:43:28 +0100]: > Sam Steingold writes: >> > * Philippe Brochard <ub...@se...> [2008-11-29 23:52:16 +0100]: > I take it from modules/clx/mit-clx/keysyms.lisp. Those values are > hardcoded in this file. In fact McCLIM expect that there is a very that's better - so this is a piece of general clx cruft, not specific to new-clx. > fiew number of 'special keys' (return, tab, linefeed,...) that have an > associated character. It attempt that all others (Left, Home,...) > return a NIL value. OK, how about this: --- clx.f.~2.162.~ 2008-11-17 23:02:32.000000000 -0500 +++ clx.f 2008-11-30 11:27:06.000000000 -0500 @@ -7287,6 +7287,14 @@ DEFUN(XLIB:KEYCODE->KEYSYM, display keyc and unicode?! I really want unicode support. */ +static object keysym2char (KeySym keysym) { + /* how about just int_char ?! - won't work for things like #xFFFF=#\Rubout */ + char *name; + X_CALL(name = XKeysymToString(keysym)); + return name + ? funcall1(L(name_char),asciz_to_string(name,GLO(misc_encoding))) + : int_char(keysym); +} DEFUN(XLIB:KEYSYM->CHARACTER, display keysym &optional state) { Display *dpy; @@ -7298,7 +7306,7 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke keysym = get_uint32 (popSTACK()); dpy = pop_display (); /* Too wired -- I have to browse some more in the manuals ... Back soon. */ - VALUES1(int_char(keysym)); /* how about just int_char ?! */ + VALUES1(keysym2char(keysym)); } DEFUN(XLIB:KEYSYM-NAME, keysym) @@ -7378,7 +7386,7 @@ DEFUN(XLIB:KEYCODE->CHARACTER, display k skipSTACK(5); } /* state is ignored, just like in keysym->character */ - VALUES1(int_char(keycode2keysym(dpy,keycode,index))); + VALUES1(keysym2char(keycode2keysym(dpy,keycode,index))); } /* 14.5 Client Termination */ > In fact, what are the unicode characters associated with Left, Home, > function keys...? nothing for Home or function keys, but... 2190;LEFTWARDS ARROW;Sm;0;ON;;;;;N;LEFT ARROW;;;; 2191;UPWARDS ARROW;Sm;0;ON;;;;;N;UP ARROW;;;; 2192;RIGHTWARDS ARROW;Sm;0;ON;;;;;N;RIGHT ARROW;;;; 2193;DOWNWARDS ARROW;Sm;0;ON;;;;;N;DOWN ARROW;;;; 2397;PREVIOUS PAGE;So;0;ON;;;;;N;;;;; 2398;NEXT PAGE;So;0;ON;;;;;N;;;;; -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://palestinefacts.org http://dhimmi.com http://camera.org http://ffii.org http://jihadwatch.org http://honestreporting.com http://thereligionofpeace.com Modern man is the missing link between apes and human beings. |
From: Sam S. <sd...@gn...> - 2008-12-01 16:22:04
|
please take a look at the cvs head thanks |
From: Sam S. <sd...@gn...> - 2008-12-01 22:39:23
|
Philippe Brochard wrote: > Sam Steingold writes: >> please take a look at the cvs head >> > Works perfectly! And thanks for the keysym exploration. Things are so, can new-clx run mcclim now? you said that a small change to mcclim was necessary - did they make the change? > less approximate now. Maybe I find the hexadecimal notation more > expressive but it's just a matter of taste. ok, I switched to hex. |
From: Sam S. <sd...@gn...> - 2008-12-02 23:19:40
|
Philippe Brochard wrote: > > A question: did new-clx must have the same behaviour than mit-clx? yes, it would be nice if that were true. > Because here, in McCLIM, they doesn't do the same thing with the same > code. can you isolate and debug this discrepancy? |
From: Philippe B. <ho...@fr...> - 2008-11-30 22:28:49
|
Sam Steingold writes: > > * Philippe Brochard <ub...@se...> [2008-11-30 13:43:28 +0100]: > > Sam Steingold writes: > >> > * Philippe Brochard <ub...@se...> [2008-11-29 23:52:16 +0100]: > > I take it from modules/clx/mit-clx/keysyms.lisp. Those values are > > hardcoded in this file. In fact McCLIM expect that there is a very > > that's better - so this is a piece of general clx cruft, not specific to > new-clx. > > > fiew number of 'special keys' (return, tab, linefeed,...) that have an > > associated character. It attempt that all others (Left, Home,...) > > return a NIL value. > > OK, how about this: [...] This doesn't work for me with the "a" keysym. Here is a modified version: Index: modules/clx/new-clx/clx.f =================================================================== RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/clx.f,v retrieving revision 2.162 diff -u -w -p -r2.162 clx.f --- modules/clx/new-clx/clx.f 17 Nov 2008 18:47:11 -0000 2.162 +++ modules/clx/new-clx/clx.f 30 Nov 2008 22:19:07 -0000 @@ -7287,6 +7287,20 @@ DEFUN(XLIB:KEYCODE->KEYSYM, display keyc and unicode?! I really want unicode support. */ +static object keysym2char (KeySym keysym) { + /* how about just int_char ?! - won't work for things like #xFFFF=#\Rubout */ + char *name; + X_CALL(name = XKeysymToString(keysym)); + + if (name) + { + object ret = funcall1(L(name_char),asciz_to_string(name,GLO(misc_encoding))); + if (eq(ret, NIL)) + return ((keysym >= 0x0020 && keysym <= 0x00FF) ? int_char(keysym) : NIL); + else return ret ; + } + return NIL; +} DEFUN(XLIB:KEYSYM->CHARACTER, display keysym &optional state) { Display *dpy; @@ -7298,7 +7312,7 @@ DEFUN(XLIB:KEYSYM->CHARACTER, display ke keysym = get_uint32 (popSTACK()); dpy = pop_display (); /* Too wired -- I have to browse some more in the manuals ... Back soon. */ - VALUES1(int_char(keysym)); /* how about just int_char ?! */ + VALUES1(keysym2char(keysym)); } DEFUN(XLIB:KEYSYM-NAME, keysym) @@ -7378,7 +7392,7 @@ DEFUN(XLIB:KEYCODE->CHARACTER, display k skipSTACK(5); } /* state is ignored, just like in keysym->character */ - VALUES1(int_char(keycode2keysym(dpy,keycode,index))); + VALUES1(keysym2char(keycode2keysym(dpy,keycode,index))); } /* 14.5 Client Termination */ > > In fact, what are the unicode characters associated with Left, Home, > > function keys...? > > nothing for Home or function keys, but... > > 2190;LEFTWARDS ARROW;Sm;0;ON;;;;;N;LEFT ARROW;;;; > 2191;UPWARDS ARROW;Sm;0;ON;;;;;N;UP ARROW;;;; > 2192;RIGHTWARDS ARROW;Sm;0;ON;;;;;N;RIGHT ARROW;;;; > 2193;DOWNWARDS ARROW;Sm;0;ON;;;;;N;DOWN ARROW;;;; > > 2397;PREVIOUS PAGE;So;0;ON;;;;;N;;;;; > 2398;NEXT PAGE;So;0;ON;;;;;N;;;;; > Thanks, this can be usefull but not compatible with others CLX implementation. |
From: Philippe B. <ho...@fr...> - 2008-12-01 21:00:21
|
Sam Steingold writes: > please take a look at the cvs head > thanks > Works perfectly! And thanks for the keysym exploration. Things are less approximate now. Maybe I find the hexadecimal notation more expressive but it's just a matter of taste. |
From: Sam S. <sd...@gn...> - 2008-12-02 18:12:19
|
Philippe Brochard wrote: > I've been able to run most of the McCLIM applications and my own > CLIM application with clisp/new-clx. Good. There are a couple of things that need to be done on new-clx, specifically, two demos are broken: greynetic & bball. could you please take a look at them? Thanks. |
From: Philippe B. <ho...@fr...> - 2008-12-02 21:06:35
|
Sam Steingold writes: > Philippe Brochard wrote: > > I've been able to run most of the McCLIM applications and my own > > CLIM application with clisp/new-clx. > > Good. > > There are a couple of things that need to be done on new-clx, > specifically, two demos are broken: greynetic & bball. could you > please take a look at them? > Sure. The problem comes from the screen deph. Here is a fix: Index: modules/clx/new-clx/demos/bball.lisp =================================================================== RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/demos/bball.lisp,v retrieving revision 1.5 diff -u -w -p -r1.5 bball.lisp --- modules/clx/new-clx/demos/bball.lisp 25 Jun 2008 23:05:28 -0000 1.5 +++ modules/clx/new-clx/demos/bball.lisp 2 Dec 2008 21:02:40 -0000 @@ -111,7 +111,8 @@ :exposures :off)) (bounce-pixmap (xlib:create-pixmap :width +bball-size-x+ :height +bball-size-y+ - :depth 1 :drawable window)) + :depth (xlib:screen-root-depth screen) + :drawable window)) (pixmap-gc (xlib:create-gcontext :drawable bounce-pixmap :foreground white-pixel :background black-pixel)) @@ -128,7 +129,7 @@ (dolist (ball balls) (xor-ball bounce-pixmap window gcontext (ball-x ball) (ball-y ball))) (print 'finish) - (xlib:display-force-output dpy) + (xlib:display-finish-output dpy) (dotimes (i duration) (dolist (ball balls) (bounce-1-ball bounce-pixmap window gcontext ball)) Index: modules/clx/new-clx/demos/clx-demos.lisp =================================================================== RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/demos/clx-demos.lisp,v retrieving revision 1.14 diff -u -w -p -r1.14 clx-demos.lisp --- modules/clx/new-clx/demos/clx-demos.lisp 15 Oct 2007 22:11:00 -0000 1.14 +++ modules/clx/new-clx/demos/clx-demos.lisp 2 Dec 2008 21:02:40 -0000 @@ -11,8 +11,8 @@ (defparameter *demos* ;; (demo-name [package requirements]) - '((koch) (qix) (sokoban #:xpm) (greynetic #:broken!) (petal) (hanoi) - (recurrence) (plaid) (clclock) (bball #:broken!) (bwindow))) + '((koch) (qix) (sokoban #:xpm) (greynetic) (petal) (hanoi) + (recurrence) (plaid) (clclock) (bball) (bwindow))) (defmacro do-demos ((fun-var) &body body) (let ((demo (gensym "DO-DEMOS-DEMO-")) (reqs (gensym "DO-DEMOS-REQS-"))) Index: modules/clx/new-clx/demos/greynetic.lisp =================================================================== RCS file: /cvsroot/clisp/clisp/modules/clx/new-clx/demos/greynetic.lisp,v retrieving revision 1.4 diff -u -w -p -r1.4 greynetic.lisp --- modules/clx/new-clx/demos/greynetic.lisp 25 Jun 2008 23:05:28 -0000 1.4 +++ modules/clx/new-clx/demos/greynetic.lisp 2 Dec 2008 21:02:40 -0000 @@ -42,7 +42,7 @@ :event-mask '(:exposure :button-press :button-release :key-press :key-release) :background white-pixel)) - (pixmap (xlib:create-pixmap :width 32 :height 32 :depth 1 + (pixmap (xlib:create-pixmap :width 32 :height 32 :depth (xlib:screen-root-depth screen) :drawable window)) (gcontext (xlib:create-gcontext :drawable window :tile pixmap :fill-style :tiled |
From: Sam S. <sd...@gn...> - 2008-12-02 23:18:23
|
Philippe Brochard wrote: > Sam Steingold writes: > >> There are a couple of things that need to be done on new-clx, >> specifically, two demos are broken: greynetic & bball. could you >> please take a look at them? >> > Sure. The problem comes from the screen deph. Here is a fix: that was fast. very impressive. thanks! would you like to work on the gtk2 module? it would be nice to finally finish the gui. |
From: Philippe B. <ho...@fr...> - 2008-12-03 20:11:02
|
Sam Steingold writes: > Philippe Brochard wrote: > > Sam Steingold writes: > > > >> There are a couple of things that need to be done on new-clx, > >> specifically, two demos are broken: greynetic & bball. could you > >> please take a look at them? > >> > > Sure. The problem comes from the screen deph. Here is a fix: > > that was fast. > very impressive. > Hum, not so much, just a comment, print, RTFM loop. And lukily a one depth pixmap creation is the same with one depth or another depth. > thanks! > > would you like to work on the gtk2 module? > it would be nice to finally finish the gui. > Why not, but before I have some weird segfault with new-clx and clfswm and I want something rock solid... I also have to polish my other projects (this involves to work with new-clx). But I push the gtk2 part on my TODO list. Thank you for your trust. |
From: Philippe B. <ho...@fr...> - 2008-12-20 20:36:37
|
Philippe Brochard a écrit : [...] > Why not, but before I have some weird segfault with new-clx and clfswm > and I want something rock solid... > Just in case. I've corrected my mistake and fix this segfault. The segfault was the result of a multi xlib:alloc-color. Here is a test case which works with clisp/mit-clx and sbcl and crash clisp/new-clx. -------------------------------------------------- (defun get-color-wrong (screen color) (xlib:alloc-color (xlib:screen-default-colormap screen) color)) (let ((color-hash (make-hash-table :test 'equal))) (defun get-color-good (screen color) (multiple-value-bind (val foundp) (gethash color color-hash) (if foundp val (setf (gethash color color-hash) (xlib:alloc-color (xlib:screen-default-colormap screen) color)))))) (setf (symbol-function 'get-color) ;;#'get-color-good) #'get-color-wrong) (xlib:with-open-display (dpy) (let* ((screen (first (xlib:display-roots dpy))) (root (xlib:screen-root screen)) (font (xlib:open-font dpy "fixed")) (window (xlib:create-window :parent root :x 100 :y 100 :width 800 :height 600 :background (get-color screen "black") :colormap (xlib:screen-default-colormap screen))) (gcontext (xlib:create-gcontext :drawable window :background (get-color screen "black") :foreground (get-color screen "white") :font font)) (colors #("red" "green" "blue" "Darkgreen" "yellow" "lightblue" "Cyan" "Magenta"))) (xlib:map-window window) (xlib:display-force-output dpy) (dotimes (i 100000) (xlib:with-gcontext (gcontext :foreground (get-color screen (aref colors (random 8)))) (xlib:draw-glyphs window gcontext (random 1024) (random 768) (format nil "~A" 'toto))) (xlib:display-force-output dpy)) (print 'done))) -------------------------------------------------- Now all seems ok with clfswm and new-clx. And the good news is that I've gain a speedup :) Best regards, Philippe |
From: Sam S. <sd...@gn...> - 2008-12-04 01:09:56
|
> * Philippe Brochard <ub...@se...> [2008-12-03 21:10:57 +0100]: > >> would you like to work on the gtk2 module? >> it would be nice to finally finish the gui. > I push the gtk2 part on my TODO list. for clarity: we do have the module, but we need to fix some issues (make sure there are no memory leaks, finish the actual gui &c) -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://truepeace.org http://pmw.org.il http://israelunderattack.slide.com http://openvotingconsortium.org http://honestreporting.com Programming is like sex: one mistake and you have to support it for a lifetime. |
From: Sam S. <sd...@gn...> - 2008-12-21 04:16:23
|
> * Philippe Brochard <ub...@se...> [2008-12-20 21:36:31 +0100]: > > Just in case. I've corrected my mistake and fix this segfault. > The segfault was the result of a multi xlib:alloc-color. > > Here is a test case which works with clisp/mit-clx and sbcl and crash > clisp/new-clx. this code does not crash new-clx for me (neither get-color-wrong nor get-color-good). I am confused. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://jihadwatch.org http://openvotingconsortium.org http://ffii.org http://mideasttruth.com http://truepeace.org http://memri.org The only thing worse than X Windows: (X Windows) - X |
From: Philippe B. <ho...@fr...> - 2008-12-21 13:16:37
|
Sam Steingold writes: > > * Philippe Brochard <ub...@se...> [2008-12-20 21:36:31 +0100]: > > > > Just in case. I've corrected my mistake and fix this segfault. > > The segfault was the result of a multi xlib:alloc-color. > > > > Here is a test case which works with clisp/mit-clx and sbcl and crash > > clisp/new-clx. > > this code does not crash new-clx for me (neither get-color-wrong nor > get-color-good). > > I am confused. > Maybe you have to increase the number of draw loop. On my box the crash happened at gc time. Here is a log : ---------------------------------------------------------------------- $ time ~/local/clisp-cvs/clisp/build/clisp -K full -C test-draw-glyphs.lisp *** - handle_fault error2 ! address = 0x204cb040 not in [0x20282004,0x20434204) ! SIGSEGV cannot be cured. Fault address = 0x204cb040. GC count: 9 Space collected by GC: 0 5563264 Run time: 1 280079 Real time: 2 337162 GC time: 0 36003 Permanently allocated: 106560 bytes. Currently in use: 2493352 bytes. Free space: 619774 bytes. Segmentation fault (core dumped) real 0m2.373s user 0m0.940s sys 0m0.360s $ gdb ~/local/clisp-cvs/clisp/build/lisp.run core GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". Core was generated by `/other-home/lisp/local/clisp-cvs/clisp/build/full/lisp.run -B /other-home/lisp/'. Program terminated with signal 11, Segmentation fault. #0 0x08052a50 in savemem (stream=0xadd8e6, executable=32) at ../src/spvw_memfile.d:294 294 builtin_stream_close(&STACK_0,0); (gdb) bt #0 0x08052a50 in savemem (stream=0xadd8e6, executable=32) at ../src/spvw_memfile.d:294 #1 0x08061737 in eval (form=0x204cb000) at ../src/eval.d:2927 #2 0x0809ad72 in C_insert_window_line () at ../src/stream.d:12627 #3 0x080a3b2a in C_copy_readtable () at ../src/io.d:571 #4 0x080a5277 in C_rpar_reader () at ../src/lispbibl.d:15508 #5 0x080a3ac4 in copy_readtable (from_readtable=<value optimized out>) at ../src/io.d:444 #6 0x080a5277 in C_rpar_reader () at ../src/lispbibl.d:15508 #7 0x080a3575 in lookup_label () at ../src/io.d:3575 #8 0x080a5277 in C_rpar_reader () at ../src/lispbibl.d:15508 #9 0x080a3bec in init_reader_low () at ../src/io.d:525 #10 0x080a5277 in C_rpar_reader () at ../src/lispbibl.d:15508 #11 0x080a3b2a in C_copy_readtable () at ../src/io.d:571 #12 0x080a5277 in C_rpar_reader () at ../src/lispbibl.d:15508 #13 0x080959cd in clear_output (stream=0xbfb06cac) at ../src/stream.d:1680 #14 0x08096477 in listen_char (stream=0xf7e00560) at ../src/stream.d:16260 #15 0xb7bf8ea8 in ?? () #16 0x00000000 in ?? () (gdb) ---------------------------------------------------------------------- Feel free to ask if you want more details. My computer is an Intel/Celeron 2,6Ghz 740Mo ram with Debian GNU/Linux Etch. |
From: Sam S. <sd...@gn...> - 2008-12-21 04:28:08
|
> * Philippe Brochard <ub...@se...> [2008-12-20 21:36:31 +0100]: > Now all seems ok with clfswm and new-clx. And the good news is that > I've gain a speedup :) this should be even faster: (xlib:with-open-display (dpy) (let* ((screen (first (xlib:display-roots dpy))) (root (xlib:screen-root screen)) (font (xlib:open-font dpy "fixed")) (colormap (xlib:screen-default-colormap screen)) (black (xlib:alloc-color colormap "black")) (white (xlib:alloc-color colormap "white")) (height 600) (width 800) (window (xlib:create-window :parent root :x 100 :y 100 :width width :height height :background (get-color screen "black") :colormap colormap)) (gcontext (xlib:create-gcontext :drawable window :font font :background black :foreground white)) (colors (map 'vector (lambda (c) (xlib:alloc-color colormap c)) #("red" "green" "blue" "Darkgreen" "yellow" "lightblue" "Cyan" "Magenta")))) (xlib:map-window window) (xlib:display-force-output dpy) (dotimes (i 10000) (xlib:with-gcontext (gcontext :foreground (aref colors (random 8))) (xlib:draw-glyphs window gcontext (random width) (random height) "*")) (xlib:display-force-output dpy)))) -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://jihadwatch.org http://openvotingconsortium.org http://pmw.org.il http://iris.org.il http://palestinefacts.org http://ffii.org http://memri.org Winners never quit; quitters never win; idiots neither win nor quit. |
From: Philippe B. <ho...@fr...> - 2008-12-21 13:18:16
|
Sam Steingold writes: > > * Philippe Brochard <ub...@se...> [2008-12-20 21:36:31 +0100]: > > > Now all seems ok with clfswm and new-clx. And the good news is that > > I've gain a speedup :) > > this should be even faster: > [snip code] Yes I have something like this for my test but I can't predicte what colors the user want to use. So the hashtable is a tradeoff. |
From: Philippe B. <ho...@fr...> - 2008-12-02 21:12:47
|
Sam Steingold writes: > Philippe Brochard wrote: > > Sam Steingold writes: > >> please take a look at the cvs head > >> > > Works perfectly! And thanks for the keysym exploration. Things are > > so, can new-clx run mcclim now? > Yes, but I have no reply for my change on the McCLIM mailing list. > you said that a small change to mcclim was necessary - did they make the change? > No, not yet. A question: did new-clx must have the same behaviour than mit-clx? Because here, in McCLIM, they doesn't do the same thing with the same code. |
From: Philippe B. <ho...@fr...> - 2008-12-03 21:51:59
|
Sam Steingold writes: > Philippe Brochard wrote: > > A question: did new-clx must have the same behaviour than mit-clx? > > yes, it would be nice if that were true. > Ok, so there is some work to do on new-clx. > > Because here, in McCLIM, they doesn't do the same thing with the same > > code. > > can you isolate and debug this discrepancy? > Here is the full trace with mcclim/Examples/clim-fig.lisp: * new-clx freeze on tracking-pointer in handle-draw-object (line 105) in mcclim/Examples/clim-fig.lisp * The freeze is in invoke-tracking-pointer-loop (line 101) in mcclim/pointer-tracking.lisp. * Then in event-read in tracking-pointer-loop (line 130) in mcclim/pointer-tracking.lisp * The event-read freeze on event-queue-read (line 370) in mcclim/input.lisp * It's condition-wait who freeze in event-queue-read (line 84) in mcclim/input.lisp * The problem is in condition-wait (line 124) in mcclim/Lisp-Dep/mp-nil.lisp ---------------------------------------------------------------------- (defun condition-wait (cv lock &optional timeout) (declare (ignore lock)) (flet ((wait-func () (loop for port in climi::*all-ports* ;; this is dubious do (loop as this-event = (process-next-event port :timeout 0) for got-events = this-event then (or got-events this-event) repeat 2 ; <- *** here is my fix *** while this-event finally (unless got-events (process-next-event port)))) (car cv))) (setf (car cv) nil) (if timeout (process-wait-with-timeout "Waiting for event" timeout #'wait-func) (process-wait "Waiting for event" #'wait-func)))) ---------------------------------------------------------------------- the problem is that the second loop never finish without the repeat 2 (or something else). * The difference between mit-clx and new-clx is in (process-next-event port :timeout 0) (line 128) in mcclim/Lisp-Dep/mp-nil.lisp * The problem is in process-next-event (line 164) in mcclim/ports.lisp with mit-clx get-next-event returns :timeout on timeout. new-clx never timeout and there is always a distribute-event. ---------------------------------------------------------------------- (defmethod process-next-event ((port basic-port) &key wait-function timeout) (let ((event (get-next-event port :wait-function wait-function :timeout timeout))) (cond ((null event) nil) ((eq event :timeout) (values nil :timeout)) (t (distribute-event port event) t)))) ---------------------------------------------------------------------- * get-next-event is backend dependent so in mcclim/Backends/CLX/port.lisp the problem is in xlib:process-event (line 888). ---------------------------------------------------------------------- (defmethod get-next-event ((port clx-port) &key wait-function (timeout nil)) (declare (ignore wait-function)) (let* ((*clx-port* port) (display (clx-port-display port))) (unless (xlib:event-listen display) (xlib:display-finish-output (clx-port-display port))) ; temporary solution (or (xlib:process-event (clx-port-display port) :timeout timeout :handler #'event-handler :discard-p t) :timeout))) ; <-^-here is the problem ;; [Mike] Timeout and wait-functions are both implementation ;; specific and hence best done in the backends. ---------------------------------------------------------------------- It's here that there is a difference between mit-clx and new-clx. Sadly I haven't found yet how to reproduce this difference. If you have any idea. |
From: Sam S. <sd...@gn...> - 2008-12-03 22:35:45
|
Philippe Brochard wrote: > ---------------------------------------------------------------------- > (defmethod get-next-event ((port clx-port) &key wait-function (timeout nil)) > (declare (ignore wait-function)) > (let* ((*clx-port* port) > (display (clx-port-display port))) > (unless (xlib:event-listen display) > (xlib:display-finish-output (clx-port-display port))) > ; temporary solution > (or (xlib:process-event (clx-port-display port) :timeout timeout :handler #'event-handler :discard-p t) > :timeout))) ; <-^-here is the problem > ;; [Mike] Timeout and wait-functions are both implementation > ;; specific and hence best done in the backends. > ---------------------------------------------------------------------- ok, so the problem boils down to PROCESS-EVENT. travel_queque is rife with "BUG" and "TODO" remarks, so it is hardly surprising that it is no good. |