asdf-install

Hi,

When I try (asdf-install 'cells-gtk) I get error:

Server responded 404 for GET
http://www.cliki.net/CFFI-UFFI-COMPAT?download [Condition of type
ASDF-INSTALL::DOWNLOAD-ERROR]

Is there another place where can I get this package?

Thank you,
Stanislav Bohm

Re: asdf-install

cffi-uffi-compat is part of cffi IIRC.  If not, I see cffi-uffi-compat
over in Ken Tilton's cells CVS:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells-gtk/cffi/?root=cells

I think the asdf-install is a little outdated -- you might want to
check out my instructions over here on how to set up a current system:
http://www.washbear-network.de/peterblog/getting-started-with-cells-gtk/

Some other folks around here have submitted patches to make it work
with the latest cffi.  There is a git repo around which includes a
number of recent patches.  Just skim the archives of this list for the
past few months.

Cheers,
Peter

On Tue, Mar 10, 2009 at 9:22 PM, Stanislav Bohm <s.bohm <at> centrum.cz> wrote:
>
> Hi,
>
> When I try (asdf-install 'cells-gtk) I get error:
>
> Server responded 404 for GET
> http://www.cliki.net/CFFI-UFFI-COMPAT?download [Condition of type
> ASDF-INSTALL::DOWNLOAD-ERROR]
>
> Is there another place where can I get this package?
>
> Thank you,
> Stanislav Bohm

label widgets are too high

This is a small problem, but as a warmup: When I make a set of labels in
a vbox, the height of the labels are quite high. For instance, this app 
produces a window of size 39 x 176 excluding frame and title-bar:

(cells:defmodel my-app (cells-gtk:gtk-app)
  ()
  (:default-initargs
      :md-name :my-app
    :position :center
    :kids (cells:c? (cells:the-kids (cells-gtk:mk-vbox  :kids
(cells-gtk:kids-list?

(cgtk:mk-label :text "haha")

(cgtk:mk-label :text "hihi")
                                                               ))))))

This is a small problem, but as a warmup: When I make a set of labels in
a vbox, the height of the labels are quite high. For instance, this app 
produces a window of size 39 x 176 excluding frame and title-bar:

(cells:defmodel my-app (cells-gtk:gtk-app)
  ()
  (:default-initargs
      :md-name :my-app
    :position :center
    :kids (cells:c? (cells:the-kids (cells-gtk:mk-vbox  :kids

Re: SBCL/CFFI compability problems

Yeah, I take full responsibility.  My day has been keeping me quite
busy these days.  Cells-gtk is very high up on my list of non-work
related things to do -- I hope I'll get round to it soon.

Peter

On Wed, Feb 25, 2009 at 11:35 AM, Ramarren <ramarren <at> gmail.com> wrote:
> 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
>
> _______________________________________________
> cells-gtk-devel site list
> cells-gtk-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>

unhandled memory fault in test-gtk, 64bit?

Running test-gtk with ramarrens
git://github.com/Ramarren/cells-gtk3.git, I get

Unhandled memory fault at #x400000004B.

when i run the test.

Could this have something to do with me using a 64 bit sbcl?

Unhandled memory fault at #x400000004B.
   [Condition of type SB-SYS:MEMORY-FAULT-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [ABORT] Return to SLIME's top level.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
RUNNING {10047B68C1}>)

Backtrace:
  0: (SB-SYS:MEMORY-FAULT-ERROR)
  1: ("foreign function: #x41EE82")
  2: ("foreign function: #x41EF60")
  3: ("foreign function: #x800DB044A0")
  4: (GTK-LIST-STORE-NEWV 2 #.(SB-SYS:INT-SAP #X009D0FA0))
  5: (GTK-LIST-STORE-NEW (:STRING :STRING))
  6: ((LAMBDA (CELLS::SLOT-C &AUX (SELF (CELLS::C-MODEL CELLS::SLOT-C))
(.CACHE (CELLS::C-VALUE CELLS::SLOT-C)) (.CACHE-BOUND-P
(CELLS::CACHE-BOUND-P CELLS::SLOT-C)))) dirty<0:N ID/LIST-STORE259 =
NIL>)
  7: (CELLS::CALCULATE-AND-LINK dirty<0:N ID/LIST-STORE259 = NIL>)

Re: unhandled memory fault in test-gtk, 64bit?

On Sat, Mar 14, 2009 at 3:26 PM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> Unhandled memory fault at #x400000004B.
>
> when i run the test.
>
> Could this have something to do with me using a 64 bit sbcl?

This might be it, if you have GTK compiled for 32 bits and SBCL for 64
bits their concept of "int" would differ. But I would expect failure
in that case to be earlier, and the address looks weird. Maybe the
library didn't load correctly? But then, I don't really know how GTK
works, I just hacked things until it started working on my machine,
with Gentoo Linux and gtk+-2.12.11.

Oh, and regarding your earlier problem with too high labels, I checked
your example and it creates a window just high enough to fit the text,
as it should be.

Regards,
Jakub Higersberger

Re: unhandled memory fault in test-gtk, 64bit?

lø., 14.03.2009 kl. 16.59 +0100, skrev Ramarren:
> On Sat, Mar 14, 2009 at 3:26 PM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> > Unhandled memory fault at #x400000004B.
> >
> > when i run the test.
> >
> > Could this have something to do with me using a 64 bit sbcl?
> 
> This might be it, if you have GTK compiled for 32 bits and SBCL for 64
> bits their concept of "int" would differ. But I would expect failure
> in that case to be earlier, and the address looks weird. Maybe the
> library didn't load correctly? But then, I don't really know how GTK
> works, I just hacked things until it started working on my machine,
> with Gentoo Linux and gtk+-2.12.11.
> 
> Oh, and regarding your earlier problem with too high labels, I checked
> your example and it creates a window just high enough to fit the text,
> as it should be.
> 

Fine, my 64 bit system is ubuntu hardy, and it is 64 bit from inner to
outer, I hope. Gtk version is 2.12.9-3ubuntu5.

Since last I have upgraded all packages on a 32 bit debian system,
including cells and cells-gtk3 from your git repositories. And in fact,
both the label height problem and the unhandled memory fault
disappeared, and I am able to run the complete test-gtk application.
(with the memory error, I could run it if I removed tree-view and menu
from the test-gtk app). The test-gtk application is also more visually
appealing with the height problem out of the way.

Hangs when closing app.

Now I have a real app going. Next problem: 
I want to do something resembling the :pulse-image in test-gtk, that
is a widget that changes text depending on some cell.

The difference here is that it depends on a cell in its own instance,
but I get the same problem if I put it in another instance, like in the
app itself or in a global instance of a specially designed class.

This is a minimal app showing the problem. Setting of the value works,
and the display is changed, But when I close the app, it hangs. 
If I just close it without executing the setf, it closes normally.
Any ideas?

(cells:defmodel statebar (cgtk:hbox) 
  ((busy :accessor busy :initform (cells:c-in nil)))
  (:default-initargs
      :md-name :statebar
      :kids (cgtk:kids-list?
             (cgtk:mk-label :text (if (busy cells:self) "Busy"
"NotBusy"))
             (cgtk:mk-label :markup (cgtk:with-markup (:background (if
(busy cells:self) :yellow :brown))
                            (if (busy cells:self) "Busy" "NotBusy"))))))

(cells:defmodel my-app (cells-gtk:gtk-app)
  ()
  (:default-initargs
    :kids (cells:c? (cells:the-kids 
                     (cells-gtk:mk-vbox 
                      :kids  (cells-gtk:kids-list?

Re: Hangs when closing app.

On Sun, Mar 15, 2009 at 3:51 PM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> #|
> (cells-gtk:start-app 'my-app)
> |#
>
> #|
> (cgtk:with-widget (w :statebar) (setf (busy w) t))
> |#

On my system at least cells-gtk:start-app blocks the repl, so how
would you set the widget after that? When using cells-gtk:start-win it
closes normally in both cases.

Anyway, as far as I can tell, cells have no thread-safety at all. The
GTK parts do have locks to guarantee at most one thread accesses them
at a time, but as far as I can tell the cells system doesn't, and it
is quite possible to cause two conflicting datapulses, which means
that all cell access, even with models completely separate from
cells-gtk, have to be done through cells-gtk:with-gdk-threads. But
this doesn't seem to related to your problem.

Regards,
Jakub Higersberger

Re: Hangs when closing app.

sø., 15.03.2009 kl. 16.30 +0100, skrev Ramarren:
> On Sun, Mar 15, 2009 at 3:51 PM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> > #|
> > (cells-gtk:start-app 'my-app)
> > |#
> >
> > #|
> > (cgtk:with-widget (w :statebar) (setf (busy w) t))
> > |#
> 
> On my system at least cells-gtk:start-app blocks the repl, so how
> would you set the widget after that? 
I used slime, and executed one in the repl and one by C-x C-e in the
source window. That means two threads, but I also tried enclosing the
setf in cells-gtk:with-gdk-threads, with the same result

> When using cells-gtk:start-win it
> closes normally in both cases.

That is a lead, could be threads problem. Using start-win does not make
a difference.

> Anyway, as far as I can tell, cells have no thread-safety at all. The
> GTK parts do have locks to guarantee at most one thread accesses them
> at a time, but as far as I can tell the cells system doesn't, and it
> is quite possible to cause two conflicting datapulses, which means
> that all cell access, even with models completely separate from
> cells-gtk, have to be done through cells-gtk:with-gdk-threads. But
> this doesn't seem to related to your problem.