Orion Poplawski | 31 Jul 23:01 2015

octave control test failure

So now that we've figured out how to run pkg tests as part of our normal
builds in Fedora, I have some failures to report.

From control:

  ltimodels.m ........................ PASS   21/33   FAIL 12

>> test('/usr/share/octave/packages/control-2.8.3/ltimodels.m','verbose')
>>>>> /usr/share/octave/packages/control-2.8.3/ltimodels.m
***** shared ltisys
 ltisys = tf (12);
***** assert (ltisys.ts, -2);
***** assert (isct (ltisys));
***** assert (isdt (ltisys));
***** shared ltisys
 ltisys = ss (17);
***** assert (ltisys.ts, -2);
***** assert (isct (ltisys));
***** assert (isdt (ltisys));
***** shared ltisys
 ltisys = tf (1, [1 1]);
***** assert (ltisys.ts, 0);
***** assert (isct (ltisys));
***** assert (! isdt (ltisys));
***** shared ltisys, ts
 ts = 0.1;
 ltisys = ss (-1, 1, 1, 0, ts);
***** assert (ltisys.ts, ts);
***** assert (! isct (ltisys));
***** assert (isdt (ltisys));
(Continue reading)

Rik | 31 Jul 20:14 2015

Re: patch for union.m

On 07/31/2015 09:00 AM, octave-maintainers-request <at> gnu.org wrote:
Subject:
Re: an unreported fix to union.m
From:
Juan Pablo Carbajal <ajuanpi+dev <at> gmail.com>
Date:
07/31/2015 05:08 AM
To:
Maintainers GNU Octave <octave-maintainers <at> gnu.org>
List-Post:
<mailto:octave-maintainers <at> gnu.org>
Precedence:
list
MIME-Version:
1.0
References:
<CABDtPkQgFi6nBc1_j+PBZo_9sCL41t7H2cginaTcfWgB4ATt-w <at> mail.gmail.com>
In-Reply-To:
<CABDtPkQgFi6nBc1_j+PBZo_9sCL41t7H2cginaTcfWgB4ATt-w <at> mail.gmail.com>
Message-ID:
<CABDtPkQZT2-_hz9cDX4uaMUmguTnVjRhi609fa9xTn+km==C-g <at> mail.gmail.com>
Content-Type:
text/plain; charset=UTF-8
Message:
5

On Fri, Jul 31, 2015 at 1:02 PM, Juan Pablo Carbajal <ajuanpi+dev <at> gmail.com> wrote:
I have condensed the changes into a single line correction and added some tests. Please verify that indeed the output is compatible with Matlab's https://savannah.gnu.org/patch/index.php?8710

Juan,

I know you were following the code that was already there, but I think it can be simplified further.  There is no need to check both isvector() and isrow() since isrow already checks that the input is a vector.

+  isrowvec = ( isempty(a) || (isvector (a) && isrow (a)) ) && ...
+             ( isempty(b) || (isvector (b) && isrow (b)) );

=>

  isrowvec = (isrow (a) || isempty (a)) && (isrow (b) || isempty (b));

--Rik
Rik | 31 Jul 18:30 2015

Re: Race condition in doc build

On 07/31/2015 09:00 AM, octave-maintainers-request <at> gnu.org wrote:
Subject:
Re: possible doc race condition - ideas or insight?
From:
Mike Miller <mtmiller <at> octave.org>
Date:
07/31/2015 04:57 AM
To:
Octave Maintainers <octave-maintainers <at> gnu.org>
List-Post:
<mailto:octave-maintainers <at> gnu.org>
Content-Transfer-Encoding:
8bit
Precedence:
list
MIME-Version:
1.0
References:
<20150731113234.GA1587 <at> xps14z.home.local>
In-Reply-To:
<20150731113234.GA1587 <at> xps14z.home.local>
Message-ID:
<20150731115744.GA8488 <at> xps14z.home.local>
Content-Type:
text/plain; charset=utf-8
Message:
4

On Fri, Jul 31, 2015 at 07:32:34 -0400, Mike Miller wrote:
> if I make those targets individually. But I have not yet triggered the > failure shown above with my own parallel builds.
I have now been able to reproduce this race condition by going lower and calling two instances of the font compilation command that the other TeX commands call implicitly: $ ( mktexpk --mfmode ljfour --bdpi 600 --mag 1+3/600 --dpi 603 ecti1095 \ >& log1 || echo FAIL ) & \ ( mktexpk --mfmode ljfour --bdpi 600 --mag 1+3/600 --dpi 603 ecti1095 \ >& log2 || echo FAIL ) FAIL $ cat log1 mkdir: cannot create directory ‘././home/mike/.texmf-var/fonts/pk/ljfour’: File exists mktexpk: /usr/share/texlive/texmf-dist/web2c/mktexdir /home/mike/.texmf-var/fonts/pk/ljfour/jknappen/ec failed. So yes there is a race condition with parallel builds of *.ps and *.pdf. Thanks for your attention :)
Mike,

The race condition is supposed to be resolved by the following rule in doc/interpreter/Makefile.am

-- Snip --
## The texi2dvi script (used to create both PDF and DVI output formats)
## uses some fixed temporary file names.  In order to avoid a race condition
## the DVI and PDF builds are forced to run serially through a Makefile rule.
octave.pdf: octave.dvi
-- End Snip --

This may need to be amended to depend on octave.ps as well.  Theoretically, that should be enough since octave.ps is created through dvips which will require building octave.dvi first.  But maybe it is safer to have octave.pdf depend on BOTH octave.dvi and octave.ps.

--Rik


Mike Miller | 31 Jul 13:32 2015

possible doc race condition - ideas or insight?

All,

I've noticed a build failure of Octave 4.0.0 (with Texinfo 6 patches) on
one of the Ubuntu autobuilders [1]. The error message

  kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+3/600 --dpi 603 ecti1095
  mkdir: cannot create directory '././home/buildd/.texmf-var/fonts/pk/ljfour': File exists
  mktexpk: /usr/share/texlive/texmf-dist/web2c/mktexdir
/home/buildd/.texmf-var/fonts/pk/ljfour/jknappen/ec failed.
  kpathsea: Appending font creation commands to missfont.log.
  (Operator Index) [953] [954]) [955] [956] )
  (see the transcript file for additional information)
  !pdfTeX error: pdfetex (file ecrm1095): Font ecrm1095 at 603 not found
   ==> Fatal error occurred, no output PDF file produced!

looks to me like some kind of simultaneous access failure. I have not
been able to reproduce this myself, but I suspect a race condition
between the dvips and texi2pdf (which calls pdfetex) programs.

I won't pretend to understand much about the TeX software suite, but it
seems to be compiling fonts and caching the results in the user's home
directory as needed. I believe these font caches are a result of the
recent upgrade to a new texinfo.tex, needed to support GNU Texinfo 6.

All I've been able to verify myself are that the octave.ps and
octave.pdf targets do both create font caches (with the same two fonts)
in ~/.texmf-var/fonts (the directory may be different on another distro)
if I make those targets individually. But I have not yet triggered the
failure shown above with my own parallel builds.

Anyone understand more about this problem? Any opinions if we should do
anything about this? A couple of options might be

 * make octave.pdf order-depend on octave.ps to force serial execution
 * set either the TEXMFVAR or VARTEXFONTS environment variables similar
   to the --build-dir option
 * ignore it

[1]: https://launchpadlibrarian.net/212257965/buildlog_ubuntu-wily-i386.octave_4.0.0-3_BUILDING.txt.gz

Thanks,

--

-- 
mike

Juan Pablo Carbajal | 31 Jul 13:02 2015
Picon

an unreported fix to union.m

Hi,

The developer of this software (see commments)
http://journal.frontiersin.org/article/10.3389/fninf.2013.00008/abstract

fixed an compatibility issue in union.m of octave. Of course the fix
is not compatible with Octave standards. However if we need this fix I
will port it.

The difference is

--- /home/juanpi/Devel/octave/default/scripts/set/union.m
+++ /home/juanpi/Downloads/ndt.1.0.4_exported/octave_code/union.m
 <at>  <at>  -40,7 +40,7  <at>  <at> 
 ##  <at> seealso{unique, intersect, setdiff, setxor, ismember}
 ##  <at> end deftypefn

-## Author: jwe
+## Author: jwe, modified by Ethan Meyers 2015

 function [y, ia, ib] = union (a, b, varargin)

 <at>  <at>  -48,11 +48,35  <at>  <at> 
     print_usage ();
   endif

-  [a, b] = validsetargs ("union", a, b, varargin{:});
+

   by_rows = nargin == 3;
   isrowvec = isvector (a) && isvector (b) && isrow (a) && isrow (b);

+
+  % Modified by Ethan to deal with creating a union between an empty
vector and a cell array
+  if isempty(a)
+    if by_rows
+      y = unique(b, 'rows');
+    else
+      y = unique(b);
+    end
+    return
+  end
+
+ if isempty(b)
+    if by_rows
+      y = unique(a, 'rows');
+    else
+      y = unique(a);
+    end
+    return
+ end
+
+
+ [a, b] = validsetargs ("union", a, b, varargin{:});
+
+
   if (by_rows)
     y = [a; b];
   else

Comments?

PrasannaKumar Muralidharan | 31 Jul 12:54 2015
Picon

OctConf 2014 slides and videos

Hi,

As we are nearing OctConf 2015 and several months since OctConf 2014 I
request to upload OctConf 2014 slides and video so that the whole
octave community can benefit.

Thanks and regards,
PrasannaKumar

Rik | 30 Jul 17:23 2015

Verbose make output for documentation

7/30/15

All,

Is everyone else seeing copious output when building the documentation?  I
have a changeset that quiets things down in accord with the new silent
rules option, but it has occurred to me that maybe it is only my
installation with a relatively old version of automake that has this problem.

A quick test is

rm doc/interpreter/octave.pdf
make -j1 doc/interpreter/octave.pdf

--Rik

Orion Poplawski | 30 Jul 04:48 2015

octave-image requires c++11

It appears that octave-image 2.4.0 requires c++11:

checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... no
checking whether g++ supports C++11 features with -std=gnu++0x... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... no
configure: error: *** A compiler with support for C++11 language 
features is required.

While I can very much sympathize with wanting to have progress, just 
note that it is a bit trickier (though not impossible) to get access to 
a C++11 compiler on RHEL6.  Just something I wanted to note.

--

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion <at> cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

Orion Poplawski | 30 Jul 00:53 2015

Fwd: [Bug 1244844] New: octave-specfun: shadowing of core library functions

Is this anything we should worry about or is it expected?

-------- Forwarded Message --------
Subject: [Bug 1244844] New: octave-specfun: shadowing of core library functions
Date: Mon, 20 Jul 2015 15:13:32 +0000
From: bugzilla <at> redhat.com
To: orion <at> cora.nwra.com

https://bugzilla.redhat.com/show_bug.cgi?id=1244844

            Bug ID: 1244844
           Summary: octave-specfun: shadowing of core library functions
           Product: Fedora
           Version: 22
         Component: octave
          Assignee: jcapik <at> redhat.com
          Reporter: chris <at> ianni.de
        QA Contact: extras-qa <at> fedoraproject.org
                CC: alexl <at> users.sourceforge.net, fkluknav <at> redhat.com,
                    jcapik <at> redhat.com, mmahut <at> redhat.com,
                    orion <at> cora.nwra.com, rakesh.pandit <at> gmail.com,
                    susi.lehtola <at> iki.fi

Description of problem:
on startup:

warning: function /usr/share/octave/packages/specfun-1.1.0/erfcinv.m shadows a
built-in function
warning: function /usr/share/octave/packages/specfun-1.1.0/expint.m shadows a
core library function
warning: function /usr/share/octave/packages/specfun-1.1.0/ellipke.m shadows a
core library function
warning: function
/usr/lib64/octave/packages/specfun-1.1.0/x86_64-redhat-linux-gnu-api-v49+/ellipj.oct
shadows a built-in function

Version-Release number of selected component (if applicable):
rpm -qa octave*
octave-general-1.3.4-1.fc22.x86_64
octave-specfun-1.1.0-9.fc22.x86_64
octave-control-2.6.6-1.fc22.x86_64
octave-3.8.2-18.fc22.x86_64
octave-signal-1.3.0-3.fc22.x86_64

How reproducible:

Steps to Reproduce:
1. Install octave and octave-specfun
2. start octave
3.

Actual results:

Expected results:

Additional info:

you find bug reports about that on various distributions e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741036
but i found none for fedora.

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=e294qxAgS7&a=cc_unsubscribe

Orion Poplawski | 30 Jul 00:52 2015

octave 4 copr

In case it's useful to anyone:

I've built octave 4 and a couple packages for Fedora 22+ and EPEL 6&7 here:

https://copr-fe.cloud.fedoraproject.org/coprs/orion/octave/

--

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion <at> nwra.com
Boulder, CO 80301                   http://www.nwra.com

John W. Eaton | 29 Jul 22:58 2015

question about defining some handy makefile targets

I often find myself wanting to know what the value of a variable is in 
Octave's Makefile.  Similarly, I sometimes want to clean up or build a 
set of targets that are listed in some variable.  I don't know of an 
easy way to do these things other than temporarily defining a custom 
target in a Makefile.  If there is some easy way, then let me know and 
we can probably forget what follows...  Otherwise, I'm thinking of 
defining some makefile targets so that you can (for example) clean or 
build or show variables like BUILT_DOC_IMAGES or DIRSTAMP_FILES.  One 
way to do that would be to add a series of explicit targets like

   show-BUILT_DOC_IMAGES:
      <at> echo $(BUILT_DOC_IMAGES)

   clean-BUILT_DOC_IMAGES:
     rm -f $(BUILT_DOC_IMAGES)

   build-BUILT_DOC_IMAGES: $(BUILT_DOC_IMAGES)

Or, perhaps the last two aren't strictly needed because it would be 
possible to do things like

   rm -f $(make show-BUILT_DOC_IMAGES)
   make $(make show-BUILT_DOC_IMAGES)

Though I also don't see the harm in defining the extra rules if it makes 
things slightly easier...

With the magic of GNU Make, however, we could define all of these from a 
list of variable names by doing something like

   TARGET_VARIABLES := BUILT_DOC_IMAGES DIRSTAMP_FILES

   define VARIABLE_RULES
   show-$(1):
      <at> echo $($(1))
   .phony: show-$(1)
   clean-$(1):
     rm -f $($(1))
   .phony: clean-$(1)
   build-$(1): $($(1))
   .phony: $(1)
   endef

   $(foreach VAR,$(TARGET_VARIABLES),$(eval $(call VARIABLE_RULES,$(VAR))))

and shell completion (at least in bash) still works for these targets, 
so typing

   make show-<TAB>

will display a list of all the show-VAR targets that are available.

One disadvantage that I see is that the TARGET_VARIABLES list must be 
maintained manually.  Another option would be to define rules like

   show-target-var:
      <at> echo $($(VAR))

   clean-target-var:
     rm -f $($(VAR))

   build-target-var: $($(VAR))

and then use commands like

   make show-target-var VAR=DIRSTAMP_FILES

then it would be possible to show, clean, or build any set of targets 
that are listed in a variable.

I suppose both forms could be defined and we could just maintain the 
TARGET_VARIABLES list for the most interesting sets of files and then 
the other rules would provide the same actions for more obscure 
variables like libinterp_octave_value_liboctave_value_la_DEPENDENCIES or 
whatever.

Would anyone else benefit from having rules like these defined?

jwe


Gmane