octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More octave-forge functions!!!


From: David Bateman
Subject: Re: More octave-forge functions!!!
Date: Mon, 29 May 2006 21:41:53 +0200
User-agent: Mozilla Thunderbird 1.0.6-7.6.20060mdk (X11/20050322)

Soren Hauberg wrote:
> man, 29 05 2006 kl. 14:50 +0200, skrev David Bateman:
> 
>>>The remaining functions I consider to fall into two groups. The first of
>>>these groups of function in octave-forge which are core matlab functions is
>>>
>>> brighten contourf drawnow fill fill3 gtext imread imwrite
>>> legend meshc pareto patch pcolor peaks pie psi quiver
>>> scatter stem surf surfc text view zoom
>>>
>>>Essentially these are all graphics functions and the graphics handles
>>>stuff will either largely change these functions, or simplify them and
>>>so I don't think these should be treated until the graphics handles
>>>stuff is addressed. Though they should go on someones todo list.
> 
> Why do imread and imwrite fall in this category? Do they really depend
> on the handle-graphics stuff? I thought the problem with these functions
> was ImageMagick.
> 

True, Paul pointed out the same thing offline, and that brighten might
easily be ported as it doesn't depend on anything and is not a graphics
function per-se as it doesn't directly display anything. I wrote the
list of things I considered difficult in a hurry.

> <brainfarting>
> It seems to me that you put alot of thought into portability (edit,
> ginput, sound, ...) which is great. My impression is that portability is
> very hard to achieve without using libraries designed with portability
> in mind. Such libraries do exist for things like sound, image reading,
> etc. but that drags in some dependencies. So I guess my question is what
> is the strategy with regard to portability?
> 1) Will functionality be left out due to the lack of portable libraries?
> 2) Will some platforms (i.e. Windows) be left behind due to the lack of
> portable libraries?
> 3) Should such hard stuff be left to system-specific packages?
> 4) ???
> </brainfarting>

This is in fact just the type of discussion I was hoping to promote (as
well as trying to get some help). Where do we draw the line of what
dependencies we are willing to accept in the core of octave? qhull? gsl?
libjpg/libpng? Imagemagick? It seems that to get octave duplicating all
of matlab core functions would require a significant number of
additional dependencies, and that these should be chosen with care. What
is the best subset of additional dependent libraries to get the maximum
compatibility and portability?

BTW, my efforts to strip octave-forge of octave core functions has the
goal of making repackaging octave-forge with the package manager easier.
Basically there is no point packaging octave-forge functions that should
be in octave, so better to move them first. What is the status of the
package manager in octave? Have you rechecked it? Are there any missing
features (gzipped tar files, I believe were stripped by John)? What
about cross platform support. Does it work on Mac OS (both flavours),
cygwin and mingw?

> 
> Soren
> 
> P.S. I'm quite impressed by your work on moving octave-forge into octave
> -- just wished I had your energy :-)

I want to see a good 3.0 release sooner rather than later..

D.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]