octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Beyond 2.9.5


From: David Bateman
Subject: Re: Beyond 2.9.5
Date: Wed, 12 Apr 2006 18:01:29 +0200
User-agent: Mozilla Thunderbird 1.0.6-7.5.20060mdk (X11/20050322)

John W. Eaton wrote:

>| I wonder if it might be better to add Soren's package manager (to allow
>| octave-forge to be split up) and not much else and label a 2.9.x release
>| as a testing release... 2.9.x is pretty stable as is.
>
>Yes, we could do that, but I think I'd prefer to wait just a bit so we
>can get some of the more painful transitions behind us all at once.  I
>include the DEFVAR/DEFCONST changes and the changes in the
>octave_value class hierarchy in this list.
>  
>
Perhaps also the "[x{:}] = foo(...)" changes should be included there.
In this case I'd vote for getting everything into 2.9.5+ as fast as
possible, and we can have a lovely unstable 2.9.6 release that we can
then start trying to make stable again. Also why not include the
graphics handle stuff in this list, as the basic infrastructure seems to
be firming up.


>| For the changes for the octave_value class I'm not sure I see what we
>| are winning.
>
>The change is not absolutely necessary (things work now) but it seems
>like a somewhat cleaner way of doing things.  Given that the necessary
>changes to user-defined types are relatively small, I think I'd like
>to go ahead with this change.
>
>| What I'd like to see is a consistent manner of creating and
>| extracting an arbitrary type from an octave_value. That is, we have
>| certain types that are in a privileged position like
>| 
>| NDArray m = arg.array_value ();
>| octave_value retval;
>| .....
>| retval = m;
>
>I would really prefer to keep this feature as I think it makes the
>internals of Octave much easier to read and write.
>  
>
My interest was a consistent API. The other hidden advantage of this is
that maybe_mutate() is called on the octave_value constructor, though
that might be hidden in a MACRO as below.


>| while an arbitrary type must do
>| 
>| MyType m = (const octave_my_type &)arg.get_rep()).mytype_value();
>| octave_value retval;
>| .....
>| retval = new octave_my_type (m);
>
>Do you see a better way of expressing this?  At the very least, we
>could hide some of the ugliness behind some macros.
>  
>
Err, unfortunately no, I'd hope you might... A handful of macros seems
the right way

>| getting rid of this distinction, it would then make sense to have the
>| integer and sparse types external to the base octave, and probably all
>| types and make the memory footprint of octave smaller.  The final brick
>| in the same direction would be to have the mapper class treat the types
>| generically.
>
>Does it really make sense to remove all types from the core
>interpreter?  Some will have to be loaded just to have Octave start up
>do anything useful.
>
>  
>
Minimizing the number in the core does though..

D.


>jwe
>
>  
>


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



reply via email to

[Prev in Thread] Current Thread [Next in Thread]