after 3.2

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

after 3.2

John W. Eaton
Administrator
Here's a list of possible projects for after 3.2.

I've tagged completed items with an "X" and items for which some work
has been done with an "+".

  * Namespace(s) for Octave sources.

  * Objects:
      - Operator overloading vs. constant folding
      - Overloading built-in classes (double, etc.)

  * Profiler.

  * Nested functions.

  * Graphics:
      + Fonts and text objects
      + Refactor base_properties
      + Specific types for properties with improved property value
        checking
      + Implement the addprops function allow additional properties
        to objects
      + add the hggroup object that has no fixed properties for use
        by barseries, etc.
      + Add callback DeleteFcn/CreateFcn to objects
      + Allow listener functions to be added to objects
      + Clean separation of backend from property database
      + Implement experimental backend based on OpenGL and GUI
        toolkit

  * Avoid segfault problem when clearing dynamically linked functions
    that create user-defined types.

  * Move code to external packages
      - optimization?
      - signal?
      - statistics?

  * Handle block comments inside [] or {} and also in the group of
    comments following a continuation character, etc.  See the FIXME
    comments in lex.l.

  + Mixed sparse x diagonal matrix operations (may be included in 3.2).

  * Use templates instead of macros where possible.

  * Update the configure script and make checks for header files and
    libraries more consistent (maybe we could recruit an autoconf
    expert to help with this job).

  * Rewrite Makefiles to avoid recursive make (see
    http://miller.emu.id.au/pmiller/books/rmch/ for some ideas).

For me, the first six items above have a fairly high priority.
Especially graphics and the profiler.

If you have comments, suggestions, or additions, please send them to
me or to the list for discussion, and I'll update the list and
repost.

At this point, it can be something of a wish list, but the items
should be things that we have some chance of implementing before the
next release (after 3.2).  By the time we make the 3.2 release, we
should have this list narrowed down to maybe the top 10 items as
prioity projects.  I'd still like to see us reduce the interval
between stable releases to something like 6-9 months, so I think doing
that will require focusing on a smaller list of projects for each
release, then making the release and moving on instead of allowing the
list of projects to continually expand (this is something I need to
work on as much as anyone else).

jwe
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Søren Hauberg
tor, 12 03 2009 kl. 15:55 -0400, skrev John W. Eaton:
> I'd still like to see us reduce the interval
> between stable releases to something like 6-9 months, so I think doing
> that will require focusing on a smaller list of projects for each
> release, then making the release and moving on instead of allowing the
> list of projects to continually expand (this is something I need to
> work on as much as anyone else).

Perhaps we should move to time based (rather than feature based)
releases? That is, when 3.2 is released we decide on a data for the next
release and then stick to it. This approach seems to have served other
projects (e.g. GNOME) quite well.

Søren

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Jaroslav Hajek-2
In reply to this post by John W. Eaton
On Thu, Mar 12, 2009 at 8:55 PM, John W. Eaton <[hidden email]> wrote:
> Here's a list of possible projects for after 3.2.
>
> I've tagged completed items with an "X" and items for which some work
> has been done with an "+".
>
>  * Namespace(s) for Octave sources.

Should this include renaming the classes? IIRC you agreed that using
CamelCasing for Array & Stuff is unfortunate.

I add:

* Simplify array class inheritance tree. Probably to something like
Array (indexing, sorting) --> MArray (type-generic elem-by-elem ops,
reductions) --> *NDArray (type-specific ops, fft & such stuff) -->
*Matrix (multiplication, solving, etc) --> *RowVector, *ColumnVector
That should quite simplify writing templatized code using the array
classes and should also remove a lot of code duplication.

>  * Objects:
>      - Operator overloading vs. constant folding

I think overloading built-in operators is quite useless. Constant
folding is much better.

>      - Overloading built-in classes (double, etc.)
>
>  * Profiler.
>
>  * Nested functions.
>
>  * Graphics:
>      + Fonts and text objects
>      + Refactor base_properties
>      + Specific types for properties with improved property value
>        checking
>      + Implement the addprops function allow additional properties
>        to objects
>      + add the hggroup object that has no fixed properties for use
>        by barseries, etc.
>      + Add callback DeleteFcn/CreateFcn to objects
>      + Allow listener functions to be added to objects
>      + Clean separation of backend from property database
>      + Implement experimental backend based on OpenGL and GUI
>        toolkit
>
>  * Avoid segfault problem when clearing dynamically linked functions
>    that create user-defined types.
>
>  * Move code to external packages
>      - optimization?



>      - signal?
>      - statistics?
>
>  * Handle block comments inside [] or {} and also in the group of
>    comments following a continuation character, etc.  See the FIXME
>    comments in lex.l.
>
>  + Mixed sparse x diagonal matrix operations (may be included in 3.2).

will be

>  * Use templates instead of macros where possible.

Agreed. Maybe we can also optionally (based on configure check)
attempt to use some more advanced commonly supported features.
Restrict pointers are an example.

>
>  * Update the configure script and make checks for header files and
>    libraries more consistent (maybe we could recruit an autoconf
>    expert to help with this job).
>
>  * Rewrite Makefiles to avoid recursive make (see
>    http://miller.emu.id.au/pmiller/books/rmch/ for some ideas).
>
> For me, the first six items above have a fairly high priority.
> Especially graphics and the profiler.
>
> If you have comments, suggestions, or additions, please send them to
> me or to the list for discussion, and I'll update the list and
> repost.
>
> At this point, it can be something of a wish list, but the items
> should be things that we have some chance of implementing before the
> next release (after 3.2).  By the time we make the 3.2 release, we
> should have this list narrowed down to maybe the top 10 items as
> prioity projects.
> I'd still like to see us reduce the interval
> between stable releases to something like 6-9 months, so I think doing
> that will require focusing on a smaller list of projects for each
> release, then making the release and moving on instead of allowing the
> list of projects to continually expand (this is something I need to
> work on as much as anyone else).
>
> jwe
>

After 6 months of being a stable branch release manager, I can now
summarize my feelings:
It was fairly obvious that as time passed,  the development and stable
codebases started to
divert significantly, and patches ceased to apply smoothly, it was
often hard or impossible to transplant them and 3.0.x-specific patches
were necessary.
This is probably not avoidable, but the effect was pretty magnified by
the fact that there was a single person (me) responsible for
transplanting the patches, and that person didn't understand every
part of Octave enough to be always sure what needs to be transplanted.
I especially mean the graphics patches. Now add my 3 weeks off in that
time.
Right now, 3.0.x is suspended because of some show-stopping graphics
bugs and unless someone supplies a patch for those, 3.0.4 will never
exist.

I think it will be better if more people are able to transplant
patches to the stable series, because often you can simultaneously
apply a fix to both development and stable series. Unless Savannah
allows a project to have more than one repo, the easiest way I see is
to again introduce branches within the main repo.

comments?

cheers



--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

David Bateman-2
In reply to this post by John W. Eaton
On Thu, Mar 12, 2009 at 03:55:43PM -0400, John W. Eaton wrote:
>   * Graphics:
>       + Implement the addprops function allow additional properties
>         to objects
>       + add the hggroup object that has no fixed properties for use
>         by barseries, etc.
>       + Add callback DeleteFcn/CreateFcn to objects
>       + Allow listener functions to be added to objects

Aren't these alreay implemented. I added all of the bar-series, etc
objects bqsed on Michael's hggroup code a few months back

D.

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

bpabbott
Administrator
In reply to this post by John W. Eaton

On Mar 13, 2009, at 3:55 AM, John W. Eaton wrote:

> Here's a list of possible projects for after 3.2.
>
> I've tagged completed items with an "X" and items for which some work
> has been done with an "+".
>
>  * Namespace(s) for Octave sources.
>
>  * Objects:
>      - Operator overloading vs. constant folding
>      - Overloading built-in classes (double, etc.)
>
>  * Profiler.
>
>  * Nested functions.
>
>  * Graphics:
>      + Fonts and text objects
>      + Refactor base_properties
>      + Specific types for properties with improved property value
>        checking
>      + Implement the addprops function allow additional properties
>        to objects
>      + add the hggroup object that has no fixed properties for use
>        by barseries, etc.
>      + Add callback DeleteFcn/CreateFcn to objects
>      + Allow listener functions to be added to objects
>      + Clean separation of backend from property database
>      + Implement experimental backend based on OpenGL and GUI
>        toolkit
>
>  * Avoid segfault problem when clearing dynamically linked functions
>    that create user-defined types.
>
>  * Move code to external packages
>      - optimization?
>      - signal?
>      - statistics?
>
>  * Handle block comments inside [] or {} and also in the group of
>    comments following a continuation character, etc.  See the FIXME
>    comments in lex.l.
>
>  + Mixed sparse x diagonal matrix operations (may be included in 3.2).
>
>  * Use templates instead of macros where possible.
>
>  * Update the configure script and make checks for header files and
>    libraries more consistent (maybe we could recruit an autoconf
>    expert to help with this job).
>
>  * Rewrite Makefiles to avoid recursive make (see
>    http://miller.emu.id.au/pmiller/books/rmch/ for some ideas).
>
> For me, the first six items above have a fairly high priority.
> Especially graphics and the profiler.
>
> If you have comments, suggestions, or additions, please send them to
> me or to the list for discussion, and I'll update the list and
> repost.
>
> At this point, it can be something of a wish list, but the items
> should be things that we have some chance of implementing before the
> next release (after 3.2).  By the time we make the 3.2 release, we
> should have this list narrowed down to maybe the top 10 items as
> prioity projects.  I'd still like to see us reduce the interval
> between stable releases to something like 6-9 months, so I think doing
> that will require focusing on a smaller list of projects for each
> release, then making the release and moving on instead of allowing the
> list of projects to continually expand (this is something I need to
> work on as much as anyone else).
>
> jwe


Both addproperty and addlistener (as well as dellistener) are already  
available (and being used). However, I'd like to have a  
deleteproperty, so that properties needed on a temporary basis can be  
deleted when their no longer needed (we'd need a deleteable attribute  
added to such examples).

Also, Matlab's addproperty has a different purpose.

        http://www.mathworks.com/access/helpdesk/help/techdoc/ref/addproperty.html

For compatibility with Matlab, Octave should use {set,get,is,rm}appdata.

        http://www.mathworks.com/access/helpdesk/help/techdoc/ref/setappdata.html
        http://www.mathworks.com/access/helpdesk/help/techdoc/ref/getappdata.html
        http://www.mathworks.com/access/helpdesk/help/techdoc/ref/rmappdata.html
        http://www.mathworks.com/access/helpdesk/help/techdoc/ref/isappdata.html

More detailed and robust font handling could be added as well. Using  
fontfonfig it is possible to obtain the information needed to match  
fonts (say when Helvetica is missing, the information needed to find  
an equivalent is available). For anyone interested, the link below has  
more detailed information about what information is available from  
fontconfig.

        http://fontconfig.org/fontconfig-user.html

Ben


Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Thomas Weber-8
In reply to this post by Jaroslav Hajek-2
Am Donnerstag, den 12.03.2009, 21:42 +0100 schrieb Jaroslav Hajek:
> I think it will be better if more people are able to transplant
> patches to the stable series, because often you can simultaneously
> apply a fix to both development and stable series. Unless Savannah
> allows a project to have more than one repo, the easiest way I see is
> to again introduce branches within the main repo.

I don't have a problem with adding more people to committer status of
the 3-x branch at tw-math.de.

That said, is there really a need to have two branches, stable and
development? It seems the Linux kernel works quite nicely with just one
branch.

        Thomas

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

John W. Eaton
Administrator
On 13-Mar-2009, Thomas Weber wrote:

| That said, is there really a need to have two branches, stable and
| development? It seems the Linux kernel works quite nicely with just one
| branch.

So just dismiss with the updates to the stable releases, and only have
a series of releases?

That's fine with me, but it doesn't give people a lot of comfort when
there are bugs in a release and the next one might be N months away
and introduce a lot of new untested features that could cause more
trouble even if there are fixes for the problems found in the previous
release.

The goal of the stable release series is to converge on something
that is more or less free of show-stopping bugs, even if it doesn't
have all the latest features.  But I'm not sure we do a good job of
that when we do more than fix regressions (and possibly other serious
bugs) in the stable release.  As Jaroslav noted, transplanting patches
from the development tree can have a destabilizing effect as the two
branches diverge.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Thomas Weber-8
Am Freitag, den 13.03.2009, 04:07 -0400 schrieb John W. Eaton:
> On 13-Mar-2009, Thomas Weber wrote:
>
> | That said, is there really a need to have two branches, stable and
> | development? It seems the Linux kernel works quite nicely with just one
> | branch.
>
> So just dismiss with the updates to the stable releases, and only have
> a series of releases?

Yes.

> That's fine with me, but it doesn't give people a lot of comfort when
> there are bugs in a release and the next one might be N months away
> and introduce a lot of new untested features that could cause more
> trouble even if there are fixes for the problems found in the previous
> release.

<shrug>
It seems people are okay with that in the kernel.


> The goal of the stable release series is to converge on something
> that is more or less free of show-stopping bugs, even if it doesn't
> have all the latest features.  But I'm not sure we do a good job of
> that when we do more than fix regressions (and possibly other serious
> bugs) in the stable release.  As Jaroslav noted, transplanting patches
> from the development tree can have a destabilizing effect as the two
> branches diverge.

Yes, but why are those patches transplanted? Simple, they fix bugs that
have been reported by users. So, not fixing them means users might be
totally unable to use the stable branch for whatever their specific
problem is.

        Thomas



Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Michael Goffioul
In reply to this post by bpabbott
On Fri, Mar 13, 2009 at 1:04 AM, Ben Abbott <[hidden email]> wrote:

> Both addproperty and addlistener (as well as dellistener) are already
> available (and being used). However, I'd like to have a deleteproperty, so
> that properties needed on a temporary basis can be deleted when their no
> longer needed (we'd need a deleteable attribute added to such examples).
>
> Also, Matlab's addproperty has a different purpose.
>
>
>  http://www.mathworks.com/access/helpdesk/help/techdoc/ref/addproperty.html
>
> For compatibility with Matlab, Octave should use {set,get,is,rm}appdata.
>
>
>  http://www.mathworks.com/access/helpdesk/help/techdoc/ref/setappdata.html
>
>  http://www.mathworks.com/access/helpdesk/help/techdoc/ref/getappdata.html
>
>  http://www.mathworks.com/access/helpdesk/help/techdoc/ref/rmappdata.html
>
>  http://www.mathworks.com/access/helpdesk/help/techdoc/ref/isappdata.html

I would not use these to implement dynamic properties. The actual reference
should be

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_oop/bq08quy.html#brffvja

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Jaroslav Hajek-2
In reply to this post by John W. Eaton
On Fri, Mar 13, 2009 at 9:07 AM, John W. Eaton <[hidden email]> wrote:

> On 13-Mar-2009, Thomas Weber wrote:
>
> | That said, is there really a need to have two branches, stable and
> | development? It seems the Linux kernel works quite nicely with just one
> | branch.
>
> So just dismiss with the updates to the stable releases, and only have
> a series of releases?
>
> That's fine with me, but it doesn't give people a lot of comfort when
> there are bugs in a release and the next one might be N months away
> and introduce a lot of new untested features that could cause more
> trouble even if there are fixes for the problems found in the previous
> release.
>
> The goal of the stable release series is to converge on something
> that is more or less free of show-stopping bugs, even if it doesn't
> have all the latest features.  But I'm not sure we do a good job of
> that when we do more than fix regressions (and possibly other serious
> bugs) in the stable release.  As Jaroslav noted, transplanting patches
> from the development tree can have a destabilizing effect as the two
> branches diverge.
>
> jwe
>

To carry on the idea of linear development:
I think we have essentially two groups of users using binaries: users
of packages provided by GNU/Linux distros, and users of the Windows
binaries.
As for the distro users, it's just a question of how often they can
make package updates. My impression is that most distros (e.g. Debian)
have a fairly sophisticated auto-building systems, so that updating a
binary package, say (a wild guess), once per month is not a big deal.
Perhaps the package maintainers visiting this list can comment.

As for the Windows binaries, it would be fairly nice to have something
similar to auto-updates provided by Linux distros. I'm fairly
convinced that users don't really mind bugs if there's a good chance
of getting rid of them by a few clicks within a month via some
automatic update mechanism.  Imagine a dialog popping up for the
Windows user telling him "an update is available, click OK to
install". But of course, this would require some development.

My main point is that when releases are only made twice per year,
users (other than those building from development sources) don't fully
experience one of the primary advantages of the openness of free
software: the fast bug-fixing.
Let's say that most bugs are being fixed in the development sources
within 1-2 weeks, but delivered to users in 2-4 months. It would be
very nice to close this gap somewhat.

At least that's my personal feeling. In the internet age, installing
software is not, and shouldn't be, much of a limiting factor.


--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Bill Denney-5
Jaroslav Hajek wrote:
> As for the Windows binaries, it would be fairly nice to have something
> similar to auto-updates provided by Linux distros. I'm fairly
> convinced that users don't really mind bugs if there's a good chance
> of getting rid of them by a few clicks within a month via some
> automatic update mechanism.  Imagine a dialog popping up for the
> Windows user telling him "an update is available, click OK to
> install". But of course, this would require some development.
>  

Hi Jaroslav,

This shouldn't be too hard.  The windows packagers could possibly run
something like this in the .octaverc file.  The downside is that getting
the URL will cause an indeterminate time pause during startup.

Have a good day,

Bill

function check_update_windows (update_url =
"http://sourceforge.net/project/showfiles.php?group_id=2888&package_id=40078")

[current_avail_ver_raw, success, msg] = urlread(update_url);
if (! success)
    warning("update-check:urldownload", "Could not check for
update:\nCould not read %s\n%s", update_url, msg);
    return;
endif
current_avail_ver = unique(regexp(current_avail_ver_raw,
"octave-(?<ver>[0-9]+.[0-9]+.[0-9]+)-setup", "names").ver);
higher_vers = compare_versions(current_avail_ver, OCTAVE_VERSION, ">");
current_avail_ver(!higher_vers) = [];
if (! isempty(current_avail_ver))
    ## See if the current version is development or stable
    development = development_version(OCTAVE_VERSION);
    if (! development)
       current_avail_ver(development_version(current_avail_ver)) = [];
    endif
    if (! isempty(current_avail_ver))
        printf("You are currently running Octave version %s, and version
%s is available for download at\n%s\n",
           OCTAVE_VERSION, current_avail_ver(end), update_url);
    endif
endif

function r = development_version(v)
if iscellstr (v)
    r = cellfun(@development_version, v);
elseif ischar (v)
    r = mod(double(regexp(v, "^[0-9]+.(?<mid>[0-9]+).", "names").mid), 2);
else
    error ("version must be a cellstr or a char");
end
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Rafael Laboissiere
In reply to this post by Jaroslav Hajek-2
* Jaroslav Hajek <[hidden email]> [2009-03-15 12:51]:

> As for the distro users, it's just a question of how often they can
> make package updates. My impression is that most distros (e.g. Debian)
> have a fairly sophisticated auto-building systems, so that updating a
> binary package, say (a wild guess), once per month is not a big deal.
> Perhaps the package maintainers visiting this list can comment.

I am not sure to understand what you are meaning exactly, but:

Preparation of a new release of a package and autobuilding a package are
two unrelated things, at least in Debian.  The first one is the acual
hard work: each time a new version of Octave is release, the package
maintainer (the DOG in our case) has to prepare the appropriate Debian
packaging files.  Sometimes this work is trivial but most of the time it
is not.  Once the new version of the package is uploaded, then the
autobuilders start building it for each architecture.

In other words, the sophisticated auto-building system of Debian cannot
magically update the package every time a new upstream version is
released.

I apologize if my response above is unrelated to what you were meaning.

--
Rafael
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

John W. Eaton
Administrator
On 15-Mar-2009, Rafael Laboissiere wrote:

| Preparation of a new release of a package and autobuilding a package are
| two unrelated things, at least in Debian.  The first one is the acual
| hard work: each time a new version of Octave is release, the package
| maintainer (the DOG in our case) has to prepare the appropriate Debian
| packaging files.  Sometimes this work is trivial but most of the time it
| is not.

I imagine that new package dependencies could cause trouble, but what
other things make this a difficult process?  Is there anything we can
do to make it easier?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Thomas Weber-8
In reply to this post by Jaroslav Hajek-2
On Sun, Mar 15, 2009 at 12:51:42PM +0100, Jaroslav Hajek wrote:

> On Fri, Mar 13, 2009 at 9:07 AM, John W. Eaton <[hidden email]> wrote:
> > On 13-Mar-2009, Thomas Weber wrote:
> >
> > | That said, is there really a need to have two branches, stable and
> > | development? It seems the Linux kernel works quite nicely with just one
> > | branch.
> >
> > So just dismiss with the updates to the stable releases, and only have
> > a series of releases?
> >
> > That's fine with me, but it doesn't give people a lot of comfort when
> > there are bugs in a release and the next one might be N months away
> > and introduce a lot of new untested features that could cause more
> > trouble even if there are fixes for the problems found in the previous
> > release.
> >
> > The goal of the stable release series is to converge on something
> > that is more or less free of show-stopping bugs, even if it doesn't
> > have all the latest features.  But I'm not sure we do a good job of
> > that when we do more than fix regressions (and possibly other serious
> > bugs) in the stable release.  As Jaroslav noted, transplanting patches
> > from the development tree can have a destabilizing effect as the two
> > branches diverge.
> >
> > jwe
> >
>
> To carry on the idea of linear development:
> I think we have essentially two groups of users using binaries: users
> of packages provided by GNU/Linux distros, and users of the Windows
> binaries.
> As for the distro users, it's just a question of how often they can
> make package updates. My impression is that most distros (e.g. Debian)
> have a fairly sophisticated auto-building systems, so that updating a
> binary package, say (a wild guess), once per month is not a big deal.
> Perhaps the package maintainers visiting this list can comment.

For Debian:
For Octave itself, once per month isn't a problem. However, there are
also the packages from octave-forge. If they need an update for an
Octave version, than once per month is off-limits. I'd say that building
2-3 octave-forge packages are about as much "work" as one Octave
package.

Where "work" means the time I actively spend on the packaging. It's not
like I'm supervising the compiler's output.

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Jaroslav Hajek-2
In reply to this post by Rafael Laboissiere
On Sun, Mar 15, 2009 at 5:48 PM, Rafael Laboissiere <[hidden email]> wrote:

> * Jaroslav Hajek <[hidden email]> [2009-03-15 12:51]:
>
>> As for the distro users, it's just a question of how often they can
>> make package updates. My impression is that most distros (e.g. Debian)
>> have a fairly sophisticated auto-building systems, so that updating a
>> binary package, say (a wild guess), once per month is not a big deal.
>> Perhaps the package maintainers visiting this list can comment.
>
> I am not sure to understand what you are meaning exactly, but:
>
> Preparation of a new release of a package and autobuilding a package are
> two unrelated things, at least in Debian.  The first one is the acual
> hard work: each time a new version of Octave is release, the package
> maintainer (the DOG in our case) has to prepare the appropriate Debian
> packaging files.  Sometimes this work is trivial but most of the time it
> is not.  Once the new version of the package is uploaded, then the
> autobuilders start building it for each architecture.
>

I'd hope that with more frequent releases it would become trivial more
often. Maybe I'm being too naive about it, but I imagine it as some
set of scripts that can be used by the autobuilders, and unless there
is a new dependency or a change in the build process, it should work
smoothly. Am I wrong?

> In other words, the sophisticated auto-building system of Debian cannot
> magically update the package every time a new upstream version is
> released.
>
> I apologize if my response above is unrelated to what you were meaning.
>

No, it was exactly what I mean.


--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Jaroslav Hajek-2
In reply to this post by Bill Denney-5
On Sun, Mar 15, 2009 at 5:19 PM, Bill Denney <[hidden email]> wrote:

> Jaroslav Hajek wrote:
>> As for the Windows binaries, it would be fairly nice to have something
>> similar to auto-updates provided by Linux distros. I'm fairly
>> convinced that users don't really mind bugs if there's a good chance
>> of getting rid of them by a few clicks within a month via some
>> automatic update mechanism.  Imagine a dialog popping up for the
>> Windows user telling him "an update is available, click OK to
>> install". But of course, this would require some development.
>>
>
> Hi Jaroslav,
>
> This shouldn't be too hard.  The windows packagers could possibly run
> something like this in the .octaverc file.  The downside is that getting
> the URL will cause an indeterminate time pause during startup.
>
> Have a good day,
>
> Bill
>

Hi Bill,

the implied pause is exactly why I talked about some development. I
was more thinking about an application that is silently launched in
background (perhaps only once per week or so), waits for the http
query, and then possibly pops up a dialog suggesting Octave upgrade.
It's been years since I developed anything on Windows, but I don't
think it should be very hard - I think even Windows script host was
capable of such things.

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Rafael Laboissiere
In reply to this post by John W. Eaton
* John W. Eaton <[hidden email]> [2009-03-15 12:53]:

> I imagine that new package dependencies could cause trouble, but what
> other things make this a difficult process?  Is there anything we can
> do to make it easier?

Thanks but I do not think so.  From my experience with other packages in
Debian, Octave has one of the most reactive and cooperative upstream
teams.  Most of the work comes from bug triage, patch integration,
complying with the Debian Policy, and other tasks that are specific to
the Debian packaging.

--
Rafael
Reply | Threaded
Open this post in threaded view
|

Re: after 3.2

Jason Riedy
In reply to this post by Jaroslav Hajek-2
And Jaroslav Hajek writes:
> * Simplify array class inheritance tree.

A longer-term (and harder) goal might be to eliminate many of the
classes completely and move more code into Octave's language.  If
the dynamically typed code can be run efficiently (enough), that
may help break apart the huge operation mesh.

I really wish I had the time & background to look into using the
guts of Tamarin-tracing[1] (a JIT compiler, the basis of
Tracemonkey) to replace Octave's interpreter.  The JavaScript
language has many of the same issues as Octave's language.  Or
look into borrowing infrastructure from GNU Smalltalk or GNU
Clisp, but the is-it-an-int-index-or-a-double issue doesn't occur
in those to the same extent.

Jason

Footnotes:
[1]  https://wiki.mozilla.org/Tamarin:Tracing

Reply | Threaded
Open this post in threaded view
|

OOP Update

Robert T. Short
In reply to this post by John W. Eaton
Attached is an update to the OOP facilities.  This fixes all of the
major problems that I know about EXCEPT

- I don't see how load/save can work.  I haven't tried yet, but I will
do that and then I will look and see what happens in MATLAB and fix
appropriately.

Notes.

There is a Changelog in both the root and in src.  I didn't know which
one to muck with so did the src one.

Other things that need attention.

-  which(xxx) where xxx is a method should return a path to the method.  
In MATLAB it would be c:\path\xxx.m  % xxx method.  I expect octave
should do "xxx is the method defined...".

- Documentation and tests.

Also attached is a tarball with my test class hierarchy.  The ClassTest
script works in both MATLAB and octave.  In the Notes file contained in
the tarball there are a lot of other notes.  Mostly minor and mostly
just reminders to myself to check all of these things out.


Bob
--
Robert T. Short
PhaseLocked Systems



# HG changeset patch
# User [hidden email]
# Date 1238865298 25200
# Node ID 316120e00366c8423fa208659b78f53068940922
# Parent  089bd295e4f7a04b08ceb5102d6280f2277cb16d
Update to OOP facilities.
* scripts/general/isa.m: Fixed isa so that multiple layers of
  class hierarchy are reported correctly.
* src/variables.cc: Make exist('obj') for objects report correctly.
* src/ov-base.h: Added an assign method so ov-class is able to
  assign structure elements properly.
* src/ov-class.h: Assign map elements.
* src/ov-class.cc:
  - Made sure that there are no duplicate classes in parent tree.
  - Simplified search algorithm for parent classes.
  - Fixed subsasgn so cls = method(cls,value) works when properly
    when method is a parent-class method.
  - Added __isa_parent__ so isa works correctly.

diff -r 089bd295e4f7 -r 316120e00366 scripts/general/isa.m
--- a/scripts/general/isa.m Fri Mar 27 22:35:14 2009 -0700
+++ b/scripts/general/isa.m Sat Apr 04 10:14:58 2009 -0700
@@ -44,10 +44,7 @@
     class_of_x = class (x);
     retval = strcmp (class_of_x, cname);
     if (! retval && isobject (x))
-      parent_classes_of_x = __parent_classes__ (x);
-      if (! isempty (parent_classes_of_x))
- retval = any (strcmp (parent_classes_of_x, cname));
-      endif
+      retval = __isa_parent__ (x, cname);
     endif
   endif
 
diff -r 089bd295e4f7 -r 316120e00366 src/ChangeLog
--- a/src/ChangeLog Fri Mar 27 22:35:14 2009 -0700
+++ b/src/ChangeLog Sat Apr 04 10:14:58 2009 -0700
@@ -1,3 +1,20 @@
+2009-04-04  Robert T. Short  <[hidden email]>
+
+        Update to OOP facilities.  This finishes a reasonably complete and
+        functional implementation of legacy (@Directory) OOP functionality.
+ * scripts/general/isa.m: Fixed isa so that multiple layers of
+          class hierarchy are reported correctly.
+        * src/variables.cc: Make exist('obj') for objects report correctly.
+        * src/ov-base.h: Added an assign method so ov-class is able to
+          assign structure elements properly.
+        * src/ov-class.h: Assign map elements.
+        * src/ov-class.cc:
+           - Made sure that there are no duplicate classes in parent tree.
+           - Simplified search algorithm for parent classes.
+           - Fixed subsasgn so cls = method(cls,value) works when properly
+             when method is a parent-class method.
+           - Added __isa_parent__ so isa works correctly.
+
 2009-03-27  Jaroslav Hajek  <[hidden email]>
 
  * DLD-FUNCTIONS/balance.cc (Fbalance): Fix order of output args.
diff -r 089bd295e4f7 -r 316120e00366 src/ov-base.h
--- a/src/ov-base.h Fri Mar 27 22:35:14 2009 -0700
+++ b/src/ov-base.h Sat Apr 04 10:14:58 2009 -0700
@@ -170,6 +170,8 @@
 
   virtual octave_value_list
   do_multi_index_op (int nargout, const octave_value_list& idx);
+
+  virtual void assign(const std::string&, const octave_value&) { };
 
   virtual octave_value
   subsasgn (const std::string& type,
diff -r 089bd295e4f7 -r 316120e00366 src/ov-class.cc
--- a/src/ov-class.cc Fri Mar 27 22:35:14 2009 -0700
+++ b/src/ov-class.cc Sat Apr 04 10:14:58 2009 -0700
@@ -78,6 +78,9 @@
  {
   std::string cnm = parent.class_name ();
 
+  if (find_parent_class (cnm))
+    error ("duplicate class in parent tree");
+
   parent_list.push_back (cnm);
 
   map.assign (cnm, parent);
@@ -91,52 +94,27 @@
 octave_class::find_parent_class (const std::string& parent_class_name)
 {
   octave_base_value* retval = 0;
-  std::string dbg_clsnm = class_name ();
 
   if (parent_class_name == class_name ())
     retval = this;
   else
-    {
-      // Search in the list of immediate parents first, then in the
-      // ancestor tree.
+    for (std::list<std::string>::iterator pit = parent_list.begin ();
+ pit != parent_list.end ();
+ pit++)
+      {
+ Octave_map::const_iterator smap = map.seek (*pit);
+  
+ const Cell& tmp = smap->second;
 
-      std::list<std::string>::iterator
- p = find (parent_list.begin (), parent_list.end (), parent_class_name);
+ octave_value vtmp = tmp(0);
 
-      if (p != parent_list.end ())
- {
-  Octave_map::const_iterator pmap = map.seek (parent_class_name);
+ octave_base_value *obvp = vtmp.internal_rep ();
 
-  if (pmap != map.end ())
-    {
-      const Cell& tmp = pmap->second;
+ retval = obvp->find_parent_class (parent_class_name);
 
-      octave_value vtmp = tmp(0);
-
-      retval = vtmp.internal_rep ();
-    }
- }
-      else
- {
-  for (std::list<std::string>::iterator pit = parent_list.begin ();
-       pit != parent_list.end ();
-       pit++)
-    {
-      Octave_map::const_iterator smap = map.seek (*pit);
-
-      const Cell& tmp = smap->second;
-
-      octave_value vtmp = tmp(0);
-
-      octave_base_value *obvp = vtmp.internal_rep ();
-
-      retval = obvp->find_parent_class (parent_class_name);
-
-      if (retval)
- break;
-    }
- }
-    }
+ if (retval)
+  break;
+      }
 
   return retval;
 }
@@ -628,7 +606,21 @@
 
     std::string key = key_idx(0).string_value ();
 
-    map.assign (key, t_rhs);
+    // FIXME -- Is there a "proper" way to do this?
+    octave_function* fcn = octave_call_stack::current ();
+    std::string my_dir = fcn->dir_name ();
+    int ipos = my_dir.find_last_of ("@");
+    std::string method_class = my_dir.substr (ipos+1);
+
+    // Find the class in which this method resides before
+    // attempting to access the requested field.
+
+    octave_base_value *obvp = find_parent_class (method_class);
+
+    if (obvp==0)
+      error("malformed class");
+
+    obvp->assign (key, t_rhs);
 
     if (! error_state)
       {
@@ -1313,6 +1305,30 @@
   return retval;
 }
 
+DEFUN (__isa_parent__, args, ,
+  "-*- texinfo -*-\n\
+@deftypefn {Built-in Function} {} __isa_parent__ (@var{x})\n\
+Undocumented internal function.\n\
+@end deftypefn")
+{
+  octave_value retval;
+
+  if (args.length () == 2)
+    {
+      octave_value cls = args(0);
+      octave_value nm  = args(1);
+
+      if (cls.find_parent_class (nm.string_value ()))
+ return octave_value (true);
+      else
+       return octave_value (false);
+    }
+  else
+    print_usage ();
+
+  return retval;
+}
+
 DEFUN (__parent_classes__, args, ,
   "-*- texinfo -*-\n\
 @deftypefn {Built-in Function} {} __parent_classes__ (@var{x})\n\
diff -r 089bd295e4f7 -r 316120e00366 src/ov-class.h
--- a/src/ov-class.h Fri Mar 27 22:35:14 2009 -0700
+++ b/src/ov-class.h Sat Apr 04 10:14:58 2009 -0700
@@ -85,6 +85,9 @@
 
   static octave_value numeric_conv (const Cell& val,
     const std::string& type);
+
+  void assign(const std::string& k, const octave_value& rhs)
+  { map.assign (k, rhs); };
 
   octave_value subsasgn (const std::string& type,
  const std::list<octave_value_list>& idx,
diff -r 089bd295e4f7 -r 316120e00366 src/variables.cc
--- a/src/variables.cc Fri Mar 27 22:35:14 2009 -0700
+++ b/src/variables.cc Sat Apr 04 10:14:58 2009 -0700
@@ -408,7 +408,7 @@
       if (! retval
   && var_ok
   && (type == "any" || type == "var")
-  && val.is_constant ())
+  && (val.is_constant () || val.is_object ()))
  {
   retval = 1;
  }

classTest.tgz (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Interesting plot behavior

Robert T. Short
In reply to this post by John W. Eaton
I use scatter plots regularly in my work, usually with thousands or tens
of thousands of points.

This little script is a trivial example:


N = 2^14;
stddev = 0.1;

q = 2*((floor(4*rand(N,1))-1.5) + i*(floor(4*rand(N,1))-1.5));
n = stddev*(randn(N,1) + i*randn(N,1));
m =  q + n;
%scatter(real(m),imag(m), 1, 'g');
plot(real(m),imag(m), ".g;;");
axis("square");

Using scatter and tic/toc, it takes 120 seconds to display 2^14 points
but using plot it is so quick I can't really measure it.

This table gives the times (time until the plot is actually displayed)
as a function of "N"

2^10  3 seconds
2^11  6 seconds
2^12  14 seconds
2^13  41 seconds
2^14  120 seconds



This was done with octave 3.0, but I get similar behavior using the tip
(cloned and built yesterday)

Bob
--
Robert T. Short
PhaseLocked Systems


12