clg-devel Mailing List for Common Lisp bindings to GTK+ (Page 3)
Brought to you by:
espen
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(12) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(17) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(8) |
2002 |
Jan
(15) |
Feb
(1) |
Mar
(18) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(21) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
2006 |
Jan
(5) |
Feb
(13) |
Mar
(3) |
Apr
(28) |
May
(21) |
Jun
(5) |
Jul
(6) |
Aug
(25) |
Sep
(10) |
Oct
(2) |
Nov
|
Dec
(4) |
2007 |
Jan
(12) |
Feb
(7) |
Mar
(4) |
Apr
|
May
(10) |
Jun
(8) |
Jul
(21) |
Aug
(12) |
Sep
(3) |
Oct
(12) |
Nov
(7) |
Dec
(20) |
2008 |
Jan
(20) |
Feb
(9) |
Mar
(22) |
Apr
(13) |
May
(7) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(9) |
Dec
(2) |
2009 |
Jan
(4) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(15) |
Aug
(7) |
Sep
(4) |
Oct
|
Nov
|
Dec
(13) |
2010 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Walter C. P. <wa...@pe...> - 2008-04-25 16:01:04
|
Six months later I've been able to find out the answer to my question. The explanation is at the bottom of this page: http://common-lisp.net/project/cmucl/doc/cmu-user/aliens.html So basically there will never be any -dynamic-space-size that will allow more room for external allocation. This is predetermined by CMUCL (or SBCL) and won't change, no matter what. As far as I can tell there is no way around. I suppose one should just try to keep external allocation as small as possible and keep large objects as Lisp objects (not as reference to aliens). -- walter pelissero http://www.pelissero.de |
From: Walter C. P. <wa...@pe...> - 2008-04-25 15:41:30
|
The following code will leak memory but I couldn't quite find the hole. The larger the loaded pixbuf/image the faster. (gffi:defbinding (pixbuf-loader-write "gdk_pixbuf_loader_write") () boolean (loader gdk:pixbuf-loader) (buffer (vector (unsigned-byte 8))) ((length buffer) integer) (nil glib:gerror-signal :out)) (gffi:defbinding (pixbuf-loader-close "gdk_pixbuf_loader_close") () boolean (loader gdk:pixbuf-loader) (nil glib:gerror-signal :out)) (gffi:defbinding (pixbuf-loader-get-pixbuf "gdk_pixbuf_loader_get_pixbuf") () (glib:referenced gdk:pixbuf) (loader gdk:pixbuf-loader)) (gffi:defbinding (pixbuf-loader-set-size "gdk_pixbuf_loader_set_size") () nil (loader gdk:pixbuf-loader) (width integer) (height integer)) (defparameter *image* (make-instance 'image :width-request 128 :height-request 64)) (defun loader-test () (let ((file "/home/wcp/pictures/scanned/archive/swan.jpg")) #+cmu (ext:gc :full t) #+sbcl (sb-ext:gc :full t) (let ((loader (make-instance 'gdk:pixbuf-loader))) (signal-connect loader 'size-prepared #'(lambda (image-width image-height) (declare (ignore image-width image-height)) (pixbuf-loader-set-size loader 128 64) nil)) (signal-connect loader 'area-prepared #'(lambda () (setf (image-pixbuf *image*) (pixbuf-loader-get-pixbuf loader)) nil)) (unwind-protect (with-open-file (stream file :element-type '(unsigned-byte 8)) (let ((buffer (make-sequence '(vector (unsigned-byte 8)) (* 4 1024)))) (flet ((forward-buffer (&optional n) (pixbuf-loader-write loader (if n (subseq buffer 0 n) buffer)))) (loop for n = (read-sequence buffer stream) while (= n (length buffer)) do (forward-buffer) finally (unless (zerop n) (forward-buffer n)))))) (ignore-errors (pixbuf-loader-close loader)))))) (defun leak-memory () (loop for i from 0 do (format t "~A~%" i) (loader-test))) Does anyone have suggestions? -- walter pelissero http://www.pelissero.de |
From: Hazen B. <hba...@ma...> - 2008-04-10 02:16:36
|
On Apr 9, 2008, at 4:09 PM, Espen S Johnsen wrote: > Hazen Babcock <hba...@ma...> writes: > >> My sample program follows. I only added the necessary functionality >> for this to cl-plplot and to PLplot in the last few days so >> unfortunately you'd need both the latest cl-plplot from cvs and the >> latest PLplot from svn to test this. > > My first attempt to run the sample code also resulted in a crashed > SBCL > process, due to lost X server connection. This usually happens (with > some X servers) when the path extends to far out of the current > viewport. So I expected a scaling problem and found after some > experimentation that inserting the following before the call to > rotate_cairo_surface in plD_esc_extcairo, would fix the problem: > > cairo_scale (aStream->cairoContext, 1.0 / pls->xlength, 1.0 / pls- > >ylength); It does, thanks! I really appreciate your help. It would have taken me quite some time to figure this one out on my own. -Hazen |
From: Espen S J. <es...@cs...> - 2008-04-09 20:09:54
|
Hazen Babcock <hba...@ma...> writes: > My sample program follows. I only added the necessary functionality > for this to cl-plplot and to PLplot in the last few days so > unfortunately you'd need both the latest cl-plplot from cvs and the > latest PLplot from svn to test this. My first attempt to run the sample code also resulted in a crashed SBCL process, due to lost X server connection. This usually happens (with some X servers) when the path extends to far out of the current viewport. So I expected a scaling problem and found after some experimentation that inserting the following before the call to rotate_cairo_surface in plD_esc_extcairo, would fix the problem: cairo_scale (aStream->cairoContext, 1.0 / pls->xlength, 1.0 / pls->ylength); I hope this helps. -- Espen |
From: Hazen B. <hba...@ma...> - 2008-04-09 01:55:53
|
On Apr 8, 2008, at 1:44 PM, Espen S Johnsen wrote: > Hazen Babcock <hba...@ma...> writes: > >> It is possible to get a pointer to a cairo context? I thought that >> perhaps (gffi::foreign-location cr) would do it, but passing this to >> the code that expects a pointer to a cairo context seems to crash my >> (SBCL) Lisp process. > >> I hoped that something like this might work: >> >> (gdk:with-cairo-context (cr (widget-window drawing-area)) >> (multiple-value-bind (width height) >> (widget-get-size-allocation drawing-area) >> (cairo:scale cr width height)) >> (draw-a-plot (gffi::foreign-location cr))) > > This should be correct as far as i can tell, but I couldn't figure out > how to use cl-plplot with cairo so I wasn't able to do any testing. If > you could provide some example code I could try to reproduce the > crash. My sample program follows. I only added the necessary functionality for this to cl-plplot and to PLplot in the last few days so unfortunately you'd need both the latest cl-plplot from cvs and the latest PLplot from svn to test this. I tested the part PLplot of this with a simple C program (also follows) so I don't think that this is the problem. Maybe I'm not passing the pointer correctly in cl- plplot? The relevant CFFI code there is: (DEFCFUN ("pl_cmd" C-PL-CMD) :VOID (OP PLINT) (PTR PLPOINTER)) PLPOINTER is of CFFI type :pointer. thanks, -Hazen ;;; ;;; Combining PLplot and GTK. ;;; (defpackage :plplot-gtk (:use :common-lisp :cl-plplot-system :clg)) (in-package :plplot-gtk) ;; to use first do the following: ; ; 1. (require :gtk) ; 2. (require :cl-plplot) ; 3. (clg-init) ; ;; global variables ; windows (defvar *main-window*) ;; functions (defun draw-a-plot (cr) "Attempts to use PLplot to draw a plot in context cr." (plsdev "extcairo") (plinit) (pl-cmd 26 cr) (plcol0 1) (plwid 2) (plenv 0 2 0 2 0 0) (plcol0 2) (pllab "x" "y" "title") (plend)) (defun setup-drawing (drawing-area) "Creates the drawing function." (signal-connect drawing-area 'expose-event #'(lambda (event) (declare (ignore event)) (gdk:with-cairo-context (cr (widget-window drawing-area)) (multiple-value-bind (width height) (widget-get-size-allocation drawing-area) (cairo:scale cr width height)) (cairo:set-source-color cr 1.0 01.0 1.0) (cairo:rectangle cr 0.0 0.0 1.0 1.0) (cairo:fill cr) (cairo:set-source-color cr 0.5 0.5 0.5) (cairo:rectangle cr 0.1 0.1 0.8 0.8) (cairo:fill cr) (draw-a-plot (gffi::foreign-location cr)))))) ;(cairo:xlib-surface-get-drawable ;(gdk:drawable-display (defun create-main-window () "Creates the main window." (let ((menu-bar) (graph-area) (main-window (make-instance 'window :title "Plplot-GTK" :name "main_window" :width-request 400 :height- request 300 :visible t))) ; menu setup (let ((menu (make-instance 'menu-item :label "File")) (sub-menu (make-instance 'menu))) (setf menu-bar (make-instance 'menu-bar)) (let ((item (make-instance 'menu-item :label "Quit"))) (signal-connect item 'activate #'(lambda () (widget-destroy *main- window*))) (menu-shell-append sub-menu item)) (setf (menu-item-submenu menu) sub-menu) (menu-shell-append menu-bar menu)) ; graphics setup (setf graph-area (make-instance 'drawing-area)) (setup-drawing graph-area) ; window setup (make-instance 'v-box :parent main-window :child (list menu-bar :expand nil :fill nil) :child graph-area) (signal-connect main-window 'destroy #'(lambda () (setf *main-window* nil))) (setf *main-window* main-window) (widget-show-all main-window))) PLplot C test program: #include <stdio.h> #include <cairo.h> #include <cairo-ps.h> #include <plplot.h> int main(int argc, char *argv[]) { cairo_surface_t *cairoSurface; cairo_t *cairoContext; cairoSurface = cairo_ps_surface_create("test.ps", 720, 540); cairoContext = cairo_create(cairoSurface); plsdev("extcairo"); plinit(); pl_cmd(PLESC_DEVINIT, cairoContext); plenv(0.0, 1.0, 0.0, 1.0, 1, 0); pllab("x", "y", "title"); plend(); cairo_destroy(cairoContext); cairo_surface_destroy(cairoSurface); } |
From: Espen S J. <es...@cs...> - 2008-04-08 17:45:08
|
Hazen Babcock <hba...@ma...> writes: > It is possible to get a pointer to a cairo context? I thought that > perhaps (gffi::foreign-location cr) would do it, but passing this to > the code that expects a pointer to a cairo context seems to crash my > (SBCL) Lisp process. > I hoped that something like this might work: > > (gdk:with-cairo-context (cr (widget-window drawing-area)) > (multiple-value-bind (width height) > (widget-get-size-allocation drawing-area) > (cairo:scale cr width height)) > (draw-a-plot (gffi::foreign-location cr))) This should be correct as far as i can tell, but I couldn't figure out how to use cl-plplot with cairo so I wasn't able to do any testing. If you could provide some example code I could try to reproduce the crash. -- Espen |
From: Espen S J. <es...@cs...> - 2008-04-08 16:02:06
|
Steve Rolls <sro...@ya...> writes: > This occurs during gc after calling tree-view-columns > > Can be reproduced with testgtk.lisp by adding this > (print (tree-view-columns tree)) > to the list example > > GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed > [Condition of type GLIB:CRITICAL-LOG-LEVEL] This was caused by a ref counting bug, which I've checked in a fix for now. -- Espen |
From: Hazen B. <hba...@ma...> - 2008-04-08 02:52:34
|
Hello, It is possible to get a pointer to a cairo context? I thought that perhaps (gffi::foreign-location cr) would do it, but passing this to the code that expects a pointer to a cairo context seems to crash my (SBCL) Lisp process. More details about what I'm trying to do. I'd like to use cl-plplot (a wrapper for the C plotting library PLplot) to render graphs in the cairo context of a window provided by clg, but to do this I need to pass a pointer to the windows cairo context off to the PLplot graphics library. CL-plplot is using CFFI to interact with PLplot, so I'm passing the return value of (gffi::foreign-location cr) as type :pointer and assuming that it is in fact a cairo_t *. I hoped that something like this might work: (gdk:with-cairo-context (cr (widget-window drawing-area)) (multiple-value-bind (width height) (widget-get-size-allocation drawing-area) (cairo:scale cr width height)) (draw-a-plot (gffi::foreign-location cr))) Thank you, -Hazen |
From: Steve R. <sro...@ya...> - 2008-04-04 19:17:09
|
This occurs during gc after calling tree-view-columns Can be reproduced with testgtk.lisp by adding this (print (tree-view-columns tree)) to the list example GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed [Condition of type GLIB:CRITICAL-LOG-LEVEL] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Return to Top-Level. Backtrace: 0: (GLIB::LOG-HANDLER 268430975 268430971) 1: ("call_into_lisp+#x8C [#x8054D3C] /home/srolls/cl/cmucl/bin/lisp") 2: ("funcall3+#x29 [#x8054B4F] /home/srolls/cl/cmucl/bin/lisp") 3: ("Foreign function call land") 4: ("g_logv+#x1D0 [#xB7BF2563] /home/srolls/local/gtk/lib/libglib-2.0.so") 5: ("g_log+#x29 [#xB7BF27D3] /home/srolls/local/gtk/lib/libglib-2.0.so") 6: ("g_return_if_fail_warning+#x57 [#xB7BF28A3] /home/srolls/local/gtk/lib/libglib-2.0.so") 7: ("g_object_unref+#x9D [#xB7B94453] /home/srolls/local/gtk/lib/libgobject-2.0.so") 8: (GLIB::%OBJECT-UNREF #.(SYSTEM:INT-SAP #x08250BB8)) 9: ("DEFUN FINALIZE-CORPSES" (#<Broken Weak Pointer {5958E357}> . #<Closure Over Function "DEFMETHOD INSTANCE-FINALIZER AROUND (PROXY)" {5958E369}>)) 10: (DELETE-IF #<Function "DEFUN FINALIZE-CORPSES" {10570F69}> ((# . #) (# . #) (# . #) (# . #) (# . #) ...) :FROM-END NIL ...) 11: (EXTENSIONS::FINALIZE-CORPSES) 12: ((FLET #:G5 LISP::SUB-GC)) 13: (LISP::SUB-GC :VERBOSE-P T :FORCE-P T ...) 14: (SWANK::EVAL-REGION "(gc) --------------------------------- You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. |
From: Walter C. P. <wa...@pe...> - 2008-03-27 16:38:11
|
Espen S Johnsen writes: > "Walter C. Pelissero" <wa...@pe...> writes: > > > Since recently I've been observing sporadic errors like this > > > > Type-error in KERNEL::OBJECT-NOT-FUNCTION-ERROR-HANDLER: > > GTK::%ICON-VIEW-MARKUP-COLUMN-BOUNDP is not of type FUNCTION > > [Condition of type TYPE-ERROR] > > > > somewhere in the initialisation of an icon view > > Unfortunately, I have not been able to reproduce or locate the problem > from the stack trace. It would be nice if you could create some example > code that can be used to trigger the error. Contrary to my first impressions the error can be reproduced reliably. Here is how. Compile the following and execute the RUN function. (defpackage :bugger (:use :common-lisp :gtk :pcl) (:export #:run)) (in-package :bugger) (defclass fancy-metaclass (standard-class) ()) (defclass fancy-object () ()) (defclass fancy-effective-slot-definition (standard-effective-slot-definition) ()) (defmethod slot-boundp-using-class ((class fancy-metaclass) (instance fancy-object) (slot fancy-effective-slot-definition)) t) (trace slot-boundp-using-class) (defun run () (clg-init) (make-instance 'icon-view)) ---------------------------------------------------------------------- Commenting out the definition of slot-boundp-using-class the error disappears. Considering that SBCL doesn't seem to be adversely affected by this code and, even on CMUCL, just loading my code, doesn't trigger any error, I believe I tripped on a CMUCL bug. -- walter pelissero http://www.pelissero.de |
From: Espen S J. <es...@cs...> - 2008-03-26 17:10:16
|
"Walter C. Pelissero" <wa...@pe...> writes: > Since recently I've been observing sporadic errors like this > > Type-error in KERNEL::OBJECT-NOT-FUNCTION-ERROR-HANDLER: > GTK::%ICON-VIEW-MARKUP-COLUMN-BOUNDP is not of type FUNCTION > [Condition of type TYPE-ERROR] > > somewhere in the initialisation of an icon view Unfortunately, I have not been able to reproduce or locate the problem from the stack trace. It would be nice if you could create some example code that can be used to trigger the error. -- Espen |
From: Walter C. P. <wa...@pe...> - 2008-03-26 10:56:11
|
Since recently I've been observing sporadic errors like this Type-error in KERNEL::OBJECT-NOT-FUNCTION-ERROR-HANDLER: GTK::%ICON-VIEW-MARKUP-COLUMN-BOUNDP is not of type FUNCTION [Condition of type TYPE-ERROR] somewhere in the initialisation of an icon view 0: (PCL::SLOT-BOUNDP-USING-CLASS-DFUN #<unused-arg> #<GTK:ICON-VIEW at 0x82D4128> #<EFFECTIVE-VIRTUAL-ALIEN-SLOT-DEFINITION GTK:MARKUP-COLUMN {4A62D555}>) 1: ("DEFMETHOD SHARED-INITIALIZE (SLOT-OBJECT T)" #<#1=unused-arg> #<#1#> #<GTK:ICON-VIEW at 0x82D4128> T ...) 2: ((METHOD SHARED-INITIALIZE NIL (GLIB:GOBJECT T)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function "DEFMETHOD SHARED-INITIALIZE (SLOT-OBJECT T)" {1124BBA1}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2 . T)) #<GTK:ICON-VIEW at 0x82D4128> T ...) 3: ((METHOD SHARED-INITIALIZE NIL (GTK:CONTAINER T)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function # {4A030969}> :PV-CELL NIL :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL # :ARG-INFO #) :ARG-INFO (2 . T)) ..) 4: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G6665 G6666 G6667)" #<#1=unused-arg> #<#1#> #<GTK:ICON-VIEW at 0x82D4128> T ...) 5: ((METHOD INITIALIZE-INSTANCE NIL (GTK::%OBJECT)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function "DEFMETHOD INITIALIZE-INSTANCE (SLOT-OBJECT)" {112AB381}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<GTK:ICON-VIEW at 0x82D4128> (:MODEL #<GTK:LIST-STORE at 0x833F208> :SELECTION-MODE :MULTIPLE :TEXT-COLUMN ...)) 6: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G6868 G6869 G6870)" #<#1=unused-arg> #<#1#> #<GTK:ICON-VIEW at 0x82D4128> (:MODEL #<GTK:LIST-STORE at 0x833F208> :SELECTION-MODE :MULTIPLE :TEXT-COLUMN ...)) 7: ((METHOD INITIALIZE-INSTANCE (:AROUND) (GFFI:PROXY)) (#() . #(#)) #S(PCL::FAST-METHOD-CALL :FUNCTION #<Closure Over Function "LAMBDA (.KEYARGS-START. .VALID-KEYS. G6868 G6869 G6870)" {485099D9}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<GTK:ICON-VIEW at 0x82D4128> (:MODEL #<GTK:LIST-STORE at 0x833F208> :SELECTION-MODE :MULTIPLE :TEXT-COLUMN ...)) 8: ((METHOD INITIALIZE-INSTANCE (:AROUND) (GLIB:GOBJECT)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function # {4A027799}> :PV-CELL (# . #) :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO #) :ARG-INFO (1 . T)) ..) 9: ((METHOD INITIALIZE-INSTANCE (:AROUND) (GTK::%OBJECT)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function # {4A027311}> :PV-CELL NIL :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL # :NEXT-METHOD-CALL # :ARG-INFO #) :ARG-INFO (1 . T)) ..) 10: ("DEFMETHOD MAKE-INSTANCE (CLASS)" #<#1=unused-arg> #<#1#> #<GOBJECT-CLASS GTK:ICON-VIEW {482D786D}> (:MODEL #<GTK:LIST-STORE at 0x833F208> :SELECTION-MODE :MULTIPLE :TEXT-COLUMN ...)) [...] The error usually disappears restarting the Lisp, reloading everything (asdf:load-op), and re-running the application. I'm pretty sure that if a dumped image exhibits this behaviour, it always does no matter how many times I restart it, while if it doesn't the first time it won't, ever. It's quite puzzling. Looks like it may have something to do with the way ASDF loads the modules, maybe the order, but I couldn't notice any big difference between various runs (showing different behaviours). BTW, I wonder if %icon-view-set-tmarkup-column in gtktypes.lisp shouldn't read %icon-view-set-markup-column. -- walter pelissero http://www.pelissero.de |
From: Espen S J. <es...@cs...> - 2008-03-20 22:59:19
|
Hi, I just packet up the code from CVS and made a new release. Thanks to everybody who has contributed with bug fixes and patches. -- Espen |
From: Espen S J. <es...@cs...> - 2008-03-19 14:35:13
|
Chisheng Huang <cp...@ch...> writes: > Hi Espen, > > Could you please replace the last expression in tools/clg-tools.asd > with the following? > > (let ((dir (asdf:component-pathname (asdf:find-system :clg-tools)))) > (setf (logical-pathname-translations "clg") > `(("**;*.*.*" ,(make-pathname :directory (append (butlast (pathname-directory dir)) > (list :wild-inferiors)) > :defaults dir))))) Thanks, should be fixed now. -- Espen |
From: Chisheng H. <cp...@ch...> - 2008-03-19 04:25:14
|
Chisheng Huang <cp...@ch...> writes: > Hi Espen, > > Could you please replace the last expression in tools/clg-tools.asd > with the following? > > (let ((dir (asdf:component-pathname (asdf:find-system :clg-tools)))) > (setf (logical-pathname-translations "clg") > `(("**;*.*.*" ,(make-pathname :directory (append (butlast (pathname-directory dir)) > (list :wild-inferiors)) > :defaults dir))))) > > With the current one in CVS, the pathname device part will be missing > on Micros*t machines. For example: if the clg directory is at > d:\home\aaa\clg\, (translate-logical-pathname "clg:") will give > #P"\\home\\aaa\\clg\\" as the answer but the correct answer should be > #P"d:home\\aaa\\clg\\". ^^^^^^^^^^^^^^^^^^^^^ Should be #P"d:\\home\\aaa\\clg\\". Best, -cph |
From: Chisheng H. <cp...@ch...> - 2008-03-19 00:41:16
|
Hi Espen, Could you please replace the last expression in tools/clg-tools.asd with the following? (let ((dir (asdf:component-pathname (asdf:find-system :clg-tools)))) (setf (logical-pathname-translations "clg") `(("**;*.*.*" ,(make-pathname :directory (append (butlast (pathname-directory dir)) (list :wild-inferiors)) :defaults dir))))) With the current one in CVS, the pathname device part will be missing on Micros*t machines. For example: if the clg directory is at d:\home\aaa\clg\, (translate-logical-pathname "clg:") will give #P"\\home\\aaa\\clg\\" as the answer but the correct answer should be #P"d:home\\aaa\\clg\\". Best wishes, -cph |
From: Leandro R. <lea...@tu...> - 2008-03-18 17:16:31
|
Chisheng Huang escribió: > Hi Leandro, > > I'm the culprit responsible for polluting the clg source code with > a bunch of WIN32's:) Sorry about replying this late; I was attending > a meeting for a few days. I have't run clg on a Micros*t machine for > more than half a year. I didn't even remember how to run it a few > minutes ago until I dug out a message I sent to Espen. Here is part > of that message that might be of some help: > > In order to use GTK+ and clg on MS Windows machines, one has to download > 1. The various runtimes available at > http://www.gimp.org/~tml/gimp/win32/downloads.html > 2. mingw-utils-0.3.tar.gz from http://www.mingw.org/. > The function pexports.exe in this tar archive is needed in > GLIB:%FIND-TYPES-IN-LIBRARY because nm from either cygwin or mingw > gives out junk. I'm not sure mingw-utils-0.3.tar.gz can be installed > without installing MinGW first; so, one may have to download and install > MinGW, too. > > Finally, some notes about the win32 version of SBCL. I tried many ways > to run clg with win32 SBCL and only found 1 way that won't throw me into > the LDB monitor:( > A. Create a .sbclrc like the following: > (load "d:/....../slime/swank-loader") > (swank:create-server) > B. Fire up Emacs and do M-x slime-connnect. > C. Once the connection is established, evaluate the followings: > > (setf (logical-pathname-translations "clg") > '(("**;*.*.*" "d:\\......\\clg\\**\\"))) > > (loop for pathname in '("clg:atk;" "clg:cairo;" "clg:tools;" > "clg:gdk;" "clg:gffi;" "clg:glade-xml;" > "clg:glib;" "clg:gtk;" "clg:pango;" > "clg:rsvg;") > do (push (translate-logical-pathname pathname) > asdf:*central-registry*)) > > (asdf:oos 'asdf:load-op :gtk) > (load "d:\\......\\clg\\examples\\testgtk") > > So far, I haven't managed to run clg directly in the black win32 SBCL > window. No matter what I tried, I got into the LDB monitor quickly. > > You have to use an explicit main loop and it's kind of brutal to run > sbcl/clg on Micros*t machines. I'll try the latest clg and the latest > SBCL for Win32 this week. > > Best wishes, > > -cph > > Hi Chisheng, Thanks for your answer. I've been able to compile clg, and to run test-gtk, but an explicit main loop must be started, which renders slime's repl unusable. I tried to hook main-iterate-all to the periodic polling function on the swank server, but I found that all of the non-blocking stream reads in fact, block. The best I was able to do in this route was to have a main loop iteration for every return pressed in the repl. That rendered clg unusable. So, it seems that until we have proper socket (non blocking reads) or threading support in sbcl win32, (or serve-event, or timers) we'll have to live with the explicit main loop. Thanks, Leandro |
From: Espen S J. <es...@cs...> - 2008-03-18 15:04:58
|
Steve Rolls <sro...@ya...> writes: > I get the following error when calling menu-popup (cmucl 19d, gtk+ 2.10.13). Am I just doing something wrong here? No, you're not doing something wrong, but encountered upon an event type (introduced in Gtk+ 2.8) which didn't have a corresponding proxy class in clg. I've added a definition for this class now and also added a better error message in case this happens again. -- Espen |
From: Steve R. <sro...@ya...> - 2008-03-18 05:41:20
|
I get the following error when calling menu-popup (cmucl 19d, gtk+ 2.10.13). Am I just doing something wrong here? Function that generates the error follows. Error in function PCL::FIND-CLASS-FROM-CELL: No class named NIL. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to Top-Level. Backtrace: 0: (PCL::FIND-CLASS-FROM-CELL NIL NIL T) 1: ((METHOD GFFI:MAKE-PROXY-INSTANCE NIL (SYMBOL T)) #<#1=unused-arg> #<#1#> NIL #.(SYSTEM:INT-SAP #x08108990) ...) 2: (GFFI:ENSURE-PROXY-INSTANCE GDK:EVENT #.(SYSTEM:INT-SAP #x08108990) :REFERENCE NIL ...) 3: (GLIB::CALLBACK-TRAMPOLINE #<Function GLIB::INVOKE-SIGNAL-HANDLER {58B82671}> 6 2 #.(SYSTEM:INT-SAP #x3FFFC70C) ...) 4: (GLIB::SIGNAL-HANDLER-MARSHAL 268431660 268431656) 5: ("call_into_lisp+#x8C [#x8054D3C] /home/srolls/cl/cmucl/bin/lisp") 6: ("funcall3+#x29 [#x8054B4F] /home/srolls/cl/cmucl/bin/lisp") 7: ("Foreign function call land") 8: ("g_closure_invoke+#x11E [#xB7B4EE3F] /home/srolls/local/gtk/lib/libgobject-2.0.so") 9: ("NIL+#xB7B5DB6A [#xB7B5DB6A] /home/srolls/local/gtk/lib/libgobject-2.0.so") 10: ("g_signal_emit_valist+#x41D [#xB7B5F106] /home/srolls/local/gtk/lib/libgobject-2.0.so") 11: ("g_signal_emit+#x29 [#xB7B5F709] /home/srolls/local/gtk/lib/libgobject-2.0.so") 12: ("NIL+#xB76B520B [#xB76B520B] /home/srolls/local/gtk/lib/libgtk-x11-2.0.so") 13: ("gtk_main_do_event+#x315 [#xB75AA7EB] /home/srolls/local/gtk/lib/libgtk-x11-2.0.so") 14: ("NIL+#xB782159C [#xB782159C] /home/srolls/local/gtk/lib/libgdk-x11-2.0.so") 15: ("g_main_context_dispatch+#x1EC [#xB7BA6FAD] /home/srolls/local/gtk/lib/libglib-2.0.so") 16: ("NIL+#xB7BAA086 [#xB7BAA086] /home/srolls/local/gtk/lib/libglib-2.0.so") 17: ("g_main_context_iteration+#x62 [#xB7BAA50E] /home/srolls/local/gtk/lib/libglib-2.0.so") 18: ("gtk_main_iteration_do+#x33 [#xB75A9381] /home/srolls/local/gtk/lib/libgtk-x11-2.0.so") 19: (GTK:MAIN-ITERATION-DO NIL) 20: ("DEFUN MAIN-ITERATE-ALL" #<#1=unused-arg> #<#1#>)[:OPTIONAL] 21: (LISP::SUB-SERVE-EVENT 0 10000) 22: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 23: (LISP::DO-INPUT #<Stream for Standard Input>) 24: (LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL (LISP::*EOF*)) 25: (LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (LISP::*EOF*)) 26: (LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (LISP::*EOF*)) 27: (LISP::SYNONYM-IN #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*)) 28: (READ-CHAR #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*) NIL) 29: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) T) 30: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 31: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) ...)[:EXTERNAL] 32: (LISP::READ-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 33: (READ #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 34: (LISP::%TOP-LEVEL) 35: ((LABELS LISP::RESTART-LISP SAVE-LISP)) (defun popup-test() (let ((window (make-instance 'gtk:window :title "popup-test" :visible t :show-children t)) (ui (make-instance 'gtk:ui-manager :ui '((:popup "Popup" (:menuitem "PopupTest"))) :action-group (make-instance 'gtk:action-group :name "TestActions" :action (make-instance 'gtk:action :name "PopupTest" :label "Popup test" :callback #'(lambda() (make-instance 'gtk:message-dialog :message-type :info :visible t :text "Popup Test" :signal (list :ok #'gtk:widget-destroy :object t)))))))) (gtk:widget-add-events window '(:button-press :button-release)) (gtk:signal-connect window "event" #'(lambda(widget event) (declare (ignore widget)) (typecase event (gdk:button-press-event (gtk:menu-popup (gtk:ui-manager-get-widget ui "/Popup") (gdk:event-button event) (gdk:event-time event))))) :object t))) --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. |
From: Chisheng H. <cp...@ch...> - 2008-03-18 05:14:33
|
Leandro Ríos <lea...@tu...> writes: > Espen S Johnsen escribió: >> Leandro Ríos <lea...@tu...> writes: >> >>> Did someone succeed using clg in win32? I can compile it under SBCL >>> 1.0.2 and 1.0.13, but when I load "testgtk.lisp", >>> all I have is the main window with caption but blank contents and >>> blocked. I can evaluate code in slime's repl buffer, but the window is >>> dead. When I try to close it, Windows asks if I want to terminate sbcl. >>> That, or entering (quit) in the repl is the only way I found to make the >>> window close. >>> >>> Is it known? Is there some workaround? >> >> As I only use Windows exceptionally, I been not been able to test the >> win32 port of clg my self. But Chisheng Huang, who supplied the win32 >> patches, have at least had some success with clg and win32. The main >> problem seems to be that it is not possible to handle events in >> background, so one has to start an explicit main loop (and thus lose >> access to the REPL). >> > > Espen, > > Thanks for your prompt reply. I was guessing this could be the problem, > as sbcl in win32 does not support threading yet. I was hoping that in > 1.0.2 SERVE-EVENT were enabled, but seems to be as crippled as > threading. I'll try the explicit main loop. Hi Leandro, I'm the culprit responsible for polluting the clg source code with a bunch of WIN32's:) Sorry about replying this late; I was attending a meeting for a few days. I have't run clg on a Micros*t machine for more than half a year. I didn't even remember how to run it a few minutes ago until I dug out a message I sent to Espen. Here is part of that message that might be of some help: In order to use GTK+ and clg on MS Windows machines, one has to download 1. The various runtimes available at http://www.gimp.org/~tml/gimp/win32/downloads.html 2. mingw-utils-0.3.tar.gz from http://www.mingw.org/. The function pexports.exe in this tar archive is needed in GLIB:%FIND-TYPES-IN-LIBRARY because nm from either cygwin or mingw gives out junk. I'm not sure mingw-utils-0.3.tar.gz can be installed without installing MinGW first; so, one may have to download and install MinGW, too. Finally, some notes about the win32 version of SBCL. I tried many ways to run clg with win32 SBCL and only found 1 way that won't throw me into the LDB monitor:( A. Create a .sbclrc like the following: (load "d:/....../slime/swank-loader") (swank:create-server) B. Fire up Emacs and do M-x slime-connnect. C. Once the connection is established, evaluate the followings: (setf (logical-pathname-translations "clg") '(("**;*.*.*" "d:\\......\\clg\\**\\"))) (loop for pathname in '("clg:atk;" "clg:cairo;" "clg:tools;" "clg:gdk;" "clg:gffi;" "clg:glade-xml;" "clg:glib;" "clg:gtk;" "clg:pango;" "clg:rsvg;") do (push (translate-logical-pathname pathname) asdf:*central-registry*)) (asdf:oos 'asdf:load-op :gtk) (load "d:\\......\\clg\\examples\\testgtk") So far, I haven't managed to run clg directly in the black win32 SBCL window. No matter what I tried, I got into the LDB monitor quickly. You have to use an explicit main loop and it's kind of brutal to run sbcl/clg on Micros*t machines. I'll try the latest clg and the latest SBCL for Win32 this week. Best wishes, -cph |
From: Leandro R. <lea...@tu...> - 2008-03-13 17:29:33
|
Espen S Johnsen escribió: > Leandro Ríos <lea...@tu...> writes: > >> Did someone succeed using clg in win32? I can compile it under SBCL >> 1.0.2 and 1.0.13, but when I load "testgtk.lisp", >> all I have is the main window with caption but blank contents and >> blocked. I can evaluate code in slime's repl buffer, but the window is >> dead. When I try to close it, Windows asks if I want to terminate sbcl. >> That, or entering (quit) in the repl is the only way I found to make the >> window close. >> >> Is it known? Is there some workaround? > > As I only use Windows exceptionally, I been not been able to test the > win32 port of clg my self. But Chisheng Huang, who supplied the win32 > patches, have at least had some success with clg and win32. The main > problem seems to be that it is not possible to handle events in > background, so one has to start an explicit main loop (and thus lose > access to the REPL). > Espen, Thanks for your prompt reply. I was guessing this could be the problem, as sbcl in win32 does not support threading yet. I was hoping that in 1.0.2 SERVE-EVENT were enabled, but seems to be as crippled as threading. I'll try the explicit main loop. Thanks again, Leandro |
From: Espen S J. <es...@cs...> - 2008-03-13 16:34:28
|
Leandro Ríos <lea...@tu...> writes: > Did someone succeed using clg in win32? I can compile it under SBCL > 1.0.2 and 1.0.13, but when I load "testgtk.lisp", > all I have is the main window with caption but blank contents and > blocked. I can evaluate code in slime's repl buffer, but the window is > dead. When I try to close it, Windows asks if I want to terminate sbcl. > That, or entering (quit) in the repl is the only way I found to make the > window close. > > Is it known? Is there some workaround? As I only use Windows exceptionally, I been not been able to test the win32 port of clg my self. But Chisheng Huang, who supplied the win32 patches, have at least had some success with clg and win32. The main problem seems to be that it is not possible to handle events in background, so one has to start an explicit main loop (and thus lose access to the REPL). -- Espen |
From: Leandro R. <lea...@tu...> - 2008-03-13 02:03:56
|
Hi, Did someone succeed using clg in win32? I can compile it under SBCL 1.0.2 and 1.0.13, but when I load "testgtk.lisp", all I have is the main window with caption but blank contents and blocked. I can evaluate code in slime's repl buffer, but the window is dead. When I try to close it, Windows asks if I want to terminate sbcl. That, or entering (quit) in the repl is the only way I found to make the window close. Is it known? Is there some workaround? Thanks in advance, Leandro |
From: Espen S J. <es...@cs...> - 2008-03-12 16:20:34
|
Steve Rolls <sro...@ya...> writes: > First off, I have just started using clg, and would just like to give a big > thank you to Espen for his excellent work. > > Found a few occurrences of placehoder instead of placeholder leading > to "placeholder not valid subelement in ..." errors Thanks, I've fixed these typos and updated the CVS repository. -- Espen |
From: Steve R. <sro...@ya...> - 2008-03-09 18:26:51
|
First off, I have just started using clg, and would just like to give a big thank you to Espen for his excellent work. Found a few occurrences of placehoder instead of placeholder leading to "placeholder not valid subelement in ..." errors Index: gtkaction.lisp =================================================================== RCS file: /cvsroot/clg/clg/gtk/gtkaction.lisp,v retrieving revision 1.11 diff -c -r1.11 gtkaction.lisp *** gtkaction.lisp 14 Jan 2007 23:22:19 -0000 1.11 --- gtkaction.lisp 9 Mar 2008 17:58:36 -0000 *************** *** 208,216 **** (defvar *valid-ui-elements* '((:ui :menubar :toolbar :popup :accelerator) (:menubar :menuitem :separator :placeholder :menu) ! (:menu :menuitem :separator :placehoder :menu) ! (:popup :menuitem :separator :placehoder :menu) ! (:toolbar :toolitem :separator :placehoder) (:placeholder :menuitem :toolitem :separator :placeholder :menu) (:menuitem) (:toolitem) --- 208,216 ---- (defvar *valid-ui-elements* '((:ui :menubar :toolbar :popup :accelerator) (:menubar :menuitem :separator :placeholder :menu) ! (:menu :menuitem :separator :placeholder :menu) ! (:popup :menuitem :separator :placeholder :menu) ! (:toolbar :toolitem :separator :placeholder) (:placeholder :menuitem :toolitem :separator :placeholder :menu) (:menuitem) (:toolitem) --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. |