The future of Octave

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

Re: The future of Octave

Kevin Straight
On Sat, 9 Dec 2000, Paul Kienzle wrote:

> I've been hesitant to pursue this option for three reasons.  
>
>     1) The need to learn a second language for programming callbacks
>     2) The overhead of installing and running a second large interpreter
>     3) The ungainliness of tcl/tk
>

Tcl is too slow, especially since everyone is obviously concerned about
execution time.  I say we should use C++m which Octave can already
dynamicly load.

The embedded interpreter model sounds like it has merit, though.  Let me
see if I understand you:

*) we would have a second process in memory that knew how to draw
all the widgets and process callbacks.

*)We would write an API of functions called in Octave, which would
communicate with this process (with pipes, I guess, but I only know
unix/linux and don't know if this would be portable) to ask for widgets,
then request their states (weather a button was pressed, for instance)

Again, I only know Linux, but I would say that (as long as you could use
dynamic linking) you could run something like this in less than one meg of
user RAM.  I would worry about stability, though.

> It occurs to me, though, that we can apply the same approach that I would
> recommend for an embedded GUI, which is a widget register defining the
> range of widgets available, and their properties and callbacks (including
> some packing widgets).  The widget definition can include all the bits
> of the foreign interpreter that are needed, leaving your Octave scripts
> with pure Octave code.
>
> The overhead of the second interpreter is offset by the benefit of having
> the GUI in a separate process.  Even if we did our own specialized
> GUI in a separate process, we would still have to incur that overhead
> (though presumably the specialized interpreter would be very simple).
>


==========================
Kevin Straight
University of Idaho
www.uidaho.edu/Šþstra9456
==========================



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: GUI (Was: The future of Octave)

Rafael Laboissiere-5
In reply to this post by Kevin Straight
On Sun, Dec 10, 2000 at 10:33:11AM -0800, Kevin Straight wrote:

> For the later, all we have to do as a group is to agree on a basic
> framework, then someone needs to write bindings for some basic
> widgets.  From then on, if anyone needs something complicated, they can do
> it themselves.  At the minimum, we need to decide what toolkit we are
> going to use.  We also need to decide some things like how we are going to
> deal with signals and mainloop handling.
>
> Heck, even someone like *me* could rough out a basic API if we could agree
> on that much (not that I'm neccessarily volanterering <smile>), and I am
> an indifferent programmer at best.  :-)

This discussion is in the wrong mailing list.  It should move into
octave-graphics.  Go through the archives and you will see that JWE made a
proposal for an Octave GUI API last year.  This year, I implemented a
proof-of-concept part of it with (threaded) GTK and posted the code.  As
usual, both John's proposal and my code caused very few interest (at least,
I did not see much reaction to them).

--
Rafael



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Andrew Bainbridge-Smith
In reply to this post by John W. Eaton-6
Hi John,

Thanks for your reply.

I hope that you didn't interpret my posting as one of criticism --- it wasn't
meant in that way.  Indeed I am well aware that you've sort assistance to help
with documentation work.  The point really was that you have managed to
maintain the package without any significant forking and keep things moving
alone with enthusiasm.  I doubt that any single person will come forward to
take leadership and put in the effort you have put in.  Instead it will
(hopefully) be a team, the downside being that forking and divided effort may
result (I agree that some forking may be acceptable provided that the overall
effort is not lost as a result).  When a team takes control there will be a
greater need for clear communications and documentation.

I take it that perhaps the most significant issue --- that of the home for
OCTAVE --- has at least been resolved.

I should of course put my hand forward to take on some supporting role.  I
have employed a student for the summer (Southern hemisphere).  As he converts
some of my MATLAB m-files to OCTAVE and becomes experienced and fires my
enthusiasm I will see if I can make such an effort.

WIth much thanks to your efforts,
        Andrew BS
--
Dr Andrew Bainbridge-Smith
Senior Research Engineer
Vision Technology Development Group
CSIRO Manufacturing Science and Technology
Australia



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

owinebar
In reply to this post by John W. Eaton-6
On Sat, 9 Dec 2000, John W. Eaton wrote:

> If you want to head down that path, then I think it makes more sense
> to use a translator to convert Matlab code to a more full-featured
> scripting language.  A similar translator would be written for Octave
> (or whatever the new environment that does not attempt Matlab
> compatibility is called).  Both translators would share the same
> underlying library and interpreter, so both could be used together,
> along with any code written for the underlying scripting language.
>
> If you agree with this approach, at least in principle, then you will
> probably want to have your favorite scripting language at the core.
> People will probably argue that one language is more popular or has
> more add-ons than another, so it should be used.  There will be Python
> and Perl advocates, and people who just like Tcl, or Java.  But my
> choice would probably be something like Scheme, which is powerful, and
> should be relatively easy to use as a target for translation.
>
> Using such an approach, you don't have to write Scheme code if you
> don't like it, you can write Octave code and pass it through the
> translator, and people who want to use the strict Matlab translator
> can still have access to your code.  Likewise, people who use Octave
> have access to all the Matlab code, via the translator.  And both have
> access to any other modules written for the Scheme interpreter.

    Wouldn't it be better to go to a virtual machine + general optimizing
phase compiler core + multiple frontends model?  These other languages are
nice and all, but how well do they support numerical computation?  And how
much cruft would be generated (if you choose Scheme, I would think you're
most of the core code (what's written in C++) would still be in C++ or C,
but with a load of Guile hooks in them.  Is that going to improve the
developer situation or worsen it?
    Personally, the only time I care about Matlab compatibility is when
I see some useful code someone else has written in Matlab and want to use
it with as little pain as possible.  I'd just as soon have a better
language interface for myself, though.  Something with continuations and
run-time macro expansion and a good object system and (drool obscures
further feature lust).
    Plus it would provide a clean separation of concerns so I don't have
to dig to the deep core when I only need something superficial (replace
"I" with "J Random Coder" if you like).  While there's a lot to be
grateful for with Octave, there are problems as well.  And source
documentation has got to be a big one for expanding it developer
base.  Forcing this kind of separation would at least require
documentation of the interface.  And it's been my experience as a reader
of software that the most flexible/cleanest designs are those that read as
interpreters (of their data, not that they have lexers and parsers).
    Take these comments for what they're worth, as I don't have the time
or expertise to help with this.  I'm only offering them as someone who
reads much more code than he writes, and has an opinion on what's easier
to read and thus work on. YMMV.

Lynn
PS Thanks for Octave.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Keisuke Nishida-2
Hello,

Lynn Winebarger <[hidden email]> writes:

>     Wouldn't it be better to go to a virtual machine + general optimizing
> phase compiler core + multiple frontends model?  These other languages are
> nice and all, but how well do they support numerical computation?  And how
> much cruft would be generated (if you choose Scheme, I would think you're
> most of the core code (what's written in C++) would still be in C++ or C,
> but with a load of Guile hooks in them.  Is that going to improve the
> developer situation or worsen it?

I am a Guile developer who is working on a Guile virtual machine.
So far Guile has been concerned in translating various languages
into Scheme, but I personally think having multiple frontends or
translating into a lower level intermediate language would be better.
I am now designing a new core language and going to spend the next
few years working on this.

Just FYI.

Thanks,
Keisuke Nishida



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

RE: The future of Octave

John Logsdon-4
In reply to this post by Ted.Harding
Picking up a few of the ideas but mainly furthering my own (I must admit),
perhaps the answer to why Linux and R have been successful is that the
syntax etc of the application has been defined before.  Linux follows
exactly the organisation etc of Unix, even picking up coding etc from some
implementations and R follows as exactly as possible the open definition
of that statistical programming language.

For this reason, the bazaar approach will work since there is a target,
which can be modified but only within the open standards.  The developers
can be proactive.

Where software is trying to replace/replicate a piece of proprietory
commercial software, it becomes much more difficult as the developers have
to be reactive rather than proactive.  Some people will get involved but
it is difficult to develop the spirit since there is always the feeling of
not being in control.  For this reason, responding to the 'can we have
feature x compatible with Matlab' is a truly depressing request,
particularly as it presumably generally comes with no attached development
funding.

This mould can only be broken when there is a major step forward.

For example I think most word processors that are not going to challenge
Word since MS will bring out a new copy that is similar with some subtle
alterations or, more pertinantly, MathSoft brings out version 5 etc with a
different internal format.

Most people are 'happy' with the offerings from MS and therefore all the
others are left running round trying to produce software that will 'read'
Word (or Excel, Access etc).  None of them do a really good job
unfortunately - again very depressing.

The solution then is to develop an open standard for a new generation of
mathematical tool - including high dimensional arrays, sparse matrix and
all the other tools (GUI and non-GUI), graphics etc that have been
mentioned in this thread.  I completely agree that the danger of GUI's is
wygiowycc (what you get is *only* what you can click) and would not like
to see a basic command line interface lost but I am drifting into personal
preferences that are better developed in a more structured way ...

Note that I am not suggesting actually doing the coding - it is the
standard that needs to be set.   That is where the S language came from.

In many ways, the R program does provide a lot of what you need although
the syntax is different (and less natural at least to start with).  It
includes multi-dimensional arrays and integrated graphics for example.  I
know (to take fellow statistician and Linux user Ted Harding's point) I
could do some obscure calculation in R and then pass an ASCII file to
Octave but in practice this would be a waste of time - I would just carry
on in R. In fact, ISTR there are Octave reading facilities in R and some
of the R-folk have also contributed to Octave at least in the past (maybe
still now).

If the standard is acceptable, various groups (probably including several
commercial developers) will try and meet it and the product will emerge.
It may well be based on Octave - the syntax is already worked out - but it
could include approaches from various other packages.  Many of the
toolboxes used in S-Plus and Matlab have actually been contributed freely
and the spirit is probably still there.  The big problem with the
commercial packages is that they cost too much.

However this really needs planning.  I get the strong feeling that Octave
has probably reached a natural limit - or at least break - and some
reflection is called for.  Any volunteers to start the standards ball
rolling?

John




-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Phil Cummins-2
In reply to this post by John W. Eaton-6

Hello,

  I'm just a user of octave (not even the development version),
but I felt I should also take the opportunity to thank John and
and all the other people who have contributed to octave. It really
has been an indispensable tool for me. I recommend it in a Linux
course I give every year to seismologists from developing countries,
whose institutes can barely afford computers, much less matlab.
  FWIW, I think it's probably right to concentrate on the
mathematics, that's what's really important (to me, anyway). I do
miss having a GUI and better graphics now and then. But surely the
way to go is to provide interfaces to existing tools, as some people
have suggested?
  The matlab compatibility is not such a big issue for me, but it
has been nice to be able to easily port over some simple matlab
scripts. (I realize it is a very big issue for some people and I
sympathize, but I am just reporting my own experience here).
  Well, that's just me 2 cents.

---------------------------------------------------------------------



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Jonathan C. Webster
In reply to this post by John W. Eaton-6
>

Hi John,

A big thank you to you and to  the other folk that have contributed to
Octave.

As to the future of Octave, let me mention  two of its features  that I use
often:

Octave can be started with the name of a script file to run. Then, at least
on a UNIX type  box ( Linux) , that can be put in the background.  I would
hate to have the GUI  enthusiasm  spoil that ability.  Read that as "The
computer can do the work while I do something else."

It's nice still to be able to pass -mat-binary files to other people working
on the same project who DID go out and buy MatLab.

As to a wish list:   Multi dimension arrays  and generalized transpose of
those arrays.

Regards,
Jonathan

> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web:  http://www.octave.org
> How to fund new projects:  http://www.octave.org/funding.html
> Subscription information:  http://www.octave.org/archive.html
> -------------------------------------------------------------



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Przemek Klosowski
In reply to this post by Kevin Straight

   > I've been hesitant to pursue this option for three reasons.  
   >
   >     1) The need to learn a second language for programming callbacks
   >     2) The overhead of installing and running a second large interpreter
   >     3) The ungainliness of tcl/tk
   >

   Tcl is too slow, especially since everyone is obviously concerned about
   execution time.  I say we should use C++m which Octave can already
   dynamicly load.

Tcl would be indeed too slow if one wanted to use it for
computation---but I don't think this is being contemplated. I think a
better idea is to wrap up Tk widgets into octave wrappers; so instead
of Tcl loop running Tk widgets you'd run Octave loop. Tk widgets have
been stolen already, twice: by Python (TkInter) and Perl (PerlTk?), so
octave could do the same. Tcl/Tk is ugly only if abused, and I speak
from experience: I once needed matrices and matrix multiplication in
Tcl, and it was awful. However, GUI in Tcl/Tk tends to be brief and
flexible.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Trond Eivind Glomsrød-2
Przemek Klosowski <[hidden email]> writes:

>    > I've been hesitant to pursue this option for three reasons.  
>    >
>    >     1) The need to learn a second language for programming callbacks
>    >     2) The overhead of installing and running a second large interpreter
>    >     3) The ungainliness of tcl/tk
>    >
>
>    Tcl is too slow, especially since everyone is obviously concerned about
>    execution time.  I say we should use C++m which Octave can already
>    dynamicly load.
>
> Tcl would be indeed too slow if one wanted to use it for
> computation---but I don't think this is being contemplated. I think a
> better idea is to wrap up Tk widgets into octave wrappers; so instead
> of Tcl loop running Tk widgets you'd run Octave loop.

Argh. TclTk can best be decribed as "evil" and "obsolete", and I think
the company who did this (Scriptics, which changed the name and was
bought) has dropped it.

If a GUI is to be made, I think using gtk+ would be better - it's the
foundation of GNOME, GNU's desktop. If taking the next step and using
gnome, visualization could be done through bonobo.

--
Trond Eivind Glomsrød
Red Hat, Inc.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Jonathan King-2
In reply to this post by John W. Eaton-6

On 11 Dec 2000 [hidden email] wrote:
>
> Argh. TclTk can best be decribed as "evil" and "obsolete", and I think
> the company who did this (Scriptics, which changed the name and was
> bought) has dropped it.

No huge disagreement about Tcl, but the Tk GUI library is still a wildly
successful product, with good bindings to it available from (among others)
perl, python, scheme, haskell, and others I know I'm forgetting.  The
Perl/Tk project has also procuced a version of Tk (pTk) that is
disentangled from the tcl-ish parts.

Tcl and Tk, meanwhile, are being kept alive in the free/open software
community:

http://sourceforge.net/projects/tcl/

(This is worth mentioning in that I thought Octave had, at one time, some
kind of sourceforge presence itself.)
 
> If a GUI is to be made, I think using gtk+ would be better - it's the
> foundation of GNOME, GNU's desktop. If taking the next step and using
> gnome, visualization could be done through bonobo.

I haven't looked at gtk+ bindings recently (I know they exist), but it
used to be that one huge advantage of the Tk approach was that it was
high-level enough to use in short-and-sweet programs.  Plus, I think it
matches fairly well with the kind of GUI projects that I suspect would be
built on top of Octave.  None of this is to say that Tk is the only way to
go, but I think that Tk has a stronger case than some people may realize.

jking



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Joao Cardoso-8
In reply to this post by Trond Eivind Glomsrød-2
Trond Eivind GlomsrØd wrote:

> >    Tcl is too slow, especially since everyone is obviously concerned about
> >    execution time.  I say we should use C++m which Octave can already
> >    dynamicly load.
> >
> > Tcl would be indeed too slow if one wanted to use it for
> > computation---but I don't think this is being contemplated. I think a
> > better idea is to wrap up Tk widgets into octave wrappers; so instead
> > of Tcl loop running Tk widgets you'd run Octave loop.
>
> Argh. TclTk can best be decribed as "evil" and "obsolete", and I think
> the company who did this (Scriptics, which changed the name and was
> bought) has dropped it.
>
> If a GUI is to be made, I think using gtk+ would be better - it's the
> foundation of GNOME, GNU's desktop. If taking the next step and using
> gnome, visualization could be done through bonobo.

This problem has been raised several times in the mailing lists.
Yes, tcl is ugly, but using Tk as a GUI is fast enought (look at
<a href="http://merlin.inescn.pt/Šþqual/tk_octave">http://merlin.inescn.pt/Šþqual/tk_octave)

Yes, gtk is nicer; no, xxx is slow, ah, but yyy is promising, no ZZZ is
"first principles" based!

This is not the correct way. Define a generic interface and let each one
use what he likes! Don't bind Octave to anything more than is just
needed: using GNOME or XXX or YYY would limit users to linux (and unix
is more than just linux!; and the dos/windows/mac guys?). This is also
true for ploting; as is now, Octave can be used with gnuplot, even on
mac, ms-windows, or amiga, or atari (!?).

As I see it, TK, being multi-platform (mac, u*nix, mswin), is the ideal
approach for a prototype implementation; also, the tk-perl/phyton
approach could be analysed and eventually used.

tcl/tk, being free soft, has no problems, as its creator/maintainer life
show us: sun/scriptics/ajuba, and now something else.

Joao

PS- John Eaton, thanks a lot for Octave and personal support in the last
half decade! Let the Force be with you!

--
João Cardoso, [hidden email]
Gab. I-314, tel. 1888



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Trond Eivind Glomsrød-2
João Cardoso <[hidden email]> writes:

> Trond Eivind GlomsrØd wrote:
>
> > >    Tcl is too slow, especially since everyone is obviously concerned about
> > >    execution time.  I say we should use C++m which Octave can already
> > >    dynamicly load.
> > >
> > > Tcl would be indeed too slow if one wanted to use it for
> > > computation---but I don't think this is being contemplated. I think a
> > > better idea is to wrap up Tk widgets into octave wrappers; so instead
> > > of Tcl loop running Tk widgets you'd run Octave loop.
> >
> > Argh. TclTk can best be decribed as "evil" and "obsolete", and I think
> > the company who did this (Scriptics, which changed the name and was
> > bought) has dropped it.
> >
> > If a GUI is to be made, I think using gtk+ would be better - it's the
> > foundation of GNOME, GNU's desktop. If taking the next step and using
> > gnome, visualization could be done through bonobo.
>
> This problem has been raised several times in the mailing lists.
> Yes, tcl is ugly, but using Tk as a GUI is fast enought (look at
> <a href="http://merlin.inescn.pt/Šþqual/tk_octave">http://merlin.inescn.pt/Šþqual/tk_octave)
>
> Yes, gtk is nicer; no, xxx is slow, ah, but yyy is promising, no ZZZ is
> "first principles" based!
>
> This is not the correct way. Define a generic interface and let each one
> use what he likes!

Sure, I'm quite happy with the text interface myself.

> Don't bind Octave to anything more than is just needed: using GNOME
>or XXX or YYY would limit users to linux (and unix is more than just
>linux!

Gtk+/GNOME is not in anyway Linux-specific, and is even backed by Sun,
HP, IBM etc. There is a Gtk+ port for Windows, while I don't think
there is one for Mac.

> and the dos/windows/mac guys?). This is also true for ploting; as is
>now, Octave can be used with gnuplot, even on mac, ms-windows, or
>amiga, or atari (!?).

Yes, but gnuplot is Octave's weakest point - it doesn't hold a candle
to Matlab, which was my favorite visualization tool.

In order to not write code specific to Octave, the best way is to use
software components - and that means doing platform specific things
(bonobo (a CORBA layer) on UNIX, OLE on Windows, <foo> on Mac)

> PS- John Eaton, thanks a lot for Octave and personal support in the last
> half decade!

Certainly - it's a very nice piece of software.

--
Trond Eivind Glomsrød
Red Hat, Inc.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Wishlist (Was: Re: The future of Octave)

Kevin Straight
In reply to this post by Jonathan C. Webster
One feature I could use that has NOTHING to do with GUI (which I agree
belongs on the other list) would be a really good macro expansion
facility, which would be a real convenience when scripting.  

I would want to be able to define multi-line macros with arguments.  I
would also want a conditional directives (like in the C preprocessor) and
the ability to include other script files (like the C include statement).  

Any idea how hard this would be?  Of course, maybe Octave already has
something like this, and I'm just missing it...

==========================
Kevin Straight
University of Idaho
www.uidaho.edu/Šþstra9456
==========================



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: Wishlist (Was: Re: The future of Octave)

Johan Kullstam-3
Kevin Straight <[hidden email]> writes:

> One feature I could use that has NOTHING to do with GUI (which I agree
> belongs on the other list) would be a really good macro expansion
> facility, which would be a real convenience when scripting.

you might want to look at matlisp.  it's essentially lapack added to
common-lisp (either cmucl or franz allegro).  if you want the power of
macros, nothing i've seen can do macros as powerful as common-lisp.

> I would want to be able to define multi-line macros with arguments.  I
> would also want a conditional directives (like in the C preprocessor) and
> the ability to include other script files (like the C include statement).  
>
> Any idea how hard this would be?  Of course, maybe Octave already has
> something like this, and I'm just missing it...

i think the real problem is that the matlab/octave language is too
brittle for really good macro action.  to support macros, it helps to
have a very simple syntax (like lisp does).

--
J o h a n  K u l l s t a m
[[hidden email]]
Don't Fear the Penguin!



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


1234