2.1.64 snapshot soon?

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

2.1.64 snapshot soon?

John W. Eaton-6
I'm preparing to make a 2.1.64 snapshot that will be declared
"testing" or "recommended".  There haven't been too many bugs
reported, but at least one was fairly serious (the "end" indexing
problem for some data types).  I think most problems reported since
the 2.1.63 snapshot was made have been fixed.  Is anyone aware of a
problem that still needs to be addressed?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: 2.1.64 snapshot soon?

David Bateman-3
Daprès John W. Eaton <[hidden email]> (le 03/12/2004):
> I'm preparing to make a 2.1.64 snapshot that will be declared
> "testing" or "recommended".  There haven't been too many bugs
> reported, but at least one was fairly serious (the "end" indexing
> problem for some data types).  I think most problems reported since
> the 2.1.63 snapshot was made have been fixed.  Is anyone aware of a
> problem that still needs to be addressed?

I don't know of any. Though I can't even remember the end indexing bug,
was that the sscanf bug in

http://www.octave.org/mailing-lists/bug-octave/2004/861

Cheers
David

--
David Bateman                                [hidden email]
Motorola CRM                                 +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

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


Reply | Threaded
Open this post in threaded view
|

Re: 2.1.64 snapshot soon?

Per Persson
In reply to this post by John W. Eaton-6

On Dec 3, 2004, at 06:11, John W. Eaton wrote:

> I'm preparing to make a 2.1.64 snapshot that will be declared
> "testing" or "recommended".  There haven't been too many bugs
> reported, but at least one was fairly serious (the "end" indexing
> problem for some data types).  I think most problems reported since
> the 2.1.63 snapshot was made have been fixed.  Is anyone aware of a
> problem that still needs to be addressed?

I'm running
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.3.6
BuildVersion:   7R28
$ uname -v
Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004;
root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC
$ autoconf --version
autoconf (GNU Autoconf) 2.59
$ gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671)
$ gperf --version
GNU gperf 2.7.2
$ flex --version
flex 2.5.31

Configured with
--enable-shared --disable-static --enable-dl --with-f77=xlf
I get the following error:


g++ -c  -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob
-I../glob -DHAVE_CONFIG_H  -Wall -W -Wshadow -g -O2 lex.cc -o lex.o
In file included from lex.l:76:
oct-gperf.h:62: warning: ISO C++ forbids declaration of `in_word_set'
with no
    type
oct-gperf.h:100: warning: ISO C++ forbids declaration of `wordlist'
with no
    type
oct-gperf.h:139: error: brace-enclosed initializer used to initialize
`const
    int'
[snipping many similar]
oct-gperf.h:139: error: brace-enclosed initializer used to initialize
`const
    int'
oct-gperf.h:155: warning: ISO C++ forbids declaration of `in_word_set'
with no
    type
oct-gperf.h: In static member function `static const int*
    octave_kw_hash::in_word_set(const char*, unsigned int)':
oct-gperf.h:166: error: request for member `name' in `wordlist[index]',
which
    is of non-class type `const int'
oct-gperf.h:174: warning: ISO C++ forbids declaration of `wordptr' with
no type
oct-gperf.h:175: warning: ISO C++ forbids declaration of `wordendptr'
with no
    type
oct-gperf.h:179: error: request for member `name' in `*wordptr', which
is of
    non-class type `const int'
lex.l: In function `int is_keyword_token(const std::string&)':
lex.l:1217: error: cannot convert `const int*' to `const octave_kw*' in
    initialization
lex.l: In function `octave_value_list Fiskeyword(const
octave_value_list&, int)
    ':
lex.l:2716: error: request for member `name' in `wordlist[i]', which is
of
    non-class type `const int'
make[2]: *** [lex.o] Error 1
make[1]: *** [src] Error 2
make: *** [all] Error 2


I had some warnings when running autogen.sh, but I think they are
benign:


$ ./autogen.sh
calling autoconf and autoheader...
/Users/per/Source/octave
configure.in:504: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
autoconf/lang.m4:224: AC_LANG_SOURCE is expanded from...
autoconf/lang.m4:234: AC_LANG_PROGRAM is expanded from...
autoconf/general.m4:2215: AC_LINK_IFELSE is expanded from...
autoconf/general.m4:2223: AC_TRY_LINK is expanded from...
autoconf/general.m4:1799: AC_CACHE_VAL is expanded from...
aclocal.m4:414: OCTAVE_F77_FLAG is expanded from...
configure.in:504: the top level
configure.in:510: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
configure.in:510: the top level
configure.in:512: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
configure.in:512: the top level
configure.in:513: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
configure.in:513: the top level
configure.in:504: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
autoconf/lang.m4:224: AC_LANG_SOURCE is expanded from...
autoconf/lang.m4:234: AC_LANG_PROGRAM is expanded from...
autoconf/general.m4:2215: AC_LINK_IFELSE is expanded from...
autoconf/general.m4:2223: AC_TRY_LINK is expanded from...
autoconf/general.m4:1799: AC_CACHE_VAL is expanded from...
aclocal.m4:414: OCTAVE_F77_FLAG is expanded from...
configure.in:504: the top level
configure.in:510: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
configure.in:510: the top level
configure.in:512: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
configure.in:512: the top level
configure.in:513: warning: AC_LANG_PROGRAM(Fortran 77): ignoring
PROLOGUE: []
configure.in:513: the top level
/Users/per/Source/octave/glob
/Users/per/Source/octave/scripts
skipping autoheader in ./scripts
done


I haven't been following development closely for a while so maybe it is
just a matter of bad piloting. I'm investigating right now, thought I'd
just drop you a note.


/Per


Reply | Threaded
Open this post in threaded view
|

Re: 2.1.64 snapshot soon?

Per Persson

On Dec 3, 2004, at 12:02, Per Persson wrote:

>
> On Dec 3, 2004, at 06:11, John W. Eaton wrote:
>
>> I'm preparing to make a 2.1.64 snapshot that will be declared
>> "testing" or "recommended".  There haven't been too many bugs
>> reported, but at least one was fairly serious (the "end" indexing
>> problem for some data types).  I think most problems reported since
>> the 2.1.63 snapshot was made have been fixed.  Is anyone aware of a
>> problem that still needs to be addressed?

[snip]

> $ gperf --version
> GNU gperf 2.7.2

Upgrading to gperf 3.0.1 solved the problem. I suppose that Makefile.in
and aclocal.m4 should be updated to reflect the requirements, but that
is not a problem for a snapshot.

Make check reports the following failures:
FAIL: octave.test/io/fopen-1.m
FAIL: octave.test/io/binary-io-1.m
FAIL: octave.test/string/num2str-1.m
FAIL: octave.test/string/deblank-1.m

No time to dig deeper right now :-(

/Per


Reply | Threaded
Open this post in threaded view
|

Re: 2.1.64 snapshot soon?

David Bateman-3
Daprès Per Persson <[hidden email]> (le 03/12/2004):

>
> On Dec 3, 2004, at 12:02, Per Persson wrote:
>
> >
> >On Dec 3, 2004, at 06:11, John W. Eaton wrote:
> >
> >>I'm preparing to make a 2.1.64 snapshot that will be declared
> >>"testing" or "recommended".  There haven't been too many bugs
> >>reported, but at least one was fairly serious (the "end" indexing
> >>problem for some data types).  I think most problems reported since
> >>the 2.1.63 snapshot was made have been fixed.  Is anyone aware of a
> >>problem that still needs to be addressed?
>
> [snip]
>
> >$ gperf --version
> >GNU gperf 2.7.2
>
> Upgrading to gperf 3.0.1 solved the problem. I suppose that Makefile.in
> and aclocal.m4 should be updated to reflect the requirements, but that
> is not a problem for a snapshot.
>
> Make check reports the following failures:
> FAIL: octave.test/io/fopen-1.m
> FAIL: octave.test/io/binary-io-1.m
> FAIL: octave.test/string/num2str-1.m
> FAIL: octave.test/string/deblank-1.m

I think all of these are related to the change to deblank.m that went in
yesterday. I believe it is probably the tests that need updating than a
real bug..

Regards
David

--
David Bateman                                [hidden email]
Motorola CRM                                 +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

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


Reply | Threaded
Open this post in threaded view
|

Re: 2.1.64 snapshot soon?

John W. Eaton-6
In reply to this post by David Bateman-3
On  3-Dec-2004, David Bateman <[hidden email]> wrote:

| Daprès John W. Eaton <[hidden email]> (le 03/12/2004):
| > I'm preparing to make a 2.1.64 snapshot that will be declared
| > "testing" or "recommended".  There haven't been too many bugs
| > reported, but at least one was fairly serious (the "end" indexing
| > problem for some data types).  I think most problems reported since
| > the 2.1.63 snapshot was made have been fixed.  Is anyone aware of a
| > problem that still needs to be addressed?
|
| I don't know of any. Though I can't even remember the end indexing bug,
| was that the sscanf bug in
|
| http://www.octave.org/mailing-lists/bug-octave/2004/861

No, it was this problem:

  http://www.octave.org/mailing-lists/octave-maintainers/2004/877

The sscanf problem was really an indexing problem, but at least it was
not a regression for valid input...

In any case, I think both have been fixed.

jwe