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 >