octave-dev — GNU Octave developers' list

[OctDev] Help files and paging slowdown on Windows

[amar s. <ama...@ya...>]

I am using Octave on Windows, and face a problem of the computer getting hanged for half a minute or so, if I type the command help. Even the mouse does not respond. 
It also happens when output data is more than 20 lines on the console window.
(While it works very fast for normal complex processing of calculations!)
 
Anyone has a clue?
 
Thanks,
Amar


---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Re: [OctDev] convhulln options.

[Simon C. <si...@li...>]

Greetings,

Having recently worked with convhulln() and qhull I'd definitely like to
have access to qhull's options from within Octave.  The default
option set isn't appropriate for all applications and I've had to
recompile convhulln() so that it calls qhull with the options I need.

I think convhulln() should remain compatible with the Matlab version but
it would be nice to have another function (called qhull?) which allows
one to pass options through to the qhull library.

Another route would be to have some way of setting the options which
convhulln() passes to the qhull library.

Perhaps it would be best to implement both these options.  Then one
could easily modify the behaviour of convhulln() for a particular
program. The function convhulln() could then be implemented as a call to
qhull().

Schiavo
Simon
-- 
4979 486 380 (llec)   :leT	9383 056 120 (krow)
ten.az.noulg@nomis    :liam-E

Re: [OctDev] convhulln options. =?windows-1252?q?=BFDo=20we=20need=20a=20better?= implementation?

[Pedro T. <pt...@te...>]

> Thanks for this thorough example.

Just copy and paste when I was trying to understand what was going on. 
Anyway... your're welcome ;)
>
> My understanding is that Paul Kienzle fixed this problem in his last commit
> to convhulln.cc, namely by adding a Qt option to the qhull command call.

It doesn't seem to work though. Please test it with my example and if it works 
I will have to look further on the qhull libraries (I think I have the 
latest).

> More than one year ago I changed the delaunay3.m, delaunay.m, and
> delaunayn.cc files such that the associated functions would accept an extra
> (optional) argument containing additional options to the qhull command.
> This extra argument is just a string that is concatenated to the qhull
> command string.
> I think that a similar change to convhulln.cc would fit your needs.  Also,
> similar changes could be done to the voronoy functions.  Should I implement
> them?

This would be perfect. However I still don't understand how the non-simplex 
facets with non triangulated output will be imported to octave. We would need 
a matrix with as many columns as the largest number of vertices in this facet 
and define vertex 0 as non-existant, or something like...

Waiting to test the new convhulln....

Regards,
Pedro

Re: [OctDev] Octave-Forge Release??

[<pki...@us...>]

Octave-forge should be able to support the last few versions
of octave.  We almost have 2.1.51 support --- it builds in CVS.
I just need to figure out some warning messages from the 
sparse matrix type (something about complex scalar
ops being redefined).  And I want to hack something in to
run the existing script-based tests so I can have more
confidence in the release readiness.

Paul Kienzle
pki...@us...

On 23 Nov 2003 at 23:22, David Bateman wrote:

> 
> Just to point out that I committed a change to a couple of files today
> that are needed since register_type now requires that the types have a
> void constructor. Without this octave-forge won't build on the next 
> octave release. It seems that octave is adding lots of things at the
> moment that affect octave-forge. While 2.1.50 is the recommended
> release, perhaps it is better to hold-off a release of octave-forge
> till things stabilize a bit in octave itself....
> 
> Cheers
> 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
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] Re: Octave-dev digest, Vol 1 #142 - 1 msg

[<pki...@us...>]

On 21 Nov 2003 at 18:21, ta...@lb... wrote:

> Hi Paul,
> 
> Thanks for your letter.
> 
> In my mind, we have to distinguish between some things. I think that
> we should think of what we could distribute as falling into one of
> three categories:
> 
> * Octave-forge's typical contents: a mixture of M-file & OCT-files,
>   which are of general utility to Octave users.
> 
> * Octave packages, which are mainly OCT-files, that provide specific
>   functionality ( domain/application-centric ).
> 
> * General M-files that were written for Octave and/or Matlab.
> 
> To me, the CPAN equivalent that we could put together is the third; an
> organized M-file cache. For me, this is the closest to the equivalents
> of other languages ( Perl, R, Python, etc. ):
> 
> * doesn't require any environment testing aside from the version of
>   Matlab/Octave that it is running on ( well, maybe for file I/O &
>   stuff... )
> 
> * can flag packages as being tested on eithe Matlab or Octave ( or
>   both ), and which versions.
> 
> * should be fairly platform-independent.

R includes binary packages.  I don't know about python or perl.
Cantcl, when it is viable will include binary packages.  I think
binary packages should be prebuilt for Windows and possibly
linux.  Source packages with automatic build for all architectures.

Octave-forge itself would be split into 6-8 packages.  And I would
be much more willing to include domain specific packages since
they wouldn't all be installed by default, but would have a
well-defined installation process.

> ...
> 
> Okay, and here's a thornier issue that I don't know a convenient
> work-around for. Name-spaces. Perl, for example, requires you to
> specify in a script which package you'd like to use. Only then is it
> accessible. The Matlab/Octave style of doing things, correct me if I'm
> wrong, so to just extend the path to point to new M-file directories,
> and then just have the interpreter running like mad to find these
> function definitions. The point is because of the way that Octave &
> Matlab hunt for function definitions when evaluating an expression,
> the entire path's function definitions are always in scope,
> a.k.a. global scope for all functions. If we're going to start having
> people being able to download "packages/toolboxes" to install, we'd
> have to prevent name clashes, etc. 

Matlab allows you to have a 'private' subdirectory for functions
visible only within a directory.  Careful naming of private functions
accomplishes the same thing (e.g., _signal_privatefn()), while
making the signal code slightly uglier.

A more sophisticated solution would require extending octave so that
e.g., "using signal" would find the signal processing directory and
allow searches within it, but only add the names to the current
symbol table rather than the global function table.  The
toplevel would use the global function table, so any 'using'
statements in .octaverc would automatically may those functions
available to the user defined m-files.  With duplicate names,
'using' in a function would make the package function trump the
global function.  With multiple using statements, it would be either
first or last, depending on how the packages were traversed.

> 
> A hack would be to have a "package.m" file, that would extend the path
> dynamically when called with a string that had the name of a directory
> for a given package/toolbox, which would be kept in a given parent
> directory:
> 
> package("statistics");

This wouldn't work since the package definitions would continue
to exist even after the function exited.

> 
> ---
> 
> I think if we stick to M-files, it will be simpler & we'll get a *TON*
> of initial contributions. Once we have that worked out, we can move on
> to getting Octave packages into the scheme of things.
> 
> Thoughts & comments are always welcome.

Without the authors permission, we can only collect a patch and a
pointer to the package whereever it exists on the net.  Automatically
downloading the package, installing the patch, building and running
would be nice.

You won't get a *TON* of submissions since matlab package authors
already have matlab and its various distribution mechanisms.  You
either need something a lot better, or you need to do significant
work soliciting contributions from various authors.

I've find most authors are willing to let me include their
contributions, but I also have a fairly large non-response
rate.

- Paul

> On Nov 20, 2003 at 10:59pm, pki...@us... wrote:
> 
> pkienz >Date: Thu, 20 Nov 2003 22:59:46 +0000
> pkienz >From: pki...@us...
> pkienz >To: TA...@lb..., oct...@li...
> pkienz >Subject: Re: [OctDev] Re: Octave-dev digest, Vol 1 #142 - 1 msg
> pkienz >
> pkienz >I presume you mean my CPAN equivalent site.
> pkienz >
> pkienz >Source-forge itself is sufficient for distribution.  Just drop the
> pkienz >packages into the html directory, rebuild the index and serve
> pkienz >the pages statically.  I do it right now with the categorical
> pkienz >index.
> pkienz >
> pkienz >For now we can forego automation and update the packages by
> pkienz >hand.  It would mean either giving each upstream author a
> pkienz >source-forge account and trusting them not to do damage,
> pkienz >(someone other than me is mirroring the source-forge daily
> pkienz >snapshot CVS tarball, right?), or creating an octave-package
> pkienz >list where they can e-mail packages and someone who already
> pkienz >has access can package things.
> pkienz >
> pkienz >Packages will need to have a standard format, so that standard
> pkienz >tools can install the package on the system.  This is the hard
> pkienz >part.  I have not looked in detail at other packaging systems,
> pkienz >so I can't give you any suggestions, other than to keep it as 
> pkienz >simple as possible, but no simpler.
> pkienz >
> pkienz >Some possible goals:
> pkienz >
> pkienz >	* simple download and install --- may require that the user
> pkienz >	first install the install tools; must distinguish user and system
> pkienz >	installs.
> pkienz >	* tinderboxes to automatically test on different architectures
> pkienz >	and against new releases of Octave --- automatic notification
> pkienz >	to authors if the package fails.
> pkienz >	* prebuilt binaries for some architectures --- a few blessed
> pkienz >	tinderboxen can package and checksum their builds.
> pkienz >	* simple upgrade process --- when you reinstall octave you
> pkienz >	don't want to reselect all your packages by hand.
> pkienz >	* unified documentation system so the user can find out
> pkienz >	what packages are available and what they contain ---
> pkienz >	available online so you don't have to install the package to
> pkienz >	learn if you need it.
> pkienz >	* demos so that package capabilities are easier to assess.
> pkienz >	* per-package communication features --- bug and patch
> pkienz >	tracking, threaded discussion group all with e-mail gateway.
> pkienz >	* package categories --- the space of matlab add-ons is huge
> pkienz >	so a flat package list will quickly become unwieldy; expect
> pkienz >	the tree to change as the archive grows; allow for links in
> pkienz >	multiple categories.
> pkienz >	* support for Octave and Matlab from the same source
> pkienz >	build --- this will require an octave->matlab translator (I wrote
> pkienz >	one years ago which is still around somewhere) for source
> pkienz >	packages.
> pkienz >
> pkienz >matlinks.net tried to do some of these things a number of years ago.
> pkienz >
> pkienz >I think there are three keys to success: (1) make it easy to
> pkienz >find and assess packages, (2) make it easy to install and 
> pkienz >upgrade packages, and (3) have a large base of seed packages 
> pkienz >so that it is the obvious place to look  when you need 
> pkienz >something.  Once (1) and (2) are done, we will have to canvas 
> pkienz >the existing matlab package authors for permission to host 
> pkienz >their packages at our site, and be willing  to put in some effort 
> pkienz >into wrapping their packages for them.
> pkienz >
> pkienz >You tell me what we can simplify.
> pkienz >
> pkienz >Paul Kienzle
> pkienz >pki...@us...
> pkienz >
> pkienz >On 20 Nov 2003 at 19:15, ta...@lb... wrote:
> pkienz >
> pkienz >> I'm more than happy to work on such a site, but I don't have any
> pkienz >> facilities to do so. I guess I could rig up something here at my lab,
> pkienz >> but if it starts to get many hits a day, my boss might have to speak
> pkienz >> with me... :-)
> pkienz >> 
> pkienz >> I guess at that point we could switch to bevo.che.wisc.edu, or some
> pkienz >> other box?
> pkienz >> 
> pkienz >> Thanks,
> pkienz >> 
> pkienz >> ~Tomer
> pkienz >> 
> pkienz >> 
> pkienz >> 
> pkienz >> -------------------------------------------------------
> pkienz >> This SF.net email is sponsored by: SF.net Giveback Program.
> pkienz >> Does SourceForge.net help you be more productive?  Does it
> pkienz >> help you create better code?  SHARE THE LOVE, and help us help
> pkienz >> YOU!  Click Here: http://sourceforge.net/donate/
> pkienz >> _______________________________________________
> pkienz >> Octave-dev mailing list
> pkienz >> Oct...@li...
> pkienz >> https://lists.sourceforge.net/lists/listinfo/octave-dev
> pkienz >
> pkienz >
> pkienz >
> 

[OctDev] Octave-Forge Release??

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

Just to point out that I committed a change to a couple of files today
that are needed since register_type now requires that the types have a
void constructor. Without this octave-forge won't build on the next 
octave release. It seems that octave is adding lots of things at the
moment that affect octave-forge. While 2.1.50 is the recommended
release, perhaps it is better to hold-off a release of octave-forge
till things stabilize a bit in octave itself....

Cheers
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] 'fieldnames' & 'struct_elements'

[<pki...@us...>]

octave used to have struct_elements, not fieldnames.

octave-forge supplied fieldnames, but suggested using the
official octave function.

Now that octave has fieldnames, it should be removed from
octave-forge, or at least not installed by default.  I don't
want to put in the infrastructure to test for functions that
have moved into (or been reimplemented in) octave.

- Paul

On 23 Nov 2003 at 2:37, Tomer Altman wrote:

> Hi,
> 
> When I go to "Programming->Structures" through the Categorical Index
> found on the Octave Forge homepage, I find two links to "fieldnames",
> and "struct_elements", each of which seem to suggest to use the
> other. ;-)
> 
> What's the status of this package? I'd be glad to work on it, but I
> don't want to step on toes, or reinvent the wheel.
> 
> ~Tomer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] 'fieldnames' & 'struct_elements'

[Tomer A. <ta...@lb...>]

Hi,

When I go to "Programming->Structures" through the Categorical Index
found on the Octave Forge homepage, I find two links to "fieldnames",
and "struct_elements", each of which seem to suggest to use the
other. ;-)

What's the status of this package? I'd be glad to work on it, but I
don't want to step on toes, or reinvent the wheel.

~Tomer

[OctDev] 'map' function in Octave-Forge

[Tomer A. <ta...@lb...>]

Introducing 'map':

  ## usage: [ result ] = map ( FUN_STR, ARG1, ... )
  ##
  ## map, like LISP's ( & numerous other language's ) function for
  ## iterating the result of a function applied to each of the data
  ## structure's elements in turn. The results are stored in the
  ## corresponding input's place. For now, just will work with cells
  ##and
  ## matrices, but support for structs are intended for future
  ##versions.
  ## Also, only "postfix" functions ( like "min(a,b,c,..)" ) are
  ## supported.
  ##
  ## Example:
  ##
  ## octave> A
  ## A 
  ## {
  ##   [1,1] = 0.0096243
  ##   [2,1] = 0.82781
  ##   [1,2] = 0.052571
  ##   [2,2] = 0.84645
  ## }
  ## octave> B
  ## B =
  ## {
  ##   [1,1] = 0.75563
  ##   [2,1] = 0.84858
  ##   [1,2] = 0.16765
  ##   [2,2] = 0.85477
  ## }
  ## octave> map("min",A,B)
  ## ans =
  ## {
  ##   [1,1] = 0.0096243
  ##   [2,1] = 0.82781
  ##   [1,2] = 0.052571
  ##   [2,2] = 0.84645
  ## }

Uploaded to Octave-Forge:

octave-forge/main/miscellaneous

---

Cheers,

~Tomer

Re: [OctDev] convhulln =?iso-8859-1?Q?opti?= =?iso-8859-1?Q?ons=2E_=BFDo?= we need a better implementation?

[Rafael L. <rla...@us...>]

* Pedro Tarrafeta <pt...@te...> [2003-11-21 16:36]:

> This is a post to start discussing the convhulln implementation in octave.
> 
> convhulln() is a function that returns the convex hull of a set of points. It 
> is based on qhull (http://www.thesa.com/software/qhull/).
> 
> Lets start with an example to center the discussion.
> I did prepare the following script:
> 
> [...]

Thanks for this thorough example. 

> If we run it with QJ or Qt options we get triangulated output, although the 
> triangulation is different.
> 
> So... after writing this long, long brick.... Should we give some more 
> functionality to the convhulln function? (maybe giving it some other name
> for compatibility reasons). I don't understand why the new convhulln
> doesn't give also triangulated output (not trimmed rows...).

My understanding is that Paul Kienzle fixed this problem in his last commit
to convhulln.cc, namely by adding a Qt option to the qhull command call.

More than one year ago I changed the delaunay3.m, delaunay.m, and
delaunayn.cc files such that the associated functions would accept an extra
(optional) argument containing additional options to the qhull command.
This extra argument is just a string that is concatenated to the qhull
command string.

I think that a similar change to convhulln.cc would fit your needs.  Also,
similar changes could be done to the voronoy functions.  Should I implement
them?

-- 
Rafael

Re: [OctDev] Re: Octave-dev digest, Vol 1 #142 - 1 msg

[<ta...@lb...>]

Hi Paul,

Thanks for your letter.

In my mind, we have to distinguish between some things. I think that
we should think of what we could distribute as falling into one of
three categories:

* Octave-forge's typical contents: a mixture of M-file & OCT-files,
  which are of general utility to Octave users.

* Octave packages, which are mainly OCT-files, that provide specific
  functionality ( domain/application-centric ).

* General M-files that were written for Octave and/or Matlab.

To me, the CPAN equivalent that we could put together is the third; an
organized M-file cache. For me, this is the closest to the equivalents
of other languages ( Perl, R, Python, etc. ):

* doesn't require any environment testing aside from the version of
  Matlab/Octave that it is running on ( well, maybe for file I/O &
  stuff... )

* can flag packages as being tested on eithe Matlab or Octave ( or
  both ), and which versions.

* should be fairly platform-independent.

...

Okay, and here's a thornier issue that I don't know a convenient
work-around for. Name-spaces. Perl, for example, requires you to
specify in a script which package you'd like to use. Only then is it
accessible. The Matlab/Octave style of doing things, correct me if I'm
wrong, so to just extend the path to point to new M-file directories,
and then just have the interpreter running like mad to find these
function definitions. The point is because of the way that Octave &
Matlab hunt for function definitions when evaluating an expression,
the entire path's function definitions are always in scope,
a.k.a. global scope for all functions. If we're going to start having
people being able to download "packages/toolboxes" to install, we'd
have to prevent name clashes, etc. 

A hack would be to have a "package.m" file, that would extend the path
dynamically when called with a string that had the name of a directory
for a given package/toolbox, which would be kept in a given parent
directory:

package("statistics");

---

I think if we stick to M-files, it will be simpler & we'll get a *TON*
of initial contributions. Once we have that worked out, we can move on
to getting Octave packages into the scheme of things.

Thoughts & comments are always welcome.

~Tomer




On Nov 20, 2003 at 10:59pm, pki...@us... wrote:

pkienz >Date: Thu, 20 Nov 2003 22:59:46 +0000
pkienz >From: pki...@us...
pkienz >To: TA...@lb..., oct...@li...
pkienz >Subject: Re: [OctDev] Re: Octave-dev digest, Vol 1 #142 - 1 msg
pkienz >
pkienz >I presume you mean my CPAN equivalent site.
pkienz >
pkienz >Source-forge itself is sufficient for distribution.  Just drop the
pkienz >packages into the html directory, rebuild the index and serve
pkienz >the pages statically.  I do it right now with the categorical
pkienz >index.
pkienz >
pkienz >For now we can forego automation and update the packages by
pkienz >hand.  It would mean either giving each upstream author a
pkienz >source-forge account and trusting them not to do damage,
pkienz >(someone other than me is mirroring the source-forge daily
pkienz >snapshot CVS tarball, right?), or creating an octave-package
pkienz >list where they can e-mail packages and someone who already
pkienz >has access can package things.
pkienz >
pkienz >Packages will need to have a standard format, so that standard
pkienz >tools can install the package on the system.  This is the hard
pkienz >part.  I have not looked in detail at other packaging systems,
pkienz >so I can't give you any suggestions, other than to keep it as 
pkienz >simple as possible, but no simpler.
pkienz >
pkienz >Some possible goals:
pkienz >
pkienz >	* simple download and install --- may require that the user
pkienz >	first install the install tools; must distinguish user and system
pkienz >	installs.
pkienz >	* tinderboxes to automatically test on different architectures
pkienz >	and against new releases of Octave --- automatic notification
pkienz >	to authors if the package fails.
pkienz >	* prebuilt binaries for some architectures --- a few blessed
pkienz >	tinderboxen can package and checksum their builds.
pkienz >	* simple upgrade process --- when you reinstall octave you
pkienz >	don't want to reselect all your packages by hand.
pkienz >	* unified documentation system so the user can find out
pkienz >	what packages are available and what they contain ---
pkienz >	available online so you don't have to install the package to
pkienz >	learn if you need it.
pkienz >	* demos so that package capabilities are easier to assess.
pkienz >	* per-package communication features --- bug and patch
pkienz >	tracking, threaded discussion group all with e-mail gateway.
pkienz >	* package categories --- the space of matlab add-ons is huge
pkienz >	so a flat package list will quickly become unwieldy; expect
pkienz >	the tree to change as the archive grows; allow for links in
pkienz >	multiple categories.
pkienz >	* support for Octave and Matlab from the same source
pkienz >	build --- this will require an octave->matlab translator (I wrote
pkienz >	one years ago which is still around somewhere) for source
pkienz >	packages.
pkienz >
pkienz >matlinks.net tried to do some of these things a number of years ago.
pkienz >
pkienz >I think there are three keys to success: (1) make it easy to
pkienz >find and assess packages, (2) make it easy to install and 
pkienz >upgrade packages, and (3) have a large base of seed packages 
pkienz >so that it is the obvious place to look  when you need 
pkienz >something.  Once (1) and (2) are done, we will have to canvas 
pkienz >the existing matlab package authors for permission to host 
pkienz >their packages at our site, and be willing  to put in some effort 
pkienz >into wrapping their packages for them.
pkienz >
pkienz >You tell me what we can simplify.
pkienz >
pkienz >Paul Kienzle
pkienz >pki...@us...
pkienz >
pkienz >On 20 Nov 2003 at 19:15, ta...@lb... wrote:
pkienz >
pkienz >> I'm more than happy to work on such a site, but I don't have any
pkienz >> facilities to do so. I guess I could rig up something here at my lab,
pkienz >> but if it starts to get many hits a day, my boss might have to speak
pkienz >> with me... :-)
pkienz >> 
pkienz >> I guess at that point we could switch to bevo.che.wisc.edu, or some
pkienz >> other box?
pkienz >> 
pkienz >> Thanks,
pkienz >> 
pkienz >> ~Tomer
pkienz >> 
pkienz >> 
pkienz >> 
pkienz >> -------------------------------------------------------
pkienz >> This SF.net email is sponsored by: SF.net Giveback Program.
pkienz >> Does SourceForge.net help you be more productive?  Does it
pkienz >> help you create better code?  SHARE THE LOVE, and help us help
pkienz >> YOU!  Click Here: http://sourceforge.net/donate/
pkienz >> _______________________________________________
pkienz >> Octave-dev mailing list
pkienz >> Oct...@li...
pkienz >> https://lists.sourceforge.net/lists/listinfo/octave-dev
pkienz >
pkienz >
pkienz >

[OctDev] convhulln options. =?iso-8859-15?q?=BFDo=20we=20need=20a=20better?= implementation?

[Pedro T. <pt...@te...>]

This is a post to start discussing the convhulln implementation in octave.

convhulln() is a function that returns the convex hull of a set of points. =
It=20
is based on qhull (http://www.thesa.com/software/qhull/).

Lets start with an example to center the discussion.
I did prepare the following script:

convhulltest.m
************************************
#! /usr/bin/octave -qf

% This is an example of what happens with different versions of convhulln()
% We will first define an easy to visualize polyhedron and after that we wi=
ll=20
% check what happens with the output
% prisma will hold the coordinates of a prisma with pentagonal base. There's
% also one point inside the prisma (just to verify it doesn' appear in the
% hull)

prisma =3D [0,0,0;0,1,0;1,3,0;2,0,0;2,1,0;0,0,1;0,1,1;1,3,1;2,0,1;2,1,1;1,1=
,0.5]

% I have the following commands
% convhulln() , computes the convex hull with QJ option (this is my default)
% convhullnold(), is the old version of convhulln()
% convhullnnew(), is the recently modified (1.5) version of convhulln

ch1 =3D convhulln(prisma)
ch2 =3D convhullnnew(prisma)
ch3 =3D convhullnold(prisma)

% I will run this script and comment the results. I will also comment the=20
% results using command line qhull.
*****************************************

The prisma described in the script has clearly 7 faces, two of which are=20
penthagons and the other five are rectangles. Point #11 is interior to the=
=20
prisma so it should never appear on the hull.

Here are the results... first, what I see on the console (warnings):

******************************************
pedro@linux:~> ./convhulltest.m > result

Output completed.  Verifying that all points are below 1.2e-14 of
all facets.  Will make 176 distance computations.

Output completed.  Verifying that all points are below outer planes of
all facets.  Will make 77 distance computations.
warning: extra vertex 3 of facet 0 =3D 4
warning: extra vertex 4 of facet 0 =3D 1
warning: extra vertex 3 of facet 1 =3D 1
warning: extra vertex 3 of facet 2 =3D 4
warning: extra vertex 3 of facet 3 =3D 3
warning: extra vertex 3 of facet 4 =3D 10
warning: extra vertex 4 of facet 4 =3D 6
warning: extra vertex 3 of facet 5 =3D 1
warning: extra vertex 3 of facet 6 =3D 3

Output completed.  Verifying that all points are below outer planes of
all facets.  Will make 77 distance computations.
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Violaci=F3n de segmento
*****************************************************

As you can see, something terrible happened at the end of the last computat=
ion=20
(with the older version of convhulln). We will come back later on this.

Now the results, I will coment them using { }

******************************************************
prisma =3D

  0.00000  0.00000  0.00000
  0.00000  1.00000  0.00000
  1.00000  3.00000  0.00000
  2.00000  0.00000  0.00000
  2.00000  1.00000  0.00000
  0.00000  0.00000  1.00000
  0.00000  1.00000  1.00000
  1.00000  3.00000  1.00000
  2.00000  0.00000  1.00000
  2.00000  1.00000  1.00000
  1.00000  1.00000  0.50000

{ok... this looks pretty obvious... just to have a visual reference on what=
=20
the index of the points mean}

ch1 =3D {this is what I get with joggled input. I get the prisma constructe=
d=20
with 16 triangles: 3 on the bottom, 3 on top, and 2 for each side. Every=20
point that is a vertex is listed here somehow}

  10   9   7
  10   8   7
   6   9   7
   3   8   7
   3   2   7
   3   5   2
   3  10   8
   3  10   5
   1   2   7
   1   6   7
   4   5   2
   4   1   2
   4  10   9
   4  10   5
   4   6   9
   4   1   6

ch2 =3D {this is what I get with the new convhulln(). Notice that I only ha=
ve a=20
triangle on each face. I can not reconstruct the prisma with this=20
information. Vertex #1 which is part of the hull does not list. It is=20
possible to find it in the warnings we listed before. Notice that the=20
warnings use C enumeration for facets and vertex info; 0 is what we would=20
call 1, etc. Then what comes after the =3D sign is "in our language"}

   5   2   3
   9   6   4
   9   5  10
   8   5  10
   7   8   9
   7   2   6
   7   8   2

******************************************************

Here the results break... the old convhulln couldn't handle something....


If we run qhull (without options) from the command line against a similar=20
prisma, this is what we get:

0 3 4 2 1
5 8 3 0
8 9 4 3
9 7 2 4
6 7 9 8 5
6 5 0 1
7 6 1 2=20

To speak in the same language we should add 1 to every index listed here. A=
s=20
we can see it's not easy for octave to handle this ouput. Not all the rows=
=20
have the same number of elements. Maybe this is the reason for the=20
seg-fault?.

If we run it with QJ or Qt options we get triangulated output, although the=
=20
triangulation is different.


So... after writing this long, long brick.... Should we give some more=20
functionality to the convhulln function? (maybe giving it some other name f=
or=20
compatibility reasons). I don't understand why the new convhulln doesn't gi=
ve=20
also triangulated output (not trimmed rows...).

I hope this can be an starting point for discussion.

Regards,
Pedro

Re: [OctDev] Re: Octave-dev digest, Vol 1 #142 - 1 msg

[<pki...@us...>]

I presume you mean my CPAN equivalent site.

Source-forge itself is sufficient for distribution.  Just drop the
packages into the html directory, rebuild the index and serve
the pages statically.  I do it right now with the categorical
index.

For now we can forego automation and update the packages by
hand.  It would mean either giving each upstream author a
source-forge account and trusting them not to do damage,
(someone other than me is mirroring the source-forge daily
snapshot CVS tarball, right?), or creating an octave-package
list where they can e-mail packages and someone who already
has access can package things.

Packages will need to have a standard format, so that standard
tools can install the package on the system.  This is the hard
part.  I have not looked in detail at other packaging systems,
so I can't give you any suggestions, other than to keep it as 
simple as possible, but no simpler.

Some possible goals:

	* simple download and install --- may require that the user
	first install the install tools; must distinguish user and system
	installs.
	* tinderboxes to automatically test on different architectures
	and against new releases of Octave --- automatic notification
	to authors if the package fails.
	* prebuilt binaries for some architectures --- a few blessed
	tinderboxen can package and checksum their builds.
	* simple upgrade process --- when you reinstall octave you
	don't want to reselect all your packages by hand.
	* unified documentation system so the user can find out
	what packages are available and what they contain ---
	available online so you don't have to install the package to
	learn if you need it.
	* demos so that package capabilities are easier to assess.
	* per-package communication features --- bug and patch
	tracking, threaded discussion group all with e-mail gateway.
	* package categories --- the space of matlab add-ons is huge
	so a flat package list will quickly become unwieldy; expect
	the tree to change as the archive grows; allow for links in
	multiple categories.
	* support for Octave and Matlab from the same source
	build --- this will require an octave->matlab translator (I wrote
	one years ago which is still around somewhere) for source
	packages.

matlinks.net tried to do some of these things a number of years ago.

I think there are three keys to success: (1) make it easy to
find and assess packages, (2) make it easy to install and 
upgrade packages, and (3) have a large base of seed packages 
so that it is the obvious place to look  when you need 
something.  Once (1) and (2) are done, we will have to canvas 
the existing matlab package authors for permission to host 
their packages at our site, and be willing  to put in some effort 
into wrapping their packages for them.

You tell me what we can simplify.

Paul Kienzle
pki...@us...

On 20 Nov 2003 at 19:15, ta...@lb... wrote:

> I'm more than happy to work on such a site, but I don't have any
> facilities to do so. I guess I could rig up something here at my lab,
> but if it starts to get many hits a day, my boss might have to speak
> with me... :-)
> 
> I guess at that point we could switch to bevo.che.wisc.edu, or some
> other box?
> 
> Thanks,
> 
> ~Tomer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] Re: Octave-dev digest, Vol 1 #142 - 1 msg

[<ta...@lb...>]

I'm more than happy to work on such a site, but I don't have any
facilities to do so. I guess I could rig up something here at my lab,
but if it starts to get many hits a day, my boss might have to speak
with me... :-)

I guess at that point we could switch to bevo.che.wisc.edu, or some
other box?

Thanks,

~Tomer

[OctDev] Re: octave-forge account for cosmo/

[<pki...@us...>]

Context:  I've had several requests to include specialized
projects into octave forge, including one from Boud (see
below).  So far most of octave forge is general, with the 
exception of a couple of bits of code (protein database, 
civil engineering, finance).  

I'm biased toward keeping it that way since I have neither 
the time nor the skills to keep such code running when the 
author disappears.

I would prefer to have a packaging system which makes 
things easy to build and install, a public archive to store 
them and several tinderbox machines to build and test the 
code on different architectures. The packaging system
should include author email addresses to report bugs and
an easy way for users to post and apply patches when
the author is too busy to respond.  The distribution system
must support dependencies.  Ideally this system could
handle octave and/or matlab packages to increase the size
of the contributing community.

However, I don't have time to create such a system, and I
have yet to inspire someone else to do so.  So in the mean
time, what should we do?  Put specialized packages in
extra with a NOINSTALL file?  I suppose that's better than
letting it die on the net, so unless anyone else has a better
suggestion, that is what I will recommend.

Paul Kienzle
pki...@us...

On 19 Nov 2003 at 15:36, Boud Roukema wrote:

> Hi Paul,
> 
> On Sat, 15 Nov 2003 pki...@us... wrote:
> 
> > Hi.
> >
> > I consider octave-forge to be a community project,
> > so anyone can become a developer just by asking.
> 
> :)
> 
> > My concern is that what you are doing sounds very
> > specific, and I don't want every octave-forge use to
> > have to build and install it by default.  On the other
> > hand, I don't want your users to have to work too
> > hard to get it.
> 
> It's specific in the sense that many ordinary readers of popular
> science magazines/books normally don't realise that they can make
> simple "random checks" on the science they read about, and they have
> to make judgments more by the "argument of authority" (such and such a
> magazine is "serious and trustworthy", a study done at an Ivy League
> university or "by NASA" is more credible than any other, ...) rather
> than by checking themselves.
> 
> My hope is to completely change this culture. Empirical science is for
> everybody, especially since in the internet era, empirical data can be
> easily shared so that people who cannot buy/build/run a 4m telescope
> or a synchroton or whatever can still do their own analyses of the
> data. Most astronomy data and the arxiv.org publications database are
> freely available on the internet (in contrast to social sciences which
> AFAIK mostly seem to be closed), so it's possible for ordinary people
> to participate *a lot*.
> 
> However, i agree that we should not "force" users who do not share
> this vision to have to install scientific packages.
> 
> So if there is some solution where "my users" (or maybe eventually,
> general users curious about empirical science) can install it without
> "having to work too hard", of course that makes sense.
> 
> 
> For the moment, i was only thinking of contributing functions
> to calculate distance as a function of redshift and vice-versa,
> though it's true that in the long term i'm interested in making
> more general scientific packages available, even though i'm not
> sure how useful an octave "front-end" would be.
> 
> Would simply putting in a file "NOINSTALL" as suggested here:
> http://octave.sourceforge.net/new_developer.html
> be enough?
> 
> 
> > The best thing would be a package archive system
> > for Octave much like CRAN or CPAN.  Then just
> > the users who want the specialized packages
> > need to download and install them.
> 
> i hadnt' heard of CRAN before (though i vaguely knew about CPAN) - it
> looks good.
> 
> 
> > Are you interested in working on a packaging
> > system?
> 
> Ummm....  You mean for me to start a web of ftp and web sites around
> the world for this project?
> 
> If this could be open-ended in the sense that it could involve general
> packaging of cosmology packages, both with octave front-ends and
> independently, and if some people (like you) could help me, then yes,
> i would be interested.
> 
> As a member of the cosmology community, i think that other cosmo institutes
> would be likely to join in in making a network of mirrors etc, but *only*
> once one site is clearly functioning and i publish a few papers using
> the packages.
> 
> BTW, can we shift this thread onto a public list, e.g. octave-dev?
> Apart from stuff which is security related, i generally prefer
> discussion to be public. The more people can double check a
> conversation, the more chance there is that software will evolve in a
> way useful to users.
> 
> Or else i could make a new mailman list:
> http://adjani.astro.uni.torun.pl/mailman/listinfo
> 
> boud
> 
> > - Paul
> >
> >
> > On 14 Nov 2003 at 16:51, Boud Roukema wrote:
> >
> > > hi paul,
> > >   On the page
> > >
> > > http://octave.sourceforge.net/new_developer.html
> > >
> > > you are listed as an admin of the source-forge project.
> > >
> > > i'd like to submit some scientific functions with the hope
> > > of having them eventually accepted in the main distribution so that
> > > students and other people around the world can easily make simple
> > > cosmology calculations with octave.
> > >
> > > They're in fortran but i've got a C++ wrapper which seems to work OK,
> > > at least for getting the functions to work on scalars. i'd probably
> > > need help for making the functions work on vectors or matrices in the
> > > transparent way of ordinary functions like sin, log etc.
> > >
> > > i've got an account on sourceforge as
> > >
> > > boud1
> > >
> > > Could i become an octave-force developer please?
> > >
> > > thanks
> > > boud
> >
> >

Re: [OctDev] Ocatve release 2.1.51 and Octave-Forge

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

I agree that the changes I made for 2.1.51 make the code crufty, and I 
agree that a minimum version is the best way to handle the issue. However,
its too brutal to say the next version has to have 2.1.51, as some of the
changes in 2.1.51 can still be considered experimental. What I'd suggest 
is keeping the 2.1.36 limit, and then the octave-forge release in a years
time ups this to 2.1.51, and removes the cruft...

Cheers
David


According to pki...@us... <pki...@us...> (on 11/18/03):
> On 17 Nov 2003 at 21:30, John W. Eaton wrote:
> 
> > My preference would be to not clutter the sources with these kinds of
> > macros/tests and instead simply state that a minimum version of Octave
> > is required to use octave-forge.  I understand doing that could cause
> > some trouble, but I think in the long run we will be better off.
> 
> That was too painful the last time I tried it (circa 2.1.42).  I agree
> though, that it even makes new code look crufty.
> 
> Paul Kienzle
> pki...@us...
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
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] Ocatve release 2.1.51 and Octave-Forge

[<pki...@us...>]

On 17 Nov 2003 at 21:30, John W. Eaton wrote:

> My preference would be to not clutter the sources with these kinds of
> macros/tests and instead simply state that a minimum version of Octave
> is required to use octave-forge.  I understand doing that could cause
> some trouble, but I think in the long run we will be better off.

That was too painful the last time I tried it (circa 2.1.42).  I agree
though, that it even makes new code look crufty.

Paul Kienzle
pki...@us...

Re: [OctDev] Ocatve release 2.1.51 and Octave-Forge

[<pki...@us...>]

I've added support for TYPEID_HAS_CLASS and class names for
everything that defines a type (ov-re-tri, comm, sparse, symbolic,
dispatch). Everything compiles, and the meager tests that I have in
place run, except that sparse is broken.

Other than fixing sparse, what else do we want to go into
this release?

Oops!  It occurs to me that the current octave version should be the
unmarked form!  So instead of HAVE_ND_ARRAY it should be
MISSING_ND_ARRAY and instead of TYPEID_HAS_CLASS it
should be MISSING_TYPEID_CLASS, or whatever the GNU standard
is for negative tests.  If nothing else I should have used
HAVE_TYPEID_CLASS rather than TYPEID_HAS_CLASS.  Feel
free to fix it.

Paul Kienzle
pki...@us...

On 17 Nov 2003 at 11:29, David Bateman wrote:

> Dear All,
> 
> We need a new release of Octave-Forge for 2.1.51 due to numereous changes.
> I've already made some of the necessary changes to the CVS previous for
> the fortran_indexing, etc flags. However I know of at least one other 
> change that hasn't been implemented that needs to be before a release,
> and perhaps there are other. The change I know about is that all of the
> registered types need this change made

Re: [OctDev] Ocatve release 2.1.51 and Octave-Forge

[<pki...@us...>]

Thanks for your efforts. I will compile and check now.

An octave-for-windows release will probably have to wait for the
weekend.

Anyone know what to do about the xerbla problem I sent to
octave-maintainers?  I want LAPACK as a DLL so it can be
swapped out with ATLAS enabled versions.  Octave wants
to override BLAS's xerbla.f with it's own, but AFAIK it isn't
possible to replace a function reference with another in a DLL
at runtime.

- Paul

On 17 Nov 2003 at 19:06, David Bateman wrote:

> Ok, seeing the limited response to this e-mail I've updated octave-forge
> for this change for 2.1.51. The authors of symbolic and sparse packages
> should check the changes however.
> 
> I hope we can have a release rapidly, since the current octave-forge 
> release will NOT work with 2.1.51.....
> 
> Regards
> David
> 
> According to David Bateman <Dav...@mo...> (on 11/17/03):
> > Dear All,
> > 
> > We need a new release of Octave-Forge for 2.1.51 due to numereous changes.
> > I've already made some of the necessary changes to the CVS previous for
> > the fortran_indexing, etc flags. However I know of at least one other 
> > change that hasn't been implemented that needs to be before a release,
> > and perhaps there are other. The change I know about is that all of the
> > registered types need this change made
> > 
> > #ifdef HAVE_ND_ARRAYS
> >   dim_vector dims (void) const { static dim_vector dv (1, 1); return dv; }
> > #else
> >   int rows (void) const { return 1; }
> > 
> >   int columns (void) const { return 1; }
> > 
> >   int length (void) const { return 1; }
> > #endif
> > 
> > for scalar objects, and
> > 
> > #ifdef HAVE_ND_ARRAYS
> >   dim_vector dims (void) const { return matrix.dims (); }
> > #else
> >   int rows (void) const { return matrix.rows (); }
> >   int columns (void) const { return matrix.columns (); }
> > 
> >   int length (void) const
> >   {
> >     int r = rows ();
> >     int c = columns ();
> > 
> >     return (r == 0 || c == 0) ? 0 : ((r > c) ? r : c);
> >   }
> > #endif
> > 
> > for vector/matrix objects, in the corresponding *.h files, and the
> > corresponding Makefiles need to have the flag $(HAVE_ND_ARRAYS) added
> > appropriately. I've already added the HAVE_ND_ARRAYS to
> > configure.base, so this should be a relatively easy change to
> > make. What needs to be changed includes
> > 
> > main/comm/ov-galois.h                   % This is my file.
> > main/sparse/make_sparse.h
> > main/symbolic/ov-ex.h
> > main/symbolic/ov-ex-mat.h
> > main/symbolic/ov-relational.h
> > main/symbolic/ov-vpa.h
> > 
> > I'll of course change my own code, but would not like to touch sparse
> > of symbolic packages if the authors are willing to do the changes themselves.
> > 
> > There are possibly other changes for 2.1.51 that I'm not aware of, also. So
> > if you can think of anything now is the time to make these changes, so a 
> > new octave-forge release can be made rapidly.
> > 
> > Cheers
> > 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
> > 
> > 
> > -------------------------------------------------------
> > This SF. Net email is sponsored by: GoToMyPC
> > GoToMyPC is the fast, easy and secure way to access your computer from
> > any Web browser or wireless device. Click here to Try it Free!
> > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> > _______________________________________________
> > Octave-dev mailing list
> > Oct...@li...
> > https://lists.sourceforge.net/lists/listinfo/octave-dev
> 
> -- 
> 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
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] plot3 has issues with hold?

[Mike P. <mik...@fs...>]

Hello, I've noticed that plot3 seems to be having some issues with hold.
It seems to be ignoring my 'hold off' requests.. 

Attached is a tarball that demonstrates this bug.

Also, you will note when you run it that there are *tons* of line
segments in the key (which is annoying). 

Is it possible for you guys to throw a 'gset nokey' into plot3.m or
__plt3__.m? This would make the behavior more inline with matlab, where
you only get a key if you specifically request one with legend().


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Re: [OctDev] Ocatve release 2.1.51 and Octave-Forge

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

Ok, seeing the limited response to this e-mail I've updated octave-forge
for this change for 2.1.51. The authors of symbolic and sparse packages
should check the changes however.

I hope we can have a release rapidly, since the current octave-forge 
release will NOT work with 2.1.51.....

Regards
David

According to David Bateman <Dav...@mo...> (on 11/17/03):
> Dear All,
> 
> We need a new release of Octave-Forge for 2.1.51 due to numereous changes.
> I've already made some of the necessary changes to the CVS previous for
> the fortran_indexing, etc flags. However I know of at least one other 
> change that hasn't been implemented that needs to be before a release,
> and perhaps there are other. The change I know about is that all of the
> registered types need this change made
> 
> #ifdef HAVE_ND_ARRAYS
>   dim_vector dims (void) const { static dim_vector dv (1, 1); return dv; }
> #else
>   int rows (void) const { return 1; }
> 
>   int columns (void) const { return 1; }
> 
>   int length (void) const { return 1; }
> #endif
> 
> for scalar objects, and
> 
> #ifdef HAVE_ND_ARRAYS
>   dim_vector dims (void) const { return matrix.dims (); }
> #else
>   int rows (void) const { return matrix.rows (); }
>   int columns (void) const { return matrix.columns (); }
> 
>   int length (void) const
>   {
>     int r = rows ();
>     int c = columns ();
> 
>     return (r == 0 || c == 0) ? 0 : ((r > c) ? r : c);
>   }
> #endif
> 
> for vector/matrix objects, in the corresponding *.h files, and the
> corresponding Makefiles need to have the flag $(HAVE_ND_ARRAYS) added
> appropriately. I've already added the HAVE_ND_ARRAYS to
> configure.base, so this should be a relatively easy change to
> make. What needs to be changed includes
> 
> main/comm/ov-galois.h                   % This is my file.
> main/sparse/make_sparse.h
> main/symbolic/ov-ex.h
> main/symbolic/ov-ex-mat.h
> main/symbolic/ov-relational.h
> main/symbolic/ov-vpa.h
> 
> I'll of course change my own code, but would not like to touch sparse
> of symbolic packages if the authors are willing to do the changes themselves.
> 
> There are possibly other changes for 2.1.51 that I'm not aware of, also. So
> if you can think of anything now is the time to make these changes, so a 
> new octave-forge release can be made rapidly.
> 
> Cheers
> 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
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
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

[OctDev] Ocatve release 2.1.51 and Octave-Forge

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

Dear All,

We need a new release of Octave-Forge for 2.1.51 due to numereous changes.
I've already made some of the necessary changes to the CVS previous for
the fortran_indexing, etc flags. However I know of at least one other 
change that hasn't been implemented that needs to be before a release,
and perhaps there are other. The change I know about is that all of the
registered types need this change made

#ifdef HAVE_ND_ARRAYS
  dim_vector dims (void) const { static dim_vector dv (1, 1); return dv; }
#else
  int rows (void) const { return 1; }

  int columns (void) const { return 1; }

  int length (void) const { return 1; }
#endif

for scalar objects, and

#ifdef HAVE_ND_ARRAYS
  dim_vector dims (void) const { return matrix.dims (); }
#else
  int rows (void) const { return matrix.rows (); }
  int columns (void) const { return matrix.columns (); }

  int length (void) const
  {
    int r = rows ();
    int c = columns ();

    return (r == 0 || c == 0) ? 0 : ((r > c) ? r : c);
  }
#endif

for vector/matrix objects, in the corresponding *.h files, and the
corresponding Makefiles need to have the flag $(HAVE_ND_ARRAYS) added
appropriately. I've already added the HAVE_ND_ARRAYS to
configure.base, so this should be a relatively easy change to
make. What needs to be changed includes

main/comm/ov-galois.h                   % This is my file.
main/sparse/make_sparse.h
main/symbolic/ov-ex.h
main/symbolic/ov-ex-mat.h
main/symbolic/ov-relational.h
main/symbolic/ov-vpa.h

I'll of course change my own code, but would not like to touch sparse
of symbolic packages if the authors are willing to do the changes themselves.

There are possibly other changes for 2.1.51 that I'm not aware of, also. So
if you can think of anything now is the time to make these changes, so a 
new octave-forge release can be made rapidly.

Cheers
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] admin/mk{doc,texi} and multiple Octave versions.

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

Ok, the people at soucreforge kindly fixed this for me..

Cheers
David

Dapr=E8s Lute Kamstra <Lut...@cw...> (le 07/11/2003):
> David Bateman <Dav...@mo...> writes:
>=20
> > So unless someone has RCS access on sourceforge, the old solution I
> > see is to rename these files.
>=20
> I took a quick look at the SourceForge docs.  The section:
>=20
>   http://sourceforge.net/docman/display_doc.php?docid=3D768&group_id=3D=
1#cleanup
>=20
> says:
>=20
> ,----
> |   CVS Repository Clean-Up
> |=20
> |     Through the course of learning to use CVS, and in long-term use
> |     of CVS, it is not uncommon to encounter cases where you need
> |     something within your repository to be manipulated directly (for
> |     example, files which have been removed via "cvs remove", but
> |     which should be purged from the Attic, as well). While
> |     SourceForge.net does not provide direct access for developers to
> |     modify their own repository contents via a shell, the
> |     SourceForge.net team is happy to perform actions of this nature
> |     on your behalf.
> `----
>=20
> So I guess you have to contact the SourceForge staff and ask them to
> chmod +x the RCS files..
>=20
>   Lute.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> 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

[OctDev] append_save.m

[<ta...@lb...>]

Hello all,

I just submitted the "append_save.m" file that I posted to help-octave
& octave-sources not too long ago. Please give me feedback about how
great it is, or how useless it is. :-)

I put it under:
main/io/append_save.m

Was that the right place to put it? This is my first times submitting
code, so did I forget to do something?

Thanks,

~Tomer

Re: [OctDev] "dispatch.oct is not a valid shared library".

[Lute K. <Lut...@cw...>]

David Bateman <Dav...@mo...> writes:

> This happened to me when I built octave-forge against an older 2.1.50
> version and then rebuilt the CVS version of octave without rebuilding
> octave-forge. As teh CVS version of octave has the name 2.1.50 still.
>
> Maybe you have the same problem..

Nope, I first built octave-2.1.50 from scratch (today's CVS) and then
octave-forge from scratch (today's CVS as well).

  Lute.