octave-dev

Re: [OctDev] new release?

[Dirk E. <ed...@de...>]

On Sat, Jul 03, 2004 at 01:27:07PM -0400, Paul Kienzle wrote:
> Will it cause problems for you if the build succeeds even
> when it fails?  That is, if I put in the -k business so that
> people can ignore things that don't build on their architecture
> unless they really need them, it won't generate an exit
> status on Debian builds.

Well, I'd rather have it succeed in the first place for me. 

> On second thought, I can put in a make parameter such as:
> 	make STOP=1
> Use this if you want to build and stop at the first error.  If
> nobody disagrees, that's what I will do.  I'll skip the nice
> report of what doesn't build for now.

I think I can also make it fault tolerant at my level because debian/rules,
a makefile, can call 'make' as '-make' and even if your make failed, it
would continue.

But I think that would open a can of worms. We need to decide between you
and me what we think will build under Debian, and then just build it. On
i386 and all other ten or eleven arches, if possible.

Dirk

-- 
White House officials praised the performance of the controversial 
new Diebold electronic voting machines, which successfully tabulated 
final results from Florida before a single vote was cast.
          -- Andy Borowitz, http://borowitzreport.com, 29 June 2004

Re: [OctDev] new release?

[Steve L. <vo...@de...>]

On Mon, Jun 21, 2004 at 04:47:23PM +0200, Rafael Laboissiere wrote:
> The problem is that there are circular dependencies between the new hdf5
> packages and lots of others (including octave2.1, octave-forge and
> octave-plplot).  This can be seen at:

>     http://bjorn.haxx.se/debian/testing.pl?package=3Dhdf5

> The only way to fix this dead-lock situation is by manually adding a hint=
 to
> the program that promotes packages from unstable to testing (britney).  T=
he
> hints can be seen at:

>     http://ftp-master.debian.org/testing/hints/

> One thing that complicates the situation is that the number of packages
> involved is quite high and new versions are constantly uploaded to unstab=
le.
> Since the 10-days rule must be obeyed, the joint promotion of all packages
> keep being delayed.

> Should we impose a freeze on the involved packages until they get all
> together into testing?

I would appreciate this.  It's unfortunate to see that plplot has
recently reset the clock on testing propagation for these packages; it
looks like octave2.1 is very close to being ready, since it has been
built on m68k and alpha and it's just a question of prodding the buildd
admins into getting those packages uploaded.

Since the clock has been reset, I don't see any reason a new
octave-forge upload should be a problem, if it's done soon; of course,
if there are architecture-specific problems getting octave-forge ready,
this does not hold true.  You might also consider using an upload
priority of "medium" here, to help prevent delays, or else just hold off
for 8 days before uploading.

> [ N.B.: Steve Langasek is one of the ftp-admins who is helping us with th=
is
>   issue.  Josselin Mouette is the maintainer of the Debian hdf5 packages.=
  I
>   am CC:ing this message to them.  ]

Release assistant, not ftp-admin.  Please don't mistake me for someone
with direct authority over the archive. :)

Cheers,
--=20
Steve Langasek
postmodern programmer

Re: [OctDev] new release?

[Rafael L. <ra...@de...>]

* Steve Langasek <vo...@de...> [2004-06-21 11:33]:

> On Mon, Jun 21, 2004 at 04:47:23PM +0200, Rafael Laboissiere wrote:
> > The problem is that there are circular dependencies between the new hdf5
> > packages and lots of others (including octave2.1, octave-forge and
> > octave-plplot).  This can be seen at:
> 
> >     http://bjorn.haxx.se/debian/testing.pl?package=hdf5
> 
> > The only way to fix this dead-lock situation is by manually adding a hint to
> > the program that promotes packages from unstable to testing (britney).  The
> > hints can be seen at:
> 
> >     http://ftp-master.debian.org/testing/hints/
> 
> > One thing that complicates the situation is that the number of packages
> > involved is quite high and new versions are constantly uploaded to unstable.
> > Since the 10-days rule must be obeyed, the joint promotion of all packages
> > keep being delayed.
> 
> > Should we impose a freeze on the involved packages until they get all
> > together into testing?
> 
> I would appreciate this.  It's unfortunate to see that plplot has
> recently reset the clock on testing propagation for these packages; [...]

Mea culpa.

> [...] it looks like octave2.1 is very close to being ready, since it has
> been built on m68k and alpha and it's just a question of prodding the
> buildd admins into getting those packages uploaded.
> 
> Since the clock has been reset, I don't see any reason a new
> octave-forge upload should be a problem, if it's done soon; of course,
> if there are architecture-specific problems getting octave-forge ready,
> this does not hold true.  You might also consider using an upload
> priority of "medium" here, to help prevent delays, or else just hold off
> for 8 days before uploading.

The use of hold off is perhaps a good idea.  Here is the list of source
packages concerned by the eventual freeze (this message is being Cc:ed to
their maintainers):

    hdf5 (J. Mouette)
    mpb (J. Mouette)
    pytables (F. Alted)
    octave2.1 (D. Eddelbuetel)
    octave-forge (D. Eddelbuetel)
    plplot (R. Laboissiere)
    statdataml (R. Laboissiere)

I think that in seven days from now everything will be stabilized (plplot
already successfully built on all architectures), unless new versions of
octave2.1 and octave-forge are uploaded to unstable.

When establishing the hint, you will probably have to take care of the
following packages:

    octave-gpc (R. Laboissiere)
    octave-sp (D. Eddelbuetel)

which would be made uninstallable by the upgrade of hdf5.    

> Release assistant, not ftp-admin.  Please don't mistake me for someone
> with direct authority over the archive. :)

Okay, I will not blame you for ftp-admin problems anymore :-)

-- 
Rafael

Re: [OctDev] new release?

[David B. <Dav...@mo...>]

Try the attached patch. It works for all of the test cases you propose he=
re.
Just a stupid little bug it seems.. This patch is applied to the CVS

Cheers
David

Dapr=E8s Quentin Spencer <qsp...@ie...> (le 18/06/2004):
> OK, I tested your changes to the coding stuff and this is what I found:
>=20
> bchpoly appears to give correct results for the cases I tested
> cyclgen(255,bchpoly(255,247)) gives the correct result
> cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> first 8x8 submatrix, and zeros everywhere else !?
> cyclpoly gives a vector containing all zeros for every input I tried.
>=20
> Well, I guess there's at least some progress since one case worked. I'm
> sorry the news isn't better.
>=20
> -Quentin
>=20
>=20
> David Bateman wrote:
>=20
> >According to Quentin Spencer <qsp...@ie...> (on 06/16/04):
> >=20
> >
> >>David,
> >>
> >>Thanks. The updates fixed hammgen. However, now I've found another bu=
g.=20
> >>I don't know if it was there all along or newly introduced. The=20
> >>following command should produce the 16x255 parity check matrix for a=
=20
> >>BCH 2-error correcting code:
> >>cyclgen(255,bchpoly(255,239))
> >>
> >>The result instead is:
> >>error: cyclgen: generator polynomial does not produce cyclic code
> >>
> >>I verified the resulting polynomial against MATLAB and they matched.
> >>  =20
> >>
> >
> >Ok, I'm a bit draft. The test I added checks if the polynomial is prim=
itive
> >rather than just irreducible. I'd previously tried to adapt this test =
in
> >the older code, but failed.
> >
> >So I went back to the basic implementation of dividing x^n-1 by the
> >polynomial and checking that there was no remainder. It appears to
> >work correctly for you test case now. Though maybe you want to give
> >it a bit more testing.. Changes checked into the CVS
> >
> >Regards
> >David
> >
> >=20
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:=20

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

Re: [OctDev] new release?

[Quentin S. <qsp...@ie...>]

I just returned from vacation and noticed that CVS contained several 
updates to the files in question in my previous mail below. I'm happy to 
report that cyclgen appears to work properly for the inputs that I 
tested. I also tested cyclpoly and discovered that when compared to the 
ouput of the same function in Matlab, the results are the same but 
appear in reverse order, i.e. fliplr(cyclgen(255,247)) is equivalent to 
cyclgen(255,247) in Matlab. Thank you for all the work you have done in 
fixing these functions.

-Quentin



Quentin Spencer wrote:

> OK, I tested your changes to the coding stuff and this is what I found:
>
> bchpoly appears to give correct results for the cases I tested
> cyclgen(255,bchpoly(255,247)) gives the correct result
> cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> first 8x8 submatrix, and zeros everywhere else !?
> cyclpoly gives a vector containing all zeros for every input I tried.
>
> Well, I guess there's at least some progress since one case worked. I'm
> sorry the news isn't better.
>
> -Quentin
>
>
> David Bateman wrote:
>
>> According to Quentin Spencer <qsp...@ie...> (on 06/16/04):
>>
>>> David,
>>>
>>> Thanks. The updates fixed hammgen. However, now I've found another 
>>> bug. I don't know if it was there all along or newly introduced. The 
>>> following command should produce the 16x255 parity check matrix for 
>>> a BCH 2-error correcting code:
>>> cyclgen(255,bchpoly(255,239))
>>>
>>> The result instead is:
>>> error: cyclgen: generator polynomial does not produce cyclic code
>>>
>>> I verified the resulting polynomial against MATLAB and they matched.
>>
>> Ok, I'm a bit draft. The test I added checks if the polynomial is 
>> primitive
>> rather than just irreducible. I'd previously tried to adapt this test in
>> the older code, but failed.
>>
>> So I went back to the basic implementation of dividing x^n-1 by the
>> polynomial and checking that there was no remainder. It appears to
>> work correctly for you test case now. Though maybe you want to give
>> it a bit more testing.. Changes checked into the CVS
>>
>> Regards
>> David
>

Re: [OctDev] new release?

[David B. <Dav...@mo...>]

Quentin,

The reason for the reversal is a stupidity in matlab. I can't remember
the details offhand but I believe hammgen and cyclgen return the matrices
in reverse order. Similarly the polynomials with cyclpoly are reversed...
I tried to keep the functions consistent with each other, so that they
might be used interchangably.

Regards
David

According to Quentin Spencer <qsp...@ie...> (on 07/06/04):
> I just returned from vacation and noticed that CVS contained several 
> updates to the files in question in my previous mail below. I'm happy to 
> report that cyclgen appears to work properly for the inputs that I 
> tested. I also tested cyclpoly and discovered that when compared to the 
> ouput of the same function in Matlab, the results are the same but 
> appear in reverse order, i.e. fliplr(cyclgen(255,247)) is equivalent to 
> cyclgen(255,247) in Matlab. Thank you for all the work you have done in 
> fixing these functions.
> 
> -Quentin
> 
> 
> 
> Quentin Spencer wrote:
> 
> >OK, I tested your changes to the coding stuff and this is what I found:
> >
> >bchpoly appears to give correct results for the cases I tested
> >cyclgen(255,bchpoly(255,247)) gives the correct result
> >cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> >first 8x8 submatrix, and zeros everywhere else !?
> >cyclpoly gives a vector containing all zeros for every input I tried.
> >
> >Well, I guess there's at least some progress since one case worked. I'm
> >sorry the news isn't better.
> >
> >-Quentin
> >
> >
> >David Bateman wrote:
> >
> >>According to Quentin Spencer <qsp...@ie...> (on 06/16/04):
> >>
> >>>David,
> >>>
> >>>Thanks. The updates fixed hammgen. However, now I've found another 
> >>>bug. I don't know if it was there all along or newly introduced. The 
> >>>following command should produce the 16x255 parity check matrix for 
> >>>a BCH 2-error correcting code:
> >>>cyclgen(255,bchpoly(255,239))
> >>>
> >>>The result instead is:
> >>>error: cyclgen: generator polynomial does not produce cyclic code
> >>>
> >>>I verified the resulting polynomial against MATLAB and they matched.
> >>
> >>Ok, I'm a bit draft. The test I added checks if the polynomial is 
> >>primitive
> >>rather than just irreducible. I'd previously tried to adapt this test in
> >>the older code, but failed.
> >>
> >>So I went back to the basic implementation of dividing x^n-1 by the
> >>polynomial and checking that there was no remainder. It appears to
> >>work correctly for you test case now. Though maybe you want to give
> >>it a bit more testing.. Changes checked into the CVS
> >>
> >>Regards
> >>David
> >

-- 
David Bateman                                Dav...@mo...
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

Re: [OctDev] new release?

[Etienne G. <et...@cs...>]

  Hi all,

just to say that I fixed minimize(), test_min_[1-4] and
test_minimize_1 so that they use bfgsmin() instead of bfgs().

  I should still do some list -> cell work, but that will wait a
little more.

  Cheers,

  Etienne

On Mon, Jun 14, 2004 at 06:37:58PM -0400, Paul Kienzle wrote:
# I would like make a new octave-forge release.  Please let me
# know when you all are ready.
# 
# - Paul
# 
# 
# 
# -------------------------------------------------------
# This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
# Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
# Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
# REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] new release?

[Etienne G. <et...@is...>]

  Hello,

maybe we could put an entry for 'vmesh' in the INDEX file, under
'Surface plots'.

  Cheers,

  Etienne

On Thu, May 15, 2003 at 05:34:35PM -0400, Paul Kienzle wrote:
# All,
# 
# We need a new release to support octave-2.1.48 since
# OCTAVE_LOCAL_BUFFER now requires #include <memory>.
# I've updated the half-dozen files that require it
# (inc. comm/gf.cc and sparse/make_sparse.h).
# 
# Here is my take on the changes since the last release.
# Please correct any errors in octave-forge/RELEASE-NOTES 
# 
# * Support for octave 2.1.36-2.1.48.
# 
# * Communications:
#   - sqrt over Galois field
#   - BCH code, modulator
#   - bug fixes and documentation improvements
# 
# * Image:
#   - add rotate_scale()
# 
# * Optimization:
#   - add Nick Higham's adsmax, mdsmax nmsmax for fmins
#   - lp() fix range error
# 
# * Plotting:
#   - surf()/surfc() support gnuplot 3.8i shaded surfaces
#   - add peaks()
#   - legend() inside/ouside/boxon/boxoff/right/left
# 
# * Signal Processing
#   - return statespace and laplacian IIR filters (butter, cheby1, cheby2, ellip)
#   - fix aryule
# 
# * Statistics:
#   - add normplot()
#   - scatter() optimization
# 
# * Symbolic:
#   - added poly2sym, sym2poly, numden, findsymbols, findsym, symlsolve,
#     symfsolve, syminfo
#   - subs() accepts cell arrays
# 
# * TSA/NaN:
#   - many bug fixes and documentation improvements
#   - quantiles -> Quantile
# 
# * Miscellaneous:
#   - add cellstr()
#   - fieldnames() now returns cell array
#   - listen() bugfixes
#   - ellipke() supports m < 0
#   - extend deal() to handle [a,b] = deal(b,a)
#   - dlmread() converted to C++ for speed and more flexible input
# 
# * administration:
#   - target specific build instructions (MacOSX, windows, Irix)
# 
# 
# 
# -------------------------------------------------------
# Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
# The only event dedicated to issues related to Linux enterprise solutions
# www.enterpriselinuxforum.com
# 
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev
# 
# 

-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

Re: [OctDev] new release?

[Per P. <per...@ma...>]

On Thursday, May 15, 2003, at 11:34 PM, Paul Kienzle wrote:
> * Communications:
>   - sqrt over Galois field
>   - BCH code, modulator
>   - bug fixes and documentation improvements

I'm still having a problem with the install_doc target in 
main/comms/Makefile on OS X (described in a previous mail).

>
> * administration:
>   - target specific build instructions (MacOSX, windows, Irix)
>

Could someone confirm that the following patches are OK on non-OSX 
systems (and generally acceptable)?

/Per


Index: configure.base
===================================================================
RCS file: /cvsroot/octave/octave-forge/configure.base,v
retrieving revision 1.14
diff -u -w -r1.14 configure.base
--- configure.base      15 May 2003 16:05:50 -0000      1.14
+++ configure.base      21 May 2003 18:31:12 -0000
@@ -224,6 +224,15 @@
  AC_PROG_INSTALL
  AC_PROG_RANLIB

+dnl Use $(COPY_FLAGS) to set options for cp when installing .oct files.
+COPY_FLAGS="-fdp"
+case "$canonical_host_type" in
+    powerpc-apple-darwin*)
+        COPY_FLAGS="-Rfp"
+    ;;
+esac
+AC_SUBST(COPY_FLAGS)
+
  dnl Use $(STRIP) in the makefile to strip executables.  If not found,
  dnl STRIP expands to ':', which in the makefile does nothing.
  dnl Don't need this for .oct files since mkoctfile handles them 
directly

Index: octinst.sh.in
===================================================================
RCS file: /cvsroot/octave/octave-forge/octinst.sh.in,v
retrieving revision 1.4
diff -u -w -r1.4 octinst.sh.in
--- octinst.sh.in       9 Mar 2003 02:34:44 -0000       1.4
+++ octinst.sh.in       21 May 2003 18:56:57 -0000
@@ -21,6 +21,7 @@
  INSTALL_DATA="@INSTALL_DATA@"
  INSTALL_PROGRAM="@INSTALL_PROGRAM@"
  MKPKGADD="@TOPDIR@/admin/mkpkgadd"
+COPY_FLAGS="@COPY_FLAGS@"

  # grab the m-files
  files=`echo $source/*.m`
@@ -34,7 +35,7 @@
  if test "$files" != "$source/*.oct" ; then
      $INSTALL -d $opath
  ## Grrr... install doesn't preserve links.  Hope this works.
-    cp -fdp $files $opath
+    cp $COPY_FLAGS $files $opath
  fi

  # create PKG_ADD


------------
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications

www:   http://www.its.bth.se/staff/pee
e-mail: per...@bt...

Re: [OctDev] new release?

[Paul K. <pki...@ja...>]

On Wed, May 21, 2003 at 09:08:32PM +0200, Per Persson wrote:
> On Thursday, May 15, 2003, at 11:34 PM, Paul Kienzle wrote:
> >
> > * administration:
> >   - target specific build instructions (MacOSX, windows, Irix)
> >
> 
> Could someone confirm that the following patches are OK on non-OSX 
> systems (and generally acceptable)?

They look fine (but I haven't tested them) and are acceptable short term.

Longer term I should figure out a better way of indicating which links to
make at install time rather than trying to copy the linked files.

Really long term, Octave should have a better way to indicate that routine
xxx is located in object file yyy rather than relying on symbolic links in
the file system, but that's a topic for another list.

- Paul