octave-dev — GNU Octave developers' list

Re: [OctDev] state of octave-forge code

[David B. <Dav...@mo...>]

Keith Goodman a =E9crit :

>I think it partly depends on the plans for Octave 2.9. When will it
>become the recommended stable version of Octave?
>
> =20
>

John has mentioned some time this summer as the release date for 3.0 a=20
couple of months ago. I'd say the very end of summer is realistic at the=20
moment. A testing release is vital before such a release and so I=20
wouldn't expect more than a couple of months before a testing version of=20
2.9.x, at which time it would make sense to start thinking about a new=20
release of octave-forge.

>And it partly depends on how much work is needed to be make
>Octave-Forge ready for 2.9.
> =20
>
octave-forge is already ready for 2.9.3 as you note... This is not the=20
issue. The issue is that there are many duplicate function in=20
octave-forge relative to octave that should be removed, and there are a=20
large number of version specific tests in octave-forge as Paul pointed=20
out that make the code rather crufty... The purpose of a 2.9 specific=20
version is to profit from the upcoming release of octave 3.0 to largely=20
simplify octave-forge..

Cheers
David

Re: [OctDev] state of octave-forge code

[Keith G. <kwg...@gm...>]

On 6/14/05, David Bateman <Dav...@mo...> wrote:
> Paul Kienzle a =E9crit :
>=20
> >
> > On Jun 13, 2005, at 8:21 AM, David Bateman wrote:
> >
> >> Paul Kienzle a =E9crit :
> >>
> >>> Presumably we should maintain a separate branch in CVS for those who
> >>> don't want to do the 2.9.x upgrade and are interested in backporting
> >>> bug fixes.  That won't be me.
> >>
> >>
> >>
> >> I feel the main branch in the CVS should probably be the 2.9.x code,
> >> but that might be too agressive at the start with octave 2.9 still
> >> considered as unstable. For that reason I'd suggest creating a 2.1
> >> and a 2.9 branch right now, where 2.1 branch will follow the MAIN
> >> branch at the start, and when 2.9 goes into testing we merge the 2.9
> >> branch into the main branch.
> >
> >
> > If that is easy to do feel free to do so.
> >
> > Having no experiences with branches I would keep it simple, using the
> > trunk for 2.9 and leaving it to the 2.1 folks to deal with branches.
>=20
> It depends on really on what the people who will be developing the
> changes want, so I wouldn't just do such a change, but raise a
> discussion to see what others want...

I think it partly depends on the plans for Octave 2.9. When will it
become the recommended stable version of Octave?

And it partly depends on how much work is needed to be make
Octave-Forge ready for 2.9.

I haven't run into any problems running Octave-Forge with 2.9.3.

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

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

  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] state of octave-forge code

[David B. <Dav...@mo...>]

Paul Kienzle a =E9crit :

>
> On Jun 13, 2005, at 8:21 AM, David Bateman wrote:
>
>> Paul Kienzle a =E9crit :
>>
>>> Presumably we should maintain a separate branch in CVS for those who=20
>>> don't want to do the 2.9.x upgrade and are interested in backporting=20
>>> bug fixes.  That won't be me.
>>
>>
>>
>> I feel the main branch in the CVS should probably be the 2.9.x code,=20
>> but that might be too agressive at the start with octave 2.9 still=20
>> considered as unstable. For that reason I'd suggest creating a 2.1=20
>> and a 2.9 branch right now, where 2.1 branch will follow the MAIN=20
>> branch at the start, and when 2.9 goes into testing we merge the 2.9=20
>> branch into the main branch.
>
>
> If that is easy to do feel free to do so.
>
> Having no experiences with branches I would keep it simple, using the=20
> trunk for 2.9 and leaving it to the 2.1 folks to deal with branches.

It depends on really on what the people who will be developing the=20
changes want, so I wouldn't just do such a change, but raise a=20
discussion to see what others want...

D.

Re: [OctDev] state of octave-forge code

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

On Jun 13, 2005, at 8:21 AM, David Bateman wrote:

> Paul Kienzle a =E9crit :
>
>> Presumably we should maintain a separate branch in CVS for those who=20=

>> don't want to do the 2.9.x upgrade and are interested in backporting=20=

>> bug fixes.  That won't be me.
>
>
> I feel the main branch in the CVS should probably be the 2.9.x code,=20=

> but that might be too agressive at the start with octave 2.9 still=20
> considered as unstable. For that reason I'd suggest creating a 2.1 and=20=

> a 2.9 branch right now, where 2.1 branch will follow the MAIN branch=20=

> at the start, and when 2.9 goes into testing we merge the 2.9 branch=20=

> into the main branch.

If that is easy to do feel free to do so.

Having no experiences with branches I would keep it simple, using the=20
trunk for 2.9 and leaving it to the 2.1 folks to deal with branches.

- Paul

Re: [OctDev] faster 'textread' function

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

Here is a patch that fixes an end-of-line problem in the previous
version.  Thanks to Keith Goodman for finding the bug.

Regards
Stefan

On Mon, Jun 13, 2005 at 06:01:57PM +0200, Stefan van der Walt wrote:
> Please review the attached version of `textread'.
> 
> This version is aimed at increasing the speed at which `textread'
> (currently implemented as an m-file) operates.  Since it is used for
> reading data files, often thousands of lines in length,
> re-implementing the function in C++ seems to be the right thing to do.
> 
> The interface is MATLAB compatible, but none of the optional
> parameters are implemented.  Also, only a subset of the format
> specifiers are included: %s, %d (or %u or %f) and %*.
> 
> Regards
> Stefan
> 

Re: [OctDev] dxfwrite.m

[Larry D. <ldo...@re...>]

Paul et al. -

On Sun, Jun 12, 2005 at 11:11:10PM -0400, Paul Kienzle wrote:
> I applied this patch without testing.  Will users of
> dxfwrite please confirm that it works for them.

Although it's hardly an independent test, I just tried
my version again.  It works as I expect on GNU Octave,
version 2.1.69 (x86_64-pc-linux-gnu), reading with AutoCAD-2005.

       - Larry

[OctDev] faster 'textread' function

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

Please review the attached version of `textread'.

This version is aimed at increasing the speed at which `textread'
(currently implemented as an m-file) operates.  Since it is used for
reading data files, often thousands of lines in length,
re-implementing the function in C++ seems to be the right thing to do.

The interface is MATLAB compatible, but none of the optional
parameters are implemented.  Also, only a subset of the format
specifiers are included: %s, %d (or %u or %f) and %*.

Regards
Stefan

Re: [OctDev] state of octave-forge code

[David B. <Dav...@mo...>]

Paul Kienzle a =E9crit :

> Yes, it is time for spring cleaning.
>
> (1) Target 2.9.x code.  Remove #ifdefs which support older versions of=20
> octave.
>
> (2) Remove functions that are duplicated in octave. For every function=20
> in the core matlab package, use texinfo docs, octave coding standards=20
> and write test cases.  These should be part of octave before the 3.0=20
> release.
>
> (3) It would also be nice to reorganize the project into a package=20
> manager plus a set of independent packages.
>
> Presumably we should maintain a separate branch in CVS for those who=20
> don't want to do the 2.9.x upgrade and are interested in backporting=20
> bug fixes.  That won't be me.


I feel the main branch in the CVS should probably be the 2.9.x code, but=20
that might be too agressive at the start with octave 2.9 still=20
considered as unstable. For that reason I'd suggest creating a 2.1 and a=20
2.9 branch right now, where 2.1 branch will follow the MAIN branch at=20
the start, and when 2.9 goes into testing we merge the 2.9 branch into=20
the main branch.

There is rather a lot of spring cleaning to do...

D.

Re: [OctDev] state of octave-forge code

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

Yes, it is time for spring cleaning.

(1) Target 2.9.x code.  Remove #ifdefs which support older versions of 
octave.

(2) Remove functions that are duplicated in octave. For every function 
in the core matlab package, use texinfo docs, octave coding standards 
and write test cases.  These should be part of octave before the 3.0 
release.

(3) It would also be nice to reorganize the project into a package 
manager plus a set of independent packages.

Presumably we should maintain a separate branch in CVS for those who 
don't want to do the 2.9.x upgrade and are interested in backporting 
bug fixes.  That won't be me.

Also, I foresee having even less time for octave work in the near term, 
so if you see something on the list that you can address (such as 
helping new and occasional contributors get their code into 
octave-forge) please do so.

Thanks

	- Paul

On Jun 13, 2005, at 5:59 AM, Stefan van der Walt wrote:

> With the new release out the door, I assume it is ok to make those
> changes now?
>
> Regards
> Stefan
>
> On Sun, Jun 12, 2005 at 03:23:26PM -0400, Paul Kienzle wrote:
>> Use 2.1.70 for now.
>>
>> After the next release we can purge any pre-2.9.x code.  If somebody 
>> is
>> interested in supporting 2.1.x code, they should create a branch after
>> the next release.
>>
>> -Paul
>>
>> On Jun 9, 2005, at 4:35 AM, Stefan van der Walt wrote:
>>
>>> Should the scripts in CVS be compatible with Octave 2.1.70, or is it
>>> OK to use functionality from the 2.9.x branch?
>>>
>>> Regards
>>> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] state of octave-forge code

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

With the new release out the door, I assume it is ok to make those
changes now?

Regards
Stefan

On Sun, Jun 12, 2005 at 03:23:26PM -0400, Paul Kienzle wrote:
> Use 2.1.70 for now.
> 
> After the next release we can purge any pre-2.9.x code.  If somebody is 
> interested in supporting 2.1.x code, they should create a branch after 
> the next release.
> 
> -Paul
> 
> On Jun 9, 2005, at 4:35 AM, Stefan van der Walt wrote:
> 
> >Should the scripts in CVS be compatible with Octave 2.1.70, or is it
> >OK to use functionality from the 2.9.x branch?
> >
> >Regards
> >Stefan

Re: [OctDev] dxfwrite.m

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

I applied this patch without testing.  Will users of
dxfwrite please confirm that it works for them.

	- Paul

On Jan 7, 2005, at 2:54 PM, Larry Doolittle wrote:

> Laurent -
>
> Just scratching an itch.
>
> The DXF files made by CVS dxfwrite.m do not load
> properly into AutoCAD 2002.  That attached version
> "works for me".  Please test for regression, and
> consider checking back into CVS.
>
> I couldn't find an e-mail address for Patrick Labbe.
>
>      - Larry
> <dxfwrite.m>

Re: [OctDev] interp2.m

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

On Jun 12, 2005, at 10:00 PM, Tom Holroyd wrote:

>> The bug is in the documentation for not saying that the function is 
>> restricted to meshgrids :-)
>
> Ah, yeah, I was afraid of that.  :-)
>
> It actually interpolates each point correctly, so one workaround is to 
> just call it repeatedly for each point.  That's a little bit slow, but 
> if it only has to be done once it's almost tolerable.  I might get 
> around to it fixing it eventually but it's a bit low on my list at the 
> moment.

On second thought, it is not so bad.  Rather than using (i,j) indexing, 
which grabs regular submatrices, use (i+(j-1)*m), which grabs 
individual elements.  See attached.

Note that unlike interp2, calling interp2fi with vectors xi,yi will not 
automatically form a meshgrid.

Note also that x,y are still constrained to meshgrids.  Working around 
that will require griddata.

- Paul

Re: [OctDev] interp2.m

[Tom H. <to...@ku...>]

> The bug is in the documentation for not saying that the function is 
> restricted to meshgrids :-)

Ah, yeah, I was afraid of that.  :-)

It actually interpolates each point correctly, so one workaround 
is to just call it repeatedly for each point.  That's a little 
bit slow, but if it only has to be done once it's almost 
tolerable.  I might get around to it fixing it eventually but 
it's a bit low on my list at the moment.

Dr. Tom Holroyd
"A man of genius makes no mistakes. His errors are volitional and
are the portals of discovery." -- James Joyce

Re: [OctDev] Re: [Fwd: Re: Octave Forge on linux error during compile??]

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

Paul Kienzle wrote:
 > I check for pcre.h and if it doesn't exist I check for pcre-config.  I
 > don't check for pcre/pcre.h.
 >
 > - Paul
 >

pcre-config does exist, but it does not do is what (at least I) expect it to do:


[dima@tumbleweed ~]$ pcre-config --cflags

[dima@tumbleweed ~]$ pcre-config --cflags-posix

yet:

[dima@tumbleweed ~]$ pcre-config --libs
-lpcre

I suggest we leave it as the particular distribution bug/annoyance. I think some
distributions (other than Fedora Core [123]) also put pcre into pcre/pcre.h, but
Fedora Core 4 (to be released tomorrow) should have it back in the /usr/include

Dmitri.
-- 

Re: [OctDev] Re: [Fwd: Re: Octave Forge on linux error during compile??]

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

I check for pcre.h and if it doesn't exist I check for pcre-config.  I 
don't check for pcre/pcre.h.

- Paul

On Jun 12, 2005, at 5:20 PM, Stefan van der Walt wrote:

> This one again -- Dmitri seems to recall it all too well :-)
>
> Paul: which patch did you apply in the end?  I thought we now look for
> both pcre/pcre.h and pcre.h?
>
> Regards
> Stefan
>
> On Sat, Jun 11, 2005 at 11:26:13PM -0600, Dmitri A. Sergatskov wrote:
>> Louis Ciotti wrote:
>>
>>>
>>> find /usr/include/ -name "pcre.h"
>>> /usr/include/pcre/pcre.h
>>>
>>
>> as root, do the following:
>>
>> cd /usr/include
>> ln -s pcre/pcre.h ./
>>
>> Then re-run configure and make
>>
>> Dmitri.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] Re: [Fwd: Re: Octave Forge on linux error during compile??]

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

This one again -- Dmitri seems to recall it all too well :-)

Paul: which patch did you apply in the end?  I thought we now look for
both pcre/pcre.h and pcre.h?

Regards
Stefan

On Sat, Jun 11, 2005 at 11:26:13PM -0600, Dmitri A. Sergatskov wrote:
> Louis Ciotti wrote:
> 
> >
> >find /usr/include/ -name "pcre.h"
> >/usr/include/pcre/pcre.h
> >
> 
> as root, do the following:
> 
> cd /usr/include
> ln -s pcre/pcre.h ./
> 
> Then re-run configure and make
> 
> Dmitri.

Re: [OctDev] state of octave-forge code

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

Use 2.1.70 for now.

After the next release we can purge any pre-2.9.x code.  If somebody is 
interested in supporting 2.1.x code, they should create a branch after 
the next release.

-Paul

On Jun 9, 2005, at 4:35 AM, Stefan van der Walt wrote:

> Should the scripts in CVS be compatible with Octave 2.1.70, or is it
> OK to use functionality from the 2.9.x branch?
>
> Regards
> Stefan
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] datestr patch

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

On Jun 9, 2005, at 8:58 PM, Keith Goodman wrote:

> Crap. Now I crashed on the format of 'mm'. I would have submitted it 
> all at once had I known.
>
> $ diff -u datestr.m datestr2.m
> --- datestr.m   2005-06-09 17:49:14.677736696 -0700
> +++ datestr2.m  2005-06-09 17:49:31.562169872 -0700
> @@ -25,7 +25,7 @@
>   ## @item  2 @tab mm/dd/yy               @tab 09/07/00
>   ## @item  3 @tab mmm                    @tab Sep
>  ## @item  4 @tab m                      @tab S
> -## @item  5 @tab mm                     @tab 9
> +## @item  5 @tab mm                     @tab 09
>  ## @item  6 @tab mm/dd                  @tab 09/07
>  ## @item  7 @tab dd                     @tab 07
>   ## @item  8 @tab ddd                    @tab Thu
> @@ -124,7 +124,7 @@
>        case { 4, 'm' }
>         str = sprintf("%s",__month_names(M,1));
>        case { 5, 'mm' }
> -       str = sprintf("%d",M);
> +       str = sprintf("%02d",M);
>        case { 6, 'mm/dd' }
>         str = sprintf("%02d/%02d",M,D);
>        case { 7, 'dd' }

Applied.

Note that the 5.2 documentation on the web gives the example of '3' for 
format 'mm'.  Was the documentation wrong or has the definition 
changed?  Is there any way we can support scripts written for older 
versions?  Even if there were, should we bother?

Maintaining compatibility with a language which doesn't even stay 
compatible with itself is frustrating.

- Paul

Re: [OctDev] datestr patch

[Keith G. <kwg...@gm...>]

On 6/9/05, Paul Kienzle <pki...@us...> wrote:
> Applied.  Thanks,
>=20
>         - Paul
>=20
> On Jun 9, 2005, at 7:14 PM, Keith Goodman wrote:
>=20
> > Is this how I submit a patch to octave-forge?
> >
> > main/time/datestr.m: Format 'dd' now pads with leading zero if day is
> > less than 10.
> >
> > Current behaviour
> >
> > datestr(now,"dd")
> > ans =3D 9
> >
> > Patched behaviour (compatible and more consistent with dd in other
> > contexts such as mm/dd/yyyy)
> >
> > datestr(now,"dd")
> > ans =3D 09
> >
> > --- datestr.m   2005-06-09 09:00:56.455208088 -0700
> > +++ datestr2.m  2005-06-09 09:01:58.381793816 -0700
> > @@ -27,7 +27,7 @@
> >  ## @item  4 @tab m                      @tab S
> >  ## @item  5 @tab mm                     @tab 9
> >  ## @item  6 @tab mm/dd                  @tab 09/07
> > -## @item  7 @tab dd                     @tab 7
> > +## @item  7 @tab dd                     @tab 07
> >  ## @item  8 @tab ddd                    @tab Thu
> >  ## @item  9 @tab d                      @tab T
> >  ## @item 10 @tab yyyy                   @tab 2000
> > @@ -128,7 +128,7 @@
> >        case { 6, 'mm/dd' }
> >         str =3D sprintf("%02d/%02d",M,D);
> >        case { 7, 'dd' }
> > -       str =3D sprintf("%d",D);
> > +       str =3D sprintf("%02d",D);
> >        case { 8, 'ddd' }
> >         [d,str] =3D weekday(datenum(Y,M,D));
> >        case { 9, 'd' }

Crap. Now I crashed on the format of 'mm'. I would have submitted it
all at once had I known.

$ diff -u datestr.m datestr2.m
--- datestr.m   2005-06-09 17:49:14.677736696 -0700
+++ datestr2.m  2005-06-09 17:49:31.562169872 -0700
@@ -25,7 +25,7 @@
  ## @item  2 @tab mm/dd/yy               @tab 09/07/00
  ## @item  3 @tab mmm                    @tab Sep
 ## @item  4 @tab m                      @tab S
-## @item  5 @tab mm                     @tab 9
+## @item  5 @tab mm                     @tab 09
 ## @item  6 @tab mm/dd                  @tab 09/07
 ## @item  7 @tab dd                     @tab 07
  ## @item  8 @tab ddd                    @tab Thu
@@ -124,7 +124,7 @@
       case { 4, 'm' }
        str =3D sprintf("%s",__month_names(M,1));
       case { 5, 'mm' }
-       str =3D sprintf("%d",M);
+       str =3D sprintf("%02d",M);
       case { 6, 'mm/dd' }
        str =3D sprintf("%02d/%02d",M,D);
       case { 7, 'dd' }

Re: [OctDev] datestr patch

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

Applied.  Thanks,

	- Paul

On Jun 9, 2005, at 7:14 PM, Keith Goodman wrote:

> Is this how I submit a patch to octave-forge?
>
> main/time/datestr.m: Format 'dd' now pads with leading zero if day is
> less than 10.
>
> Current behaviour
>
> datestr(now,"dd")
> ans = 9
>
> Patched behaviour (compatible and more consistent with dd in other
> contexts such as mm/dd/yyyy)
>
> datestr(now,"dd")
> ans = 09
>
> --- datestr.m   2005-06-09 09:00:56.455208088 -0700
> +++ datestr2.m  2005-06-09 09:01:58.381793816 -0700
> @@ -27,7 +27,7 @@
>  ## @item  4 @tab m                      @tab S
>  ## @item  5 @tab mm                     @tab 9
>  ## @item  6 @tab mm/dd                  @tab 09/07
> -## @item  7 @tab dd                     @tab 7
> +## @item  7 @tab dd                     @tab 07
>  ## @item  8 @tab ddd                    @tab Thu
>  ## @item  9 @tab d                      @tab T
>  ## @item 10 @tab yyyy                   @tab 2000
> @@ -128,7 +128,7 @@
>        case { 6, 'mm/dd' }
>         str = sprintf("%02d/%02d",M,D);
>        case { 7, 'dd' }
> -       str = sprintf("%d",D);
> +       str = sprintf("%02d",D);
>        case { 8, 'ddd' }
>         [d,str] = weekday(datenum(Y,M,D));
>        case { 9, 'd' }
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] datestr patch

[Keith G. <kwg...@gm...>]

Is this how I submit a patch to octave-forge?

main/time/datestr.m: Format 'dd' now pads with leading zero if day is
less than 10.

Current behaviour

datestr(now,"dd")
ans =3D 9

Patched behaviour (compatible and more consistent with dd in other
contexts such as mm/dd/yyyy)

datestr(now,"dd")
ans =3D 09

--- datestr.m   2005-06-09 09:00:56.455208088 -0700
+++ datestr2.m  2005-06-09 09:01:58.381793816 -0700
@@ -27,7 +27,7 @@
 ## @item  4 @tab m                      @tab S
 ## @item  5 @tab mm                     @tab 9
 ## @item  6 @tab mm/dd                  @tab 09/07
-## @item  7 @tab dd                     @tab 7
+## @item  7 @tab dd                     @tab 07
 ## @item  8 @tab ddd                    @tab Thu
 ## @item  9 @tab d                      @tab T
 ## @item 10 @tab yyyy                   @tab 2000
@@ -128,7 +128,7 @@
       case { 6, 'mm/dd' }
        str =3D sprintf("%02d/%02d",M,D);
       case { 7, 'dd' }
-       str =3D sprintf("%d",D);
+       str =3D sprintf("%02d",D);
       case { 8, 'ddd' }
        [d,str] =3D weekday(datenum(Y,M,D));
       case { 9, 'd' }

[OctDev] state of octave-forge code

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

Should the scripts in CVS be compatible with Octave 2.1.70, or is it
OK to use functionality from the 2.9.x branch?

Regards
Stefan

[OctDev] Re: Permisson to edit ScaryOctave

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

  Hi Javier,

thanks for proposing to contribute to the wiki. I just added your IP
to the list of authorized accesses. Please let me know whether it
works.

  Cheers,

  Etienne

On Wed, Jun 08, 2005 at 03:55:00PM +0200, Javier Arantegui wrote:
# Hello,
#=20
# I'd like to prepare a repository of Octave scripts, and I think that th=
e wiki=20
# is the best place to do it.
#=20
# According to www.whatsmyip.com my IP is 193.144.12.130. Could you give =
me=20
# access to edit the wiki? Please, if you need more information, don't he=
sitate=20
# to ask.
#=20
# Best regards,
#=20
# Javier
#=20
# --=20
# Javier Ar=E1ntegui
# Dept. Tecnologia de Alimentos / Dept. of Food Technology
# Universitat de Lleida / University of Lleida (Spain)
#         =20
# Tel. +34 973702595
# Fax  +34 973702596
# IM: Jabber - javier.arantegui (AT) jabberes.org
# http://www.tecal.udl.es
#=20

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

[OctDev] imresize and bwarea

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

Hi,
If I understand the octave-forge web page correctly I should send new=20
scripts to this list.

I've implemented two minor image processing functions:

1) imresize. This function is simply a wrapper to interp2, so my version=20
  of imresize understands the same interpolation methods as interp2.

2) bwarea. This function is just some minor calls to conv2.

I've attached the functions. I do however not know if this is the=20
prefered way to send scripts to octave-forge - I don't want to spam all=20
of you with scripts you don't care about :-)

/S=F8ren