Carnë Draug | 7 Feb 04:42 2016
Gravatar

having trouble with XTRA_CFLAGS showing up on AM_CXXFLAGS

Hi

I've been playing around with our configure and I'm having a problem
that maybe someone can help me with.

I'm adding a flag to XTRA_CFLAGS in our configure script and it seems to
somehow be creeping into AM_CXXFLAGS.  The weird thing is that looking into
the generate Makefiled, it is not there.  However, when I run "make -n", I
see it showing up in AM_CXXFLAGS.

Here's what I've been doing.  I've been adding the following lines to
configure.ac:

    XTRA_CFLAGS="$XTRA_CFLAGS -std=c11"
    XTRA_CXXFLAGS="$XTRA_CXXFLAGS -std=c++11"
    CFLAGS="$CFLAGS -std=c11"
    CXXFLAGS="$CXXFLAGS -std=c++11"

After running configure, everything looks fine, the displayed resume
looks correct.  However, once the build actually starts I get warnings
like:

      GEN      libinterp/octave-value/ov-flt-re-mat.df
    cc1plus: warning: command line option ‘-std=c11’ is valid for
C/ObjC but not for C++

And indeed, running "make -n", I get g++ being called with -std=c11.  For
example, the recipe for octave-value/ov-flt-re-mat.df

    g++ -E -DHAVE_CONFIG_H -I. -I/home/carandraug/dev/octave  \
(Continue reading)

Carnë Draug | 7 Feb 01:51 2016
Gravatar

package licenses - use of SPDX identifiers

Hi everyone

A couple of years ago, downstream packagers complained that Octave Forge
packages were not consistent on naming the license on the DESCRIPTION
file which made it harder for them to automate license checks and packaging.

Because of that, Octave Forge packages use all the same identifiers for the
licenses but it was something made up by us at the time.  Turns out that
there are standard identifiers for the licenses which we should be using
instead [1].

This was brought up recently by Colin Macdonald [2] who's been doing some
work on making Octave Forge appear nicely in package managers [3].

So unless someone opposes it, I propose that future packages make use of
those identifiers.

Carnë

[1] https://spdx.org/licenses/
[2] https://lists.gnu.org/archive/html/octave-maintainers/2016-01/msg00133.html
[3] https://lists.gnu.org/archive/html/octave-maintainers/2016-01/msg00114.html

Ben Abbott | 7 Feb 00:02 2016
Picon
Gravatar

no longer able to build default on MacOS X

My tip is 

$ hg tip
changeset:   21201:88b41a4711e2
bookmark:     <at> 
tag:         tip
user:        Rik <rik <at> octave.org>
date:        Fri Feb 05 17:58:24 2016 -0800
summary:     maint: Correct names used in #ifdefs to prevent re-loading .h files.

The error message is …

  CXX      liboctave/numeric/liboctave_numeric_libnumeric_la-sparse-qr.lo
In file included from liboctave/numeric/sparse-qr.cc:30:
In file included from ./liboctave/util/oct-sparse.h:77:
/sw/include/suitesparse/cs.h:422:14: warning: 'cs_ci_house' has C-linkage specified, but returns
user-defined type 'cs_complex_t' (aka 'complex<double>') which is incompatible with C
      [-Wreturn-type-c-linkage]
cs_complex_t cs_ci_house (cs_complex_t *x, double *beta, int n) ;
             ^
/sw/include/suitesparse/cs.h:562:14: warning: 'cs_cl_house' has C-linkage specified, but returns
user-defined type 'cs_complex_t' (aka 'complex<double>') which is incompatible with C
      [-Wreturn-type-c-linkage]
cs_complex_t cs_cl_house (cs_complex_t *x, double *beta, cs_long_t n) ;
             ^
liboctave/numeric/sparse-qr.cc:2190:15: error: use 'template' keyword to treat 'tall_solve' as a
dependent template name
  return rep->tall_solve<RHS_T, RET_T> (b, info);
              ^
              template 
(Continue reading)

PhilipNienhuis | 4 Feb 19:34 2016
Picon

[MXE] "libinterp/co refcn/sighandlers.cc:392:35: error: 'strsignal' was not declared in this scope"

While crossbuilding Octave-4.1.0+ ( in MXE I get an error related to missing
strsignal().  From the log:

grep -i -R strsignal *

:
checking whether strsignal is declared without a macro... no
:
:
checking for strsignal... no
:
:
/home/philip/devel/octdev/mxe/mxe_w64_20151116/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/sighandlers.cc:
In function 'void generic_sig_handler(int)':
/home/philip/devel/octdev/mxe/mxe_w64_20151116/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/sighandlers.cc:392:35:
error: 'strsignal' was not declared in this scope
   my_friendly_exit (strsignal (sig), sig);
                                   ^
/home/philip/devel/octdev/mxe/mxe_w64_20151116/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/sighandlers.cc:
In function 'void sigint_handler(int)':
/home/philip/devel/octdev/mxe/mxe_w64_20151116/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/sighandlers.cc:537:52:
error: 'strsignal' was not declared in this scope
   w32_interrupt_manager::user_abort (strsignal (sig), sig);

On Linux (Magei-5 64-bit) Octave-4.1.0+ builds & works fine.

[philip <at> deskprn dev]$ hg  summary
parent: 21191:8e317ce26a24 tip
 unconditionally define warn_qrupdate_once

(Continue reading)

Rik | 4 Feb 00:22 2016

Re: indenting preprocessor conditionals

jwe,

I wholeheartedly agree.  It's confusing when everything is smashed up on
the left-hand margin.

I suppose I prefer 2 spaces for indentation since that's what we use
everywhere else.

--Rik

John W. Eaton | 3 Feb 21:15 2016

heads up: changes that require manual intervention

I made some changes to the way configuration info is handled.  After 
pulling from the mercurial archive you will need to delete the following 
files from your build tree:

   libinterp/oct-conf.h
   libinterp/oct-conf-features.h

jwe

John W. Eaton | 2 Feb 20:51 2016

indenting preprocessor conditionals?

Are there any preferences for indenting preprocessor conditionals?  If 
there are no objections, I'd like to start writing something like

#if defined (HAVE_SUITESPARSE_AMD_H)
# include <suitesparse/amd.h>
#elif defined (HAVE_UFSPARSE_AMD_H)
# include <ufsparse/amd.h>
#elif defined (HAVE_AMD_AMD_H)
# include <amd/amd.h>
#elif defined (HAVE_AMD_H)
# include <amd.h>
#endif

or

#if defined (HAVE_CXSPARSE)
# if defined (ENABLE_64)
#  define CXSPARSE_DNAME(name) cs_dl ## name
#  define CXSPARSE_ZNAME(name) cs_cl ## name
# else
#  define CXSPARSE_DNAME(name) cs_di ## name
#  define CXSPARSE_ZNAME(name) cs_ci ## name
# endif
#endif

instead of smashing everything over on the left margin.

Indentation increments of one space seem common for this kind of thing, 
but maybe we should go with two since that's generally the amount we use 
in other code in Octave.
(Continue reading)

Parsiad Azimzadeh | 2 Feb 20:15 2016
Picon
Gravatar

financial 0.5.0 released

Hi all,

I am happy to announce the release of financial 0.5.0 [1].

Perhaps the most exciting addition in this version is the Monte Carlo simulation framework (see, e.g., [3]), which is significantly faster than its MATLAB counterpart [4].

Other additions include Black-Scholes options and greeks valuation routines, implied volatility calculations, and general bug fixes.

[1] http://octave.sourceforge.net/financial/
[2] http://octave.sourceforge.net/financial/NEWS.html
[3] http://octave.sourceforge.net/financial/function/ <at> sde/simulate.html
[4] http://parsiad.ca/post/simulate-sdes-in-gnu-octave-financial-package/
--
Parsiad Azimzadeh [http://parsiad.ca]
PhD candidate

DC 3594 - University of Waterloo,
200 University Avenue West,
Waterloo, ON N2L 3G1
Rik | 2 Feb 19:21 2016

Re: GSOC 2016

On 02/02/2016 09:00 AM, octave-maintainers-request <at> gnu.org wrote:

​So the organization application deadline is Feb 19. Should we try again this year? If so, people should probably start updating the Wiki ideas page.
What page is this?  Is it the same as the Projects page?  http://wiki.octave.org/Projects

A quick look at the Projects page shows that some of them have been completed, and some like Agora probably never will be.

--Rik
Nir Krakauer | 2 Feb 09:36 2016

Re: GSOC 2016


​So the organization application deadline is Feb 19. Should we try again this year? If so, people should probably start updating the Wiki ideas page.
Fredy Hoyos | 31 Jan 23:09 2016
Picon

WAVELET TOOLBOX FOR OCTAVE

It is a pleasure for me to contact you.
I am a student of Electronic Engineering of the Universidad Del Quindío in
Colombia.
The fact is that I have been developing a "wavelet toolbox" for OCTAVE. And I
would like to integrate this toolbox to OCTAVE. Of course, with your consent.
My toolbox: works so good (you could prove it), is compatible with Matlab and
has a very good efficiency.
Any question, you could contact me, by email, or you can call me in Colombia
to the number 3122121513; but my english is not so good.
h
The Uniquindio Wavelet Toolbox is ready

I attach the toolbox to you, i hope you to do good use of my work



Gmane