octave-dev — GNU Octave developers' list

Re: [OctDev] wiki octave

[Etienne G. <et...@cs...>]

Done! Thx to you too.

  Etienne

On Mon, Jul 25, 2005 at 12:55:21PM -0400, Aaron Jackson wrote:
# Speaking of adding access to the wiki, I have some solaris 8 install 
# notes I can post.  My IP is 138.238.128.153.  Thanks.
# 
# Aaron
# 
# On Jul 25, 2005, at 11:02 AM, Etienne Grossmann wrote:
# 
# >
# >  Hi Claudio,
# >
# >I just added you to the authorized list. Sorry for the wait, I was
# >away.
# >
# >  Thx for proposing to contribute to the wiki.
# >
# >  Etienne
# >
# >On Thu, Jul 21, 2005 at 04:58:55PM +0200, Claudio Belotti wrote:
# ># I would like to contribute to wiki.octave
# ># my IP
# ># 149.139.5.111
# >#
# ># Claudio
# >#
# >#
# >#
# >#
# ># -------------------------------------------------------
# ># SF.Net email is sponsored by: Discover Easy Linux Migration 
# >Strategies
# ># from IBM. Find simple to follow Roadmaps, straightforward articles,
# ># informative Webcasts and more! Get everything you need to get up to
# ># speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
# ># _______________________________________________
# ># Octave-dev mailing list
# ># Oct...@li...
# ># https://lists.sourceforge.net/lists/listinfo/octave-dev
# >
# >-- 
# >Etienne Grossmann ------ http://www.cs.uky.edu/~etienne
# >
# >
# >-------------------------------------------------------
# >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
# >from IBM. Find simple to follow Roadmaps, straightforward articles,
# >informative Webcasts and more! Get everything you need to get up to
# >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
# >_______________________________________________
# >Octave-dev mailing list
# >Oct...@li...
# >https://lists.sourceforge.net/lists/listinfo/octave-dev
# >
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

[OctDev] Re: Octave Wiki

[Etienne G. <et...@cs...>]

  Hi Randall,

I just added your IP.  Thx for proposing to help w/ the wiki.

  Cheers,

  Etienne

On Mon, Jul 25, 2005 at 08:07:44AM -0700, Randall Schuh wrote:
# Cool - my IP is 68.126.150.4.  Let me know if you need to shut it back
# down and I'll see about getting an account with a static address,
# through which I can connect -- someday I need to get my website up and
# running again anyway.
# 
# Thanks,
# Randall
# 
# On 7/25/05, Etienne Grossmann <et...@cs...> wrote:
# > 
# > Hi Randall,
# > 
# > just send me your IP, I'll add a regexp to match IPs from your
# > provider and hope it doesn't host wiki defacers.
# > 
# >   Cheers
# > 
# >   Etienne
# > 
# > On Sun, Jul 24, 2005 at 09:47:00AM -0700, Randall Schuh wrote:
# > # Hi,
# > #
# > # I have dial-up, so I don't have a static IP.  Have you considered
# > # going to some form of password protection?  Is there any other way
# > # that I would be able to contribute to the wiki?
# > #
# > # I have hated MATLAB documentation for years.  This weekend, I started
# > # doing some personal calculations and realized how much time I could
# > # save by using MATLAB.  Then I looked it up and realized how much they
# > # charge.  Neither am I willing to pay that much nor do I think that it
# > # is productive for individuals and small companies to give the
# > # MathWorks that much money for relatively simple software.  As such, I
# > # feel compelled to contribute to the development of Octave.  My hatred
# > # for MATLAB documentation and my general love of wikiwikis would make
# > # the Octave wiki the natural place to operate.
# > #
# > # Let me know if there's any work around that will let me access the wiki -
# > #
# > # Thanks,
# > # Randall Schuh
# > #
# > 
# > --
# > Etienne Grossmann ------ http://www.cs.uky.edu/~etienne
# > 
# > 
# 
# 
# -- 
# PS I guess I will be calling myself that from now on -- Margit doesn't
# like "Randy" (which I never used at work because I thought it would be
# awkward for introductions) and I'm getting accusomed to being called
# "Randall".  Feel free to call me whatever you want -- for my part --
# but be prepared for me to use Randall.
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] wiki octave

[Etienne G. <et...@cs...>]

  Hi Claudio,

I just added you to the authorized list. Sorry for the wait, I was
away.

  Thx for proposing to contribute to the wiki.

  Etienne

On Thu, Jul 21, 2005 at 04:58:55PM +0200, Claudio Belotti wrote:
# I would like to contribute to wiki.octave
# my IP
# 149.139.5.111
# 
# Claudio
# 
# 
# 
# 
# -------------------------------------------------------
# SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
# from IBM. Find simple to follow Roadmaps, straightforward articles,
# informative Webcasts and more! Get everything you need to get up to
# speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Stefan v. d. W. <st...@su...>]

ImageMagick unfortunately also links to libjpeg and libpng to read
those two formats.  Also, the libMagick API has changed from version 6
to 8 -- some distributions like Debian keep to v6 while others like
Mandrake have moved to v8.

Whichever way, the API example given on their webpage compiles but
doesn't run with either versions!

St=E9fan

On Sun, Jul 24, 2005 at 08:24:11AM -0400, Andy Adler wrote:
> St=E9fan,
>=20
> That sounds like a good idea. On the other hand, a better implementatio=
n
> would be to write an oct file  to link to the imagemagick libraries dir=
ectly.
>=20
> After that, the only reason to have jpgread etc is for users that don't=
 have
> libmagick.a.
>=20
> What do you think?
>=20
> Andy
>=20
> On 7/24/05, Stefan van der Walt <st...@su...> wrote:
> > Last time I checked, the pipes implementation was much slower than th=
e
> > file approach for large images.  Can you verify whether this is still
> > the case?
> >=20
> > I have made some fixes to pngread and jpegread, which I will submit
> > soon.  Then, we can use those functions in imread.m to load JPGs and
> > PNGs, but revert to ImageMagick otherwise.
> >=20
> > Regards
> > St=E9fan

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Andy A. <ax...@gm...>]

St=E9fan,

That sounds like a good idea. On the other hand, a better implementation
would be to write an oct file  to link to the imagemagick libraries directl=
y.

After that, the only reason to have jpgread etc is for users that don't hav=
e
libmagick.a.

What do you think?

Andy

On 7/24/05, Stefan van der Walt <st...@su...> wrote:
> Last time I checked, the pipes implementation was much slower than the
> file approach for large images.  Can you verify whether this is still
> the case?
>=20
> I have made some fixes to pngread and jpegread, which I will submit
> soon.  Then, we can use those functions in imread.m to load JPGs and
> PNGs, but revert to ImageMagick otherwise.
>=20
> Regards
> St=E9fan
>=20
> On Thu, Jul 21, 2005 at 04:03:08PM +0000, andy adler wrote:
> > Update of /cvsroot/octave/octave-forge/main/image
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22457/main/image
> >
> > Modified Files:
> >       imread.m imwrite.m
> > Log Message:
> > Improve error messages and use pipes
> >
> > Index: imread.m
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > RCS file: /cvsroot/octave/octave-forge/main/image/imread.m,v
> > retrieving revision 1.11
> > retrieving revision 1.12
> > diff -u -d -r1.11 -r1.12
>

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Stefan v. d. W. <st...@su...>]

Last time I checked, the pipes implementation was much slower than the
file approach for large images.  Can you verify whether this is still
the case?

I have made some fixes to pngread and jpegread, which I will submit
soon.  Then, we can use those functions in imread.m to load JPGs and
PNGs, but revert to ImageMagick otherwise.

Regards
St=E9fan

On Thu, Jul 21, 2005 at 04:03:08PM +0000, andy adler wrote:
> Update of /cvsroot/octave/octave-forge/main/image
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22457/main/image
>=20
> Modified Files:
> 	imread.m imwrite.m=20
> Log Message:
> Improve error messages and use pipes
>=20
> Index: imread.m
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/octave/octave-forge/main/image/imread.m,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -d -r1.11 -r1.12

[OctDev] wiki octave

[Claudio B. <be...@li...>]

I would like to contribute to wiki.octave
my IP
149.139.5.111

Claudio

Re: [OctDev] new branch

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

Keep 2.9.* on the trunk and branch off tag R2005-06-13.

As far as I know this has not yet been done, but it looks like it can=20
be done any time:

	http://www.psc.edu/~semke/cvs_branches.html

Feel free to commit 2.9.* changes immediately.

- Paul

On Jul 19, 2005, at 4:18 AM, Stefan van der Walt wrote:

> There was talk a while ago of branching octave forge, so that we can
> start committing changes compatible with 2.9.* only.  Has this been=20
> done?
>
> Regards
> St=E9fan

[OctDev] new branch

[Stefan v. d. W. <st...@su...>]

There was talk a while ago of branching octave forge, so that we can
start committing changes compatible with 2.9.* only.  Has this been done?

Regards
St=E9fan

[OctDev] Re: octave ready for manual translation

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

If you want to help with the octave translation project, the tree is=20
now available at source-forge.  Go to the source-forge site and create=20=

an account for yourself, then send a request to oct...@li...=20=

to be included in the project.

Once you have done that, check out the new octave-lang module using=20
your sourceforge id $SFID

	cvs -d:ext:$SF...@cv...:/cvsroot/octave co octave-lang

- Paul

On Jul 16, 2005, at 12:54 AM, Jorge Barros de Abreu wrote:

> Hi for All.
>
> I make some changes that put in
> http://usr.solar.com.br/~ficmatin/octave-lang.tar.gz
>
> The solution is very handiwork and not professional but work and is=20
> open for
> refine and suggestions.
>
> []=B4s
>
>
>
> -------------------------------------------------------------
> 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
> -------------------------------------------------------------
>

[OctDev] complex polar form routines

[Richardson, A. <ar...@ev...>]

I've written two simple m-files (to_p.m and to_r.m) that convert=20
complex numbers to/from standard form from/to the polar form that
it is often used in electrical engineering.

Please add them to the forge.

Usage notes and examples are included as comments in the code.

Thanks
Tony Richardson

## Copyright (C) 2005 Anthony M. Richardson
##
## This program 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 2
## of the License, or (at your option) any later version.
##
## This program 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 this program; if not, write to the Free Software
## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.

## Author: Tony Richardson <ric...@ev...>
## Created: July 2005

function [R, Theta] =3D to_p(A,opt)
% [R, Theta] =3D to_p(A, opt) - Convert from rectangular to polar form.
% With single return argument:
%   If opt =3D=3D 1 (default)
%     Returns magnitudes and phases in alternate columns
%   If opt =3D=3D 2
%     Returns magnitudes
%   If opt =3D=3D 3
%     Returns phase angles
% With two return arguments:
%   Returns magnitudes and phase angle (in degrees) matrices.
%   (opt is ignored)
%
% Notes:
%   1) to_p() displays complex numbers in the polar form that is often
%      used in electrical engineering. Results from to_p() are typically
%      not used for additional computation.
%   2) to_r() is the corresponding inverse function.
%
% Examples:
%  > % Convert a complex matrix to polar form
%  > R =3D to_p([i 3+4*i; 0 10; 2+2*i 5])
%  R =3D
%
%  1.00000  90.00000   5.00000  53.13010
%  0.00000   0.00000  10.00000   0.00000
%  2.82843  45.00000   5.00000   0.00000
%
%  > % Generate random voltage and impedance matrices
%  > V =3D 10*rand(3,1)+i*10*rand(3,1);
%  > Z =3D 1000*rand(3,3)+i*1000*rand(3,3);
%  > I =3D Z\V
%  I =3D
%
%  0.0069266 + 0.0067151i
%  0.0053507 - 0.0158189i
%  0.0095161 + 0.0070036i
%
%  > % Display currents in polar form
%  > to_p(I)
%  ans =3D
%
%  9.6473e-03    4.4112e+01
%  1.6699e-02   -7.1312e+01
%  1.1816e-02    3.6352e+01
%
%  > % In the last example, we find I1 =3D 9.65 mA /_ 44.1 degrees, I2 =
=3D
%  > % 16.7 mA /_ -71.3 degress and I3 =3D 11.8 mA /_ 36.4 degrees.

 if (nargout <=3D 1)=20
   % Only a single return argument.
   if nargin =3D=3D 1=20
     % Return the mag and phase in adjacent columns.
     nc =3D 2*size(A,2);
     R =3D zeros(size(A,1),nc);
     R(:,1:2:nc) =3D abs(A);
     Theta =3D arg(A)*180./pi;
     R(:,2:2:nc) =3D Theta;
   else
     if opt =3D=3D 1=20
       % Return the mag and phase in adjacent columns.
       nc =3D 2*size(A,2);
       R =3D zeros(size(A,1),nc);
       R(:,1:2:nc) =3D abs(A);
       Theta =3D arg(A)*180./pi;
       R(:,2:2:nc) =3D Theta;
     elseif opt =3D=3D 2=20
       % Return only the mag
       R =3D abs(A);
     elseif opt =3D=3D 3=20
       % Return only the phase (in degrees)
       R =3D arg(A)*180./pi;
     else
       error("invalid second argument");
     end
   end
 elseif nargout =3D=3D 2=20
   % With two return arguments, the mag and phase are in stored in
   % separate matrices
   R =3D abs(A);
   Theta =3D arg(A)*180./pi;
 else
   error("invalid number of return arguments");
 end
endfunction



## Copyright (C) 2005 Anthony M. Richardson
##
## This program 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 2
## of the License, or (at your option) any later version.
##
## This program 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 this program; if not, write to the Free Software
## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.

## Author: Tony Richardson <ric...@ev...>
## Created: July 2005

function [A] =3D to_r(R,Theta)
% A =3D to_r(R,Theta) - Convert from polar to rectangular form.
% With single argument R:
%   R must have an even number of columns. Alternate columns contain the
%   magnitudes and phase angles (in degrees).
% With two arguments R and Theta:
%    R is a matrix containing the magnitudes
%    Theta is a matrix containing the phase angles (in degrees).
%
% Notes:
%  1) to_r() converts complex numbers from the polar form that is
%     common in electrical engineering to standard rectangular form.
%     When performing calculations, all complex matrices should be
%     in standard (rectangular) form.  There are not octave routines
%     that work directly with "polar form" complex matrices.
%  2) to_p() is the corresponding inverse function.
%
% Examples:
%  > % Assume we have a four impedances equal to 100/_ 45, 50+50*i, 200,
%  > % 80 /_ 90.  We can easily create a corresponding impedance matrix
%  > % in standard form as:
%  > Z =3D [to_r(100, 45) 50+50*i; 200 to_r(80, 90)]
%  Z =3D
%
%   70.71068 +  70.71068i   50.00000 +  50.00000i
%  200.00000 +   0.00000i    0.00000 +  80.00000i
%
%  > % Or, if we have two voltages equal to (polar form) 200 /_45, and
100.
%  > % We can create the corresponding complex vector as:
%  > V =3D to_r([200 45; 100 0])
%  V =3D
%
%  141.42 + 141.42i
%  100.00 +   0.00i
%
%  > % The corresponding currents can be determined using:
%  > I =3D Z\V
%  I =3D
%
%  0.86364 - 0.64282i
%  1.60706 + 0.90909i
%
%  > % The currents can be displayed in polar form with to_p():
%  > to_p(I)
%  ans =3D
%
%    1.0766  -36.6612
%    1.8464   29.4962

 if nargin > 2=20
    error("incorrect number of arguments.");
 end

 if nargin =3D=3D 1=20
   % If there is a single argument, the mag and phase are
   % in adjacent columns.
   nc =3D size(R,2);
   if (nc - fix(nc/2)*2) =3D=3D 1=20
     error("single argument must have have an even number of columns");
   end
   A =3D R(:,1:2:nc).*exp(i*pi*R(:,2:2:nc)/180.);
 elseif nargin =3D=3D 2=20
   % With two arguments, the mag and phase are in separate matrices
   if ~all(size(R) =3D=3D size(Theta))=20
      error("arguments must be of the same dimension.");
   end
   A =3D R.*exp(i*pi*Theta/180.);
 end
endfunction

[OctDev] Re: translation test

[Jorge B. de A. <fic...@so...>]

That is OK Paul.

Em Thu 14 Jul 2005 11:59, Paul Kienzle escreveu:
> You don't find out that you need to update the translation until there
> is another release of octave.

[OctDev] Re: translation test

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

We run md5sum on the base files in the directory 
octave-lang/base/octave/help/*.

We put the md5sum along with the CVS revision number of the 
octave-lang/base/octave/help/* file in the first line of the file in 
octave-lang/pt/octave/help/*.

Whenever there is a new release of octave, somebody extracts the 
docstrings and puts them in octave-lang/base/octave/help
and commits all the changes.

Translators run langcheck on their directory which compares the md5sum 
of each translated file with the md5sum of the file in 
octave-lang/base/octave/help/*.   This reports which files need to be 
updated.  Use

	cvs diff -cp -r <rev> octave-lang/base/octave/help/fn

to get a report of the changes to the original text.

You don't find out that you need to update the translation until there 
is another release of octave.

The live help system will query octave for the base text, compute the 
md5sum compare that to the md5sum of the translated text and report to 
the user that the translation is out of date, possibly reporting both 
the original text and the out of date translation.  This isn't 
implemented yet since it requires some slight modifications to Octave.

You don't upload things to the net yet since I haven't created the 
octave-lang tree.

- Paul

On Jul 14, 2005, at 6:43 AM, Jorge Barros de Abreu wrote:

> The following files is translated:
>
> __abcddims__.pt
> __axis_label__.pt
> __bodquist__.pt
> __end__.pt
> __errcomm__.pt
> __errplot__.pt
> __freqresp__.pt
> __glpk__.pt
>
> How to get the latest version for update the translation and 
> recalculate the
> md5 key???
> How to know if any of its do not was modified tree hours ago???
> In which link on the internet to take it ???
>
> Thanks
>
>
> Em Thu 14 Jul 2005 08:16, Stefan van der Walt escreveu:
>
>> I'm tempted to say that
>> this should be left as a responsibility to the translator, i.e. make
>> sure to note the version/date of the checkout you use.
>

Re: [OctDev] Re: octave-forge translation packages

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

It's hard to understand all this because we're making it up as we go=20
along.

Assuming we have people motivated to do the translations and tools to=20
help them figure out what needs to be translated and what has changed=20
since it was last translated, how should we organize the translated=20
packages in a way that is convenient for package maintainers,=20
translators and users?

Package maintainers want to release their package when they are done. =20=

They don't want to wait upon a half dozen translators who may or may=20
not care about their particular package to finally get around to=20
finishing the translation.

Translators want a big set of text to translate.  They don't want to go=20=

through 20 different packages checking which
strings are still needed or which translations are now out of date.

Users want the translations for their language to be distributed with=20
the packages they want to install.

Any suggestions how we can organize the translation effort to achieve=20
this contradictory goals?

- Paul

On Jul 9, 2005, at 9:23 AM, S=F8ren Hauberg wrote:

> Sorry about the late reply...
> I must admit I don't understand all of this, which makes it hard for=20=

> me to answer wether or not my package system could be used for this.=20=

> Is there a thread I should read, to get the details of how translation=20=

> should be done?
>
> It seems to me that translating the manual and the help texts should=20=

> be rather trivial. I just don't see how you would translate=20
> non-standard error messages or any other kind of function specific=20
> text output.
>
> Most of the programs I run on my PC are translated into Danish, which=20=

> is very nice, except when a program is only half translated. A partly=20=

> translated program is very annoying to use as it forces you to think=20=

> in two languages. I'm saying this because I have a very strong feeling=20=

> that Octave would end up being such a program. Atleast, I know I get=20=

> alot of code from different people around the world, and these people=20=

> would most certainly not translate their functions to Danish.
>
> Anyway, to summarize this post
> 1) Is there a thread I should read to understand all this translation=20=

> stuff?
> 2) Should Octave really be translated? Wouldn't it be better to simply=20=

> try to translate the manual, and then leave it at that?
>
> /S=F8ren
>
> Paul Kienzle wrote:
>> All,
>> I suggest we put translations for various octave packages in a new=20
>> top-level directory in the octave-forge CVS server:
>>     octave-lang
>> I recommend keeping the translation for each language as a separate=20=

>> distribution to reduce coordination efforts.  I don't want to wait=20
>> until the translators for twenty different languages complete their=20=

>> work before releasing a package.  The translators don't want to dig=20=

>> through twenty different packages to see what needs to be translated.
>> What do the octave packagers for various platforms think about this? =20=

>> With complete translations, each language could add 1/2 Mb or more to=20=

>> the distribution.  Would the octave packaging system be able to fetch=20=

>> and install the language specific docs for the package being=20
>> installed?  Can this be a post-install operation for the package=20
>> manager?  Individual packages should of course be able to be bundled=20=

>> with their own i18n.
>> We will need octave-lang/tools for things such as docstring=20
>> extractors, hash string checkers and other programs to list what=20
>> needs to be translated for each language.  I think the installation=20=

>> tools should be part of the octave packaging system.
>> We will need octave-lang/admin for scripts to build and maintain the=20=

>> online docs and distributions.
>> We will need octave-lang/zz for each language zz we wish to=20
>> translate, including zz=3Den for those packages whose original =
language=20
>> is not English.
>> Translations for the base system will go in octave-lang/zz/octave.=20
>> Translations for individual packages (such as the packages in=20
>> octave-forge and others) will go in octave-lang/zz/<package-name>.
>> The internal structure of the package directories will be dictated by=20=

>> the package system.  It will include translations of the usual=20
>> packaging documents such as package description and README.  I=20
>> suspect it will have a subdirectory for functions and maybe another=20=

>> for the manual and another to contain translated demos.  We will=20
>> eventually need a directory for translated warnings, error messages,=20=

>> axis labels, etc.  We may also want replacement m-files for those=20
>> functions which are to hard to translate string by string.  Somebody=20=

>> else will have to fill in the details.
>> As a convenience to translators, we will need the source documents in=20=

>> octave-lang/source/<package-name> with exactly the same structure as=20=

>> we want in zz tree.
>> Is this as simple as can be and no simpler?
>> - Paul
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in=20
> dual
> core and dual graphics technology at this free one hour event hosted=20=

> by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] Re: octave-forge translation packages

[<so...@ha...>]

Sorry about the late reply...
I must admit I don't understand all of this, which makes it hard for me=20
to answer wether or not my package system could be used for this. Is=20
there a thread I should read, to get the details of how translation=20
should be done?

It seems to me that translating the manual and the help texts should be=20
rather trivial. I just don't see how you would translate non-standard=20
error messages or any other kind of function specific text output.

Most of the programs I run on my PC are translated into Danish, which is=20
very nice, except when a program is only half translated. A partly=20
translated program is very annoying to use as it forces you to think in=20
two languages. I'm saying this because I have a very strong feeling that=20
Octave would end up being such a program. Atleast, I know I get alot of=20
code from different people around the world, and these people would most=20
certainly not translate their functions to Danish.

Anyway, to summarize this post
1) Is there a thread I should read to understand all this translation stu=
ff?
2) Should Octave really be translated? Wouldn't it be better to simply=20
try to translate the manual, and then leave it at that?

/S=F8ren

Paul Kienzle wrote:
> All,
>=20
> I suggest we put translations for various octave packages in a new=20
> top-level directory in the octave-forge CVS server:
>=20
>     octave-lang
>=20
> I recommend keeping the translation for each language as a separate=20
> distribution to reduce coordination efforts.  I don't want to wait unti=
l=20
> the translators for twenty different languages complete their work=20
> before releasing a package.  The translators don't want to dig through=20
> twenty different packages to see what needs to be translated.
>=20
> What do the octave packagers for various platforms think about this? =20
> With complete translations, each language could add 1/2 Mb or more to=20
> the distribution.  Would the octave packaging system be able to fetch=20
> and install the language specific docs for the package being installed?=
=20
>  Can this be a post-install operation for the package manager? =20
> Individual packages should of course be able to be bundled with their=20
> own i18n.
>=20
> We will need octave-lang/tools for things such as docstring extractors,=
=20
> hash string checkers and other programs to list what needs to be=20
> translated for each language.  I think the installation tools should be=
=20
> part of the octave packaging system.
>=20
> We will need octave-lang/admin for scripts to build and maintain the=20
> online docs and distributions.
>=20
> We will need octave-lang/zz for each language zz we wish to translate,=20
> including zz=3Den for those packages whose original language is not Eng=
lish.
>=20
> Translations for the base system will go in octave-lang/zz/octave.=20
> Translations for individual packages (such as the packages in=20
> octave-forge and others) will go in octave-lang/zz/<package-name>.
>=20
> The internal structure of the package directories will be dictated by=20
> the package system.  It will include translations of the usual packagin=
g=20
> documents such as package description and README.  I suspect it will=20
> have a subdirectory for functions and maybe another for the manual and=20
> another to contain translated demos.  We will eventually need a=20
> directory for translated warnings, error messages, axis labels, etc.  W=
e=20
> may also want replacement m-files for those functions which are to hard=
=20
> to translate string by string.  Somebody else will have to fill in the=20
> details.
>=20
> As a convenience to translators, we will need the source documents in=20
> octave-lang/source/<package-name> with exactly the same structure as we=
=20
> want in zz tree.
>=20
> Is this as simple as can be and no simpler?
>=20
> - Paul
>=20

[OctDev] Fwd: New: octave-forge-2005.06.13-1 for Cygwin

[James R. P. <ant...@ya...>]

Octave Forge Developers,

Please feel free to try the new cygwin package announced below.  I am
subscribed to mai...@oc..., if you want to send comments there, or to
the cygwin list identified below.

Thanks,

Jim Phillips


--- "James R. Phillips" <ant...@ya...> wrote:

> Date: Fri, 8 Jul 2005 07:13:52 -0700 (PDT)
> From: "James R. Phillips" <ant...@ya...>
> Subject: New: octave-forge-2005.06.13-1 for Cygwin
> To: cyg...@cy..., mai...@oc...
> 
> INFO
> ====
> octave-forge-2005.06.13 has been packaged for cygwin.  This package requires
> and supplements octave-2.1.71-1.
> 
> The octave-forge project contains over 500 contributed functions for GNU
> Octave
> which are not in the main distribution. These functions are grouped according
> to the following subdirectories: audio, comm, control, general, geometry,
> ident, image, io, linear-algebra, miscellaneous, optim, path, plot, set,
> signal, sparse, specfun, special-matrix, splines, statistics, strings,
> struct,
> symbolic, time. The Cygwin distribution of octave-forge also incorporates
> m-files from the octave-ci collection.
> 
> octave-forge home page: http://octave.sourceforge.net
> 
> octave-ci collection: ftp://ftp.ci.tuwien.ac.at/pub/octave/octave-ci.tar.gz
> 
> 
> UPDATE
> ======
> 
> To update your installation, click on the "Install Cygwin now" link on the
> http://cygwin.com/ web page.  This downloads setup.exe to your system.  Save
> it
> and run setup, answer the questions and pick up 'octave-forge' from the
> 'Math'
> category. Then click on the 'skip' field next to 'octave-forge' until
> '2005.06.13-1' is displayed.
> 
> DOWNLOAD:
> =========
> Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed
> due
> to bandwidth limitations.  This means that you will need to find a mirror
> which
> has this update, please choose the one nearest to you: 
> 
> http://cygwin.com/mirrors.html
> 
> 
> QUESTIONS:
> ==========
> If you want to make a point or ask a question the Cygwin mailing list is the
> appropriate place.
> 
> 
> CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
> =================================
> To unsubscribe to the cygwin-announce mailing list, look at the
> "List-Unsubscribe: " tag in the email header of this message.  Send email to
> the address specified there.  It will be in the format:
> 
> cygwin-announce-unsubscribe-YOU=YOU...@cy...
> 
> If you need more information on unsubscribing, start reading here:
> 
> http://sources.redhat.com/lists.html#unsubscribe-simple
> 
> Please read *all* of the information on unsubscribing that is available
> starting at this URL.
> 
> MAINTAINER
> ==========
> James R. Phillips
> 
> 
> 
> 

[OctDev] octave-forge translation packages

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

All,

I suggest we put translations for various octave packages in a new 
top-level directory in the octave-forge CVS server:

	octave-lang

I recommend keeping the translation for each language as a separate 
distribution to reduce coordination efforts.  I don't want to wait 
until the translators for twenty different languages complete their 
work before releasing a package.  The translators don't want to dig 
through twenty different packages to see what needs to be translated.

What do the octave packagers for various platforms think about this?  
With complete translations, each language could add 1/2 Mb or more to 
the distribution.  Would the octave packaging system be able to fetch 
and install the language specific docs for the package being installed? 
  Can this be a post-install operation for the package manager?  
Individual packages should of course be able to be bundled with their 
own i18n.

We will need octave-lang/tools for things such as docstring extractors, 
hash string checkers and other programs to list what needs to be 
translated for each language.  I think the installation tools should be 
part of the octave packaging system.

We will need octave-lang/admin for scripts to build and maintain the 
online docs and distributions.

We will need octave-lang/zz for each language zz we wish to translate, 
including zz=en for those packages whose original language is not 
English.

Translations for the base system will go in octave-lang/zz/octave. 
Translations for individual packages (such as the packages in 
octave-forge and others) will go in octave-lang/zz/<package-name>.

The internal structure of the package directories will be dictated by 
the package system.  It will include translations of the usual 
packaging documents such as package description and README.  I suspect 
it will have a subdirectory for functions and maybe another for the 
manual and another to contain translated demos.  We will eventually 
need a directory for translated warnings, error messages, axis labels, 
etc.  We may also want replacement m-files for those functions which 
are to hard to translate string by string.  Somebody else will have to 
fill in the details.

As a convenience to translators, we will need the source documents in 
octave-lang/source/<package-name> with exactly the same structure as we 
want in zz tree.

Is this as simple as can be and no simpler?

- Paul

Re: [OctDev] octave-forge on solaris 8

[Aaron J. <ja...@ms...>]

On Jul 1, 2005, at 10:55 PM, Dmitri A. Sergatskov wrote:

> FWIW:
>
> I would recommend to install gnu version even of those utils
> which are provided with Solaris 8. perl, sed, and, as you found, grep
> are some of the examples.
> Also, Solaris' /bin/sh is not POSIX compliant, so you may want to
> replace
> SHELL=/bin/sh
> with
> SHELL=/usr/local/bin/bash
> in a couple makefile/makeconf scripts
>
> You can get most of the stuff at www.sunfreeware.com

The regular Solaris commands listed above are not POSIX compliant, 
however there are POSIX compliant versions in /usr/xpg4/bin.  I just 
tested it and it is only necessary to put /usr/xpg4/bin first in the 
PATH variable to run the scripts as is.  As a side effect I see that 
main/image/bestblk.m, main/image/bweuler.m and main/image/conndef.m are 
missing new lines at their end.  I guess the build process for solaris 
should be

setenv PATH /usr/xpg4/bin:$PATH
./configure
gmake -k
gmake check
gmake install

Thanks.

Aaron

Re: [OctDev] octave-forge on solaris 8

[Dmitri A. S. <das...@gm...>]

FWIW:

I would recommend to install gnu version even of those utils
which are provided with Solaris 8. perl, sed, and, as you found, grep
are some of the examples.
Also, Solaris' /bin/sh is not POSIX compliant, so you may want to
replace
SHELL=/bin/sh
with
SHELL=/usr/local/bin/bash
in a couple makefile/makeconf scripts

You can get most of the stuff at www.sunfreeware.com

Sincerely,

Dmitri.
-- 

Re: [OctDev] octave-forge on solaris 8

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

On Jul 1, 2005, at 4:34 PM, Aaron Jackson wrote:

> I hope this is the proper place for this...

Yes.

> I am trying to build octave-forge on a solaris 8 system.  I have never 
> done this before, so I'm not sure what to expect so I have a few 
> questions.  My first question, is that the version of octave I'm using 
> is 2.1.71 while the version of octave-forge is 
> octave-forge-2005.06.13.  Is this a bad idea?  I didn't realize the 
> version mismatch until after I installed 2.1.71 and I would rather not 
> redo the 9+ hour build (octave and octave-forge) if I don't have to.

The octave-forge build skips what can't be built (the -k is done in the 
build).  As far as I'm aware everything in 2005.06.013 should build in 
2.1.71, but I haven't tested this combination.

> Doing a
>
> ./configure --prefix=/opt/sfw
> gmake -k
>
> Seemed to work, but there were a few ld errors along the way.  I guess 
> that's what the -k is for.  However doing a
>
> gmake check
>
> gave me some problems.

>   I did some searching and found that there were some problems with 
> bash specific shell scripts.  The admin/mktests.sh and admin/run_forge 
> scripts do need bash not sh to run.

Are there a lot of changes required for it to run on sh?  I'm happy not 
to depend on bash if it is easy enough.  Please send a patch.

> Also, admin/mktests.sh calls grep -E.  The -E is not a valid switch 
> for /usr/bin/grep for solaris 8.  So either the script needs to call 
> /usr/xpg4/bin/grep, or it needs to call egrep.  After fixing that I 
> was able to run the check.

egrep sounds like a better option.  However, I don't see anything in 
the pattern which requires extended expressions.  Will it work with 
plain grep and no -E option?


>   There were a lot of failed tests and the check eventually errored 
> out (See below.  I can send the fntests.log to anybody who is 
> interested.).  Is this normal, because octave builds and tests very 
> cleanly on this system?

Most tests should work.   From below I suspect that for some reason you 
cannot use compiled functions in oct files.   Does your octave/src 
directory contain *.oct files?  Can you run them from the octave 
command line?

If the answer is no, then try

	./configure --enable-shared --disable-static

and rebuild.  At some point this became the default but I don't 
remember when.  You can also scan through config.log to see if shared 
is enabled if you want to save yourself a nine hour test.

>
> I then did a
>
> gmake install
>
> This also gave me some errors since the install scripts call grep -q.  
> Again, -q is not a valid switch for /usr/bin/grep.

Easy enough to fix these with a >/dev/null.  Might break mingw install 
though.

>
> After fixing that, when I started up octave I got the following errors:
>
>
> error: `dispatch' undefined near line 2 column 1
> error: near line 2 of file 
> `/opt/sfw/share/octave/2.1.71/site/m/octave-forge/comm//PKG_ADD'
> error: source: error sourcing file 
> `/opt/sfw/share/octave/2.1.71/site/m/octave-forge/comm//PKG_ADD'
>
> I then took the advice of the install script and uninstalled 
> octave-forge.  There are some functions in octave-forge that I need 
> access to, but I am having problems installing it.  Has anybody gotten 
> this to work on a solaris 8 machine?  Should I make sure that the 
> versions match and then try everything from scratch?  Thanks for any 
> pointers.

Check the mailing list archives at http://www.octave.org.  There are 
occasional posts Re: Solaris.

- Paul

[OctDev] octave-forge on solaris 8

[Aaron J. <ja...@ms...>]

I hope this is the proper place for this...

I am trying to build octave-forge on a solaris 8 system.  I have never  
done this before, so I'm not sure what to expect so I have a few  
questions.  My first question, is that the version of octave I'm using  
is 2.1.71 while the version of octave-forge is octave-forge-2005.06.13.  
  Is this a bad idea?  I didn't realize the version mismatch until after  
I installed 2.1.71 and I would rather not redo the 9+ hour build  
(octave and octave-forge) if I don't have to.

Doing a

./configure --prefix=/opt/sfw
gmake -k

Seemed to work, but there were a few ld errors along the way.  I guess  
that's what the -k is for.  However doing a

gmake check

gave me some problems.  I did some searching and found that there were  
some problems with bash specific shell scripts.  The admin/mktests.sh  
and admin/run_forge scripts do need bash not sh to run.  Also,  
admin/mktests.sh calls grep -E.  The -E is not a valid switch for  
/usr/bin/grep for solaris 8.  So either the script needs to call  
/usr/xpg4/bin/grep, or it needs to call egrep.  After fixing that I was  
able to run the check.  There were a lot of failed tests and the check  
eventually errored out (See below.  I can send the fntests.log to  
anybody who is interested.).  Is this normal, because octave builds and  
tests very cleanly on this system?

I then did a

gmake install

This also gave me some errors since the install scripts call grep -q.   
Again, -q is not a valid switch for /usr/bin/grep.

After fixing that, when I started up octave I got the following errors:


error: `dispatch' undefined near line 2 column 1
error: near line 2 of file  
`/opt/sfw/share/octave/2.1.71/site/m/octave-forge/comm//PKG_ADD'
error: source: error sourcing file  
`/opt/sfw/share/octave/2.1.71/site/m/octave-forge/comm//PKG_ADD'

I then took the advice of the install script and uninstalled  
octave-forge.  There are some functions in octave-forge that I need  
access to, but I am having problems installing it.  Has anybody gotten  
this to work on a solaris 8 machine?  Should I make sure that the  
versions match and then try everything from scratch?  Thanks for any  
pointers.

Aaron

jackson@helen:octave-forge-2005.06.13 {29} gmake check
admin/mktests.sh
admin/run_forge octave --norc -q fntests.m
FIXES [tests        2 of       13 files]
warning: hankel: column wins anti-diagonal conflict
                                          ---> passes 8 out of 22 tests
main/audio [tests        2 of       11 files]
                                          ---> success
main/cell [tests        1 of        2 files]
                                          ---> success
main/comm [tests        5 of       60 files]
                                          ---> success
main/control [tests        0 of        1 files]
                                          ---> success
main/econometrics [tests        0 of       25 files]
                                          ---> success
main/fixed [tests        0 of       43 files]
                                          ---> success
main/general [tests        5 of       33 files]
                                          ---> success
main/geometry [tests        0 of        7 files]
                                          ---> success
main/ident [tests        0 of        4 files]
                                          ---> success
main/image [tests       34 of       85 files]
                                          ---> passes 186 out of 242  
tests
main/io [tests        0 of        8 files]
                                          ---> success
main/irsa [tests        0 of       14 files]
                                          ---> success
main/linear-algebra [tests        0 of        3 files]
                                          ---> success
main/miscellaneous [tests        2 of       22 files]
                                          ---> passes 4 out of 15 tests
main/optim [tests        3 of       54 files]
warning: fzero: equal signs at both ends of the interval.
                         Using fsolve('sin',0.75) instead
                                          ---> passes 9 out of 10 tests
main/path [tests        2 of        3 files]
                                          ---> success
main/plot [tests        1 of       34 files]
                                          ---> passes 6 out of 7 tests
main/set [tests        2 of        5 files]
                                          ---> passes 8 out of 10 tests
main/signal [tests       19 of       79 files]
warning: grpdelay: setting group delay to 0 at singularity
warning: grpdelay: setting group delay to 0 at singularity
warning: grpdelay: setting group delay to 0 at singularity
warning: grpdelay: setting group delay to 0 at singularity
                                          ---> passes 72 out of 74 tests
main/sparse [tests        8 of       23 files]
warning: PCG: eigenvalue estimate failed: iteration converged too fast.
                                          ---> passes 62 out of 439 tests
main/specfun [tests        3 of       15 files]
                                          ---> success
main/special-matrix [tests        2 of        6 files]
                                          ---> success
main/splines [tests        3 of       13 files]
                                          ---> success
main/statistics [tests        1 of       24 files]
warning: XXX FIXME XXX Tsq return from princomp fails some tests
warning: XXX FIXME XXX Tsq return from princomp fails some tests
                                          ---> passes 10 out of 11 tests
main/strings [tests        2 of       13 files]
                                          ---> passes 25 out of 27 tests
main/struct [tests        0 of       10 files]
                                          ---> success
main/symbolic [tests        0 of        5 files]
                                          ---> success
main/time [tests        5 of        8 files]
                                          ---> passes 13 out of 31 tests
main/vrml [tests        0 of       33 files]
                                          ---> success
extra/civil [tests        0 of        3 files]
                                          ---> success
extra/graceplot [tests        0 of        3 files]
                                          ---> success
extra/integration [tests        0 of       25 files]
                                          ---> success
extra/linear-algebra [tests        1 of        2 files]
                                          ---> passes 4 out of 5 tests
extra/mapping [tests        0 of        4 files]
                                          ---> success
extra/mex [tests        0 of        2 files]
                                          ---> success
extra/ode [tests        0 of        8 files]
                                          ---> success
extra/pdb [tests        0 of        5 files]
                                          ---> success
extra/symband [tests        0 of        7 files]
                                          ---> success
extra/testfun [tests        4 of        7 files]
                                          ---> passes 85 out of 95 tests
extra/tsa [tests        0 of       50 files]
                                          ---> success
passes 742 out of 1238 tests
see fntests.log for details
admin/run_forge octave --norc -q batch_test.m
[main/comm]
 >comms

<< Random Signals Package >>
   Signal Creation:                          PASSED
   Signal Analysis:                          PASSED

<< Source Coding Package >>
   PCM Functions:                            Not tested
   Quantization Functions:                   PASSED

<< Block Coding Package >>
   Cyclic Coding:                            error: `cyclpoly' undefined  
near line 244 column 6

Note: failure expected for octave 2.1.36
[main/fixed]
 >fixed

<< Fixed Point Load Type >>
error: `fixed' undefined near line 152 column 11

Note: failure expected for octave 2.1.36
[main/image]
 >jpgread ... not available
 >jpgwrite ... not available
 >pngread ... not available
 >pngwrite ... not available
[main/struct]
 >getfield
 >setfield
[main/sparse]
error: `nnz' undefined near line 163 column 16
error: evaluating argument list element number 3
error: evaluating if command near line 142, column 1
error: near line 169 of file  
`/export/home/jackson/software/octave-forge-2005.06.13/main/sparse/ 
fem_test.m'
gmake: *** [check] Error 1

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image conv2.cc,1.7,1.8

[Stefan v. d. W. <st...@su...>]

Hi Andy

What does this patch do exactly?  Does it modify the output of conv2?
I ask because fftconv2 needs to remain compatible.

Regards
Stefan

On Wed, Jun 29, 2005 at 04:36:06PM +0000, andy adler wrote:
> Update of /cvsroot/octave/octave-forge/main/image
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14481/main/image
> 
> Modified Files:
> 	conv2.cc 
> Log Message:
> mods to octave code format
> 

Re: [OctDev] Re: Octave wiki editing permissions....

[Etienne G. <et...@cs...>]

  Hi Geordie,

I'm glad to hear that you would like to contribute to the wiki. I just
added your IP; plz let me know whether you manage to edit.

  Cheers,

  Etienne

On Fri, Jun 17, 2005 at 11:27:02AM +1000, Geordie McBain wrote:
# Dear Etienne:
# Please authorize my ScaryOctave writing.  My IP is
# geordie3.aeromech.usyd.edu.au = 129.78.216.103.
# 
# Geordie McBain
# www.aeromech.usyd.edu.au/~mcbain
# 
# On Tue, 2005-06-14 at 10:13 -0400, Etienne Grossmann wrote:
# >   Hi Matthew,
# > 
# > thanks for proposing to contribute to the wiki. I just added you to
# > the authorized list. Please let me know whether it works. I authorized
# > a 256-IP regex. If at some point access is denied to you, please send
# > me a mail and I'll try to fix that.
# > 
# >   Cheers,
# > 
# >   Etienne
# > 
# > On Tue, Jun 14, 2005 at 12:07:03PM +0100, Matthew A Swabey wrote:
# > # Hiya I run octave under cygwin a lot and would like a chance to contribute 
# > # my knowledge on the subject.
# > # 
# > # the desktop machines IP addr is:
# > # 
# > # 152.78.66.60
# > # 
# > # Unfortunately my laptop uses dhcp :(
# > # 
# > # Thanks,
# > # 
# > # Matthew Swabey
# > # 
# > 
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] Re: Octave wiki editing permissions....

[Etienne G. <et...@cs...>]

  Hi Stefan,

thanks for your help too. I'm sorry for the delay, I only saw your
mail today. I just added your IP. Could you tell me whether you can
edit the wiki?

  Cheers,

  Etienne

On Tue, Jun 14, 2005 at 05:56:20PM +0200, Stefan van der Walt wrote:
# Hi Etienne
# 
# Sorry for posting this to the list, but your SMTP server bounces
# messages from my ISP (why?).

Good question ... I don't know.
 
# Will you please add my IPs to the Wiki access list as well?
# 
# 146.232.*.*
# 
# and
# 
# *.gprs.vodacom.co.za
# 
# Thanks
# Stefan
# 
# On Tue, Jun 14, 2005 at 10:13:52AM -0400, Etienne Grossmann wrote:
# > 
# >   Hi Matthew,
# > 
# > thanks for proposing to contribute to the wiki. I just added you to
# > the authorized list. Please let me know whether it works. I authorized
# > a 256-IP regex. If at some point access is denied to you, please send
# > me a mail and I'll try to fix that.
# > 
# >   Cheers,
# > 
# >   Etienne
# 
# 
# -------------------------------------------------------
# SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
# from IBM. Find simple to follow Roadmaps, straightforward articles,
# informative Webcasts and more! Get everything you need to get up to
# speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] Re: Octave wiki editing permissions....

[Stefan v. d. W. <st...@su...>]

Hi Etienne

Sorry for posting this to the list, but your SMTP server bounces
messages from my ISP (why?).

Will you please add my IPs to the Wiki access list as well?

146.232.*.*

and

*.gprs.vodacom.co.za

Thanks
Stefan

On Tue, Jun 14, 2005 at 10:13:52AM -0400, Etienne Grossmann wrote:
> 
>   Hi Matthew,
> 
> thanks for proposing to contribute to the wiki. I just added you to
> the authorized list. Please let me know whether it works. I authorized
> a 256-IP regex. If at some point access is denied to you, please send
> me a mail and I'll try to fix that.
> 
>   Cheers,
> 
>   Etienne