Re: New g-wrap supported in guile-gtk--rotty-0.1!

Re: New g-wrap supported in guile-gtk--rotty-0.1!

[Andreas Rottmann]

[ CC'd guile-user, since maybe someone has an idea how to implement
  this ]

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

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>>
>> I now get ~3.6 seconds of loading time for (gnome gtk) with the above
>> referenced code, gcc 3.3.2 -O2 and Guile 1.7 on my Athlon 900. The
>> loading time is mostly spent in scm_add_method(), FWIW...
>
> I wonder if some lazy initializing would be possible, like catch a
> failed method dispatch and add only at that time.  (But my ignorance
> of goops is pretty profound, so maybe it's not feasible.)
>
I don't really know. Maybe one could postpone the method creation
until the first instance of that class has been instantiated...

> gtk+gnome is pretty big, there might be a good chance an application
> would use only a modest number of widgets and functions.  Those needed
> to get the first window up could be even fewer.  (Always good to get
> the first window up quickly, since the user is waiting, waiting ...)
>
Yes, I also think that we *have* to get the "time-to-initial-window"
at least under 1 second for a hello world program...

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: New g-wrap supported in guile-gtk--rotty-0.1!

[Mikael Djurfeldt]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> [ CC'd guile-user, since maybe someone has an idea how to implement
>   this ]
>
> Kevin Ryde <user42@zip.com.au> writes:
>
>> Andreas Rottmann <a.rottmann@gmx.at> writes:
>>>
>>> I now get ~3.6 seconds of loading time for (gnome gtk) with the above
>>> referenced code, gcc 3.3.2 -O2 and Guile 1.7 on my Athlon 900. The
>>> loading time is mostly spent in scm_add_method(), FWIW...
>>
>> I wonder if some lazy initializing would be possible, like catch a
>> failed method dispatch and add only at that time.  (But my ignorance
>> of goops is pretty profound, so maybe it's not feasible.)
>>
> I don't really know. Maybe one could postpone the method creation
> until the first instance of that class has been instantiated...
>
>> gtk+gnome is pretty big, there might be a good chance an application
>> would use only a modest number of widgets and functions.  Those needed
>> to get the first window up could be even fewer.  (Always good to get
>> the first window up quickly, since the user is waiting, waiting ...)
>>
> Yes, I also think that we *have* to get the "time-to-initial-window"
> at least under 1 second for a hello world program...

GOOPS is, as yet, only optimized for fast execution.  Creation of
objects and *especially* method creation involves a lot of work, most
of which is done by interpreted Scheme code.

This is not an architectural problem, though, and it is certainly
possible to speed things up.

An improvement of method addition on the algorithm level that could
help this particular case would be to allow for adding multiple
methods at once.  Presently, every call to scm_add_method involves
re-computing the methods list of the GF which means that adding N
methods to a GF is O(N^2).

An improvement on the implementation level would be to do part (or
all) of the work in C.  This, however, should be done with preserved
respect for the MOP.  Anyone who wants to do this should talk to me
first.

(Unfortunately, I can't do any work on GOOPS right now.  Hopefully
I'll be able to go over a few issues with GOOPS starting next summer.)

M


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: New g-wrap supported in guile-gtk--rotty-0.1!

[Andreas Rottmann]

Mikael Djurfeldt <mdj@mit.edu> writes:

[ First of all: Thanks for the quick answer ]

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > Yes, I also think that we *have* to get the "time-to-initial-window"
> > at least under 1 second for a hello world program...
> 
> GOOPS is, as yet, only optimized for fast execution.  Creation of
> objects and *especially* method creation involves a lot of work, most
> of which is done by interpreted Scheme code.
> 
> This is not an architectural problem, though, and it is certainly
> possible to speed things up.
> 
> An improvement of method addition on the algorithm level that could
> help this particular case would be to allow for adding multiple
> methods at once.  Presently, every call to scm_add_method involves
> re-computing the methods list of the GF which means that adding N
> methods to a GF is O(N^2).
> 
Ok, so we'd have a scm_add_methods() with this approach, I guess. I'll
have a look into this. I definitly want to have fast bindings when
Guile 1.8 comes out.

> An improvement on the implementation level would be to do part (or
> all) of the work in C.  This, however, should be done with preserved
> respect for the MOP.  Anyone who wants to do this should talk to me
> first.
> 
Best would probably to go for algorithmic performance increase at the
SCM level first and if that doesn't suffice, factor the critical parts
out into C.

> (Unfortunately, I can't do any work on GOOPS right now.  Hopefully
> I'll be able to go over a few issues with GOOPS starting next summer.)
> 
I'll do a bit of code study in the next days/week, and come back to
you when I have questions, if that's OK. Once I've wrapped my head
around the code, I'll try to implement scm_add_methods() and see how
much that gains us.

-- 
Andreas Rottmann


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: New g-wrap supported in guile-gtk--rotty-0.1!

[Andreas Rottmann]

Mikael Djurfeldt <mdj@mit.edu> writes:

>> Yes, I also think that we *have* to get the "time-to-initial-window"
>> at least under 1 second for a hello world program...
>
> GOOPS is, as yet, only optimized for fast execution.  Creation of
> objects and *especially* method creation involves a lot of work, most
> of which is done by interpreted Scheme code.
>
> This is not an architectural problem, though, and it is certainly
> possible to speed things up.
>
> An improvement of method addition on the algorithm level that could
> help this particular case would be to allow for adding multiple
> methods at once.  Presently, every call to scm_add_method involves
> re-computing the methods list of the GF which means that adding N
> methods to a GF is O(N^2).
>
Unfortunatly, I guess this will not help much. First, most generics in
the binding have only one method. Second, I'm not exactly sure how to
get complexity down: compute-new-methods currently checks each of
current methods against a duplicate specialization. However, it may be
save to assume that all methods passed to internal-add-methods! have
different specializers, so I could at least add them if there are not
any methods yet.

> An improvement on the implementation level would be to do part (or
> all) of the work in C.  This, however, should be done with preserved
> respect for the MOP.  Anyone who wants to do this should talk to me
> first.
>
Hmm, this would probably mean pulling internal-add-methods! and (part
of) the functions it calls down to the C level. What exactly do I
have to consider wrt MOP here?

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: New g-wrap supported in guile-gtk--rotty-0.1!

[Andreas Rottmann]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Unfortunatly, I guess this will not help much. First, most generics in
> the binding have only one method. Second, I'm not exactly sure how to
> get complexity down: compute-new-methods currently checks each of
> current methods against a duplicate specialization. However, it may be
> save to assume that all methods passed to internal-add-methods! have
> different specializers, so I could at least add them if there are not
> any methods yet.
>
>> An improvement on the implementation level would be to do part (or
>> all) of the work in C.  This, however, should be done with preserved
>> respect for the MOP.  Anyone who wants to do this should talk to me
>> first.
>>
> Hmm, this would probably mean pulling internal-add-methods! and (part
> of) the functions it calls down to the C level. What exactly do I
> have to consider wrt MOP here?
>
I now have a (seemingly) working version of internal-add-methods! in
C. Strange enough, it does not yield in a performance increase over
the scheme code. Maybe someone want's to review my code and point me
at bottlenecks or other glitches?

I got a significant speedup with a unrelated measure, however: I
blocked GC during the registering of a wrapset (where all the method
and GF creation takes place). This bought me a 20% increase of loading
speed...

Cheers, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

This reality is really just a fucked-up dream -- Papa Roach


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

[GOOPS] Specializing <generic> to allow lazy method addition

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> writes:

> On Thu, 2003-12-04 at 02:25, Kevin Ryde wrote:
>> I wonder if some lazy initializing would be possible, like catch a
>> failed method dispatch and add only at that time.  (But my ignorance
>> of goops is pretty profound, so maybe it's not feasible.)
>
> This is really a direct response to Andreas' question a couple days ago,
> which I have read but don't have on my laptop...
>
> I think I said something like make `add-method' cache methods, only
> adding them when `no-method' is called. We can look at the GOOPS manual
> (goops.info) to see what I mean.
>
> `Method Definition Internals' states that after ensuring the generic and
> creating the method, that the method is added to the generic via the
> generic `add-method!'. If the generics we create are actually subclasses
> of <generic>, we can specify `add-method!' to just keep the method in a
> holding pen of sorts. Which is to say,
>
> (define-class <guile-gnome-generic> (<generic>)
>    (temp-methods :init-value '()))
> (define-method (add-method! (generic <guile-gnome-generic>)
>                             (method <method>))
>   ;; Note we don't call next-method
>   (slot-set! generic 'temp-methods
>              (cons method (slot-ref generic 'temp-methods))))
>
I tried to play around with this a bit and it seems it is not viable
ATM; I experienced the problem described already in [0] and [1]. It
seems noone has answered why %invalidate-method cache insists on a
pure generic (from goops.c, in scm_sys_invalidate_method_cache_x):

  SCM_ASSERT (SCM_PUREGENERICP (gf), gf, SCM_ARG1, FUNC_NAME);

and what 'pure' generics are all about; FWICT, pureness is a flag set
for all built-in generic classes. Would someone of GOOPS knowledge
please be so kind to shed some light on this issue?

[0] http://mail.gnu.org/archive/html/guile-user/2002-04/msg00197.html
[1] http://mail.gnu.org/archive/html/guile-user/2003-07/msg00061.html

Thanks,
        Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: [GOOPS] Specializing <generic> to allow lazy method addition

[Mikael Djurfeldt]

Andreas Rottmann <a.rottmann@gmx.at> writes:

>> (define-class <guile-gnome-generic> (<generic>)
>>    (temp-methods :init-value '()))
>> (define-method (add-method! (generic <guile-gnome-generic>)
>>                             (method <method>))
>>   ;; Note we don't call next-method
>>   (slot-set! generic 'temp-methods
>>              (cons method (slot-ref generic 'temp-methods))))
>>
> I tried to play around with this a bit and it seems it is not viable
> ATM; I experienced the problem described already in [0] and [1]. It
> seems noone has answered why %invalidate-method cache insists on a
> pure generic (from goops.c, in scm_sys_invalidate_method_cache_x):
>
>   SCM_ASSERT (SCM_PUREGENERICP (gf), gf, SCM_ARG1, FUNC_NAME);
>
> and what 'pure' generics are all about; FWICT, pureness is a flag set
> for all built-in generic classes. Would someone of GOOPS knowledge
> please be so kind to shed some light on this issue?

The mechanism which allows you to subclass builtin classes like
<generic> and specialize functions to them is called meta object
protocols, or MOPs.

While the MOP for <class> works, the MOP for <generic> isn't yet
implemented.  This is a shame and I've for very long had had the hope
to find time to fix it.  What we really quickly should do is to
document this situation so that people know that they cannot yet
subclass <generic>.

The purity flag, which you ask about, marks that a class is
"untouched" by the user so that the C runtime can count on specific
slots existing and residing at specific locations within an object.

The idea is that the runtime will look for specialized functions only
if the class isn't pure.

M



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: [GOOPS] Specializing <generic> to allow lazy method addition

[Stephen Compall]

Mikael Djurfeldt <mdj@mit.edu> writes:

> While the MOP for <class> works, the MOP for <generic> isn't yet
> implemented.  This is a shame and I've for very long had had the hope
> to find time to fix it.  What we really quickly should do is to
> document this situation so that people know that they cannot yet
> subclass <generic>.
> 
> The purity flag, which you ask about, marks that a class is
> "untouched" by the user so that the C runtime can count on specific
> slots existing and residing at specific locations within an object.
> 
> The idea is that the runtime will look for specialized functions only
> if the class isn't pure.

Please tell me if this is accurate: all the Scheme-level procedure
calls in libguile eventually go through scm_apply in eval.c, which
contains a switch-on-type for the various kinds of applicable objects.
The case that calls `scm_apply_generic', the generic I added a method
to in trying to make a callable class, first checks for one of the
flags in the struct, which is why I get "wrong type to apply" anyway.

I ask this because I am more interested in making objects of any class
applicable.  One case of this is my makefile processor, which
essentially processes forms, and used to be in closure form (where you
applied the `object' to each form).

--
Stephen Compall or s11 or sirian

The Tao doesn't take sides;
it gives birth to both wins and losses.
The Guru doesn't take sides;
she welcomes both hackers and lusers.

The Tao is like a stack:
the data changes but not the structure.
the more you use it, the deeper it becomes;
the more you talk of it, the less you understand.

Hold on to the root.

JSOFC3IP number key monarchist SWAT ARPA credit card gamma ASIO
quarter S Key Watergate assassinate lock picking colonel MD2


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: [GOOPS] Specializing <generic> to allow lazy method addition

[Mikael Djurfeldt]

Stephen Compall <s11@member.fsf.org> writes:

> Mikael Djurfeldt <mdj@mit.edu> writes:
>
>> While the MOP for <class> works, the MOP for <generic> isn't yet
>> implemented.  This is a shame and I've for very long had had the hope
>> to find time to fix it.  What we really quickly should do is to
>> document this situation so that people know that they cannot yet
>> subclass <generic>.
>> 
>> The purity flag, which you ask about, marks that a class is
>> "untouched" by the user so that the C runtime can count on specific
>> slots existing and residing at specific locations within an object.
>> 
>> The idea is that the runtime will look for specialized functions only
>> if the class isn't pure.
>
> Please tell me if this is accurate: all the Scheme-level procedure
> calls in libguile eventually go through scm_apply in eval.c, which
> contains a switch-on-type for the various kinds of applicable
> objects.

(There is dispatch on type also within the evaluator (scm_ceval).)

> The case that calls `scm_apply_generic', the generic I added a method
> to in trying to make a callable class, first checks for one of the
> flags in the struct, which is why I get "wrong type to apply" anyway.

This is correct.

> I ask this because I am more interested in making objects of any class
> applicable.  One case of this is my makefile processor, which
> essentially processes forms, and used to be in closure form (where you
> applied the `object' to each form).

The correct way to make an applicable object is (sorry---couldn't
think of a better example):

(define (incrementor-function o x)
  (+ x (increment o)))

(define-class <incrementor> ()
  (increment #:init-value 1 #:init-keyword #:increment)
  #;metaclass <operator-class>
  #:procedure incrementor-function)

(define x (make <incrementor> #:increment 2))
(x 1) --> 3
(set! (increment x) 3)
(x 1) --> 4

Here all objects of class <incrementor> behave the same.

You can also subclass <entity> where every object has individual
behavior.

These also come in variants which have setters, in which case you can
give a meaning to expresions like:

(set! (x ...) ...)

M



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Guile warts (was: [GOOPS] Specializing <generic> to allow lazy method addition)

[Andy Wingo]

[cc'ing to devel for the bug list -- please reply to -devel]

On Tue, 2004-01-27 at 17:17, Mikael Djurfeldt wrote:
> While the MOP for <class> works, the MOP for <generic> isn't yet
> implemented.

I might poke around with this, we'll see. But I reply for a different
reason: <class>, in (guile-user), is not the same as <class> in (oop
goops).

guile> (use-modules (oop goops))
guile> <class>
$2 = #<struct 805c4d0:805c4d0>
guile> (module-ref (resolve-module '(oop goops)) '<class>)
$3 = #<<class> <class> 80863b0>
guile> (is-a? <class> <class>)
$4 = #f

There are some warts that I see with guile 1.6, that I don't think are
fixed yet. I'm making this list to see if there are any objections to
it. Some of these I might get to patching and perhaps others are
inspired to fix some.

* The <class> issue

Can be solved by exporting <class> from (oop goops) ?

* The default namespace is a mess

The problem lies mostly in the fact that bindings used by internal
routines from boot-9.scm are exported, by default, to (guile-user). The
solution is difficult to see. As evidence to the problem, do you really
think that routines like `make-root-module' should be exported to the
normal namespace? Really though. Press TAB at the guile command prompt,
it's ridiculous.

** There are undocumented reserved words, like `app' and `repl'

These really really need to go, somehow. But again, the byzantine nature
of the module system makes it difficult to see the answer. At the very
least, these words (and perhaps others, and if we don't actually do
anything all of boot-9.scm) must be documented. Why can't I have a
module called (gnome gtk repl)?

** Some things in the default namespace should really be in modules of
their own

POSIX, for instance, should be in (os posix) or something. inet-*. All
the environment functions.  module-*.

...

I speak as a hacker on guile-gnome, which can output a holy shitload of
bindings. Every existing binding is important. When I load up gstreamer
and gtk+, I get the following conflicts:

.append  .delete  .hash    .load    .merge   .seek    .write
.close   .error   .id      .map     .raise   .select  .yield

Some of them need to keep their vanilla meanings, like map, write,
delete, load, and append. Maybe yield. But the others should come from
(os posix). And the irritating thing is that (define-method ...) just
overshadows the bindings on these ones, doesn't create the
primitive-generic.

I don't want to sound negative. I'm so much happier programming in guile
scheme than in any other language I've tried. But I do want feedback
from the devs: are these complaints valid, and is there anyone who is
working on them? The boot-9 problems are prolly the worst and most
difficult.

Thanks for reading :-)
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile warts

[Mikael Djurfeldt]

Andy Wingo <wingo@pobox.com> writes:

> I don't want to sound negative. I'm so much happier programming in guile
> scheme than in any other language I've tried. But I do want feedback
> from the devs: are these complaints valid, and is there anyone who is
> working on them? The boot-9 problems are prolly the worst and most
> difficult.

Although I don't have time for Guile development work right now, I
think I can speak for the other developers when saying that your
points are very valid.

Regarding the name space, this is something which should have been
done long ago.  If you want a workaround, note that you can construct
a module with hand-picked bindings:

(define-module (pure-r5rs)
  :pure
  :use-module (ice-9 r5rs))

Also lookup :select in the Guile NEWS file.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel