goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

Hello,

It would be really nice if someone can help me with the following unexpected bug:

	http://paste.lisp.org/+33RA

I don't think i'll be able to solve it by myself, at this level of knowledge I have
from both goops [implementation I mean, knowledge close to zero] and the low level
machinery gnome/gobject/gtype.scm

Many thanks,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Hi,

My first impression is that the error might be caused by using the
combination of #:allocation #:virtual and #:init-keyword for the "colour"
slot. Since #:init-keyword initializes slot value with a given value, and
virtual slots have no actual value, the semantics of such operation is
rather unclear.

If your intention is to use the keyword as an argument to the constructor,
you should rather provide a custom "initialize" method (and drop the
"init-keyword" for the colour slot):

(define-method (initialize (self <bar>) args)
  (next-method)
  (let-keywords args #t ((colour (or #f some-default-value-you-wish)))
    (if colour (slot-set! self 'colour colour))))

HTH

2014-12-19 20:46 GMT+01:00 David Pirotte <david@altosw.be>:
>
> Hello,
>
> It would be really nice if someone can help me with the following
> unexpected bug:
>
>         http://paste.lisp.org/+33RA
>
> I don't think i'll be able to solve it by myself, at this level of
> knowledge I have
> from both goops [implementation I mean, knowledge close to zero] and the
> low level
> machinery gnome/gobject/gtype.scm
>
> Many thanks,
> David
>

[-- Attachment #2: Type: text/html, Size: 1953 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

Hi Panicz,

I don't think you did read the paste (3 parts) carefully, since the first part of
the paste is a goops example [no guile-gnome[clutter] code] that does work, as
expected.

> My first impression is that the error might be caused by using the
> combination of #:allocation #:virtual and #:init-keyword for the "colour"
> slot.

Your impression is wrong, please try the code from the 1st part of the paste.

> Since #:init-keyword initializes slot value with a given value, and
> virtual slots have no actual value, the semantics of such operation is
> rather unclear.

This is also wrong and there is nothing unclear here: when one uses the #:virtual
allocation option, one must also provide both #:slot-ref #:slot-set! options to
specify how to read and write values for this slot [see the manual]. so, no possible
ambiguity, if one also uses #:init-keyword, the system must call, at the right
initialization time, the provided code for the #:slot-set! option, which is what
goops does perfectly.

The problem is with/in guile-gnome, which for some reason I am unable clearly
identify and debug by myself, breaks goops.

> If your intention is to use the keyword as an argument to the constructor,
> you should rather provide a custom "initialize" method (and drop the
> "init-keyword" for the colour slot):

I don't agree, one should not have to provide any additional code, this a
guile-gnome related bug.

Happy hacking,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

On Fri 19 Dec 2014 20:46, David Pirotte <david@altosw.be> writes:

> It would be really nice if someone can help me with the following unexpected bug:
>
> 	http://paste.lisp.org/+33RA
>
> I don't think i'll be able to solve it by myself, at this level of knowledge I have
> from both goops [implementation I mean, knowledge close to zero] and the low level
> machinery gnome/gobject/gtype.scm

What is the bug?  The top part that you list that does not use
guile-gnome works fine, and I don't want to bring guile-gnome into
consideration when looking for GOOPS bugs :)  Can you still reproduce
the bug on stable-2.0 or master?  Can you make a test case without
guile-gnome?  If so please include it in your mail instead of using a
pastebin.  Thanks :)

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

Hello Andy,

> > It would be really nice if someone can help me with the following unexpected bug:
>> ...

> What is the bug?  

I don't think I could better summarize then what I did in the subject:

	guile-clutter unexpected bug while using #:virtual slot allocation for a
	<clutter-actor> subclass

> The top part that you list that does not use  guile-gnome works fine

Indeed, I wrote it to make it clear to you [and who would read my message
eventually] that I was well aware, reporting it, that it was _not_ a goops bug, but a
guile-gnome bug :)

> and I don't want to bring guile-gnome into consideration when looking for GOOPS
> bugs :)

Sure, I wouldn't either :)

> Can you still reproduce the bug on stable-2.0 or master?

Yes, on stable-2.0 [no master here yet, apart from myself of course :)]

>  Can you make a test case without guile-gnome?

No, it is a guile-gnome problem/bug, so here below, a very short test case (*)

Thanks,
David

(*) I agree with you that this is less important then goops bugs of course, and I
would be particularly interested to get the setters inheritance bug solved before
anything else [if not done already as I write this answer :)].  Beside I found a way
to circumvent this problem, not perfect but ok, so no rush for this one.

;; module virtual-slot.scm starts here
(define-module (virtual-slot)
  #:use-module (oop goops)
  #:use-module (gnome-2)
  #:use-module (gnome clutter)

  #:export (<virtual>
	    !colour))


(define-class <virtual> (<clutter-actor>)
  (colour #:accessor !colour
	  #:init-keyword #:colour
	  #:allocation #:virtual
	  #:slot-ref (lambda (obj)
		       (get-background-color obj))
	  #:slot-set! (lambda (obj value)
			(set-background-color obj value))))
;; module ends here

...
,use (oop goops)
,use (gnome-2)
,use (gnome clutter)
,use (virtual-slot)
(make <virtual> #:colour (clutter-color-from-string "Red"))

=> ERROR: Throw to key `gruntime-error' with args `("%scm->gtype-instance" "Object
~A has been destroyed." (#<<virtual> 251db20>) ())'.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

On Tue 27 Jan 2015 02:00, David Pirotte <david@altosw.be> writes:

>>  Can you make a test case without guile-gnome?
>
> No, it is a guile-gnome problem/bug, so here below, a very short test case (*)

OK, then please file it in the guile-gnome bugzilla.  Thanks.  We
probably don't need to talk about it on guile-devel.

> (*) I agree with you that this is less important then goops bugs of course, and I
> would be particularly interested to get the setters inheritance bug solved before
> anything else [if not done already as I write this answer :)].  Beside I found a way
> to circumvent this problem, not perfect but ok, so no rush for this one.

The setters inheritance bug is fixed to be like 1.8.  I'll write another
mail, but briefly the idea is this: an accessor on a slot (or a getter,
or a setter), declared via #:accessor or #:getter or #:setter, is used
to access the value of the slot in which it is declared.  However not
all subclasses of a class have all slots of their superclasses;
consider:

  (define-class <super> ()
    (a #:accessor access-a))

  (define-class <sub> ()
    (a))

<sub> declares a *new* slot that happens to also have the same name,
`a'.  But all slots in any particular class have to have different
names, so there's a procedure that builds the composite list of slots
for any given class in the hierarchy, taking as input the class
precedence list and the direct slots of all classes in that list.  It
prefers slots declared in more specific classes, so <sub> will have its
own slot `a' *and not* the slot from <super>.

So for that reason, the accessor `access-a' *does not apply* to
instances of <sub>.  Applicability of accessor methods is based on
whether the given class has the given slot, not based simply on the
CPL.

Now, I broke this in 2009, so it has been broken for all of Guile 2.0.
I fixed it yesterday though, as it's in keeping with 1.8, and it was
just wrong.

OK.  So what about your case?  Well it's this: if you do this:

  (define-method (access-a (obj <sub>)) (next-method))

There is no next method, because the access-a accessor method from
<super> doesn't apply to <sub>, so you will get a no-applicable-method
error.

If you want to have generics that "inherit" accessors you'll have to
come up with some other pattern.

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

Hello Andy,

	- we should not have mixed the 'accessor' problem as reported by
	another user and the setter bug I reported [on irc];

	- also I should have reported a separate bug to bug-guile@gnu.org, but I
	thought we perfectly understood each other, I was wrong and we got confused,
	my bad.

> >>  Can you make a test case without guile-gnome?
> >
> > No, it is a guile-gnome problem/bug, so here below, a very short test case (*)
> 
> OK, then please file it in the guile-gnome bugzilla.  Thanks.  We
> probably don't need to talk about it on guile-devel.

Ok, will do.

> The setters inheritance bug is fixed to be like 1.8.

Thanks, it _does_ work as expected now, now as in using the latest stable-2.0! my
apologies [wrt our irc chat today] because I was dead sure I did check [2 days ago]
with the latest stable-2.0, and it appears I was still using the detached... It
happens, but I am sorry.

>  I'll write another mail, but briefly the idea is this: an accessor on a slot (or
> a getter, or a setter), declared via #:accessor or #:getter or #:setter, is used
> to access the value of the slot in which it is declared.  However not
> all subclasses of a class have all slots of their superclasses;
> consider:
> ...

Yes, of course, but this answer totally confused me: what you are talking about
here and the code you are using has nothing to do with the setter bug I reported on
irc and for which I pasted a specific short test case, I got really confused here.

Happy hacking,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]


To be complete, raise the confusion, and allow who would want to follow and
test, the setter bug test case I pasted on irc was this one (*):

Using guile versions previous to the goops refactoring work Andy did recently, you'd
have this answer:

	scheme@(guile-user)> ,use (oop goops)
	scheme@(guile-user)> ,use (b)
	...
	scheme@(guile-user)> (set! (!width (make <b>)) 10)
	$2 = 10
	scheme@(guile-user)>

The expected and correct answer after the refactoring... is

	...
	scheme@(guile-user)> (set! (!width (make <b>)) 10)

	;;; ("this is <a> !width setter method, hello!")
	scheme@(guile-user)> 

Cheers,
David

(*)

;; module a.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
	    !width))

(define-class <a> ()
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  ;; here comes complex code, computing earth orbit and calling lower
  ;; level clutter internals, such as the <clutter-actor> layout...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width))
;; module ends here

;; module b.scm starts here
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!width))

(define-class <b> (<a>))

#;(define-method ((setter !width) (self <b>) width)
  (next-method))
;; module ends here

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

On Tue 27 Jan 2015 20:11, David Pirotte <david@altosw.be> writes:

>> The setters inheritance bug is fixed to be like 1.8.
>
> Thanks, it _does_ work as expected now, now as in using the latest
> stable-2.0!

Are you certain?  What git revision are you using?  I don't think the
test should "work" with the current stable-2.0 or master, or 1.8 for
that matter.

    $ /opt/guile-1.8/bin/guile
    guile> (use-modules (oop goops))
    guile> (define-class <a> ()
    ...    (width #:accessor width #:init-keyword #:width #:init-value 0))
    guile> (define-class <b> (<a>))
    guile> (define b (make <b>))
    guile> (width b)
    0
    guile> (set! (width b) 10)
    guile> (width b)
    10
    guile> (define-method ((setter width) (self <b>) width) (next-method))
    guile> (set! (width b) 10)

    Backtrace:
    In current input:
      10: 0* [setter:width #<<b> 7f795ed527e0> 10]
       ?: 1  (let* ((next-method (goops:make-next-method self width))) (next-method))

    <unnamed port>: In expression (let* (#) (next-method)):
    <unnamed port>: No next method when calling #<<generic> setter:width (2)>
    with arguments (#<<b> 7f795ed527e0> 10)
    ABORT: (goops-error)

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

Hello Andy,

	we should change the subject or start a new thread, maybe

> Are you certain?  What git revision are you using?  I don't think the
> test should "work" with the current stable-2.0 or master, or 1.8 for
> that matter.

Oh no, it's not working as it should, too bad:  this time I cleared my cache
I did not take care of that carefully enough I guess... anyway, the good news is
that:

	I think we still are not talking about _exactly_ the same think here and
	hope that when we do, you will agree;

	Indeed please note that in the code of my previous message, the define
	setter on the <b> class _is_ commented:  i am sorry if it induced you in
	some sort of misunderstanding, but that line should _not_ even exist (that
	was a trick to circumvent till now);

	If that line does not exist,  then using the setter on a <b> instance must
	call/execute the code of the setter defined at superclass level, <a> in our
	case.  by no mean, it should internally/hiddenly redefine my beautiful
	setter :), in my back, not without talking to me first anyway :)

So, here is the code, without the setter being redefined...:

;; module a.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
	    !width))

(define-class <a> ()
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  ;; here comes complex code, computing earth orbit and calling lower
  ;; level clutter internals, such as the <clutter-actor> layout...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width))
;; module ends here

;; module b.scm starts here
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!width))

(define-class <b> (<a>))
;; module ends here

And here is what I get, which is not correct:  since I did not redefine anything
at <b> level, the slot and 'associated functionality', the setter in this case, must
be 'fully' inherited: it is the setter I define on <a> that must be called when
being used on any instances, all <a> and <b> instances

	[ this  time I left the guile version as well), please double check

david@capac:~/alto/projects/guile-tests/goops 15 $ guile
GNU Guile 2.0.11.113-583a
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: source file ./b.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/next-method-not-called/b.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling ./b.scm
;;; note: source file ./a.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/next-method-not-called/a.scm.go
;;; compiling ./a.scm
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/next-method-not-called/a.scm.go
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/next-method-not-called/b.scm.go
scheme@(guile-user)> (make <b>)
$1 = #<<b> 1ffcb80>
scheme@(guile-user)> (!width $1)
$2 = 0
scheme@(guile-user)> (set! (!width $1) 20)
$3 = 20
scheme@(guile-user)> 


Cheers,
David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]

Hi again,

and, to be very very precise, I even renamed my directory now [which appears in the
compilation trace] because its previous name was terrible (and terribly wrong)!
so,  the appropriate directory name is:	.../setter-inheritance-bug

	[ the new trace is here below, 'in place'
	[ the rest of the text is unchanged
	[ and I still pretend it is a bug

Cheers,
David

> ...
> Oh no, it's not working as it should, too bad:  this time I cleared my cache
> I did not take care of that carefully enough I guess... anyway, the good news is
> that:
> 
> 	I think we still are not talking about _exactly_ the same think here and
> 	hope that when we do, you will agree;
> 
> 	Indeed please note that in the code of my previous message, the define
> 	setter on the <b> class _is_ commented:  i am sorry if it induced you in
> 	some sort of misunderstanding, but that line should _not_ even exist (that
> 	was a trick to circumvent till now);
> 
> 	If that line does not exist,  then using the setter on a <b> instance must
> 	call/execute the code of the setter defined at superclass level, <a> in our
> 	case.  by no mean, it should internally/hiddenly redefine my beautiful
> 	setter :), in my back, not without talking to me first anyway :)
> 
> So, here is the code, without the setter being redefined...:
> 
> ;; module a.scm starts here
> (define-module (a)
>   #:use-module (oop goops)
>   #:export (<a>
> 	    !width))
> 
> (define-class <a> ()
>   (width #:accessor !width #:init-keyword #:width #:init-value 0))
> 
> (define-method ((setter !width) (self <a>) width)
>   ;; here comes complex code, computing earth orbit and calling lower
>   ;; level clutter internals, such as the <clutter-actor> layout...
>   (pk "this is <a> !width setter method, hello!")
>   (slot-set! self 'width width))
> ;; module ends here
> 
> ;; module b.scm starts here
> (define-module (b)
>   #:use-module (oop goops)
>   #:use-module (a)
>   #:export (<b>)
> 
>   #:re-export (!width))
> 
> (define-class <b> (<a>))
> ;; module ends here
> 
> And here is what I get, which is not correct:  since I did not redefine anything
> at <b> level, the slot and 'associated functionality', the setter in this case,
> must be 'fully' inherited: it is the setter I define on <a> that must be called
> when being used on any instances, all <a> and <b> instances
> 
> 	[ this  time I left the guile version as well), please double check

david@capac:~/alto/projects/guile-tests/goops/setter-inheritance-bug 21 $ guile
GNU Guile 2.0.11.113-583a
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: source file ./b.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling ./b.scm
;;; note: source file ./a.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiling ./a.scm
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
scheme@(guile-user)> (make <b>)    
$1 = #<<b> 21b39a0>
scheme@(guile-user)> (!width $1)
$2 = 0
scheme@(guile-user)> (set! (!width $1) 20)
$3 = 20
scheme@(guile-user)> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

On Wed 28 Jan 2015 04:05, David Pirotte <david@altosw.be> writes:

> david@capac:~/alto/projects/guile-tests/goops 15 $ guile
> GNU Guile 2.0.11.113-583a

This version had bugs, as I tried to explain.  Please update your
stable-2.0 and try again.  Thanks :)

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

Hello Andy,

> > david@capac:~/alto/projects/guile-tests/goops 15 $ guile
> > GNU Guile 2.0.11.113-583a
> 
> This version had bugs, as I tried to explain.  Please update your
> stable-2.0 and try again.  Thanks :)

	as an aside note, yesterday I did not pull, i thought all the comments you
	made on irc and here were about the refactoring you have been
	working on, and which i pulled 2 days ago: next time, even if you think
	it is not necessary, just to avoid [my] confusion, please tell me explicitly
	'david please pull, check, I made changes since the refactoring...' thanks!

So, I just pulled/compiled your latest changes, but it is not working:


david@capac:~/alto/projects/guile-tests/goops/setter-inheritance-bug 25 $ guile
GNU Guile 2.0.11.114-649ec
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling ./b.scm
;;; compiling ./a.scm
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
scheme@(guile-user)> (set! (!width (make <b>)) 20)
$1 = 20
scheme@(guile-user)>         


Cheers,
David


;; module a.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
	    !width))

(define-class <a> ()
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  ;; here comes complex code, computing earth orbit and calling lower
  ;; level clutter internals, such as the <clutter-actor> layout...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width))
;; module ends here

;; module b.scm starts here
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!width))

(define-class <b> (<a>))
;; module ends here

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]

Andy,

> Are you certain?  What git revision are you using?  I don't think the
> test should "work" with the current stable-2.0 or master, or 1.8 for
> that matter.

>     $ /opt/guile-1.8/bin/guile
>     guile> (use-modules (oop goops))
>     guile> (define-class <a> ()
>     ...    (width #:accessor width #:init-keyword #:width #:init-value 0))
>     guile> (define-class <b> (<a>))
>     guile> (define b (make <b>))
>     guile> (width b)
>     0
>     guile> (set! (width b) 10)
>     guile> (width b)
>     10
>     guile> (define-method ((setter width) (self <b>) width) (next-method))
>     guile> (set! (width b) 10)
> 
>     Backtrace:
>     In current input:
>       10: 0* [setter:width #<<b> 7f795ed527e0> 10]
>        ?: 1  (let* ((next-method (goops:make-next-method self width)))
> (next-method))
> 
>     <unnamed port>: In expression (let* (#) (next-method)):
>     <unnamed port>: No next method when calling #<<generic> setter:width (2)>
>     with arguments (#<<b> 7f795ed527e0> 10)
>     ABORT: (goops-error)

When talking about goops, we should not refer to 1.8 (*), 1.6 or any guile version
for that matter, but to the clos language spec subset goops implements [appart from
the adaptation for it to be module protected, but that is not the point here].

This said and with that in mind, the implementation you say was in guile-1.8 and
that it appears you have reimplemented 'right now' breaks the specification and
afaiac makes goops totally unusable for any serious work: this is a catastrophy,
please reconsider!

	-] anything defined by a user using define-method _must_ pass thought the
	exact same computation machinery _and_ all become applicable methods;

	-] within the core of a define-method, one must always be able to call
	(next-method) [of course if the user do so inappropriately it raises an
	error, I'm not talking about that];

	-] they is no exception for setters, which are _just_ methods, with, in
	addition and as we know, a bit of 'magic' so that they can be used with set!
	
		-> otherwise, there would be 2 define-method semantics
		-> that can't be, and if it was the case the clos 'comity' would
		have defined another method for setters such as
		define-setter-method, and restrict that method from being able to
		call (call-next-method);

	-] within the core of methods, including the ones called with (next-method)
	calls to slot-ref slot-set! must _always_ call the instance(s) slot-ref-
	slot-set! as defined by the system [if none were provided], or the user's
	code they were provided [such as when #:allocation is #:virtual]

We should not need any really, but here is a description [no code, no need to at
this point] of a [still very simple] 'visual' example, so everyone can follow:

	let's define a gravity sensitive class <apple> and a !gravity setter, which
	sets the position of the instance on a scene and takes care of its layout
	[as in 'horizontal or 'vertical] depending on the gravity poles the instance
	respond to: at some point this setter method calls sot-set! to set the
	instance position slot value, such as 'north-west;

	then we define a <toolbar> class, which inherit from <apple>, with
	an item slot filled with <button> instances, each button having an optional 
	<tooltip> instance [a text, "My beautiful tooltip..."];

	each tooltip text must 'glue' to there button _and_ always be entirely on the
	scene [visible to the user, if the scene is itself visible of course, but
	that's not the question here]:

	-> that means there is extra work to be done on toolbar instances, but we
	want to run the <apple> !gravity setter code first

	(define-method ((setter !gravity) (self <clus-toolbar>) gravity)
	  (next-method)
	  (for-each (lambda (toolbar-item)
		      (ensure-tooltips-on-stage toolbar-item))
	    (!items self)))

Cheers,
David

(*) Besides, let me tell you that I never intensively used goops before guile-2, but
just played a little with it, precisely because I could not trust it, as I had my
heisen bugs using guile 1.6 because in these past times I could not even trust the
module system




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]

Hello Andy,

>     $ /opt/guile-1.8/bin/guile
>     guile> (use-modules (oop goops))
>     guile> (define-class <a> ()
>     ...    (width #:accessor width #:init-keyword #:width #:init-value 0))
>     guile> (define-class <b> (<a>))
>     guile> (define b (make <b>))
>     guile> (width b)
>     0
>     guile> (set! (width b) 10)
>     guile> (width b)
>     10
>     guile> (define-method ((setter width) (self <b>) width) (next-method))
>     guile> (set! (width b) 10)
> 
>     Backtrace:
>     In current input:
>       10: 0* [setter:width #<<b> 7f795ed527e0> 10]
>        ?: 1  (let* ((next-method (goops:make-next-method self width)))
> (next-method))
> 
>     <unnamed port>: In expression (let* (#) (next-method)):
>     <unnamed port>: No next method when calling #<<generic> setter:width (2)>
>     with arguments (#<<b> 7f795ed527e0> 10)
>     ABORT: (goops-error)

With respect to the above example(*), I _do_ get the expected result here, using
the latest stable-2.0:

	please leave it as it is, it _is_ correct: I'm writing back because you
	pretend it should not work, I got confused...

	but it does, as it should, thanks god, the opposite would be a real disaster

Cheers,
David

(*)	not to be confused with the setter inheritance bug I mentioned, still is
	present in the latest stable, so I [just[ reported it.

--8<---------------cut here---------------start------------->8---
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
	    !width))


(define-class <a> ()
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  ;; here comes complex code, computing earth orbit, captain's age...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width))
--8<---------------cut here---------------start------------->8---

--8<---------------cut here---------------start------------->8---
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!width))


(define-class <b> (<a>))
(define-method ((setter !width) (self <b>) width)
  (next-method)
  ;; here comes 'extra' work <b> instances must 'run'
  (pk "this is <b> !width setter method, hello!")
  (!width self))
--8<---------------cut here---------------start------------->8---

GNU Guile 2.0.11.114-649ec
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> 
scheme@(guile-user)> 
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: source file ./b.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling ./b.scm
;;; note: source file ./a.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiling ./a.scm
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
scheme@(guile-user)> (set! (!width (make <b>)) 20)

;;; ("this is <a> !width setter method, hello!")

;;; ("this is <b> !width setter method, hello!")
$2 = 20
scheme@(guile-user)> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

Hello,

May I first please reduce your test case.  Here is an equivalent
version:

  (use-modules (oop goops))
  (define-class <a> ()
    (foo #:getter foo #:init-keyword #:foo))
  (define-class <b> (<a>))
  (define obj (make <b> #:foo 34))
  (define-method (foo (self <b>))
    (pk "ahoy!")
    (next-method))
  (pk (foo obj))
  
It has nothing to do with modules or setters, and everything to do with
GOOPS and accessors.  Anyway, this has been a confusing thread, so let
me summarize:

It used to be, in Guile 1.8, that the test case didn't work at all:
n
   guile>   (pk (foo obj))

   ;;; ("ahoy!")

   Backtrace:
   In current input:
     18: 0* [peek ...
     18: 1*  [foo #<<b> 7fc8898e0e20>]
      ?: 2   (let* ((next-method (goops:make-next-method self))) (pk "ahoy!") ...)

   <unnamed port>: In expression (let* (#) (pk "ahoy!") ...):
   <unnamed port>: No next method when calling #<<generic> foo (2)>
   with arguments (#<<b> 7fc8898e0e20>)

It is important to note what the behavior was in Guile 1.8 because it is
the version that is closest to what Mikael originally wrote (or
inherited from stklos); though there are many ways in which GOOPS could
be better, I have been surprised again and again about the thoroughness
of the original implementation.

In Guile 2.0, I made an error that accidentally made this test case
"work", in the sense that it would return the value of the slot "foo".

   scheme@(guile-user)>   (pk (foo obj))

   ;;; ("ahoy!")

   ;;; (34)
   $1 = 34

However it wouldn't always return the value of the slot "foo"; for
example:

   scheme@(guile-user)> (define-class <c> () (bar #:init-keyword #:bar))
   scheme@(guile-user)> (define-class <ac> (<a> <c>))
   scheme@(guile-user)> (define obj2 (make <ac> #:foo 34 #:bar 42))
   scheme@(guile-user)>   (define-method (foo (self <ac>))
       (pk "wat!!!")
       (next-method))
   scheme@(guile-user)>   (pk (foo obj2))

   ;;; ("wat!!!")

   ;;; (42)
   $2 = 42

Here you see that it returns the value of the "bar" slot.  Why?  Because
defining the (foo (self <ac>)) method *replaced* the accessor method for
`foo' on instances of type <ac> with our new method, and then the
next-method that applies is the accessor method that is specialized on
values of type <a>, which looks for the slot in field 0.

I thought at first that this wasn't right, that really accessor methods
need to specialize on the types that they actually see, not just their
specializers; but that's not right, because not all subtypes of a type
have all slots of all of their supertypes.  That got me thinking and
looking back, so I found the bug that I introduced.  It turns out the
GOOPS design is to add accessor methods for each subclass that has a
given slot, and they are not designed to "inherit" -- i.e. an accessor
method specialized on <base> shouldn't be in the next-method list for
<derived>.

I have recently made a change to restore us to Guile 1.8 behavior, so as
to fix the "wat" bug above in Guile 2.0 and 2.2.

> This said and with that in mind, the implementation you say was in guile-1.8 and
> that it appears you have reimplemented 'right now' breaks the specification and
> afaiac makes goops totally unusable for any serious work: this is a catastrophy,
> please reconsider!

David, I would really appreciate it if you could tone down the
hyperbole.  Thanks in advance :)

> When talking about goops, we should not refer to 1.8 (*), 1.6 or any guile version
> for that matter, but to the clos language spec subset goops implements [appart from
> the adaptation for it to be module protected, but that is not the point here].

   (defclass <a> ()
     ((foo :reader foo :initarg :foo)))
   (defclass <b> (<a>) ())
   (defvar obj (make-instance '<b> :foo 34))
   (defmethod foo ((self <b>))
     (write "ahoy!")
     (call-next-method))
   (foo obj)

Interestingly, in CLISP at least this works in the way you expect: it
prints "ahoy" and then chains up and returns the value.  I also note
that it doesn't install accessor methods on each subtype; before
defining the "ahoy" method, I got this:

   > (generic-function-methods #'foo)
   (#<STANDARD-READER-METHOD (#<STANDARD-CLASS <A>>)>)

And that method worked on instances of <b> just as well.

I am not sure how to interpret this result.  The slot definition
protocol in CLOS is different; for example,
compute-effective-slot-definition in CLOS logically *combines* slot
definitions with the same name.  Could it be that in CLOS, all instances
of a type are considered to have all slots of all supertypes?  That is
not the GOOPS design, but perhaps that should change.

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 5547 bytes --]

Hello Andy,

> May I first please reduce your test case.  Here is an equivalent
> version:

	sure, especially because it is not 'my' test case :)  which got us very
	confused: when you were talking about this one, I was thinking about
	another... which to remove the confusion I finally reported:

		bug #19770: I hope it is 'easy' to solve and hope you can fix it
		soon, to me this one is really important

	but of course I am happy to talk about this one as well, to remove all
	the confusion, if possible :)! and help us getting goops even better!

So, wrt this reduced test, to summarize but see below for details, (1) I agree with
you for the first part [the code before defining <ac>], and (2) I have a different
answer from my guile version for the second part [which I think is the correct
answer, maybe you wanted to paste some other code [?], don't know.

>   (use-modules (oop goops))
>   (define-class <a> ()
>     (foo #:getter foo #:init-keyword #:foo))
>   (define-class <b> (<a>))
>   (define obj (make <b> #:foo 34))
>   (define-method (foo (self <b>))
>     (pk "ahoy!")
>     (next-method))
>   (pk (foo obj))

>    guile>   (pk (foo obj))
> 
>    ;;; ("ahoy!")
> 
>    Backtrace:
>    In current input:
>      18: 0* [peek ...
>      18: 1*  [foo #<<b> 7fc8898e0e20>]
>       ?: 2   (let* ((next-method (goops:make-next-method self))) (pk "ahoy!") ...)
> 
>    <unnamed port>: In expression (let* (#) (pk "ahoy!") ...):
>    <unnamed port>: No next method when calling #<<generic> foo (2)>
>    with arguments (#<<b> 7fc8898e0e20>)

I totally agree with you and with the above goops 'answer', for all our guile
versions.  In this case indeed, the only method that exists and is applicable is the
getter foo that <a> defines and<b> inherits: there is no next-method and calling
(next-method) would be a user bug, in my opinion too.

> However it wouldn't always return the value of the slot "foo"; for
> example:
> 
>    scheme@(guile-user)> (define-class <c> () (bar #:init-keyword #:bar))
>    scheme@(guile-user)> (define-class <ac> (<a> <c>))
>    scheme@(guile-user)> (define obj2 (make <ac> #:foo 34 #:bar 42))
>    scheme@(guile-user)>   (define-method (foo (self <ac>))
>        (pk "wat!!!")
>        (next-method))
>    scheme@(guile-user)>   (pk (foo obj2))
> 
>    ;;; ("wat!!!")
> 
>    ;;; (42)
>    $2 = 42

Here I am confused again: given the above, defining foo on <ac> and calling
(next-method) is not different then the foo on <b>, there is no next-method and I
get the error as well, maybe you wanted to paste some other code? Here is what I
get, given the definitions above (*)

GNU Guile 2.0.11.114-649ec
...
scheme@(guile-user)> ,use (abc)
;;; note: source file ./abc.scm
;;;       newer than compiled...
;;; ...
scheme@(guile-user)> ,m (abc)
scheme@(abc)> (foo obj2)

;;; ("wat!!!")
ERROR: In procedure scm-error:
ERROR: No next method when calling #<<generic> foo (3)>
with arguments (#<<ac> 15c98a0>)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(abc) [1]> 

>    (defclass <a> ()
>      ((foo :reader foo :initarg :foo)))
>    (defclass <b> (<a>) ())
>    (defvar obj (make-instance '<b> :foo 34))
>    (defmethod foo ((self <b>))
>      (write "ahoy!")
>      (call-next-method))
>    (foo obj)

> Interestingly, in CLISP at least this works in the way you expect:
> ...

Interesting indeed, and a surprise, it's been a very long time I've used CL and CLOS.
For info, sbcl also 'works' the same way, but I don't think we should implement that
in guile, I second you here:

This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
...
* (defclass <a> ()
* (defclass <a> ()
     ((foo :reader foo :initarg :foo)))

#<STANDARD-CLASS <A>>
* (defclass <b> (<a>) ())

#<STANDARD-CLASS <B>>
* (defvar obj (make-instance '<b> :foo 34))

OBJ
* (defmethod foo ((self <b>))
     (write "ahoy!")
     (call-next-method))

#<STANDARD-METHOD FOO (<B>) {1003B3A773}>
* (foo obj)
"ahoy!"
34
* 

> I am not sure how to interpret this result.

Same here, I should carefully read/study the spec again I guess, but anyway, wrt the
the first part of your test case, I agree with you.

>  The slot definition protocol in CLOS is different; for example,
> compute-effective-slot-definition in CLOS logically *combines* slot
> definitions with the same name.

Is it not what goops does as well? I thought so.

>  Could it be that in CLOS, all instances  of a type are considered to have all
> slots of all supertypes?  That is not the GOOPS design, but perhaps that should
> change.

I am confused with what you mean exactly with the above sentence, which to me is
'correct' and with which you seem to disagree?  But for me, if that is what we are
talking about here, goops class-slots procedure does the right job.

Cheers,
And thanks!
David


(*)	here an abc module from the defs of your email:


(define-module (abc)
  #:use-module (oop goops))


(define-class <a> ()
  (foo #:getter foo #:init-keyword #:foo))

(define-class <b> (<a>))

(define-method (foo (self <b>))
  (pk "ahoy!")
  (next-method))

(define-class <c> ()
  (bar #:init-keyword #:bar))

(define-class <ac> (<a> <c>))

(define-method (foo (self <ac>))
  (pk "wat!!!")
  (next-method))

(define obj (make <b> #:foo 34))
(define obj2 (make <ac> #:foo 34 #:bar 42))

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

Hi :)

On Fri 06 Feb 2015 18:09, David Pirotte <david@altosw.be> writes:

> (2) I have a different answer from my guile version for the second
> part [which I think is the correct answer, maybe you wanted to paste
> some other code [?], don't know.

Part of my mail described buggy Guile 2.0.  Please re-read to be sure,
if you have questions :)

With the stable-2.0 or master branches, the current behavior is:

    scheme@(guile-user)> (use-modules (oop goops))
    scheme@(guile-user)> (define-class <a> ()
    ...   (foo #:getter foo #:init-keyword #:foo))
    scheme@(guile-user)> (define-class <b> (<a>))
    scheme@(guile-user)> (define obj (make <b> #:foo 34))
    scheme@(guile-user)> (define-method (foo (self <b>))
    ...   (pk "ahoy!")
    ...   (next-method))
    scheme@(guile-user)> (pk (foo obj))

    ;;; ("ahoy!")
    ERROR: In procedure scm-error:
    ERROR: No next method when calling #<<generic> foo (2)>
    with arguments (#<<b> 2c207e0>)

    Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
    scheme@(guile-user) [1]> 

> In this case indeed, the only method that exists and is applicable is
> the getter foo that <a> defines and<b> inherits: there is no
> next-method and calling (next-method) would be a user bug, in my
> opinion too.

So, we should be precise with terminology :)  In GOOPS, subclasses do
not inherit accessor methods.  (There was a bug in which they would; I
fixed that.)  Each subclass gets its own accessor method defined, if and
only if it has the corresponding slot, and that method is not inherited.

>>    ;;; ("wat!!!")
>> 
>>    ;;; (42)
>>    $2 = 42
>
> Here I am confused again: given the above, defining foo on <ac> and calling
> (next-method) is not different then the foo on <b>, there is no next-method and I
> get the error as well, maybe you wanted to paste some other code? Here is what I
> get, given the definitions above (*)

Here I was describing buggy Guile 2.0 (hence past tense).

>>  The slot definition protocol in CLOS is different; for example,
>> compute-effective-slot-definition in CLOS logically *combines* slot
>> definitions with the same name.
>
> Is it not what goops does as well? I thought so.

Nope :)  That bit of the protocol was never implemented.  Instead the
semantics are that the slot from the first entry in the CPL is used.

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 3420 bytes --]

Hi again!
:)

> With the stable-2.0 or master branches, the current behavior is:
> 
>     scheme@(guile-user)> (use-modules (oop goops))
>     scheme@(guile-user)> (define-class <a> ()
>     ...   (foo #:getter foo #:init-keyword #:foo))
>     scheme@(guile-user)> (define-class <b> (<a>))
>     scheme@(guile-user)> (define obj (make <b> #:foo 34))
>     scheme@(guile-user)> (define-method (foo (self <b>))
>     ...   (pk "ahoy!")
>     ...   (next-method))
>     scheme@(guile-user)> (pk (foo obj))
> 
>     ;;; ("ahoy!")
>     ERROR: In procedure scm-error:
>     ERROR: No next method when calling #<<generic> foo (2)>
>     with arguments (#<<b> 2c207e0>)
> 
>     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>     scheme@(guile-user) [1]> 

Yes, expected, but to me, it is because of what I just said here below.

> > In this case indeed, the only method that exists and is applicable is
> > the getter foo that <a> defines and<b> inherits: there is no
> > next-method and calling (next-method) would be a user bug, in my
> > opinion too.
> 
> So, we should be precise with terminology :)  In GOOPS, subclasses do
> not inherit accessor methods.  (There was a bug in which they would; I
> fixed that.)  Each subclass gets its own accessor method defined, if and
> only if it has the corresponding slot, and that method is not inherited.

Here we don't agree, and to me, this is a bug, not a feature :), given that in my
opinion (1) we should follow the clos spec here, and (2) you did the right thing in
2009, even by accident, it was a very good accident :).  Besides, the following
would work [i don't think it is a/the solution, the user should be 'forced' to do
that, I mention it here to show what I consider a 'contradiction']:

wdyt?

;;; module a.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
	    !width
	    set-width))

(define-class <a> ()
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  (set-width self width))

(define-method (set-width (self <a>) width)
  ;; here comes complex code, computing earth orbit, captain's age...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width)
  width)
;;; module ends here


;;; module b.scm starts here
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!width
	       set-width))


(define-class <b> (<a>))
;;; module ends here

GNU Guile 2.0.11.114-649ec
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: source file ./b.scm
;;;       newer than
;;; ... ...
;;; note: source file ./a.scm
;;;       newer than
scheme@(guile-user)> (make <b>)
$3 = #<<b> 1bc1940>
scheme@(guile-user)> (set-width $3 20)

;;; ("this is <a> !width setter method, hello!")
$4 = 20
scheme@(guile-user)> 


> >>  The slot definition protocol in CLOS is different; for example,
> >> compute-effective-slot-definition in CLOS logically *combines* slot
> >> definitions with the same name.
> >
> > Is it not what goops does as well? I thought so.
> 
> Nope :)  That bit of the protocol was never implemented.  Instead the
> semantics are that the slot from the first entry in the CPL is used.

Ok, I can live with that for now :)

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

Hello again :)

On Sat 07 Feb 2015 01:06, David Pirotte <david@altosw.be> writes:

>> So, we should be precise with terminology :)  In GOOPS, subclasses do
>> not inherit accessor methods.  (There was a bug in which they would; I
>> fixed that.)  Each subclass gets its own accessor method defined, if and
>> only if it has the corresponding slot, and that method is not inherited.
>
> Here we don't agree, and to me, this is a bug, not a feature :)

Unfortunately if the question is about GOOPS's design, I am certain that
the current stable-2.0 and master behavior follows the design, simply
because it does the same thing as Guile 1.8, before I picked up GOOPS
maintenance and started introducing bugs :)  So let us not argue over
that.  Let us instead treat your concern as request that the behavior
should be different.

> we should follow the clos spec here

Hmm, I agree in general, but you have to understand that the CLOS spec
is not identical to TinyCLOS, the predecessory of stklos.  They are
similar but not the same.  Because of this, diverging from CLOS is not a
bug.

That said I think the CLOS way is usually better, but we are limited by
two things: compatibility with past behavior (not a terrible concern in
this instance, given the lack of outcry when I broke things), and
secondly by hack-power.  In particular I do not have any additional free
time to spend on GOOPS features in the near future.

This feature you are asking for requires:

  * more logic in method-applicable? for accessor methods that would
    1. check the list of effective slot definitions in the target object
    2. for each slot, get the direct slot definition
       - currently there is no long from effective to direct, we'd have
         to add that
    3. if the target object has a slot with the same direct slot
       definition as the one associated with the accessor method, then
       the method applies, otherwise not

  * compile-time specialization for methods, as in
    583a23bf104c84d9617222856e188f3f3af4934d which was later reverted

Open questions would be, do we expose method-applicable? as a generic,
there's some gnarly circularity because these methods are part of the
method dispatch protocol, do we expose more of the slot protocol to
users (it's currently somewhat opaque and unfinished), how to document
all of this, we need a bunch of tests too, how do you relate effective
slots to direct slots in the CLOS case where you can make composite
slots, etc.

It's a bit of work and I need to do other things :)

Andy
-- 
http://wingolog.org/

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 4074 bytes --]

Hello Andy,

> > With the stable-2.0 or master branches, the current behavior is:
> > 
> >     scheme@(guile-user)> (use-modules (oop goops))
> >     scheme@(guile-user)> (define-class <a> ()
> >     ...   (foo #:getter foo #:init-keyword #:foo))
> >     scheme@(guile-user)> (define-class <b> (<a>))
> >     scheme@(guile-user)> (define obj (make <b> #:foo 34))
> >     scheme@(guile-user)> (define-method (foo (self <b>))
> >     ...   (pk "ahoy!")
> >     ...   (next-method))
> >     scheme@(guile-user)> (pk (foo obj))
> > 
> >     ;;; ("ahoy!")
> >     ERROR: In procedure scm-error:
> >     ERROR: No next method when calling #<<generic> foo (2)>
> >     with arguments (#<<b> 2c207e0>)
> > 
> >     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> >     scheme@(guile-user) [1]> 
> 
> Yes, expected, but to me, it is because of what I just said here below.
> 
> > > In this case indeed, the only method that exists and is applicable is
> > > the getter foo that <a> defines and<b> inherits: there is no
> > > next-method and calling (next-method) would be a user bug, in my
> > > opinion too.
> > 
> > So, we should be precise with terminology :)  In GOOPS, subclasses do
> > not inherit accessor methods.  (There was a bug in which they would; I
> > fixed that.)  Each subclass gets its own accessor method defined, if and
> > only if it has the corresponding slot, and that method is not inherited.

Some are, some are not...:

;;; module a.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
	    !v
	    !width
	    set-width))

(define-class <a> ()
  (v #:accessor !v
     #:init-keyword #:v
     #:allocation #:virtual
     #:slot-ref (lambda (self)
		  (pk "this is <a> v slot-ref, hello!"))
     #:slot-set! (lambda (self value)
		   (pk "this is <a> v slot-set!, hello!")))
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  (set-width self width))

(define-method (set-width (self <a>) width)
  ;; here comes complex code, computing earth orbit, captain's age...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width)
  width)
;;; module ends here

;;; module b.scm starts here
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!v
	       !width
	       set-width))


(define-class <b> (<a>))
;;; module ends here

GNU Guile 2.0.11.114-649ec
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> 
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: source file ./b.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling ./b.scm
;;; note: source file ./a.scm
;;;       newer than compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiling ./a.scm
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/a.scm.go
;;; compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/setter-inheritance-bug/b.scm.go
scheme@(guile-user)> (make <b>)
$2 = #<<b> 2334760>
scheme@(guile-user)> (!v $2)

;;; ("this is <a> v slot-ref, hello!")
$3 = "this is <a> v slot-ref, hello!"
scheme@(guile-user)> (set! (!v $2) 'blue)

;;; ("this is <a> v slot-set!, hello!")
$4 = "this is <a> v slot-set!, hello!"
scheme@(guile-user)> (set! (!width $2) 10)
$5 = 10
scheme@(guile-user)> 

Cheers,
David



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

> Hello again :)

Yes, hello,
Saturday greetings!

> ... So let us not argue over that.  Let us instead treat your concern as request
> that the behavior should be different.

Perfect, let's talk about ... should we, how, how much :) ...
 
> > we should follow the clos spec here

> That said I think the CLOS way is usually better

Agreed, definitely:  I'm well aware that it is a very complex task to implement it
correctly [and fully, but I don't need the full protocol either, 1 day maybe...], and
very 'frustrating' too, since it is almost impossible to make it run 'fast', by
definition, as you know. of course ... But I really need the subset we have in goops
to implement the corresponding clos subset protocol, especially what we are talking
about.

> but we are limited by  two things: compatibility with past behavior (not a
> terrible concern in this instance, given the lack of outcry when I broke things),
> and secondly by hack-power.  In particular I do not have any additional free
> time to spend on GOOPS features in the near future.

Would you have some available pay time? If so, could you send me a private quote, I
need this change asap, and if the quote is reasonable, you could start immediately.
If you [guilers] think it should also be in goops, fine, I am happy to 'fund
that part of the protocol for all' :)  If not, could you include in the quote a
bit of time to implement a git branch with goops only, name it gclos or what ever
is [more] appropriate , if that is possible [?], so that I can always and in a very
easy way, track stable-2 [master in the near future] but apply 'my' goops [I
mjean (re)configure/make/make install 'my' goops...


> This feature you are asking for requires:
> 
>   * more logic in method-applicable? for accessor methods that would
>     1. check the list of effective slot definitions in the target object
>     2. for each slot, get the direct slot definition
>        - currently there is no long from effective to direct, we'd have
>          to add that
>     3. if the target object has a slot with the same direct slot
>        definition as the one associated with the accessor method, then
>        the method applies, otherwise not
> 
>   * compile-time specialization for methods, as in
>     583a23bf104c84d9617222856e188f3f3af4934d which was later reverted
> 
> Open questions would be, do we expose method-applicable? as a generic,
> there's some gnarly circularity because these methods are part of the
> method dispatch protocol, do we expose more of the slot protocol to
> users (it's currently somewhat opaque and unfinished), how to document
> all of this, we need a bunch of tests too, how do you relate effective
> slots to direct slots in the CLOS case where you can make composite
> slots, etc.

I will answer this part a bit latter, I need to think about it :)

> It's a bit of work and I need to do other things :)

Sure,
I have too, 
Let's see if you are interested and has pay time available...

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]