Colin Macdonald | 26 Apr 22:35 2015
Picon
Picon

cell-array display in class

Hi,

I like how Octave displays cell arrays.  Is it possible to enable the 
`[i,j] = ` display in my own class?  If so, how?  If not, I'll file a 
bug to improve on the status quo shown below.

Example: good:

> >> C = {1 2; 3 4}
> C =
> {
>   [1,1] =  1
>   [2,1] =  3
>   [1,2] =  2
>   [2,2] =  4
> }

Not so good:

> >> pkg load symbolic
> >> pkg load interval
>
> >> C(2,1) = sym('x')
> C =
> {
>   [1,1] =  1
> (sym) x
>   [1,2] =  2
>   [2,2] =  4
> }
(Continue reading)

Oliver Heimlich | 26 Apr 12:32 2015
Picon

Manual for GNU Octave package (Octave-Forge)

I have recentently started to learn GNU Texinfo and, for example, create 
the NEWS file for my Octave Forge package from Texinfo sources, which 
saves me from the dull work of aligning plaintext paragraphs/list by hand.

Now I want to start a user manual for my package.

At first I worked on a manual page in the wiki, which was very 
beneficial in the early days of the package. I could publish 
documentation and package releases independently. It sped up 
development, because I could work on the software and its documentation 
asynchronously.

The wiki documentation is no longer an advantage and I want the package 
release to contain a matching documentation (for many different reasons) 
from now on. I started a doc/manual.texinfo file, which is naturally 
also going to be in the release tarball. However, the “pkg install” will 
probably drop it and the user is never going to see the manual. How 
should I release the manual?

1. Should I generate a HTML version of the package manual and include it 
in the [package]-html.tar.gz for publication on Octave Forge? I could 
use the HTML template from the generate_html package to get a matching 
design. I could patch the package's index.html to contain a link to the 
manual next to the function reference.

2. Should I bundle any compiled version of the manual in the package 
release tarball? Or should I leave this to downstream distributors? Are 
there any conventions, which downstream distributors expect?

3. Can you recommend any graphical editors for Texinfo files? I am 
(Continue reading)

Daniel J Sebald | 26 Apr 10:51 2015
Picon

GUI forced exit when core thread is busy/frozen

At this bug report:

https://savannah.gnu.org/bugs/?44485

we've been trying to piece together an acceptable way to force exit from 
the GUI when the core is busy or frozen.  It seems that such a thing is 
needed because

* With the GUI there is now the ability to select exit from the File 
dropdown menu.  Doing nothing if the interpreter is busy processing 
doesn't seem correct.

* If the core freezes, it would be nice to have the capability to force 
exit rather than the user have to use the system to kill the process.

The question is what exactly to do.

First, let me provide some details which I think are a good approach.

1) Exiting, as of a couple months ago, now takes a path via the 
interpreter for both the user typing "exit" and the user selecting 
"Exit" from the File dropdown menu (or Cntrl-Q).  That is, every proper 
exit follows the same code path.  That's just good practice.  Hence the 
proper shutdown is to go to the interpreter, execute exit/quit, which 
goes back to the GUI and confirms it should shutdown (i.e., check open 
files), then the core does its shutdown followed by the GUI doing its 
shutdown.

2) If the user selects File:Exit, a timer is started and if after three 
seconds the core doesn't respond to the exit with the shutdown inquiry, 
(Continue reading)

Philip Nienhuis | 25 Apr 16:56 2015
Picon

laguerre.m functions in specfun package

After Colin has tidied up a bit in the OF specfun package, I'm planning to
make a new release of it.

The package in the mercurial repo contains two laguerre.m functions, one in
inst/, the other in devel/

The latter looks to be a bit more elaborate (it contains a demo and perhaps
more aptly named variables), to compensate for that it is lacking a bit in
coding style and lacks the one comment line that was present in the original
(?) one in inst/.

So, any advice about which laguerre.m to retain?

If no one reacts within a few days I'll polish op the laguerre.m in devel/
and make a new specfun release.

Philip

--
View this message in context: http://octave.1599824.n4.nabble.com/laguerre-m-functions-in-specfun-package-tp4670060.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

Tomasz Ożański | 25 Apr 13:42 2015
Picon

SoCiS: interfacing Symbolics package with Python

Dear All,

Since my maximum entropy method algorithm proposal seems to be troublesome to be realized during this
edition, I would like to try with another topic, this time a one form the list of proposed ideas — namely I
would be interested in the development of the Symbolic package. I believe I can handle the interface
between the package and Python. 

I would like to ask you one question regarding the topic: what do you mean in „interacting with Python as a
library”? I do not know SymPy, but it seems to be written entirely in Python so it must not exist as a
standard system library, so my guess is I would have to write some intermediate code in C/C++ to handle all
the communication, am I right?

greetings,
Tomasz 

Tatsuro MATSUOKA | 25 Apr 02:42 2015
Picon

Help for test octave 4.0.0 rc3 on windows for path containing multibyte characters

Hello

I have created a bug item:

Cannot change directory path of which have Japanese Character

https://savannah.gnu.org/bugs/?44922

This will not only happen on Japanese version of windows but also windows for multi-byte character system.
Does anyone test on windows for other  multi-byte character system and add results to the above tracker
item ?

Tatsuro  

Carnë Draug | 23 Apr 21:23 2015

symbolic 2.2.1 released

Hi everyone

a new release of the symbolic package [1] is out, version 2.2.1, by
Colin B. Macdonald.
A summary of important user-visible changes is also available online [2].

This package adds symbolic calculation features to GNU Octave.
These include common Computer Algebra System tools such as algebraic
operations, calculus, equation solving, Fourier and Laplace transforms,
variable precision arithmetic and other features.  Internally, the
package uses [SymPy](www.sympy.org), but no knowledge of Python is
required.  Compatibility with other symbolic toolboxes is intended.

Enjoy Octave responsibly,
Carnë

[1] http://octave.sourceforge.net/symbolic/
[2] http://octave.sourceforge.net/symbolic/NEWS.html

rik | 23 Apr 18:23 2015

Release checklist

> Subject:
> Re: Octave library version for release
> From:
> Mike Miller <mtmiller <at> octave.org>
> Date:
> 04/23/2015 07:30 AM
> To:
> "John W. Eaton" <jwe <at> octave.org>
> CC:
> Octave Maintainers <octave-maintainers <at> gnu.org>
> List-Post:
> <mailto:octave-maintainers <at> gnu.org>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <20150423122529.GA21393 <at> xps14z.home.local> <5538F35F.8080607 <at> octave.org>
> In-Reply-To:
> <5538F35F.8080607 <at> octave.org>
> Message-ID:
> <CAD6LDLJ8GLujy-WTqMmr=0-SBS8AOxj2jVM9gGCtS2CCQQFh_A <at> mail.gmail.com>
> Content-Type:
> text/plain; charset=UTF-8
> Message:
> 3
>
> On Thu, Apr 23, 2015 at 08:27:59 -0500, John W. Eaton wrote:
> > That's OK, I think this is something that should be done just before the
> > release.  At least you remembered!  I suppose "update library versions"
> > should be on a elease checklist somewhere.
> Sounds good. I'm just the messenger though, have to thank Rafael and
> Sébastien on the Debian packaging team for noticing this as part of
> packaging rc3, all I did was confirm that I had seen this and work up
> some examples to double check.
>
> > I'm sure we've removed, changed, and added public interfaces to liboctave,
> > liboctinterp, and liboctgui since the last release, so we should increment
> > the first version number for all of the libraries and set the other two to
> > zero as in the attached diff.
> Yep, untested but I think that works.
>
> What about the OCTAVE_API_VERSION string?


There are two files in etc/ that are being used to track this: CHECKLIST and RELEASE.PROCESS.  I would probably fold CHECKLIST in to the bottom of RELEASE.PROCESS and add the note about updating libary versions in RELEASE.PROCESS.

--Rik

Alex Lam | 23 Apr 14:44 2015
Picon

Wanna join the development mailing list

Hi administrator(s),

I have been using Matlab for years and recently I switched to Octave. I really think this is a good stuff and I want to join your team to improve it. The programming language I use are C\C++ and  I have been using them for a while for my Master research project. This is my first time to do open source project am I welcomed? Thank you.


Regards,

Alex Lam

Mike Miller | 23 Apr 14:25 2015

Octave library version for release

Hey jwe, maintainers,

Sorry for bringing this up so late in the release cycle, but should
Octave 4.0.0 still be liboctave.so.2 / liboctinterp.so.2 or should the
version be bumped to 3? It seems that some things are not quite
backwards compatible, so programs or oct-files built against 3.8.2's
liboctave.so.2 may not work with 4.0.0's liboctave.so.2.

Several functions marked deprecated have been removed in 4.0.0. A simple
standalone test program that declares an Octave_map object, for example,
results in the following:

    ./testprog: Symbol `_ZTV17octave_base_value' has different size in shared object, consider re-linking
    ./testprog: symbol lookup error: ./testprog: undefined symbol: _ZN10Octave_mapC1ERK10dim_vectorRK4Cell

The following example session also shows that something is not quite
right with a very simple oct-file [1] compiled against 3.8.2 and used in
4.0.0:

    $ octave-3.8.2 -q --no-gui-libs
    octave:1> mkoctfile is_real_matrix.cc
    octave:2> is_real_matrix (5)
    ans =  1
    octave:3> is_real_matrix ([1, 2; 3, 4])
    ans =  1
    octave:4> quit
    $ octave-4.0.0-rc3 -q --no-gui-libs
    octave:1> is_real_matrix (5)
    ans = 0
    octave:2> is_real_matrix ([1, 2; 3, 4])
    ans = 0
    octave:3> mkoctfile is_real_matrix.cc
    octave:4> clear -f
    octave:5> is_real_matrix (5)
    ans =  1
    octave:6> is_real_matrix ([1, 2; 3, 4])
    ans =  1

[1] http://hg.code.sf.net/p/octave/control/file/tip/src/is_real_matrix.cc

--

-- 
mike

Julien Bect | 23 Apr 08:33 2015
Picon

A question for package maintainers still using TexInfo < 5

Hello all,

There is an ongoing discussion on this bug report: 
https://savannah.gnu.org/bugs/index.php?44899 which is related to the 
generate_html package.

The point is: there is a hack in several functions of the package 
(html_help_tex, texi2html) which is supposed to deal with a bug in 
makeinfo. The bug is longer present in recent TexInfo releases, and the 
hack has some unpleasant side effects.

Is there any package maintainer still using TexInfo < 5 ? If there is, 
could he or she join the discussion and see if removing the hack would 
cause any inconvenience ?

 <at> ++
Julien


Gmane