Introduced destructors and finalized GdkCursor

Introduced destructors and finalized GdkCursor

[Marko Rauhamaa]

Summary: Introduced destructors and finalized GdkCursor.

Details:

 - build-guile-gtk-1.2: The defs files didn't specify destructors.
   Instead, the garbage collector was trusted to release resources. This
   is the right strategy as long as the resource is a piece of client
   RAM. However, we must release X server resources as soon as they are
   no longer needed.

   I have now introduced a new option for define-boxed and
   define-struct: (physical #t). When set, the function specified in the
   free option becomes callable from guile code. The proxy object stays
   alive, but any reference to it causes an assertion to fail.

 - gdk-1.2.defs: As a first application of destructors, I added the
   (physical #t) option to GdkCursor.


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/

Re: Introduced destructors and finalized GdkCursor

[Kevin Ryde]

Marko Rauhamaa <marko@pacujo.net> writes:
>
> Summary: Introduced destructors and finalized GdkCursor.

Umm, it's probably not really my place to say this, and without
wanting to nitpick, but will there be ChangeLog entries for these
various updates?

Re: Introduced destructors and finalized GdkCursor

[Marko Rauhamaa]

Kevin Ryde <user42@zip.com.au>:

> Marko Rauhamaa <marko@pacujo.net> writes:
> >
> > Summary: Introduced destructors and finalized GdkCursor.
> 
> Umm, it's probably not really my place to say this, and without
> wanting to nitpick, but will there be ChangeLog entries for these
> various updates?

I don't know what ChangeLog is. I'm commenting the CVS commits and
copying my comments here.

Should I enter them in a third place as well?

Ideally I'd have to enter the comment in one place only (CVS).


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/

Re: Introduced destructors and finalized GdkCursor

[Kevin Ryde]

Marko Rauhamaa <marko@pacujo.net> writes:
>
> I don't know what ChangeLog is. I'm commenting the CVS commits and
> copying my comments here.
>
> Should I enter them in a third place as well?

The ChangeLog file is the main place for change notes.  Please try to
follow the style there.  In emacs "C-x 4 a" will give a starting
point.

In general it's only a summary that's wanted, it doesn't have to go
into much detail.  But anything added, deleted or changed should rate
a mention one way or another.

> Ideally I'd have to enter the comment in one place only (CVS).

Copying the ChangeLog entry into the cvs comment when committing is
good.

Re: Introduced destructors and finalized GdkCursor

[Marko Rauhamaa]

Marko Rauhamaa <marko@pacujo.net>:

> Summary: Introduced destructors and finalized GdkCursor.
> 
> Details:
> 
>  - build-guile-gtk-1.2: The defs files didn't specify destructors.
>    Instead, the garbage collector was trusted to release resources. This
>    is the right strategy as long as the resource is a piece of client
>    RAM. However, we must release X server resources as soon as they are
>    no longer needed.
> 
>    I have now introduced a new option for define-boxed and
>    define-struct: (physical #t). When set, the function specified in the
>    free option becomes callable from guile code. The proxy object stays
>    alive, but any reference to it causes an assertion to fail.
> 
>  - gdk-1.2.defs: As a first application of destructors, I added the
>    (physical #t) option to GdkCursor.

In light of my recent revelation regarding the design of the boxed
types, I have to backtrack from this scheme and take out the whole
"physical" thing.

Theoretically, the problem is real -- you could design an application
that forces the X server to store a large number of unused resources.
However,

  1. There is no way to fix the problem.

  2. In practice, the problem is not likely get bad since the main case,
     GdkWindow, happens to have the right kind of destructor
     (gdk_window_destroy).


Here's the reason for my confusion: I thought there was a one-to-one
mapping between the boxed smobs and GDK objects. It turns out multiple
smobs can share the same GDK object, and that design cannot be changed.


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/