Rik | 23 Jul 02:06 2014

Re: Overhaul FLTK toolkit resize/redraw functions

On 07/22/2014 10:01 AM, octave-maintainers-request <at> gnu.org wrote:
Subject:
Overhaul FLTK toolkit resize/redraw functions
From:
Andreas Weber <octave <at> tech-chat.de>
Date:
07/22/2014 10:01 AM
To:
octave-maintainers <at> gnu.org
List-Post:
<mailto:octave-maintainers <at> gnu.org>
Precedence:
list
MIME-Version:
1.0
Message-ID:
<53CE98D6.1020100 <at> tech-chat.de>
Content-Type:
multipart/mixed; boundary="------------070305070909080306000007"
Message:
2

Dear maintainers, I tried to overhaul the FLTK resize and redraw functions and want to ask for your optinion and if you could apply the patch and test it a little bit. There are many "std::cout <<" debugging ouputs commented which are of course removed before commit. My aim was: * Avoid redraw of the OpenGL and the plot window if not needed. Moving the mouse priviously caused a redraw of the OpenGL window. * Let FLTK do the resize of the canvas, the menubar and statusbar. This was done by creating a resize_dummy and set this as resizable for the plot_window group. Previously this was done inside draw(). * Avoid timing issues with fltk_maxtime (removed) and other hacks. You can use flush is you really need to force a immediate redraw. * Add debug_file output for graphics_toolkit fltk so that drawnow("eps", "gs", false, "sombrero.eps") is possible. This is redundant with "print -color out.eps" and will be removed. * Manually placement of the toolbar is only done once when hiding or showing the menubar. (update_toolbar_position) * set(gcf, "position", [x, y, w, h]) is now handled by figure::properties::ID_POSITION which calls figure_manager::update_position; I want to also list some problems I noticed while testing the changes for the records. (Output of compare_plot_demos is fine so far) * I don't like the "gui_mode" which is the same for all figures. Switching to pan/rotate therefore influences the other figures. I suggest adding a figure property for this. What does ML do? The current approach also makes it difficult to check in DEFUN_DLD (gui_mode..) if the requested rotate+zoom mode is valid (it's not for ndims==2). Until now you could switch to rotate+zoom using the uimenu even for 2D plots. * Save As from the uimenu doesn't work because __uiputfile_fltk__ was moved to private and the path is missing (easy to fix) * The new "legend" can be moved while panning. Try t=linspace(0,6*pi); plot(t, sin(t), ";sin;", t, cos(t), ";cos;") and drag the legend with the mouse. Another idea (independent of the above) was to make a script for testing the FLTK toolkit functions which needs human interaction or judgment. I've attached human_driven_fltk_test.m to give you a rough idea what I was trying to address. But soon I lost my enthusiasm because it creates doubt who will run it. The normal users shouldn't be bothered with this and the core devs know how the toolkit should behave. Any feedback appreciated :-D
Andy,

Overall I like it.  I've been concerned for a while about the performance implications of all the refreshes.

Another difference I notice, which should be easy to fix, is that actions from the Edit menu do not take effect immediately.  One way to get it to take effect is to go back to the command line and hit return.  The keyboard shortcut 'g' and the toolbar at the bottom of the figure both work immediately so you could probably just copy whatever strategy was used there.

The legend can be panned separately from rest of the figure because it is also implemented as an axes object.  However, all axes have the graphics property 'tag' set to 'legend'.  It should be easy to check if the current object is a legend and skip panning.

--Rik
Andreas Weber | 22 Jul 19:01 2014
Picon

Overhaul FLTK toolkit resize/redraw functions

Dear maintainers,

I tried to overhaul the FLTK resize and redraw functions and want to ask
for your optinion and if you could apply the patch and test it a little
bit. There are many "std::cout <<" debugging ouputs commented which are
of course removed before commit. My aim was:

* Avoid redraw of the OpenGL and the plot window if not needed.
  Moving the mouse priviously caused a redraw of the OpenGL window.

* Let FLTK do the resize of the canvas, the menubar and statusbar.
  This was done by creating a resize_dummy and set this as resizable
  for the plot_window group. Previously this was done inside draw().

* Avoid timing issues with fltk_maxtime (removed) and other hacks.
  You can use flush is you really need to force a immediate redraw.

* Add debug_file output for graphics_toolkit fltk so that
  drawnow("eps", "gs", false, "sombrero.eps") is possible.
  This is redundant with "print -color out.eps" and will be removed.

* Manually placement of the toolbar is only done once when hiding or
  showing the menubar. (update_toolbar_position)

* set(gcf, "position", [x, y, w, h]) is now handled by
  figure::properties::ID_POSITION which calls
  figure_manager::update_position;

I want to also list some problems I noticed while testing the changes
for the records. (Output of compare_plot_demos is fine so far)

* I don't like the "gui_mode" which is the same for all figures.
  Switching to pan/rotate therefore influences the other figures.
  I suggest adding a figure property for this. What does ML do?
  The current approach also makes it difficult to check in
  DEFUN_DLD (gui_mode..) if the requested rotate+zoom mode is
  valid (it's not for ndims==2). Until now you could switch to
  rotate+zoom using the uimenu even for 2D plots.

* Save As from the uimenu doesn't work because __uiputfile_fltk__ was
  moved to private and the path is missing (easy to fix)

* The new "legend" can be moved while panning. Try
  t=linspace(0,6*pi); plot(t, sin(t), ";sin;", t, cos(t), ";cos;")
  and drag the legend with the mouse.

Another idea (independent of the above) was to make a script for testing
the FLTK toolkit functions which needs human interaction or judgment.
I've attached human_driven_fltk_test.m to give you a rough idea what I
was trying to address. But soon I lost my enthusiasm because it creates
doubt who will run it. The normal users shouldn't be bothered with this
and the core devs know how the toolkit should behave.

Any feedback appreciated :-D
-- Andy
Attachment (fltk_overhaul.diff): text/x-diff, 23 KiB
Attachment (human_driven_fltk_test.m): text/x-objcsrc, 2856 bytes
Michael Goffioul | 22 Jul 16:37 2014
Picon

Fwd: New package

Forgot to Cc the mailing list.


---------- Forwarded message ----------
From: Michael Goffioul <michael.goffioul <at> gmail.com>
Date: Tue, Jul 22, 2014 at 10:36 AM
Subject: Re: New package
To: Guillermo Moliní <guillermoly <at> gmail.com>


On Tue, Jul 22, 2014 at 9:58 AM, Guillermo Moliní <guillermoly <at> gmail.com> wrote:



2014-07-22 15:48 GMT+02:00 Ben Abbott <bpabbott <at> mac.com>:

On Jul 22, 2014, at 9:37 AM, Guillermo Moliní <guillermoly <at> gmail.com> wrote:

> 2014-07-22 15:31 GMT+02:00 Carlo de Falco <carlo.defalco <at> gmail.com>:
> I am afraid what you want to do is not legally possible.
> Please Do NOT post your code here.
> c.
>
> What do you mean with not legally possible?
> If you mean that cuda is propietary, id say thats true, but im not modifying anything, just making use of the api. There are other examples of opensource libraries that do the same, like http://managedcuda.codeplex.com/

The terms of the GNU license make it illegal.  Or has the source code for the cuda code been made freely available?

Ben



What terms of the GNU License make it illegal? the link I just gave you above also has a GNU Library General Public License (LGPL), and does what I intend to do. That is, provide a wrapper (in that case for c#, in mine for octave), so that the cuda api can be used. Couldnt it be considered the cuda API as a system library under section 7?

 

Writing an oct-file requires you to release it under a GPLv3-compatible license. However, this is not possible if the same code also makes use of another library (like CUDA) which is not compatible with GPLv3. Whether you distribute your code in source form or binary form does not matter. And I don't think that CUDA falls under the system library definition, though you might want to ask FSF about that.

The link you gave about is a different situation: it only makes use of CUDA (as far as I understand), so it can be released under any license that is compatible with CUDA's license. But as long as you want to turn your code into an oct-file, you need to be compatible with GPLv3.

Michael.


Drew Abbot | 22 Jul 04:40 2014
Picon

bugs in periodogram.m (and proposed fixes)

There are two bugs in the current periodogram() implementation, and here's a new version which fixes both.  The first bug is that, when using one-sided spectra (the default behavior), only column vectors are supported for the input signal, x.  Sending in row vectors causes a "vertical dimensions mismatch" error due to this one-sided conversion code:
  
  Pxx = Pxx(1:nfft/2+1) + [0; Pxx(end:-1:(nfft/2+2)); 0];

To witness the bug, simply attempt:

  pxx = periodogram( sin(1:10) )

The second also involves that one-sided conversion code.  Namely, it is incorrect when nfft is odd, since it yields 1/2 the correct value at the upper-most (non-Nyquist) frequency.

To see this, note that the following returns ~0.0171 for the third component, when it should return ~0.0342:

  pxx = periodogram( sin(1:5)', [], 5 )

The attached code fixes both issues (using similar one-sided conversion code to that found in the current pwelch() implementation), and also forces that the window (if non-empty) is a vector of the same length as the signal (which is the current MATLAB behavior).

Best,
Drew Abbot
## Copyright (C) 1995-2013 Friedrich Leisch
## Copyright (C) 2010 Alois Schloegl
## Copyright (C) 2014 Drew Abbot
##
## This file is part of Octave.
##
## Octave is free software; you can redistribute it and/or modify it
## under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 3 of the License, or (at
## your option) any later version.
##
## Octave is distributed in the hope that it will be useful, but
## WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
## General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with Octave; see the file COPYING.  If not, see
## <http://www.gnu.org/licenses/>.

## -*- texinfo -*-
##  <at> deftypefn {Function File} {[Pxx,  <at> var{w}] =} periodogram ( <at> var{x})
## For a data matrix  <at> var{x} from a sample of size  <at> var{n}, return the
## periodogram.  The angular frequency is returned in  <at> var{w}.
##
## [Pxx,w] = periodogram ( <at> var{x}).
##
## [Pxx,w] = periodogram ( <at> var{x},win).
##
## [Pxx,w] = periodogram ( <at> var{x},win,nfft).
##
## [Pxx,f] = periodogram ( <at> var{x},win,nfft,Fs).
##
## [Pxx,f] = periodogram ( <at> var{x},win,nfft,Fs,"range").
##
##  <at> itemize
##  <at> item x: data; if real-valued a one-sided spectrum is estimated,
## if complex-valued or range indicates  <at> qcode{" <at> nospell{twosided}"}, the full
## spectrum is estimated.
##
##  <at> item win: weight data with window, x.*win is used for further computation,
## if window is empty, a rectangular window is used.
##
##  <at> item nfft: number of frequency bins, default max (256, 2.^ceil (log2 (length (x)))).
##
##  <at> item Fs: sampling rate, default 1.
##
##  <at> item range:  <at> qcode{" <at> nospell{onesided}"} computes spectrum from [0..nfft/2+1].
##  <at> qcode{" <at> nospell{twosided}"} computes spectrum from [0..nfft-1].  These
## strings can appear at any position in the list input arguments after
## window.
##
##  <at> item  <at> nospell{Pxx}: one-, or two-sided power spectrum.
##
##  <at> item w: angular frequency [0..2*pi) (two-sided) or [0..pi] one-sided.
##
##  <at> item f: frequency [0..Fs) (two-sided) or [0..Fs/2] one-sided.
##  <at> end itemize
##  <at> end deftypefn

## Author: FL <Friedrich.Leisch <at> ci.tuwien.ac.at>
## Description: Compute the periodogram

function [pxx, f] = periodogram (x, varargin)

  ## check input arguments

  if (nargin < 1 || nargin > 5)
    print_usage ();
  endif

  nfft = []; fs = []; range = []; window = [];
  j = 1;
  for k = 1:length (varargin)
    if (ischar (varargin{k}))
      range = varargin{k};
    else
      switch (j)
        case 1
          window = varargin{k};
        case 2
          nfft   = varargin{k};
        case 3
          fs     = varargin{k};
        case 4
          range  = varargin{k};
      endswitch
      j++;
    endif
  endfor

  if (ischar (window))
    range = window;
    window = [];
  endif;
  if (ischar (nfft))
    range = nfft;
    nfft = [];
  endif;
  if (ischar (fs))
    range = fs;
    fs = [];
  endif;

  if (isrow (x))
    x = x.';
  endif

  n = size (x,1);

  if (! isempty (window))
    if (isrow (window))
      window = window.';
    endif
    if ( size(window,1) != n || ~isvector(window) )
      error('periodogram: the window must be a vector of the same length as the signal.')
    endif
    x .*= window;
  endif

  if (numel (nfft)>1)
    error ("nfft must be scalar");
  endif
  if (isempty (nfft))
    nfft = max (256, 2.^ceil (log2 (n)));
  endif

  if (strcmp (range, "onesided"))
    range = 1;
  elseif (strcmp (range, "twosided"))
    range = 2;
  else
    range = 2-isreal (x);
  endif

  ## compute periodogram

  if (n>nfft)
    Pxx = 0;
    rr = rem (length (x), nfft);
    if (rr)
      x = [x(:); (zeros (nfft-rr, 1))];
    endif
    x = sum (reshape (x, nfft, []), 2);
  endif

  if (! isempty (window))
    n = sumsq (window);
  endif;
  Pxx = (abs (fft (x, nfft))) .^ 2 / n ;

  if (nargin<4)
    Pxx /= 2*pi;
  elseif (! isempty (fs))
    Pxx /= fs;
  endif

  ## generate output arguments

  if (range == 1)  # onesided
    if ( ~ rem(nfft,2) ) # nfft is even
      psd_len = nfft/2+1;
      Pxx = Pxx(1:psd_len) + [0; Pxx(nfft:-1:psd_len+1); 0];
    else # nfft is odd
      psd_len = (nfft+1)/2;
      Pxx = Pxx(1:psd_len) + [0; Pxx(nfft:-1:psd_len+1)];
    endif
  endif

  if (nargout != 1)
    if (range == 1)
      f = (0:nfft/2)'/nfft;
    elseif (range == 2)
      f = (0:nfft-1)'/nfft;
    endif
    if (nargin<4)
      f *= 2*pi; # generate w=2*pi*f
    elseif (! isempty (fs))
      f *= fs;
    endif
  endif

  if (nargout == 0)
    if (nargin<4)
      plot (f/(2*pi), 10*log10 (Pxx));
      xlabel ("normalized frequency [x pi rad]");
      ylabel ("Power density [dB/rad/sample]");
    else
      plot (f, 10*log10 (Pxx));
      xlabel ("frequency [Hz]");
      ylabel ("Power density [dB/Hz]");
    endif
    grid on;
    title ("Periodogram Power Spectral Density Estimate");
  else
    pxx = Pxx;
  endif

endfunction

Drew Abbot | 22 Jul 02:35 2014
Picon

bugs in periodogram.m (and proposed fixes)

There are two bugs in the current periodogram() implementation, and here's a new version which fixes both.  The first bug is that, when using one-sided spectra (the default behavior), only column vectors are supported for the input signal, x.  Sending in row vectors causes a "vertical dimensions mismatch" error due to this one-sided conversion code:
  
  Pxx = Pxx(1:nfft/2+1) + [0; Pxx(end:-1:(nfft/2+2)); 0];

To witness the bug, simply attempt:

  pxx = periodogram( sin(1:10) )

The second also involves that one-sided conversion code.  Namely, it is incorrect when nfft is odd, since it yields 1/2 the correct value at the upper-most (non-Nyquist) frequency.

To see this, note that the following returns ~0.0171 for the third component, when it should return ~0.0342:

  pxx = periodogram( sin(1:5)', [], 5 )

The attached code fixes both issues (using similar one-sided conversion code to that found in the current pwelch() implementation), and also forces that the window (if non-empty) is a vector of the same length as the signal (which is the current MATLAB behavior).

Best,
Drew Abbot
## Copyright (C) 1995-2013 Friedrich Leisch
## Copyright (C) 2010 Alois Schloegl
## Copyright (C) 2014 Drew Abbot
##
## This file is part of Octave.
##
## Octave is free software; you can redistribute it and/or modify it
## under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 3 of the License, or (at
## your option) any later version.
##
## Octave is distributed in the hope that it will be useful, but
## WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
## General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with Octave; see the file COPYING.  If not, see
## <http://www.gnu.org/licenses/>.

## -*- texinfo -*-
##  <at> deftypefn {Function File} {[Pxx,  <at> var{w}] =} periodogram ( <at> var{x})
## For a data matrix  <at> var{x} from a sample of size  <at> var{n}, return the
## periodogram.  The angular frequency is returned in  <at> var{w}.
##
## [Pxx,w] = periodogram ( <at> var{x}).
##
## [Pxx,w] = periodogram ( <at> var{x},win).
##
## [Pxx,w] = periodogram ( <at> var{x},win,nfft).
##
## [Pxx,f] = periodogram ( <at> var{x},win,nfft,Fs).
##
## [Pxx,f] = periodogram ( <at> var{x},win,nfft,Fs,"range").
##
##  <at> itemize
##  <at> item x: data; if real-valued a one-sided spectrum is estimated,
## if complex-valued or range indicates  <at> qcode{" <at> nospell{twosided}"}, the full
## spectrum is estimated.
##
##  <at> item win: weight data with window, x.*win is used for further computation,
## if window is empty, a rectangular window is used.
##
##  <at> item nfft: number of frequency bins, default max (256, 2.^ceil (log2 (length (x)))).
##
##  <at> item Fs: sampling rate, default 1.
##
##  <at> item range:  <at> qcode{" <at> nospell{onesided}"} computes spectrum from [0..nfft/2+1].
##  <at> qcode{" <at> nospell{twosided}"} computes spectrum from [0..nfft-1].  These
## strings can appear at any position in the list input arguments after
## window.
##
##  <at> item  <at> nospell{Pxx}: one-, or two-sided power spectrum.
##
##  <at> item w: angular frequency [0..2*pi) (two-sided) or [0..pi] one-sided.
##
##  <at> item f: frequency [0..Fs) (two-sided) or [0..Fs/2] one-sided.
##  <at> end itemize
##  <at> end deftypefn

## Author: FL <Friedrich.Leisch <at> ci.tuwien.ac.at>
## Description: Compute the periodogram

function [pxx, f] = periodogram (x, varargin)

  ## check input arguments

  if (nargin < 1 || nargin > 5)
    print_usage ();
  endif

  nfft = []; fs = []; range = []; window = [];
  j = 1;
  for k = 1:length (varargin)
    if (ischar (varargin{k}))
      range = varargin{k};
    else
      switch (j)
        case 1
          window = varargin{k};
        case 2
          nfft   = varargin{k};
        case 3
          fs     = varargin{k};
        case 4
          range  = varargin{k};
      endswitch
      j++;
    endif
  endfor

  if (ischar (window))
    range = window;
    window = [];
  endif;
  if (ischar (nfft))
    range = nfft;
    nfft = [];
  endif;
  if (ischar (fs))
    range = fs;
    fs = [];
  endif;

  if (isrow (x))
    x = x.';
  endif

  n = size (x,1);

  if (! isempty (window))
    if (isrow (window))
      window = window.';
    endif
    if ( size(window,1) != n || ~isvector(window) )
      error('periodogram: the window must be a vector of the same length as the signal.')
    endif
    x .*= window;
  endif

  if (numel (nfft)>1)
    error ("nfft must be scalar");
  endif
  if (isempty (nfft))
    nfft = max (256, 2.^ceil (log2 (n)));
  endif

  if (strcmp (range, "onesided"))
    range = 1;
  elseif (strcmp (range, "twosided"))
    range = 2;
  else
    range = 2-isreal (x);
  endif

  ## compute periodogram

  if (n>nfft)
    Pxx = 0;
    rr = rem (length (x), nfft);
    if (rr)
      x = [x(:); (zeros (nfft-rr, 1))];
    endif
    x = sum (reshape (x, nfft, []), 2);
  endif

  if (! isempty (window))
    n = sumsq (window);
  endif;
  Pxx = (abs (fft (x, nfft))) .^ 2 / n ;

  if (nargin<4)
    Pxx /= 2*pi;
  elseif (! isempty (fs))
    Pxx /= fs;
  endif

  ## generate output arguments

  if (range == 1)  # onesided
    if ( ~ rem(nfft,2) ) # nfft is even
      psd_len = nfft/2+1;
      Pxx = Pxx(1:psd_len) + [0; Pxx(nfft:-1:psd_len+1); 0];
    else # nfft is odd
      psd_len = (nfft+1)/2;
      Pxx = Pxx(1:psd_len) + [0; Pxx(nfft:-1:psd_len+1)];
    endif
  endif

  if (nargout != 1)
    if (range == 1)
      f = (0:nfft/2)'/nfft;
    elseif (range == 2)
      f = (0:nfft-1)'/nfft;
    endif
    if (nargin<4)
      f *= 2*pi; # generate w=2*pi*f
    elseif (! isempty (fs))
      f *= fs;
    endif
  endif

  if (nargout == 0)
    if (nargin<4)
      plot (f/(2*pi), 10*log10 (Pxx));
      xlabel ("normalized frequency [x pi rad]");
      ylabel ("Power density [dB/rad/sample]");
    else
      plot (f, 10*log10 (Pxx));
      xlabel ("frequency [Hz]");
      ylabel ("Power density [dB/Hz]");
    endif
    grid on;
    title ("Periodogram Power Spectral Density Estimate");
  else
    pxx = Pxx;
  endif

endfunction

Andreas Weber | 21 Jul 22:18 2014
Picon

demos which uses patch/legend fails after cset df972b9d080a

Dear Pantxo, since changeset

Ă„nderung:        18901:df972b9d080a
Nutzer:          Pantxo Diribarne <pantxo.diribarne <at> gmail.com>
Datum:           Sat Jun 21 13:07:57 2014 +0200
Zusammenfassung: Translate patch property listeners to C++ (bug #42159)

these demos fails with A(I,J): row index out of bounds; value 2 out of
bound 1 or A(I,J): column index out of bounds; value 3 out of bound 2

area 1
copyobj 2
legend 18
legend 19
legend 35
pie3 1
pie3 2
pie3 3
ribbon 1

for example:
octave:1> demo area 1
area example 1:
 ## Verify identity sin^2 + cos^2 = 1
 clf;
 t = linspace (0, 2*pi, 100)';
 y = [sin(t).^2, cos(t).^2];
 area (t, y);
 axis tight
 legend ('sin^2', 'cos^2', 'location', 'NorthEastOutside');
 title ('area() plot');

area example 1: failed
A(I,J): row index out of bounds; value 2 out of bound 1

-- Andy

Abbott, Ben | 21 Jul 01:18 2014

wiki is down?

Is http://wiki.octave.org down for everyone?

I'm in Central Florida.

Ben

Rik | 20 Jul 21:01 2014

Help with surfnorm compatibility

I'm trying to see whether Matlab uses colororder or the existing colormap
to determine the color for the normal vectors in surfnorm.  Could someone
run the following code in Matlab and return the two images.

clf;
colormap ('hsv');
[x,y,z] = cylinder (1:10);
surfnorm (x,y,z);
print -dpng hsv.png
colormap ('jet');
print -dpng jet.png

Thanks,
Rik

Rik | 20 Jul 20:40 2014

More help with meshz

7/20/14

I've almost got meshz to produce the same output as Matlab, but I still
have a discrepancy about the color of the edge on the boundary of the
curtain.  Could someone run the following code on a *Linux* or *Windows*
version of Matlab and send back the png and diary file?

--- Start Code ---
diary on
Z = peaks ();
h = meshz (Z(20:30, 20:30));
print -dpng tst.png
cdat = get (h, 'cdata');
cdat(1:5, 1:5)
zdat = get (z, 'zdata');
zdat(1:5, 1:5)
xdat = get (x, 'xdata');
xdat(1:5, 1:5)
ydat = get (y, 'ydata');
ydat(1:5, 1:5)
diary off
--- End Code ---

Thanks,
Rik

Magne Sjaastad | 19 Jul 10:35 2014

Invalid address in RSS feed

Hi,


I tried to use the RSS feed for the projects at http://hg.octave.org/ but they did not work as excpected. I do not think they are configured correctly. It prefer using RSS compared to mailing lists for tracking project progress.


Regards,

Magne

Charles Sweet | 18 Jul 18:37 2014

Re: Integrating Octave into Web Interface

Hi,

We (Loft Mind) are planning on integrating Octave into our Web stack.  I would like to do this in such a way as to benefit the Octave community.  Do you have similar efforts underway?   If so, we would love to participate.

Regards,
Chuck Sweet
Loft Mind, Incorporated


Gmane