3.0 when?

[John W. Eaton]

I have no plans to add any significant features at this point, and
would like to go ahead with releasing 3.0 soon.  So how long should we
wait before doing that?  Two weeks?  Three?

jwe

[dbateman3]

John W. Eaton wrote:
> I have no plans to add any significant features at this point, and
> would like to go ahead with releasing 3.0 soon.  So how long should we
> wait before doing that?  Two weeks?  Three?
>
> jwe
>

There are going to be fixes after 3,0, and 2.9.19 is really a bug fix
release for 2.9.18. So why not Friday next week, after seeing there are
no major issues with 2.9.19, and give us a Xmas present :-)

D.

[Dupuis]

David Bateman-3 wrote:

There are going to be fixes after 3,0, and 2.9.19 is really a bug fix
release for 2.9.18. So why not Friday next week, after seeing there are
no major issues with 2.9.19, and give us a Xmas present :-)
D.

Excellent idea. This way, Debian maintainers will have enough free time to prepare new packages, and the upgrade will be ready when going back to work :-)

Pascal

[gustafson]

On Thursday 13 December 2007 10:50:18 Dupuis wrote:

> David Bateman-3 wrote:
> > There are going to be fixes after 3,0, and 2.9.19 is really a bug fix
> > release for 2.9.18. So why not Friday next week, after seeing there are
> > no major issues with 2.9.19, and give us a Xmas present :-)
> > D.
>
> Excellent idea. This way, Debian maintainers will have enough free time to
> prepare new packages, and the upgrade will be ready when going back to work
>
> :-)
>
> Pascal

I had one thought as I was compiling 2.9.19 yesterday... the lingering issue
of print() and sizing.  I don't think we should "fix" the problem before 3.0,
however I suggest disabling the "-S" sizing option so as to not establish a
backwards compatibility issue.  

Just a thought,
Pete Gustafson

[John W. Eaton]

On 13-Dec-2007, Peter A. Gustafson wrote:

| I had one thought as I was compiling 2.9.19 yesterday... the lingering issue
| of print() and sizing.  I don't think we should "fix" the problem before 3.0,
| however I suggest disabling the "-S" sizing option so as to not establish a
| backwards compatibility issue.  

OK, that's probably a reasonable thing to do.

Now that we have fontname and fontsize properties, should we also drop
the -F options for setting the font properties?

jwe

[John W. Eaton]

On 12-Dec-2007, David Bateman wrote:

| John W. Eaton wrote:
| > I have no plans to add any significant features at this point, and
| > would like to go ahead with releasing 3.0 soon.  So how long should we
| > wait before doing that?  Two weeks?  Three?
| >
| > jwe
| >
|
| There are going to be fixes after 3,0, and 2.9.19 is really a bug fix
| release for 2.9.18. So why not Friday next week, after seeing there are
| no major issues with 2.9.19, and give us a Xmas present :-)

If there are no objections and no major new bugs are reported, then
the end of next week is fine for me.

jwe

[kahacjde]

David Bateman schrieb:

> John W. Eaton wrote:
>  
>> I have no plans to add any significant features at this point, and
>> would like to go ahead with releasing 3.0 soon.  So how long should we
>> wait before doing that?  Two weeks?  Three?
>>
>> jwe
>>
>>    
>
> There are going to be fixes after 3,0, and 2.9.19 is really a bug fix
> release for 2.9.18. So why not Friday next week, after seeing there are
> no major issues with 2.9.19, and give us a Xmas present :-)
>
> D.
>
>  

If not prevented by a major bug, I would also vote for a release end of
next week. ;-)

Kai

[John W. Eaton]

On 13-Dec-2007, John W. Eaton wrote:

| OK, that's probably a reasonable thing to do.
|
| Now that we have fontname and fontsize properties, should we also drop
| the -F options for setting the font properties?

If anyone has objections to these changes, please speak up soon,
otherwise I will assume that everyone agrees that dropping the size
and fontname options from the print function is a good idea.

Also, would it be reasonable to add imread and imwrite (plus any
required supporting functions) for 3.0?  These are core Matlab
functions, and now that we have better image display capability with
gnuplot, it would be nice to be able to load common image formats
easily.  Also, I think it confuses people that there is no way for
Octave to load a jpeg file without first installing a separate
package.  I'm not asking anyone to do the work, I can port the
functions from Octave Forge.  It seems to me that this change should
be OK even now, since these functions are independent of the rest of
Octave so should not introduce any new bugs in existing code but maybe
someone else sees a potential problem that I'm missing.

Comments?

Thanks,

jwe

[Søren Hauberg]

tor, 13 12 2007 kl. 16:53 -0500, skrev John W. Eaton:

> On 13-Dec-2007, John W. Eaton wrote:
>
> | OK, that's probably a reasonable thing to do.
> |
> | Now that we have fontname and fontsize properties, should we also drop
> | the -F options for setting the font properties?
>
> If anyone has objections to these changes, please speak up soon,
> otherwise I will assume that everyone agrees that dropping the size
> and fontname options from the print function is a good idea.

I have no strong opinions here.

> Also, would it be reasonable to add imread and imwrite (plus any
> required supporting functions) for 3.0?  These are core Matlab
> functions, and now that we have better image display capability with
> gnuplot, it would be nice to be able to load common image formats
> easily.  Also, I think it confuses people that there is no way for
> Octave to load a jpeg file without first installing a separate
> package.  I'm not asking anyone to do the work, I can port the
> functions from Octave Forge.  It seems to me that this change should
> be OK even now, since these functions are independent of the rest of
> Octave so should not introduce any new bugs in existing code but maybe
> someone else sees a potential problem that I'm missing.

I think it would be nice to have imread/imwrite in Octave. These
functions do however add a dependency on ImageMagick. If you add these
functions, what should happen with loadimage/saveimage? And what about
the Octave image format? Should it be removed or should imread/imwrite
be changed to support this format?

Cheers,
Søren

P.S. If the imshow function is called with a file name instead of an
image it loads the image of disc and displays it. For this, it currently
uses loadimage, but if imread gets added I think that function should be
used instead.

[Rafael Laboissiere]

* Dupuis <Pascal.Dupuis@...> [2007-12-13 07:50]:

> Excellent idea. This way, Debian maintainers will have enough free time to
> prepare new packages, and the upgrade will be ready when going back to work
> :-)

Oh, I love when people make assumptions about the readiness and availability
of free software volunteers :-).  Consider joining the DOG [1] and help us
making your assumptions become true.

[1] http://pkg-octave.alioth.debian.org/

Anyway, if 3.0 is released until the end of the next week, the chances are
high that Debian users of unstable (sid) will have the packages for
Christmas (why they would need them for Christmas is still an open question
:-)

--
Rafael

[John W. Eaton]

On 14-Dec-2007, Søren Hauberg wrote:

| I think it would be nice to have imread/imwrite in Octave. These
| functions do however add a dependency on ImageMagick.

Aren't those just run-time dependencies?  If ImageMagick is not
installed, don't the imread/imwrite functions throw errors?

I think more important new dependencies are libpng and jpeglib.  I
also just noticed this statement in jpgread.cc:

 // This is a hack into octave
 //   based on jpgread.c by jpgread by Drea Thomas, The Mathworks and the
 //        examples in the IJG distribution.
 //

Where did jpgread.c come from, and what is its license/distribution
status?

| If you add these functions, what should happen with
| loadimage/saveimage? And what about the Octave image format? Should
| it be removed or should imread/imwrite be changed to support this format?

I think we can keep the functions for now.  Eventually I think we
should at least move those functions to the deprecated directory and
maybe eventually remove them since doing that doesn't make it much
harder to read old Octave-format image files (they are simply two
matrices stored in an Octave data format, so it is easy to read them
with load).

| P.S. If the imshow function is called with a file name instead of an
| image it loads the image of disc and displays it. For this, it currently
| uses loadimage, but if imread gets added I think that function should be
| used instead.

Yes, that would be a good change to make.

OK, this is a little more complex than I thought (thanks for pointing
out some of the finer points) and so it can probably wait until after
3.0.  But I would definitely like to make these changes for 3.1.

Thanks,

jwe

[Søren Hauberg]

fre, 14 12 2007 kl. 13:47 -0500, skrev John W. Eaton:
> On 14-Dec-2007, Søren Hauberg wrote:
>
> | I think it would be nice to have imread/imwrite in Octave. These
> | functions do however add a dependency on ImageMagick.
>
> Aren't those just run-time dependencies?  If ImageMagick is not
> installed, don't the imread/imwrite functions throw errors?
>From what I understand we have the ' __magick_read__.oct' function that
links to libmagick (I think that's the name of the libraries that
ImageMagick provides).

Søren

[Jordi Gutiérrez Hermoso]

On 13/12/2007, John W. Eaton <jwe@...> wrote:

> On 12-Dec-2007, David Bateman wrote:
>
> | John W. Eaton wrote:
> | > I have no plans to add any significant features at this point, and
> | > would like to go ahead with releasing 3.0 soon.  So how long should we
> | > wait before doing that?
>
> If there are no objections and no major new bugs are reported, then
> the end of next week is fine for me.
>

Do we have any definite plans for making a lot of noise when this happens? :-)

- Jordi G. H.

[Dupuis]

Rafael Laboissiere wrote:

Oh, I love when people make assumptions about the readiness and availability
of free software volunteers :-).  Consider joining the DOG [1] and help us
making your assumptions become true.

[...]

No pun intented, I just noticed that around periods less intense in terms of workload, there were more updates in the FOSS field :-)  

Best regards

Pascal

[Benjamin Lindner]

> I have no plans to add any significant features at this point, and
> would like to go ahead with releasing 3.0 soon.  So how long should we
> wait before doing that?  Two weeks?  Three?
>
> jwe
>

I would vote for moving edit.m from the forge package to octave core
functions.
Argument is similar to the imread/imwrite topic. Why should I first
install a package to be able to conveniently invoke an editor.

It would also allow easier use of a packaged editor with the mingw binaries.

benjamin

[Tatsuro MATSUOKA-2]

Hello Benjamin

Benjamin wrote
> I would vote for moving edit.m from the forge package to octave core
> functions.
> Argument is similar to the imread/imwrite topic. Why should I first
> install a package to be able to conveniently invoke an editor.
>
> It would also allow easier use of a packaged editor with the mingw binaries.

That's a good idea!!
I also vote for moving edit.m from the forge package to octave core functions.


BTH, when your the next binaries will be coming up? At 3.0 release?
Anyway when you will have uploaded them, please inform us via the Octave ML.
I will update information in my web and OtaveForWindows Wiki as soon as possible.

Regards

Tatsuro  



--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/

[Michael Goffioul-2]

On 12/18/07, Tatsuro MATSUOKA <tmacchant@...> wrote:

> Hello Benjamin
>
> Benjamin wrote
> > I would vote for moving edit.m from the forge package to octave core
> > functions.
> > Argument is similar to the imread/imwrite topic. Why should I first
> > install a package to be able to conveniently invoke an editor.
> >
> > It would also allow easier use of a packaged editor with the mingw binaries.
>
> That's a good idea!!
> I also vote for moving edit.m from the forge package to octave core functions.

Why not also package octave-forge in the mingw binaries?

Michael.

[John W. Eaton]

On 18-Dec-2007, Michael Goffioul wrote:

| On 12/18/07, Tatsuro MATSUOKA <tmacchant@...> wrote:
| > Hello Benjamin
| >
| > Benjamin wrote
| > > I would vote for moving edit.m from the forge package to octave core
| > > functions.
| > > Argument is similar to the imread/imwrite topic. Why should I first
| > > install a package to be able to conveniently invoke an editor.
| > >
| > > It would also allow easier use of a packaged editor with the mingw binaries.
| >
| > That's a good idea!!
| > I also vote for moving edit.m from the forge package to octave core functions.
|
| Why not also package octave-forge in the mingw binaries?

I think it would be best if the standalone Windows distributions were
essentially the same except for the choice of compiler.  Would it be
difficult to make that happen?

jwe

[Tatsuro MATSUOKA-2]

Hello Michael and jwe.

Michael> Why not also package octave-forge in the mingw binaries?

jwe> I think it would be best if the standalone Windows distributions were
jwe> essentially the same except for the choice of compiler.  Would it be
jwe> difficult to make that happen?

I do not want my mingw binaries to be official release.
Perhaps Benjamin will provide the official release at octave-forge.
Yesterday I saw Benjamin's svn repository.  It seems that he is now extesively preparing the next
release.

The concept of my mingw binaries are to distribute the latest Windows native binary
as early as possible because of the building process octave itself on mingw is now quite easy.
What I have to do is to execute ./configure, make and make install-strip
if the external libraries are prepared.

However, for the forge packages, I have not fully test them.
I have only tried the odepkg package and it was successful.
>From users standpoint, I think that edit command is convinient.
So it is useful for users to be able to use edit command whether
the forge packages are installed or not.
This is because I agreed with Benjamin's proposal.

PS
I have just tried to build the miscellaneous package after your mails.
pkg install -local miscellaneous-1.0.4.tar.gz
 :
 :
make: *** [waitbar.oct] Error 1
The above is not really concerning to the discussion but it was the fact for my binary.
I will purchase the origin from now.

Anyway I'd like to hope to be usable edit command without using the forge packages.

Regards
 
Tatsuro






--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/

[John W. Eaton]

On 18-Dec-2007, Benjamin Lindner wrote:

| I would vote for moving edit.m from the forge package to octave core
| functions.
| Argument is similar to the imread/imwrite topic. Why should I first
| install a package to be able to conveniently invoke an editor.

OK, I added edit.m to Octave because it is a single .m file, so moving
it is easy.

I don't plan to move imread/imwrite to Octave until after 3.0 because
they are more complex and involve library dependencies.

jwe