Re: Octave-maintainers Digest, Vol 51, Issue 15

[Jonas Xavier]

Hi everybody. About the books with Octave's examples, my idea is translate the "GNU Octave Manual". I'm reading the book, but a large number of peoples don't understand English. Here in Brazil, the Matlab is the most used because have docs in Portuguese.  The Wikipedia has a project of open books, called Wikibooks, is a good begin, and the Wikibooks has a powerful community.

2010/6/10 <address@hidden>

Send Octave-maintainers mailing list submissions to
       address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
       https://www-old.cae.wisc.edu/mailman/listinfo/octave-maintainers
or, via email, send a message with subject or body 'help' to
       address@hidden

You can reach the person managing the list at
       address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Octave-maintainers digest..."


Today's Topics:

  1. Re: Book project (John W. Eaton)
  2. Re: Logos proposal (John W. Eaton)
  3. Re: Logos proposal (Fotios Kasolis)
  4. Re: Bug tracker for Octave Forge (John W. Eaton)
  5. Re: Bug tracker for Octave Forge (Rik)
  6. Re: Bug tracker for Octave Forge (S?ren Hauberg)
  7. Re: Book project (Levente Torok)


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

Message: 1
Date: Thu, 10 Jun 2010 11:39:21 -0400
From: "John W. Eaton" <address@hidden>
Subject: Re: Book project
To: Fotios Kasolis <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

I think it would be great to have books focused on Octave.  It doesn't
matter that there are N books about Matlab.  I think it actually
causes trouble for us when people use Octave but are reading books
about Matlab because they inevitably run into incompatible behavior
and the immediate reaction (based on what I see on the mailing lists
and in bug reports) is that Octave sucks.  So having books that show
Octave examples that actually work correctly in Octave should be a
positive thing.

jwe



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

Message: 2
Date: Thu, 10 Jun 2010 11:47:03 -0400
From: "John W. Eaton" <address@hidden>
Subject: Re: Logos proposal
To: Fotios Kasolis <address@hidden>
Cc: Ben Barrowes <address@hidden>,
       address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

I like the more abstract versions as well.

When I made the first sombrero image for Octave's web page back in
about 1997, I really didn't think too much about it.  I was just
trying to get some 3D image that Octave could create and that I would
not have to spend a lot of time generating.  The sombrero image was
easy to make.  That it was a similar to the peaks function that is the
Matlab logo never occurred to me until much later, and if I had, I
would probably chosen something else.  So I would prefer to avoid the
sombrero image as an Octave logo.

I would prefer to avoid having anything in the logo that refers to
music since Octave is not named for the musical octave.  Anything that
reinforces that misconception should be avoided.

Do we have to have a single logo/icon image?  I don't see a problem
with having more than one.

Thanks,

jwe


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

Message: 3
Date: Thu, 10 Jun 2010 18:00:12 +0200
From: Fotios Kasolis <address@hidden>
Subject: Re: Logos proposal
To: "John W. Eaton" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii


On Jun 10, 2010, at 5:47 PM, John W. Eaton wrote:

> I like the more abstract versions as well.
>
> When I made the first sombrero image for Octave's web page back in
> about 1997, I really didn't think too much about it.  I was just
> trying to get some 3D image that Octave could create and that I would
> not have to spend a lot of time generating.  The sombrero image was
> easy to make.  That it was a similar to the peaks function that is the
> Matlab logo never occurred to me until much later, and if I had, I
> would probably chosen something else.  So I would prefer to avoid the
> sombrero image as an Octave logo.
>
> I would prefer to avoid having anything in the logo that refers to
> music since Octave is not named for the musical octave.  Anything that
> reinforces that misconception should be avoided.
>
> Do we have to have a single logo/icon image?  I don't see a problem
> with having more than one.
>
> Thanks,
>
> jwe

My suggestion is that we have one, unique, and global icon application and several logos. The icon uniqueness axiom is good in the sense that everybody will recognize Octave by its application icon, it is like giving an id that signals the product. On the other hand a logo is sth that we place in our web pages or printed teaching material and there should be some alternatives.


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

Message: 4
Date: Thu, 10 Jun 2010 12:00:30 -0400
From: "John W. Eaton" <address@hidden>
Subject: Re: Bug tracker for Octave Forge
To: Rik <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On  9-Jun-2010, Rik wrote:

| Ben Abbott wrote:
| > On Jun 9, 2010, at 5:24 PM, Rik wrote:
| >
| >> 6/9/10
| >>
| >> How do we want to handle bugs related to Octave Forge on the savannah bug
| >> tracker?  At least two bugs have now been posted to the site which are
| >> really concerned with Octave Forge packages and not with Octave itself.  We
| >> could simply close the bugs with a note to the reporter that this is not
| >> the right place to report these.  Or I suppose we could figure out a more
| >> gentle solution, although I personally don't have a lot of patience for
| >> porting bugs from one tracker to another.
| >>
| >> --Rik
| >
| > Perhaps the bug-tracker could include a "octave-forge"  category?

The status field already includes "Octave Forge", so we can

| Yes, if we want the savannah tracker to become a joint tracker for Octave
| and Octave-Forge.  I'm not sure, however, that we want to take on that role.

I don't want the Octave bug tracker to be the place to report bugs for
Octave Forge packages.  Those packages are not part of Octave and I
don't think we want to appear to be responsible for the bug reports
for them.

OTOH, people don't seem to understand when they are using a function
from a package vs. a function from Octave, so they will continue to
report bugs in package functions in the Octave tracker.  It would be
good to have a way to move those bugs to the appropriate place rather
than just telling people that they have done something wrong by
reporting the bug.  Unfortunately, I don't see a way to do that unless
we are using the same bug tracking system for both projects.  And even
then, if Octave and Octave Forge are separate projects on savannah,
the current savannah tracker does not seem to allow bugs to be moved
from one project to another.  Maybe that could be fixed, but is
savannah even the right place for Octave Forge?  Given the current
variety of licensing in Octave Forge and the fact that it is not a GNU
project, I think it would have to be hosted at savannah.nongnu.org.
It's not clear whether the gnu and non-gnu parts of savannah share the
same tracker.  Bug numbers appear to be assigned globally, but
searching by bug number seems to also be somehow limited within
packages.

jwe


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

Message: 5
Date: Thu, 10 Jun 2010 09:11:23 -0700
From: Rik <address@hidden>
Subject: Re: Bug tracker for Octave Forge
To: "John W. Eaton" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

>
> I don't want the Octave bug tracker to be the place to report bugs for
> Octave Forge packages.  Those packages are not part of Octave and I
> don't think we want to appear to be responsible for the bug reports
> for them.
That was generally my feeling.  Although it's off-putting, I think we need
to flag these bugs using the Octave-Forge tag; write a quick response
saying that the problem function is in Octave Forge, not Octave; link to a
location to report Octave Forge bugs; and put the bug in a queue to be
closed in a few weeks.

--Rik


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

Message: 6
Date: Thu, 10 Jun 2010 09:12:01 -0700
From: S?ren Hauberg <address@hidden>
Subject: Re: Bug tracker for Octave Forge
To: "John W. Eaton" <address@hidden>
Cc: Rik <address@hidden>, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="UTF-8"

tor, 10 06 2010 kl. 12:00 -0400, skrev John W. Eaton:
> I don't want the Octave bug tracker to be the place to report bugs for
> Octave Forge packages.  Those packages are not part of Octave and I
> don't think we want to appear to be responsible for the bug reports
> for them.

I can understand this position.

> OTOH, people don't seem to understand when they are using a function
> from a package vs. a function from Octave, so they will continue to
> report bugs in package functions in the Octave tracker.

I don't really know what we can do to change this perception. One option
would be to mark all packages as "noautoload", such that people would be
forced to run

 pkg load package_name

before using a package function. That would make it more clear where a
package is coming from, but I guess such an action would just create
angry users.

> It would be
> good to have a way to move those bugs to the appropriate place rather
> than just telling people that they have done something wrong by
> reporting the bug.

I fear that a lot of people get the impression today that they did
something wrong when reporting a bug.

> Maybe that could be fixed, but is
> savannah even the right place for Octave Forge?  Given the current
> variety of licensing in Octave Forge and the fact that it is not a GNU
> project, I think it would have to be hosted at savannah.nongnu.org.

These days I think we have one non-free package (some spline stuff) that
hasn't been maintained in years (I don't think anything has been checked
into that package in all the time I've been involved). I'd be willing to
remove this package from the repository.

All other packages seem to be GPL, BSD or public domain. So is licensing
really an issue?

S?ren



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

Message: 7
Date: Thu, 10 Jun 2010 18:25:42 +0200
From: Levente Torok <address@hidden>
Subject: Re: Book project
To: "John W. Eaton" <address@hidden>
Cc: address@hidden
Message-ID:
       <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Not a very recommended way but I would probably use one of the matlab
books as a skeleton in order to help people convert their knowledge or
mature it similar to the case of matlab. Not because matlab (books)
is(are) superior or no-one has the ability to write as good book as it
is for matlab but we have to agree that most people think of octave as
a free alternative of matlab. So we can honestly and humbly taking
advantage of this belief.
On the other hand I would be very happy to have a book with complex examples.
I am also keen on seeing something about the object oriented part as
well as about the embedded C++ coding.
Any time I need to write an embedded octave function in C++ I am
facing with the lack of documentation (not autodoc generated stuff)
and/or useful examples so I usually find myself reading the source
code which is already a very complex and comprehensive.
So I would be grateful to have something easy to read about this or
some introductory to this.

Lev

On Thu, Jun 10, 2010 at 5:39 PM, John W. Eaton <address@hidden> wrote:
> I think it would be great to have books focused on Octave. ?It doesn't
> matter that there are N books about Matlab. ?I think it actually
> causes trouble for us when people use Octave but are reading books
> about Matlab because they inevitably run into incompatible behavior
> and the immediate reaction (based on what I see on the mailing lists
> and in bug reports) is that Octave sucks. ?So having books that show
> Octave examples that actually work correctly in Octave should be a
> positive thing.
>
> jwe
>
>



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

_______________________________________________
Octave-maintainers mailing list
address@hidden
https://www-old.cae.wisc.edu/mailman/listinfo/octave-maintainers


End of Octave-maintainers Digest, Vol 51, Issue 15
**************************************************