From set at tewebs.com  Sun Feb  1 14:28:09 2009
From: set at tewebs.com (set at tewebs.com)
Date: Sun, 01 Feb 2009 14:28:09 +0000
Subject: [cells-gtk-devel] Allegro 8.0 GUI multithreading
Message-ID: <200902011428.n11ESABT018597@webmail.ivenue.com>

I'm trying to produce a multithreaded GUI in Allegro 8.0.
However, once i try start-win, everything freezes. I traaced it back, and it
appears that it stars freezing in the main-loop function, specifically when
gtk-main is called. In addition, i tried to use the lispworks specific code in
the main-loop function marked with #+lispworks, and it still freezes.

Notice that I am not using the libcellsgtk dll which is necessary for some
aspects. Is this the problem?

Any help would be appreciated!
Thxs!



---- Msg sent via WebMail



From peter.hildebrandt at gmail.com  Sun Feb  1 15:29:33 2009
From: peter.hildebrandt at gmail.com (Peter Hildebrandt)
Date: Sun, 1 Feb 2009 16:29:33 +0100
Subject: [cells-gtk-devel] Allegro 8.0 GUI multithreading
In-Reply-To: <200902011428.n11ESABT018597@webmail.ivenue.com>
References: <200902011428.n11ESABT018597@webmail.ivenue.com>
Message-ID: <7758b2680902010729x35b29e36x3655862fd91b9fca@mail.gmail.com>

Hi,

Unfortunately I only have SBCL over here (linux), so here's a few
comments off the top of my head:

To understand your problem better, which platform are you on, linux or windows?

Have you tried using libcellsgtk?  When you're on linux, compiling it
is pretty straight forward, and for windows there are downloadable
versions.  Someone here might be able to provide a compiled version if
you give us specifics on your set up.

Have you activated cells-gtk's tracing?  Have a look at gtk-app.lisp
(I believe -- currently I am on an office machine with Win XP and no
development tools), there's a feature like "debug" or something which
you can use to activate tracing.  That might help, too.

Furthermore, how's bordeaux-threads with allegro on your platform?  Is
that all cleared (check the bordeaux-threads homepage).

If you send a trace (preferably the cells-gtk debug output) and some
more info on your environment, I might be able to give better advice.

Thanks,

Peter

On Sun, Feb 1, 2009 at 3:28 PM,  <set at tewebs.com> wrote:
> I'm trying to produce a multithreaded GUI in Allegro 8.0.
> However, once i try start-win, everything freezes. I traaced it back, and it
> appears that it stars freezing in the main-loop function, specifically when
> gtk-main is called. In addition, i tried to use the lispworks specific code in
> the main-loop function marked with #+lispworks, and it still freezes.
>
> Notice that I am not using the libcellsgtk dll which is necessary for some
> aspects. Is this the problem?
>
> Any help would be appreciated!
> Thxs!
>
>
>
> ---- Msg sent via WebMail
>
> _______________________________________________
> cells-gtk-devel site list
> cells-gtk-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>



From set at tewebs.com  Tue Feb  3 01:58:26 2009
From: set at tewebs.com (set at tewebs.com)
Date: Tue, 03 Feb 2009 01:58:26 +0000
Subject: [cells-gtk-devel] Allegro 8.0 GUI multithreading
Message-ID: <200902030158.n131wQxr001108@webmail.ivenue.com>

Hi!
First, I'm actually using Allegro 8.1, not 8.0, under windows xp. I'm using
cells-gtk3.
For a summary, i believe the code stalls in the main-loop function in the file
gtk-app when
(gtk-main) is called. I believe gtk-main directly calls a foreign function.

For reference, my test code is as follows:
(defpackage :test (:use :cl  :cells :cells-gtk))
(in-package :test)

(defvar *width* 300)
(defvar *height* 300)


(defmodel click-button (vbox)
  ()
  (:default-initargs

    :kids (c? (the-kids
               (mk-button 
                :width *width*
                :height *height*
                :on-clicked
                (callback (widget event data)))))))

(defmodel stay-awake-gui (gtk-app)
  ()
  (:default-initargs
      :width *width*
    :height *height*
    :kids (c? (the-kids
               (make-instance 'click-button
                 :fm-parent *parent*)))))

(defun start-button-monitor ()
     (cgtk::start-win 'stay-awake-gui))

(let ((*gtk-debug* t))
  (cgtk::with-trcs 
      (start-button-monitor)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I'm not using the libcellsgtk dll because all the dlls i can find do not have
the gtk-adds-g-thread-supported function in them which is required. I'm using
cells-gtk3, and these dlls i find aren't for this cells-gtk version.

Bordeaux threads is supported for allegro on windows according to the Common Lisp
Directory.
I also tried a simple example, and it worked.

I tried turning debug on, but I think there is no traces between the points the
error is 
taking place. I only got:

; Foreign loading libgobject-2.0-0.dll.
; Foreign loading libglib-2.0-0.dll.
; Foreign loading libgthread-2.0-0.dll.
; Foreign loading libgdk-win32-2.0-0.dll.
; Foreign loading libgtk-win32-2.0-0.dll.

; Foreign loading C:\Program Files\clisp-2.45\Lisp
Libraries\cells-gtk3\gtk-ffi\libcellsgtk.dll
-----UTILS--RESET-------- ;;or something like this

However, using allegro's stepper, I believe this is the place where allegro 
stalls. Start-win calls start-gtk-main which in turn calls gtk-main-thread
which then calls main-loop where everything stalls.

;;in function start-gtk-main
(threads:make-thread #'(lambda () (let ((*standard-output* so)) (gtk-thread))) 
     :name "gtk-main-thread"))

;;closure surrounding start-gtk-main which includes gtk-thread function
(progn
 (let ((gtk-main-thread nil))
   (flet ((gtk-thread ()
	    (gdk-threads-register-gtk-main (threads:current-thread))
	    (setf gtk-main-thread (threads:current-thread))
	    (loop (main-loop))))


;;piece of function in which allegro stalls
;;specifically, the line
;;#-lispworks (gtk-main)
(defun main-loop ()
  "Run GTK Main until user signal quit.  Errors are caught and displayed in a
dialog, providing the user with the option to \"recklessly continue\" -- not to
be called directly"
  (unwind-protect
       (if (eql *using-thread* 'yes)
	   (loop until
		(restart-case
		    (handler-bind
		       ((gtk-continuable-error #'(lambda (condition) (invoke-restart 
'continue-from-error condition )))
			 (error #'(lambda (con) (invoke-restart 'report-error con))))
		      #-lispworks
		      (gtk-main) ;;<-----Stalls Here
		      ;; Despite a workaround for Slime (see FAQ), the gtk-main-iteration-do loop, 
		      ;; still appears to be necessary for LW. Otherwise, LW consumes 99% of CPU.
		      #+lispworks	; give slime a chance.
		      (loop 
			 (loop while (gtk-events-pending) do 
			      (gtk-main-iteration-do nil))
			 (process-wait-with-timeout .01 "GTK event loop waiting"))
		      t)



Thanks!
Seth

>Hi,
>
>Unfortunately I only have SBCL over here (linux), so here's a few
>comments off the top of my head:
>
>To understand your problem better, which platform are you on, linux or windows?
>
>Have you tried using libcellsgtk?  When you're on linux, compiling it
>is pretty straight forward, and for windows there are downloadable
>versions.  Someone here might be able to provide a compiled version if
>you give us specifics on your set up.
>
>Have you activated cells-gtk's tracing?  Have a look at gtk-app.lisp
>(I believe -- currently I am on an office machine with Win XP and no
>development tools), there's a feature like "debug" or something which
>you can use to activate tracing.  That might help, too.
>
>Furthermore, how's bordeaux-threads with allegro on your platform?  Is
>that all cleared (check the bordeaux-threads homepage).
>
>If you send a trace (preferably the cells-gtk debug output) and some
>more info on your environment, I might be able to give better advice.
>
>Thanks,
>
>Peter
>
>On Sun, Feb 1, 2009 at 3:28 PM,  set at tewebs.com> wrote:
>> I'm trying to produce a multithreaded GUI in Allegro 8.0.
>> However, once i try start-win, everything freezes. I traaced it back, and it
>> appears that it stars freezing in the main-loop function, specifically when
>> gtk-main is called. In addition, i tried to use the lispworks specific code in
>> the main-loop function marked with #+lispworks, and it still freezes.
>>
>> Notice that I am not using the libcellsgtk dll which is necessary for some
>> aspects. Is this the problem?
>>
>> Any help would be appreciated!
>> Thxs!
>>
>>
>>
>> 
>>
>> _______________________________________________
>> cells-gtk-devel site list
>> cells-gtk-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>>


---- Msg sent via WebMail



From peter.hildebrandt at gmail.com  Tue Feb  3 09:39:51 2009
From: peter.hildebrandt at gmail.com (Peter Hildebrandt)
Date: Tue, 3 Feb 2009 10:39:51 +0100
Subject: [cells-gtk-devel] Allegro 8.0 GUI multithreading
In-Reply-To: <200902030158.n131wQxr001108@webmail.ivenue.com>
References: <200902030158.n131wQxr001108@webmail.ivenue.com>
Message-ID: <7758b2680902030139h68476133ha5bcc4aaa116f38b@mail.gmail.com>

Hi Seth,

thanks a lot for the comprehensive description.  I am quite busy right
now, but I will look into it.  This will entail me installing Allegro
on my win xp office machine, and as I am quite busy right now, it
might take a few days (possibly until the weekend) until I get round
to it.  Sorry about that.

I have a hunch that it is connected to the g_thread_supported func, so
my first shot would be to recompile the dll on windows with the new
functions (since I do not have windows on my development box, I never
did that).  I am not a really a windows person, so I don't even know
which tools to use, but we'll see ...

I also remember reading that there was some issue with gdk/gtk and
threading on windows in general, and that there was something special
to take care of -- but since I was solely on linux and writing a
thesis, I had other things on my mind.

I'll get back to you in a few days.

Cheers,

Peter

Btw, does it work w/o threading?


On Tue, Feb 3, 2009 at 2:58 AM,  <set at tewebs.com> wrote:
> Hi!
> First, I'm actually using Allegro 8.1, not 8.0, under windows xp. I'm using
> cells-gtk3.
> For a summary, i believe the code stalls in the main-loop function in the file
> gtk-app when
> (gtk-main) is called. I believe gtk-main directly calls a foreign function.
>
> For reference, my test code is as follows:
> (defpackage :test (:use :cl  :cells :cells-gtk))
> (in-package :test)
>
> (defvar *width* 300)
> (defvar *height* 300)
>
>
> (defmodel click-button (vbox)
>  ()
>  (:default-initargs
>
>    :kids (c? (the-kids
>               (mk-button
>                :width *width*
>                :height *height*
>                :on-clicked
>                (callback (widget event data)))))))
>
> (defmodel stay-awake-gui (gtk-app)
>  ()
>  (:default-initargs
>      :width *width*
>    :height *height*
>    :kids (c? (the-kids
>               (make-instance 'click-button
>                 :fm-parent *parent*)))))
>
> (defun start-button-monitor ()
>     (cgtk::start-win 'stay-awake-gui))
>
> (let ((*gtk-debug* t))
>  (cgtk::with-trcs
>      (start-button-monitor)))
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> I'm not using the libcellsgtk dll because all the dlls i can find do not have
> the gtk-adds-g-thread-supported function in them which is required. I'm using
> cells-gtk3, and these dlls i find aren't for this cells-gtk version.
>
> Bordeaux threads is supported for allegro on windows according to the Common Lisp
> Directory.
> I also tried a simple example, and it worked.
>
> I tried turning debug on, but I think there is no traces between the points the
> error is
> taking place. I only got:
>
> ; Foreign loading libgobject-2.0-0.dll.
> ; Foreign loading libglib-2.0-0.dll.
> ; Foreign loading libgthread-2.0-0.dll.
> ; Foreign loading libgdk-win32-2.0-0.dll.
> ; Foreign loading libgtk-win32-2.0-0.dll.
>
> ; Foreign loading C:\Program Files\clisp-2.45\Lisp
> Libraries\cells-gtk3\gtk-ffi\libcellsgtk.dll
> -----UTILS--RESET-------- ;;or something like this
>
> However, using allegro's stepper, I believe this is the place where allegro
> stalls. Start-win calls start-gtk-main which in turn calls gtk-main-thread
> which then calls main-loop where everything stalls.
>
> ;;in function start-gtk-main
> (threads:make-thread #'(lambda () (let ((*standard-output* so)) (gtk-thread)))
>     :name "gtk-main-thread"))
>
> ;;closure surrounding start-gtk-main which includes gtk-thread function
> (progn
>  (let ((gtk-main-thread nil))
>   (flet ((gtk-thread ()
>            (gdk-threads-register-gtk-main (threads:current-thread))
>            (setf gtk-main-thread (threads:current-thread))
>            (loop (main-loop))))
>
>
> ;;piece of function in which allegro stalls
> ;;specifically, the line
> ;;#-lispworks (gtk-main)
> (defun main-loop ()
>  "Run GTK Main until user signal quit.  Errors are caught and displayed in a
> dialog, providing the user with the option to \"recklessly continue\" -- not to
> be called directly"
>  (unwind-protect
>       (if (eql *using-thread* 'yes)
>           (loop until
>                (restart-case
>                    (handler-bind
>                       ((gtk-continuable-error #'(lambda (condition) (invoke-restart
> 'continue-from-error condition )))
>                         (error #'(lambda (con) (invoke-restart 'report-error con))))
>                      #-lispworks
>                      (gtk-main) ;;<-----Stalls Here
>                      ;; Despite a workaround for Slime (see FAQ), the gtk-main-iteration-do loop,
>                      ;; still appears to be necessary for LW. Otherwise, LW consumes 99% of CPU.
>                      #+lispworks       ; give slime a chance.
>                      (loop
>                         (loop while (gtk-events-pending) do
>                              (gtk-main-iteration-do nil))
>                         (process-wait-with-timeout .01 "GTK event loop waiting"))
>                      t)
>
>
>
> Thanks!
> Seth
>
>>Hi,
>>
>>Unfortunately I only have SBCL over here (linux), so here's a few
>>comments off the top of my head:
>>
>>To understand your problem better, which platform are you on, linux or windows?
>>
>>Have you tried using libcellsgtk?  When you're on linux, compiling it
>>is pretty straight forward, and for windows there are downloadable
>>versions.  Someone here might be able to provide a compiled version if
>>you give us specifics on your set up.
>>
>>Have you activated cells-gtk's tracing?  Have a look at gtk-app.lisp
>>(I believe -- currently I am on an office machine with Win XP and no
>>development tools), there's a feature like "debug" or something which
>>you can use to activate tracing.  That might help, too.
>>
>>Furthermore, how's bordeaux-threads with allegro on your platform?  Is
>>that all cleared (check the bordeaux-threads homepage).
>>
>>If you send a trace (preferably the cells-gtk debug output) and some
>>more info on your environment, I might be able to give better advice.
>>
>>Thanks,
>>
>>Peter
>>
>>On Sun, Feb 1, 2009 at 3:28 PM,  set at tewebs.com> wrote:
>>> I'm trying to produce a multithreaded GUI in Allegro 8.0.
>>> However, once i try start-win, everything freezes. I traaced it back, and it
>>> appears that it stars freezing in the main-loop function, specifically when
>>> gtk-main is called. In addition, i tried to use the lispworks specific code in
>>> the main-loop function marked with #+lispworks, and it still freezes.
>>>
>>> Notice that I am not using the libcellsgtk dll which is necessary for some
>>> aspects. Is this the problem?
>>>
>>> Any help would be appreciated!
>>> Thxs!
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cells-gtk-devel site list
>>> cells-gtk-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>>>
>
>
> ---- Msg sent via WebMail
>



From kentilton at gmail.com  Tue Feb  3 15:20:01 2009
From: kentilton at gmail.com (Kenneth Tilton)
Date: Tue, 03 Feb 2009 10:20:01 -0500
Subject: [cells-gtk-devel] Allegro 8.0 GUI multithreading
In-Reply-To: <7758b2680902030139h68476133ha5bcc4aaa116f38b@mail.gmail.com>
References: <200902030158.n131wQxr001108@webmail.ivenue.com>
	<7758b2680902030139h68476133ha5bcc4aaa116f38b@mail.gmail.com>
Message-ID: <498860A1.2060008@gmail.com>



Peter Hildebrandt wrote:
> Hi Seth,
> 
> thanks a lot for the comprehensive description.  I am quite busy right
> now, but I will look into it.  This will entail me installing Allegro
> on my win xp office machine, and as I am quite busy right now, it
> might take a few days (possibly until the weekend) until I get round
> to it.  Sorry about that.
> 
> I have a hunch that it is connected to the g_thread_supported func, so
> my first shot would be to recompile the dll on windows with the new
> functions (since I do not have windows on my development box, I never
> did that).  I am not a really a windows person, so I don't even know
> which tools to use, but we'll see ...
> 
> I also remember reading that there was some issue with gdk/gtk and
> threading on windows in general, and that there was something special
> to take care of -- but since I was solely on linux and writing a
> thesis, I had other things on my mind.
> 
> I'll get back to you in a few days.

I can confirm that I could only run a cells-gtk test once under 
ACL/win32 and then I had to kill the Lisp.

As for win32 C/C++ tools:

- The whole cygwin stack for a unix-y experience
- Microsoft VC++ express or whatever they call it now
- Something that uses Mingw but installs nicely so I never knew that 
till I just wen here to find a link:

     http://www.bloodshed.net/devcpp.html


Thx fer keeping your hand in on Cells-Gtk, Peter. Today I am looking at 
cloning Celtk into CellsQX where qooxdoo is the backend. Could be Web 
2.0 heaven.

kenneth



From peter.hildebrandt at gmail.com  Wed Feb  4 18:43:15 2009
From: peter.hildebrandt at gmail.com (Peter Hildebrandt)
Date: Wed, 4 Feb 2009 19:43:15 +0100
Subject: [cells-gtk-devel] Allegro 8.0 GUI multithreading
In-Reply-To: <200902040055.n140tcfd019317@webmail.ivenue.com>
References: <200902040055.n140tcfd019317@webmail.ivenue.com>
Message-ID: <7758b2680902041043na524646wf6a38cfbd1264f94@mail.gmail.com>

Hi Seth,

given the low volume and the small number of subscribers here, I think
you can feel free to hit "reply all" and thus cc the list on each of
your posts.  The cells-gtk community is pretty small (optimistic
guess:  you need two hands to count 'em all).

I might say otherwise if there was a bigger audience and 50+ mails a
day, but this way I don't think anyone minds.

If anyone here is seriously upset about deleting an occasional "thank
you" mail, please let me know, before I go on teaching wrong stuff to
people :-)

As to the problem at hand:  I'll install the Bloodshed DevCpp (see
Kenny's link) and some lisp on my office laptop on the weekend and see
how far I get.  I'll keep you posted.

Cheers,
Peter




On Wed, Feb 4, 2009 at 1:55 AM,  <set at tewebs.com> wrote:
> Thanks! I'll look forward to hearing from you.
> Yes, it does work if i don't try to use the multithreaded start-win.
>
> Just a quick question. Do I specifically send an email to the person who replied
> to me or
> do I somehow send the email to the cells-gtk-devel? I'm new to this.
>
> Thanks,
> Seth
>
> On Tue Feb  3  1:39 , Peter Hildebrandt <peter.hildebrandt at gmail.com> sent:
>
>>Hi Seth,
>>
>>thanks a lot for the comprehensive description.  I am quite busy right
>>now, but I will look into it.  This will entail me installing Allegro
>>on my win xp office machine, and as I am quite busy right now, it
>>might take a few days (possibly until the weekend) until I get round
>>to it.  Sorry about that.
>>
>>I have a hunch that it is connected to the g_thread_supported func, so
>>my first shot would be to recompile the dll on windows with the new
>>functions (since I do not have windows on my development box, I never
>>did that).  I am not a really a windows person, so I don't even know
>>which tools to use, but we'll see ...
>>
>>I also remember reading that there was some issue with gdk/gtk and
>>threading on windows in general, and that there was something special
>>to take care of -- but since I was solely on linux and writing a
>>thesis, I had other things on my mind.
>>
>>I'll get back to you in a few days.
>>
>>Cheers,
>>
>>Peter
>>
>>Btw, does it work w/o threading?
>>
>>
>>On Tue, Feb 3, 2009 at 2:58 AM,  set at tewebs.com> wrote:
>>> Hi!
>>> First, I'm actually using Allegro 8.1, not 8.0, under windows xp. I'm using
>>> cells-gtk3.
>>> For a summary, i believe the code stalls in the main-loop function in the file
>>> gtk-app when
>>> (gtk-main) is called. I believe gtk-main directly calls a foreign function.
>>>
>>> For reference, my test code is as follows:
>>> (defpackage :test (:use :cl  :cells :cells-gtk))
>>> (in-package :test)
>>>
>>> (defvar *width* 300)
>>> (defvar *height* 300)
>>>
>>>
>>> (defmodel click-button (vbox)
>>>  ()
>>>  (:default-initargs
>>>
>>>    :kids (c? (the-kids
>>>               (mk-button
>>>                :width *width*
>>>                :height *height*
>>>                :on-clicked
>>>                (callback (widget event data)))))))
>>>
>>> (defmodel stay-awake-gui (gtk-app)
>>>  ()
>>>  (:default-initargs
>>>      :width *width*
>>>    :height *height*
>>>    :kids (c? (the-kids
>>>               (make-instance 'click-button
>>>                 :fm-parent *parent*)))))
>>>
>>> (defun start-button-monitor ()
>>>     (cgtk::start-win 'stay-awake-gui))
>>>
>>> (let ((*gtk-debug* t))
>>>  (cgtk::with-trcs
>>>      (start-button-monitor)))
>>>
>>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>>
>>> I'm not using the libcellsgtk dll because all the dlls i can find do not have
>>> the gtk-adds-g-thread-supported function in them which is required. I'm using
>>> cells-gtk3, and these dlls i find aren't for this cells-gtk version.
>>>
>>> Bordeaux threads is supported for allegro on windows according to the Common Lisp
>>> Directory.
>>> I also tried a simple example, and it worked.
>>>
>>> I tried turning debug on, but I think there is no traces between the points the
>>> error is
>>> taking place. I only got:
>>>
>>> ; Foreign loading libgobject-2.0-0.dll.
>>> ; Foreign loading libglib-2.0-0.dll.
>>> ; Foreign loading libgthread-2.0-0.dll.
>>> ; Foreign loading libgdk-win32-2.0-0.dll.
>>> ; Foreign loading libgtk-win32-2.0-0.dll.
>>>
>>> ; Foreign loading C:\Program Files\clisp-2.45\Lisp
>>> Libraries\cells-gtk3\gtk-ffi\libcellsgtk.dll
>>> -----UTILS--RESET-------- ;;or something like this
>>>
>>> However, using allegro's stepper, I believe this is the place where allegro
>>> stalls. Start-win calls start-gtk-main which in turn calls gtk-main-thread
>>> which then calls main-loop where everything stalls.
>>>
>>> ;;in function start-gtk-main
>>> (threads:make-thread #'(lambda () (let ((*standard-output* so)) (gtk-thread)))
>>>     :name "gtk-main-thread"))
>>>
>>> ;;closure surrounding start-gtk-main which includes gtk-thread function
>>> (progn
>>>  (let ((gtk-main-thread nil))
>>>   (flet ((gtk-thread ()
>>>            (gdk-threads-register-gtk-main (threads:current-thread))
>>>            (setf gtk-main-thread (threads:current-thread))
>>>            (loop (main-loop))))
>>>
>>>
>>> ;;piece of function in which allegro stalls
>>> ;;specifically, the line
>>> ;;#-lispworks (gtk-main)
>>> (defun main-loop ()
>>>  "Run GTK Main until user signal quit.  Errors are caught and displayed in a
>>> dialog, providing the user with the option to \"recklessly continue\" -- not to
>>> be called directly"
>>>  (unwind-protect
>>>       (if (eql *using-thread* 'yes)
>>>           (loop until
>>>                (restart-case
>>>                    (handler-bind
>>>                       ((gtk-continuable-error #'(lambda (condition)
> (invoke-restart
>>> 'continue-from-error condition )))
>>>                         (error #'(lambda (con) (invoke-restart 'report-error
> con))))
>>>                      #-lispworks
>>>                      (gtk-main) ;;
>>>                      ;; Despite a workaround for Slime (see FAQ), the
> gtk-main-iteration-do loop,
>>>                      ;; still appears to be necessary for LW. Otherwise, LW
> consumes 99% of CPU.
>>>                      #+lispworks       ; give slime a chance.
>>>                      (loop
>>>                         (loop while (gtk-events-pending) do
>>>                              (gtk-main-iteration-do nil))
>>>                         (process-wait-with-timeout .01 "GTK event loop waiting"))
>>>                      t)
>>>
>>>
>>>
>>> Thanks!
>>> Seth
>>>
>>>>Hi,
>>>>
>>>>Unfortunately I only have SBCL over here (linux), so here's a few
>>>>comments off the top of my head:
>>>>
>>>>To understand your problem better, which platform are you on, linux or windows?
>>>>
>>>>Have you tried using libcellsgtk?  When you're on linux, compiling it
>>>>is pretty straight forward, and for windows there are downloadable
>>>>versions.  Someone here might be able to provide a compiled version if
>>>>you give us specifics on your set up.
>>>>
>>>>Have you activated cells-gtk's tracing?  Have a look at gtk-app.lisp
>>>>(I believe -- currently I am on an office machine with Win XP and no
>>>>development tools), there's a feature like "debug" or something which
>>>>you can use to activate tracing.  That might help, too.
>>>>
>>>>Furthermore, how's bordeaux-threads with allegro on your platform?  Is
>>>>that all cleared (check the bordeaux-threads homepage).
>>>>
>>>>If you send a trace (preferably the cells-gtk debug output) and some
>>>>more info on your environment, I might be able to give better advice.
>>>>
>>>>Thanks,
>>>>
>>>>Peter
>>>>
>>>>On Sun, Feb 1, 2009 at 3:28 PM,  set at tewebs.com> wrote:
>>>>> I'm trying to produce a multithreaded GUI in Allegro 8.0.
>>>>> However, once i try start-win, everything freezes. I traaced it back, and it
>>>>> appears that it stars freezing in the main-loop function, specifically when
>>>>> gtk-main is called. In addition, i tried to use the lispworks specific code in
>>>>> the main-loop function marked with #+lispworks, and it still freezes.
>>>>>
>>>>> Notice that I am not using the libcellsgtk dll which is necessary for some
>>>>> aspects. Is this the problem?
>>>>>
>>>>> Any help would be appreciated!
>>>>> Thxs!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cells-gtk-devel site list
>>>>> cells-gtk-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>>>>>
>>>
>>>
>>> ---- Msg sent via WebMail
>>>
>
>
> ---- Msg sent via WebMail
>



From qy513victor at gmail.com  Fri Feb  6 21:17:20 2009
From: qy513victor at gmail.com (Qu Yang)
Date: Sat, 7 Feb 2009 07:17:20 +1000
Subject: [cells-gtk-devel] Compilation error in cairo-drawing-area.lisp
Message-ID: <ee8030670902061317y2a45009bveab9fd6a733b52f0@mail.gmail.com>

Hi all,

This is the error I have after (require 'cells-gtk)

or:
;   READ failure in COMPILE-FILE:
;     SB-INT:SIMPLE-READER-PACKAGE-ERROR at 22404 (line 576, column 69) on
#<SB-SYS:FD-STREAM for "file
/home/yang/.sbcl/site/cells-gtk3/cells-gtk/cairo-drawing-area.lisp"
{BD5DAB1}>:
;       Symbol "FONT-SLANT-ITALIC" not found in the CL-CAIRO2 package.
; compilation aborted after 0:00:03

I have installed cl-cairo2.

Can anyone please help to solve this problem?

Regards,
Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20090207/aceb646c/attachment.html>

From ramarren at gmail.com  Sat Feb  7 19:24:10 2009
From: ramarren at gmail.com (Ramarren)
Date: Sat, 7 Feb 2009 20:24:10 +0100
Subject: [cells-gtk-devel] Compilation error in cairo-drawing-area.lisp
Message-ID: <b840f45d0902071124r279a9a02nb615bb0fab32c4ce@mail.gmail.com>

> Can anyone please help to solve this problem?

Hm, I never used mailing lists before, so I hope this message doesn't
get lost somewhere... anyway, although I do not need a Lisp-driven GUI
at the moment, I try too keep cells-gtk3 in a state in which at least
test-gtk runs in case I need one. I have published my patched versions
of both cells and cells-gtk3 to github:
http://github.com/Ramarren/cells/tree/master
http://github.com/Ramarren/cells-gtk3/commits/master

Hopefully, I haven't broken anything.



From peter.hildebrandt at gmail.com  Mon Feb  9 15:54:39 2009
From: peter.hildebrandt at gmail.com (Peter Hildebrandt)
Date: Mon, 9 Feb 2009 16:54:39 +0100
Subject: [cells-gtk-devel] Compilation error in cairo-drawing-area.lisp
In-Reply-To: <b840f45d0902071124r279a9a02nb615bb0fab32c4ce@mail.gmail.com>
References: <b840f45d0902071124r279a9a02nb615bb0fab32c4ce@mail.gmail.com>
Message-ID: <7758b2680902090754x2d40b17ft29617b81cc730a45@mail.gmail.com>

Thanks for sharing this.  I will check it out and merge it with the
cvs on common-lisp.net

Background for these problems:  cl-cairo2 and cffi have been updated
since I put out the last release of cells-gtk3, and unfortunately
those updates were not quite backwards compatible.


Peter
On Sat, Feb 7, 2009 at 8:24 PM, Ramarren <ramarren at gmail.com> wrote:
>> Can anyone please help to solve this problem?
>
> Hm, I never used mailing lists before, so I hope this message doesn't
> get lost somewhere... anyway, although I do not need a Lisp-driven GUI
> at the moment, I try too keep cells-gtk3 in a state in which at least
> test-gtk runs in case I need one. I have published my patched versions
> of both cells and cells-gtk3 to github:
> http://github.com/Ramarren/cells/tree/master
> http://github.com/Ramarren/cells-gtk3/commits/master
>
> Hopefully, I haven't broken anything.
>
> _______________________________________________
> cells-gtk-devel site list
> cells-gtk-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>



From johan at riise-data.no  Tue Feb 10 22:53:05 2009
From: johan at riise-data.no (Johan Ur Riise)
Date: Tue, 10 Feb 2009 23:53:05 +0100
Subject: [cells-gtk-devel] Compilation error in cairo-drawing-area.lisp
In-Reply-To: <ee8030670902061317y2a45009bveab9fd6a733b52f0@mail.gmail.com>
References: <ee8030670902061317y2a45009bveab9fd6a733b52f0@mail.gmail.com>
Message-ID: <20090210225305.GA26362@riise-data.no>

On Sat, Feb 07, 2009 at 07:17:20AM +1000, Qu Yang wrote:
> Hi all,
> 
> This is the error I have after (require 'cells-gtk)
> 
> or:
> ;   READ failure in COMPILE-FILE:
> ;     SB-INT:SIMPLE-READER-PACKAGE-ERROR at 22404 (line 576, column 69) on
> #<SB-SYS:FD-STREAM for "file
> /home/yang/.sbcl/site/cells-gtk3/cells-gtk/cairo-drawing-area.lisp"
> {BD5DAB1}>:
> ;       Symbol "FONT-SLANT-ITALIC" not found in the CL-CAIRO2 package.
> ; compilation aborted after 0:00:03
> 
> I have installed cl-cairo2.
> 
> Can anyone please help to solve this problem?
> 
> Regards,
> Yang

> _______________________________________________
> cells-gtk-devel site list
> cells-gtk-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-gtk-devel

If you have not got round to cloning the git repository, here is what 
you can change in the mean time:

johan at perle:~/prg/cells-gtk/cells-gtk$ diff -u cairo-drawing-area.lisp.orig cairo-drawing-area.lisp
--- cairo-drawing-area.lisp.orig        2008-06-03 18:33:44.000000000 +0200
+++ cairo-drawing-area.lisp     2009-01-17 21:49:41.000000000 +0100
@@ -573,8 +573,8 @@
 (defdraw text-label (p text font-face font-size italic bold alignment vertical-alignment rgb alpha)
   (cl-cairo2:set-font-size font-size context)
   (cl-cairo2:select-font-face font-face
-                              (if italic 'cl-cairo2:font-slant-italic 'cl-cairo2:font-slant-normal)
-                              (if bold 'cl-cairo2:font-weight-bold 'cl-cairo2:font-weight-normal)
+                              (if italic :italic :normal)
+                              (if bold :bold :normal)
                               context)
   (multiple-value-bind (x-bearing y-bearing text-width text-height)
       (cl-cairo2:text-extents text context)
johan at perle:~/prg/cells-gtk/cells-gtk$ 



-- 
Hilsen
Johan Ur Riise



From christian.lynbech at tieto.com  Wed Feb 25 09:42:04 2009
From: christian.lynbech at tieto.com (Lynbech Christian)
Date: Wed, 25 Feb 2009 10:42:04 +0100
Subject: [cells-gtk-devel] SBCL/CFFI compability problems
Message-ID: <ytqpljruc0pf.fsf@ul000205.eu.tieto.com>

I have been playing a little with cells-gtk and have run into some
problems between SBCL and CFFI.

I was using CFFI 0.9.2 but this triggers a package lock violation with
SBCL 1.0.22 (on x86 linux) so I upgraded to the most recent CFFI version
(0.10.4), but then cells-gtk stopped working.

The error I get when trying to run a little simple demo is this:

        The value of STRING is #(71 85 73 32 68 101 109 111), 
        which is not of type STRING.

ultimately coming from a call to GTK-FFI:GTK-WINDOW-SET-TITLE with a
string argument ("GUI Demo").

Presumably CFFI used to accept octet sequences as string arguments but
doesn't anymore.

Anyway, if I then disable the sbcl code specific code in 'lisp-to-utf-8'
and 'utf-8-to-lisp' in "gtk-ffi/gtk-ffi-impl.lisp", then our little demo
works again.

I have attached the stack trace and a diff for the aforementioned
disabling to illustrate what I have done.

I am however unsure as to what the proper solution is. I suspect that
code was invented for a reason, but it is unclear to me if those reasons
remain valid in the face of the newer CFFI and what we may lose by
disabling it.

I should perhaps also mention that I am running with this in my .sbclrc:

        (setq sb-impl::*default-external-format* :latin-1)

in case that makes a difference.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stack-trace.txt
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20090225/a64c12c1/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbcl.diff
Type: text/x-patch
Size: 1242 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20090225/a64c12c1/attachment.bin>

From ramarren at gmail.com  Wed Feb 25 10:35:14 2009
From: ramarren at gmail.com (Ramarren)
Date: Wed, 25 Feb 2009 11:35:14 +0100
Subject: [cells-gtk-devel] SBCL/CFFI compability problems
In-Reply-To: <ytqpljruc0pf.fsf@ul000205.eu.tieto.com>
References: <ytqpljruc0pf.fsf@ul000205.eu.tieto.com>
Message-ID: <b840f45d0902250235n51096f53tc297963ac1178f1a@mail.gmail.com>

2009/2/25 Lynbech Christian <christian.lynbech at tieto.com>:
> I have been playing a little with cells-gtk and have run into some
> problems between SBCL and CFFI.

When I have been playing with cells-gtk some time ago I ran into the
same problem, as well as some others. I have included all my proposed
corrections at http://github.com/Ramarren/cells-gtk3/tree/master , but
unfortunately cells-gtk maintainters did not have time to review and
include them into official repository. Hope this helps.

Jakub Higersberger