A mess with GOOPS

A mess with GOOPS

[Panicz Maciej Godek]

Hi,
I've been using GOOPS with vectors now, and I've observed an annoying
feature. While "array-map!" et al. accept vectors, uvecs and arrays,
and so it is easy to write joint code for these types, this fact is
not reflected in the world of objects.
In other words, classes <vector>, <uvec> and <array> have nothing in
common, which requires me to triple the number of methods that could
accept any of these types.
If I would write any wrapping class hierarchy to embrace these
similarities, I would loose the advantage of having the special reader
extension for vectors and arrays, so I believe that this can be only
changed in the core of GOOPS.
Is there any possibility to do so?
Regards,
M.

Re: A mess with GOOPS

[Andy Wingo]

Hi Panicz,

On Fri 02 Sep 2011 21:53, Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> In other words, classes <vector>, <uvec> and <array> have nothing in
> common, which requires me to triple the number of methods that could
> accept any of these types.

We should fix this.  We can probably do it in 2.0.  Interested in
sending a patch?

Currently this stuff is in C, unfortunately.  Perhaps it should move to
Scheme at some point, but if you just wanted to add an <array> or
<generalized-vector> superclass, see goops.c.  Look for the <uvec> stuff
and follow the patterns.

Andy
-- 
http://wingolog.org/

Re: A mess with GOOPS

[Panicz Maciej Godek]

I've been trying to add the superclass.
Adding it to <vector> and <bytevector> turned out
to be extremely simple, but the problem emerged
when I was trying to generalize the <array> class.

The thing is that <array> is implemented as a smob,
and that there is no easy way to add a superclass
to a class created from smob.

I can think of a number of ways of making
a workaround, but all of them are nasty. Each
of them will require the modification of
goops.c: create_smob_classes.

The first way would be to check whether
!strcmp (SCM_SMOBNAME (i), "array")
and to behave appropriately when it happens.

But that would be just ugly.

The other two ways that come to my mind would be:
1. to modify the type `scm_smob_descriptor', adding
SCM supers; /* list of superclasses */

or, equivalently
2. to add a new global array,
SCM_API SCM smob_supers[MAX_SMOB_COUNT], such
that their default would either be SCM_EOL, or
scm_list1(scm_class_top).

The other idea would be to mess with
scm_sys_inherit_magic_x and add a superclass
after the creation of "<array>", but that doesn't
sound too sound (at least for as long as this action
is undocumented)

So to me it seems that adding the <generalized-array>
(or however should it be called) that would be the
ancestor of "array" requires some changes in the
guile API. I wouldn't do it without the overall approval.

Best regards
M.


2011/9/3, Andy Wingo <wingo@pobox.com>:
> Hi Panicz,
>
> On Fri 02 Sep 2011 21:53, Panicz Maciej Godek <godek.maciek@gmail.com>
> writes:
>
>> In other words, classes <vector>, <uvec> and <array> have nothing in
>> common, which requires me to triple the number of methods that could
>> accept any of these types.
>
> We should fix this.  We can probably do it in 2.0.  Interested in
> sending a patch?
>
> Currently this stuff is in C, unfortunately.  Perhaps it should move to
> Scheme at some point, but if you just wanted to add an <array> or
> <generalized-vector> superclass, see goops.c.  Look for the <uvec> stuff
> and follow the patterns.
>
> Andy
> --
> http://wingolog.org/
>

Re: A mess with GOOPS

[Panicz Maciej Godek]

OK, you were right :)
I made a small change -- instead of namiing my new class
<generalized-array>, I simply named it <array>, so that the smob name
overlaps with the class name. I don't know if it's a proper
programming style, but it's simple and it works.

There is, however, another problem that I've observed. I don't know if
it is caused by my modification, but both array-shape and
array-dimensions return the following error:

While compiling expression:
ERROR: In procedure vector-length: Wrong type argument in position 1

Other than that, I could send the patch (if I only knew how to generate it).

Best regards,
M.

2011/9/5, Panicz Maciej Godek <godek.maciek@gmail.com>:
> I've been trying to add the superclass.
> Adding it to <vector> and <bytevector> turned out
> to be extremely simple, but the problem emerged
> when I was trying to generalize the <array> class.
>
> The thing is that <array> is implemented as a smob,
> and that there is no easy way to add a superclass
> to a class created from smob.
>
> I can think of a number of ways of making
> a workaround, but all of them are nasty. Each
> of them will require the modification of
> goops.c: create_smob_classes.
>
> The first way would be to check whether
> !strcmp (SCM_SMOBNAME (i), "array")
> and to behave appropriately when it happens.
>
> But that would be just ugly.
>
> The other two ways that come to my mind would be:
> 1. to modify the type `scm_smob_descriptor', adding
> SCM supers; /* list of superclasses */
>
> or, equivalently
> 2. to add a new global array,
> SCM_API SCM smob_supers[MAX_SMOB_COUNT], such
> that their default would either be SCM_EOL, or
> scm_list1(scm_class_top).
>
> The other idea would be to mess with
> scm_sys_inherit_magic_x and add a superclass
> after the creation of "<array>", but that doesn't
> sound too sound (at least for as long as this action
> is undocumented)
>
> So to me it seems that adding the <generalized-array>
> (or however should it be called) that would be the
> ancestor of "array" requires some changes in the
> guile API. I wouldn't do it without the overall approval.
>
> Best regards
> M.
>
>
> 2011/9/3, Andy Wingo <wingo@pobox.com>:
>> Hi Panicz,
>>
>> On Fri 02 Sep 2011 21:53, Panicz Maciej Godek <godek.maciek@gmail.com>
>> writes:
>>
>>> In other words, classes <vector>, <uvec> and <array> have nothing in
>>> common, which requires me to triple the number of methods that could
>>> accept any of these types.
>>
>> We should fix this.  We can probably do it in 2.0.  Interested in
>> sending a patch?
>>
>> Currently this stuff is in C, unfortunately.  Perhaps it should move to
>> Scheme at some point, but if you just wanted to add an <array> or
>> <generalized-vector> superclass, see goops.c.  Look for the <uvec> stuff
>> and follow the patterns.
>>
>> Andy
>> --
>> http://wingolog.org/
>>
>

Re: A mess with GOOPS

[Panicz Maciej Godek]

2011/9/6, Panicz Maciej Godek <godek.maciek@gmail.com>:
> OK, you were right :)
> I made a small change -- instead of namiing my new class
> <generalized-array>, I simply named it <array>, so that the smob name
> overlaps with the class name. I don't know if it's a proper
> programming style, but it's simple and it works.
>
> There is, however, another problem that I've observed. I don't know if
> it is caused by my modification, but both array-shape and
> array-dimensions return the following error:
>
> While compiling expression:
> ERROR: In procedure vector-length: Wrong type argument in position 1
>

Oh, and I forgot to mention -- the error appears when I try
to apply these funtions to regular (non-typed) array with rank > 1.
It works for typed arrays, vectors and uvecs.

I'll try to look for the reason of this and let you know if I find
anything interesting.

Regards,
M.

Re: A mess with GOOPS

[Panicz Maciej Godek]

> Oh, and I forgot to mention -- the error appears when I try
> to apply these funtions to regular (non-typed) array with rank > 1.
> It works for typed arrays, vectors and uvecs.
>
I removed my modifications and the error still appears.
I've figured that the reason lies somewhere in the special
reader syntax for ordinary arrays: when I write
#2((1 2 3)(4 5 6)), I get the aforementioned error, but
when I use "make-array", everything works nicely. It does
not appear with uniform arrays, so #2f32((1 2 3)(4 5 6))
is fine as well.

I am using origin/stable-2.0 branch from the git repo, last
commited Wed Aug 31 2011

Re: A mess with GOOPS

[Daniel Llorens]

>> While compiling expression:
>> ERROR: In procedure vector-length: Wrong type argument in position 1
>> 
> 
> Oh, and I forgot to mention -- the error appears when I try
> to apply these funtions to regular (non-typed) array with rank > 1.
> It works for typed arrays, vectors and uvecs.
> 
> I'll try to look for the reason of this and let you know if I find
> anything interesting.
> 
> Regards,
> M.

Hi,

I posted a patch for precisely this error yesterday on bug-guile. It's a trivial bug in module/language/glil/compile-assembly.scm, but I don't know why array.test didn't catch it.

diff --git a/module/language/glil/compile-assembly.scm b/module/language/glil/compile-assembly.scm
index a081822..c76e412 100644
--- a/module/language/glil/compile-assembly.scm
+++ b/module/language/glil/compile-assembly.scm
@@ -856,7 +856,7 @@
           (vector-fold2 (lambda (x codes addr)
                           (receive (subcode addr) (ref-or-dump x i addr)
                             (values (cons subcode codes) addr)))
-                          x '() addr)
+                          contents '() addr)
         (receive (shape addr) (ref-or-dump (array-shape x) i addr)
           (values (fold append
                         (let ((len (vector-length contents)))
-- 
1.7.1

Regards,

	Daniel.

Re: A mess with GOOPS

[Andy Wingo]

Hi Panicz,

On Mon 05 Sep 2011 23:35, Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> The thing is that <array> is implemented as a smob,
> and that there is no easy way to add a superclass
> to a class created from smob.

Ew.  Why don't we instead allocate a typecode for arrays.  I just pushed
a patch to do that, and for bitvectors as well.  Copying Daniel Llorens,
to check that I didn't break arrays.

Want to submit a new patch, Panicz?

Thanks,

Andy
-- 
http://wingolog.org/

Re: A mess with GOOPS

[Daniel Llorens]

On Jan 9, 2012, at 18:11, Andy Wingo wrote:

> Ew.  Why don't we instead allocate a typecode for arrays.  I just pushed
> a patch to do that, and for bitvectors as well.  Copying Daniel Llorens,
> to check that I didn't break arrays.

I've just tested g3248c95 and I see no breakage.

Thanks,

	Daniel

Re: A mess with GOOPS

[Daniel Llorens]

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


On Jan 10, 2012, at 13:22, Daniel Llorens wrote:

> On Jan 9, 2012, at 18:11, Andy Wingo wrote:
> 
>> Ew.  Why don't we instead allocate a typecode for arrays.  I just pushed
>> a patch to do that, and for bitvectors as well.  Copying Daniel Llorens,
>> to check that I didn't break arrays.
> 
> I've just tested g3248c95 and I see no breakage.


Hm, maybe not so. I've filed http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10482. I think it maybe related to this, but I haven't tested before the patch.

Regards,

	Daniel


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