gui-release branch CLOSED

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

gui-release branch CLOSED

John W. Eaton
Administrator
After the following discussion, I've closed the gui-release branch.

 
http://lists.gnu.org/archive/html/octave-maintainers/2015-01/msg00226.html

and

 
http://lists.gnu.org/archive/html/octave-maintainers/2015-01/msg00226.html

Please make all bug fixes and enhancements on the default branch now.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: gui-release branch CLOSED

Daniel Sebald
On 01/30/2015 07:16 PM, John W. Eaton wrote:

> After the following discussion, I've closed the gui-release branch.
>
>
> http://lists.gnu.org/archive/html/octave-maintainers/2015-01/msg00226.html
>
> and
>
>
> http://lists.gnu.org/archive/html/octave-maintainers/2015-01/msg00226.html
>
> Please make all bug fixes and enhancements on the default branch now.

OK, I'm trying things out here...

Why is the "make install" taking so long?  It used to take just ten
seconds or so, but now it takes over a minute doing all sorts of library
operations like, what looks like, linking and reinstalling.  Is it just
me with some outdated tools?

The default build now comes up as 4.1.0+.  A few posts back was some
mention about the next release being 4.0.0.  What is the next version
and where in the source tree will it be?  Is stable?

So I understand what this classdef issue is, what are we to be watching
out for in terms of bugs?  Here's one thing I notice at startup:

warning: strmatch is obsolete and will be removed from a future version
of Octave,please use strncmp, strcmp, or regexp instead
warning: called from
     strmatch at line 63 column 5
     unique at line 53 column 16
     installed_packages at line 44 column 10
     load_packages at line 26 column 22
     pkg at line 419 column 7
     /usr/local/share/octave/4.1.0+/m/startup/octaverc at line 20 column 1

Is this related to classdef (Rik gave an example of a strfind error)?
Line 20 of the default startup is:

pkg ("load", "auto");

Dan

A side comment after looking at the HTML graph in the repository:  I
generally like the HTML interface for Mercurial, but I sure wish the
graph feature had a key to go along with the color-coded branches.  I
know that the branch names appear next to the changesets, but I can't
ever seem to make sense of what the connections are in the branch graph.
  On the other hand, TortoiseHg has a graph that is a much clearer
depiction of what is happening.  It lists the branch name in color and
uses a color dot that coincides with that branch name.

Reply | Threaded
Open this post in threaded view
|

Re: gui-release branch CLOSED

John W. Eaton
Administrator
On 01/30/2015 08:29 PM, Daniel J Sebald wrote:

> Why is the "make install" taking so long?  It used to take just ten
> seconds or so, but now it takes over a minute doing all sorts of library
> operations like, what looks like, linking and reinstalling.  Is it just
> me with some outdated tools?

That's what libtool does.

> The default build now comes up as 4.1.0+.

Not for me.  For me, the version on the default branch is now 3.9.0+.

Aha.  The problem is that I didn't push all my changes.  I thought I
had, but it didn't happen because the "@" bookmark didn't advance for
the last operations I did.  In any case, I've done that now.  Update and
you should see two more changesets from me.

> A few posts back was some
> mention about the next release being 4.0.0.  What is the next version
> and where in the source tree will it be?  Is stable?

Just before the next release, the default branch will be merged to (and
become) the stable branch.  When the release is made, the version number
will be set to 4.0.0.

> So I understand what this classdef issue is, what are we to be watching
> out for in terms of bugs?  Here's one thing I notice at startup:
>
> warning: strmatch is obsolete and will be removed from a future version
> of Octave,please use strncmp, strcmp, or regexp instead
> warning: called from
>      strmatch at line 63 column 5
>      unique at line 53 column 16
>      installed_packages at line 44 column 10
>      load_packages at line 26 column 22
>      pkg at line 419 column 7
>      /usr/local/share/octave/4.1.0+/m/startup/octaverc at line 20 column 1

I don't see that.  I have no idea why it is happening for you.

> A side comment after looking at the HTML graph in the repository:  I
> generally like the HTML interface for Mercurial, but I sure wish the
> graph feature had a key to go along with the color-coded branches.  I
> know that the branch names appear next to the changesets, but I can't
> ever seem to make sense of what the connections are in the branch graph.
>   On the other hand, TortoiseHg has a graph that is a much clearer
> depiction of what is happening.  It lists the branch name in color and
> uses a color dot that coincides with that branch name.

Use TortoiseHg if you like it better.  Or help to fix the web interface
for mercurial (and get a newer version installed on savannah).  These
problems are not really Octave issues, are they?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: gui-release branch CLOSED

Daniel Sebald
On 01/30/2015 07:49 PM, John W. Eaton wrote:

> On 01/30/2015 08:29 PM, Daniel J Sebald wrote:
>
>> Why is the "make install" taking so long? It used to take just ten
>> seconds or so, but now it takes over a minute doing all sorts of library
>> operations like, what looks like, linking and reinstalling. Is it just
>> me with some outdated tools?
>
> That's what libtool does.
>
>> The default build now comes up as 4.1.0+.
>
> Not for me. For me, the version on the default branch is now 3.9.0+.
>
> Aha. The problem is that I didn't push all my changes. I thought I had,
> but it didn't happen because the "@" bookmark didn't advance for the
> last operations I did. In any case, I've done that now. Update and you
> should see two more changesets from me.
>
>> A few posts back was some
>> mention about the next release being 4.0.0. What is the next version
>> and where in the source tree will it be? Is stable?
>
> Just before the next release, the default branch will be merged to (and
> become) the stable branch. When the release is made, the version number
> will be set to 4.0.0.

OK, updated and compiled.  I see 3.9.0+ now.


>> warning: strmatch is obsolete and will be removed from a future version
>> of Octave,please use strncmp, strcmp, or regexp instead
>> warning: called from
>> strmatch at line 63 column 5
>> unique at line 53 column 16
>> installed_packages at line 44 column 10
>> load_packages at line 26 column 22
>> pkg at line 419 column 7
>> /usr/local/share/octave/4.1.0+/m/startup/octaverc at line 20 column 1
>
> I don't see that. I have no idea why it is happening for you.

Some cruft on my system from modifying unique.m tests long ago.  The
warning did its job.

...

One bug when attempting to print, which wants a temporary file.
"tempname.m" and "tmpnam.m" recursively call one another:

>> which tempname
'tempname' is a function from the file
/usr/local/share/octave/3.9.0+/m/miscellaneous/tempname.m
>> which tmpnam
'tmpnam' is a function from the file
/usr/local/share/octave/3.9.0+/m/miscellaneous/tmpnam.m
>> tempname
error: max_recursion_depth exceeded
error: called from
     tmpnam at line 43 column 12
     tempname at line 29 column 12
     tmpnam at line 43 column 12
     tempname at line 29 column 12
[etc]

Is one of these functions something that was in the deprecated list?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: gui-release branch CLOSED

Daniel Sebald
On 01/30/2015 09:07 PM, Daniel J Sebald wrote:

> One bug when attempting to print, which wants a temporary file.
> "tempname.m" and "tmpnam.m" recursively call one another:
>
>>> which tempname
> 'tempname' is a function from the file
> /usr/local/share/octave/3.9.0+/m/miscellaneous/tempname.m
>>> which tmpnam
> 'tmpnam' is a function from the file
> /usr/local/share/octave/3.9.0+/m/miscellaneous/tmpnam.m
>>> tempname
> error: max_recursion_depth exceeded
> error: called from
> tmpnam at line 43 column 12
> tempname at line 29 column 12
> tmpnam at line 43 column 12
> tempname at line 29 column 12
> [etc]
>
> Is one of these functions something that was in the deprecated list?

Oops, more cruft.  Rolling back the version number to 3.9.0+ corresponds
to some old library files from a previous installation.  Fixed after
wiping all of the /usr/local/share/octave/3.9.0+ directory and reinstalling.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: gui-release branch CLOSED

Michael Godfrey

On 01/30/2015 10:24 PM, Daniel J Sebald wrote:
> Oops, more cruft.  Rolling back the version number to 3.9.0+
> corresponds to some old library files from a previous installation.  
> Fixed after wiping all of the /usr/local/share/octave/3.9.0+ directory
> and reinstalling.
>

cd /usr/local
find . -iname octave\* -print -follow

will likely find quite a lot more "leftover" versions of octave components.