octave-dev — GNU Octave developers' list

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[XXXXXXXXXXXXXXXXXXXXXXXXXXX]

Julien Salort wrote:
> That makes 3 packages for the same purpose. However, I don't know about
> yours, but mine uses National Instruments libraries for VISA and DAQmx,
> and free libraries for FireWire cameras and Modbus.
 >
 > I guess the NI part is not compatible with octave-forge policy of not
 > encouraging using proprietary software.

I wrote the toolbox for my work, where I use Windows and Linux. Since NI 
VISA is very complicated to install on Ubuntu - if even possible on 
actual 64bit installation - I had to find other ways. Besides that, I 
think linking to NI VISA would violate the GPL.

For linux you can talk to all instruments without using any proprietary 
software. For windows you still have a problem if you don't have serial 
or LAN based instruments or at least a VXI11-GPIB gateway.

Of course, the best way to communicate with instruments would be using 
the VISA interface, but you need a (working) free VISA library first.

Stefan

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[XXXXXXXXXXXXXXXXXXXXXXXXXXX]

Jordi Gutiérrez Hermoso wrote:
 >> Some years ago I already posted my toolbox for serial, tcp, gpib
 >> (and visa) to this list. Meanwhile I have added VXI11 and USBTMC.
 >> National Instruments GPIBENET-100 support is started, but even more
 >> incomplete than the rest of the toolbox. However, basic I/O is
 >> working and I'm able to talk with all of my instruments.
 >
 > It would be more useful if you could add your code to the existing
 > instrument-control package in OF and merge your instrument-control
 > with the one that Andrius Sutas wrote for SOCIS.
 >
 > Do you have the time and interest to do so?

c. wrote:
 > If you see room for improving either of the two packages maybe you'd
 > like to work on merging the two?

Merging to OC would probably mean a complete rewrite. At the moment I 
don't have enough time for this effort.

Stefan

Re: [OctDev] removing java package from SVN tree

[Martin H. <ma...@nu...>]

Am 23.11.2012 21:52, schrieb Carnë Draug:
> Hi everyone
>
> the java package as been moved to Octave core (see
> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610). I want to
> remove the package from the SVN tree to prevent accidental branching
> of its development.
>
> I will keep the tarball in the servers available for download and
> install, even after the release of whatever Octave version includes
> it.
>
> Carnë
>
Is it planned to integrate it at some point in a similar way as the java
support is integrated into Matlab?

[OctDev] removing java package from SVN tree

[Carnë D. <car...@gm...>]

Hi everyone

the java package as been moved to Octave core (see
http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610). I want to
remove the package from the SVN tree to prevent accidental branching
of its development.

I will keep the tarball in the servers available for download and
install, even after the release of whatever Octave version includes
it.

Carnë

Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Jordi G. H. <jo...@oc...>]

On 23 November 2012 15:40, Daniel J Sebald <dan...@ie...> wrote:
> Still "forge" I wonder about.  The term seems too broad and vague.

"Forge" is a pretty generic term for a code sharing site, although
SourceForge happens to be the most popular one. ForjaIris and GForge
come to mind as alternative examples.

- Jordi G. H.

Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Daniel J S. <dan...@ie...>]

On 11/23/2012 02:26 PM, Carnë Draug wrote:
> On 23 November 2012 19:46, Olaf Till<i7...@t-...>  wrote:
>> I'd call it pac...@oc..., so it is clearer what is meant.
>> Also, 'forge' relates to SourceForge, doesn't it? And who can be sure
>> that the package repository will stick to SourceForge forever.
>
> On 23 November 2012 20:00, Daniel J Sebald<dan...@ie...>  wrote:
>> Wasn't there some discussion about changing the name "forge" because of
>> confusion with SourceForge?
>>
>> What about Agora?  Should that have it's own mail list?
>
> Yes there was a discussion at OctConf and we agreed to keep the name
> Forge. Agora would have 3 sections, one of them named forge for Octave
> Forge. It's likely that Forge came from being hosted at Sourceforge,
> but if we move out we can still keep that part of the name.
>
> I don't think that packages is a name representative of what the
> mailing list is meant for. There are other packages not part of Octave
> Forge. And this will be specially true if Agora works and many people
> upload their own packages (who will not be part of Octave Forge). Such
> name would suggest that we are developing them and giving them
> support. We will not. For such cases, users should contact the Agora
> package author directly. That is also the reason why Agora should not
> have its own mailing list. If one compares Agora to FileExchange, it
> does not make sense to have everyone that ever submitted code to
> FileExchange on a mailing list in case a user has a question for one
> of them.

OK, makes sense.  May want to note that in the Agora documentation, that 
much of it is not community supported, but individually supported.


> On 23 November 2012 19:46, Olaf Till<i7...@t-...>  wrote:
>> On Fri, Nov 23, 2012 at 07:17:40PM +0100, Carnë Draug wrote:
>>> * some e-mails are sent for more than one mailing list. If the same
>>> mailman server is handling them, this should prevent people from
>>> receiving 2 e-mails with the same subject.
>>
>> Really? It does not seem to be so with octave-help and
>> octave-maintainers now.
>
> Oh! I thought mailman was smarter than that. It may be gmail that is
> fusing the 2 e-mails together, I assumed it was mailman doing.
>
> On 23 November 2012 20:00, Daniel J Sebald<dan...@ie...>  wrote:
>> How much activity does the help list get?
>
> In what units?

I just searched the archives--wow that list gets a lot of activity, 
hundreds of posts per month.  Can't really change that one.

Still "forge" I wonder about.  The term seems too broad and vague.

Dan

Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Carnë D. <car...@gm...>]

On 23 November 2012 19:46, Olaf Till <i7...@t-...> wrote:
> I'd call it pac...@oc..., so it is clearer what is meant.
> Also, 'forge' relates to SourceForge, doesn't it? And who can be sure
> that the package repository will stick to SourceForge forever.

On 23 November 2012 20:00, Daniel J Sebald <dan...@ie...> wrote:
> Wasn't there some discussion about changing the name "forge" because of
> confusion with SourceForge?
>
> What about Agora?  Should that have it's own mail list?

Yes there was a discussion at OctConf and we agreed to keep the name
Forge. Agora would have 3 sections, one of them named forge for Octave
Forge. It's likely that Forge came from being hosted at Sourceforge,
but if we move out we can still keep that part of the name.

I don't think that packages is a name representative of what the
mailing list is meant for. There are other packages not part of Octave
Forge. And this will be specially true if Agora works and many people
upload their own packages (who will not be part of Octave Forge). Such
name would suggest that we are developing them and giving them
support. We will not. For such cases, users should contact the Agora
package author directly. That is also the reason why Agora should not
have its own mailing list. If one compares Agora to FileExchange, it
does not make sense to have everyone that ever submitted code to
FileExchange on a mailing list in case a user has a question for one
of them.

On 23 November 2012 19:46, Olaf Till <i7...@t-...> wrote:
> On Fri, Nov 23, 2012 at 07:17:40PM +0100, Carnë Draug wrote:
>> * some e-mails are sent for more than one mailing list. If the same
>> mailman server is handling them, this should prevent people from
>> receiving 2 e-mails with the same subject.
>
> Really? It does not seem to be so with octave-help and
> octave-maintainers now.

Oh! I thought mailman was smarter than that. It may be gmail that is
fusing the 2 e-mails together, I assumed it was mailman doing.

On 23 November 2012 20:00, Daniel J Sebald <dan...@ie...> wrote:
> How much activity does the help list get?

In what units?

> What is it primarily for? For
> newer users needing help with language?  Help for compiling?  Just asking
> questions here as a means to review the current situation.

The help list is to obtain help with Octave, be it compiling,
vectorizing code, how to use a specific function, how to solve a
specific problem with Octave, and also for announcements such as new
Octave releases, new Forge package releases, people offering jobs to
Octave users, and anything else that is not related to the development
of Octave.

Carnë

Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Daniel J S. <dan...@ie...>]

On 11/23/2012 12:17 PM, Carnë Draug wrote:
> Hi everyone
>
> I'm proposing moving the current Octave Forge mailing list
> (oct...@li...) to the same server as as the ones
> from Octave core. My suggestion is to have the following octave
> related mailing lists:
>
> * mai...@oc... - same as now, discussion of development of Octave core
> * fo...@oc... - new mailing list for discussion of development of
> Octave Forge

Wasn't there some discussion about changing the name "forge" because of 
confusion with SourceForge?

What about Agora?  Should that have it's own mail list?


> * he...@oc... - mailing list for discussion of any help related to
> Octave (packages included)

How much activity does the help list get?  What is it primarily for? 
For newer users needing help with language?  Help for compiling?  Just 
asking questions here as a means to review the current situation.

Dan


>
> Note that I'm moving all help stuff to he...@oc..., so most of the
> Octave Forge threads would now be done in octave help. Their subjects
> overlap too much to make sense keep them separated (the only
> separation is whether one of the suggestion involves the use of an OF
> package). Things such as, "how can I use the butter function to design
> a low pass filter?" would now belong to help and not to the forge
> mailing list. The new forge mailing list would be for discussion of
> forge development issues (the core equivalent to maintainers).
>
> Another reason I propose this change is that octave-dev is misleading,
> specially for people submitting stuff from Nabble who see the
> following http://octave.1599824.n4.nabble.com/Octave-f1599824.subapps.html
> when starting a new thread. If we would make a change to fix this, it
> would force subscribers having to subscribe again and maybe change
> mail client settings. We might as well propose a better arrangement.
>
> Other reasons:
> * some e-mails are sent for more than one mailing list. If the same
> mailman server is handling them, this should prevent people from
> receiving 2 e-mails with the same subject.
> * at the bottom of each e-mail from the Octave Forge mailing list
> there's a add (some longer than others). This move would remove them
> since they are added by SourceForge and we have no control over it.
>
> How I propose to do the merging: if no one opposes to this, move all
> current subscribers of the Octave Forge mailing list, to both forge
> and help (this can be done automatically, subscribers should only
> receive an e-mail to confirm). Those who were on it for the help can
> unsubscribe from forge, and those who were on it for the development
> can unsubscribe from help. I'll send an e-mail to the mailing list
> when such change takes place with instructions on how to unsubscribe
> (and also suggest to instead change configuration to receive a daily
> digest of the other rather than unsubscribe because there's too many
> individual e-mails).
>
> Carnë

Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Olaf T. <i7...@t-...>]

On Fri, Nov 23, 2012 at 07:46:50PM +0100, Olaf Till wrote:
> ...
>
> And actually I would like to see what list a
> mail was meant for, even if there was more than one destination.

Sorry, this part was nonsense. Please Forget it. Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Olaf T. <i7...@t-...>]

Hi Carnë,

On Fri, Nov 23, 2012 at 07:17:40PM +0100, Carnë Draug wrote:
> Hi everyone
> 
> I'm proposing moving the current Octave Forge mailing list
> (oct...@li...) to the same server as as the ones
> from Octave core. My suggestion is to have the following octave
> related mailing lists:
> 
> * mai...@oc... - same as now, discussion of development of Octave core
> * fo...@oc... - new mailing list for discussion of development of
> Octave Forge
> * he...@oc... - mailing list for discussion of any help related to
> Octave (packages included)

I'd vote for pro.

But I'd call it pac...@oc..., so it is clearer what is meant.
Also, 'forge' relates to SourceForge, doesn't it? And who can be sure
that the package repository will stick to SourceForge forever.

> ...
>
> Other reasons:
> * some e-mails are sent for more than one mailing list. If the same
> mailman server is handling them, this should prevent people from
> receiving 2 e-mails with the same subject.

Really? It does not seem to be so with octave-help and
octave-maintainers now. And actually I would like to see what list a
mail was meant for, even if there was more than one destination.

But I really think duplicating mails should be avoided at all. One
reason for the suggested change could be to avoid duplicates. But it
does not seem to avoid duplicates between 'forge' and
octave-maintainers.

Regards,

Olaf

> ...

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

[OctDev] moving Octave Forge mailing list to core's mailman server

[Carnë D. <car...@gm...>]

Hi everyone

I'm proposing moving the current Octave Forge mailing list
(oct...@li...) to the same server as as the ones
from Octave core. My suggestion is to have the following octave
related mailing lists:

* mai...@oc... - same as now, discussion of development of Octave core
* fo...@oc... - new mailing list for discussion of development of
Octave Forge
* he...@oc... - mailing list for discussion of any help related to
Octave (packages included)

Note that I'm moving all help stuff to he...@oc..., so most of the
Octave Forge threads would now be done in octave help. Their subjects
overlap too much to make sense keep them separated (the only
separation is whether one of the suggestion involves the use of an OF
package). Things such as, "how can I use the butter function to design
a low pass filter?" would now belong to help and not to the forge
mailing list. The new forge mailing list would be for discussion of
forge development issues (the core equivalent to maintainers).

Another reason I propose this change is that octave-dev is misleading,
specially for people submitting stuff from Nabble who see the
following http://octave.1599824.n4.nabble.com/Octave-f1599824.subapps.html
when starting a new thread. If we would make a change to fix this, it
would force subscribers having to subscribe again and maybe change
mail client settings. We might as well propose a better arrangement.

Other reasons:
* some e-mails are sent for more than one mailing list. If the same
mailman server is handling them, this should prevent people from
receiving 2 e-mails with the same subject.
* at the bottom of each e-mail from the Octave Forge mailing list
there's a add (some longer than others). This move would remove them
since they are added by SourceForge and we have no control over it.

How I propose to do the merging: if no one opposes to this, move all
current subscribers of the Octave Forge mailing list, to both forge
and help (this can be done automatically, subscribers should only
receive an e-mail to confirm). Those who were on it for the help can
unsubscribe from forge, and those who were on it for the development
can unsubscribe from help. I'll send an e-mail to the mailing list
when such change takes place with instructions on how to unsubscribe
(and also suggest to instead change configuration to receive a daily
digest of the other rather than unsubscribe because there's too many
individual e-mails).

Carnë

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[c. <car...@gm...>]

On 23 Nov 2012, at 16:34, XXXXXXXXXXX wrote:

> Hi,
> 
> I just noticed that there were Summer of Code Project Ideas for low level I/O.
> 
> Some years ago I already posted my toolbox for serial, tcp, gpib (and visa) to this list. Meanwhile I have added VXI11 and USBTMC. National Instruments GPIBENET-100 support is started, but even more incomplete than the rest of the toolbox. However, basic I/O is working and I'm able to talk with all of my instruments.
> 
> I put the code to
> https://github.com/dac922/octave-instrument-control-toolbox
> 
> Hope someone find it useful.
> 
> Best regards,
> Stefan


Hi Stefan,

This is the package that Andrius Sutas wrote as a Summer of Code Project:

http://octave.sourceforge.net/instrument-control/index.html
http://sourceforge.net/p/octave/code/11449/tree/trunk/octave-forge/main/instrument-control

If you see room for improving either of the two packages maybe you'd like to work
on merging the two?

c.

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Jordi G. H. <jo...@oc...>]

On 23 November 2012 10:34, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:


> Some years ago I already posted my toolbox for serial, tcp, gpib
> (and visa) to this list. Meanwhile I have added VXI11 and USBTMC.
> National Instruments GPIBENET-100 support is started, but even more
> incomplete than the rest of the toolbox. However, basic I/O is
> working and I'm able to talk with all of my instruments.

It would be more useful if you could add your code to the existing
instrument-control package in OF and merge your instrument-control
with the one that Andrius Sutas wrote for SOCIS.

Do you have the time and interest to do so?

- Jordi G. H.

[OctDev] low level I/O (GPIB, USBTMC, VXI11)

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

Hi,

I just noticed that there were Summer of Code Project Ideas for low level I/O.

Some years ago I already posted my toolbox for serial, tcp, gpib (and visa) to this list. Meanwhile I have added VXI11 and USBTMC. National Instruments GPIBENET-100 support is started, but even more incomplete than the rest of the toolbox. However, basic I/O is working and I'm able to talk with all of my instruments.

I put the code to
https://github.com/dac922/octave-instrument-control-toolbox

Hope someone find it useful.

Best regards,
Stefan

Re: [OctDev] Octconf 2013

[Philip N. <pr....@hc...>]

c. wrote:
>
> On 22 Nov 2012, at 21:11, Júlio Hoffimann wrote:
>
>> Do you have a defined date?
>>
>> Regards,
>> Júlio.
>
> OctConf 2012 was July 16-20 I'd say around that time (2 weeks before or after at most) would be a
> good choice to not interfere with spring semester and summer holidays.

Expect most European summer holidays to peak around mid to late July & 
early to mid August.
Do you want OctConf inside or outside the holiday period? If outside, 
neither July nor August would be a good time.

P.

Re: [OctDev] Octconf 2013

[c. <car...@gm...>]

On 22 Nov 2012, at 21:11, Júlio Hoffimann wrote:

> Do you have a defined date?
> 
> Regards,
> Júlio.

OctConf 2012 was July 16-20 I'd say around that time (2 weeks before or after at most) would be a 
good choice to not interfere with spring semester and summer holidays.

c.

Re: [OctDev] Octconf 2013

[Júlio H. <jul...@gm...>]

Do you have a defined date?

Regards,
Júlio.


2012/11/22 JuanPi <aj...@gm...>

> Hello Space Coder!
>
> During OctConf 2012, we kind of agreed that we should do OctConf
> switch continent every year (so far America (south, central, north)
> and Eurasia). Next year should be the turn for Eurasia and in
> particular Europe.
>
> It would be nice to know who is able and is willing to help organizing
> the conference in their home country.
>
> We are hearing suggestions, accompanied with volunteers!
>
> The fact that the conference is in your local country doesn't mean you
> have to take care of all the organization, we can all help, but the
> local details (building, room , etc) will definitely be a
> responsibility of the local(s).
>
> So, lets the games begin!
>
> See You Space Coders ...
>
> Jpi, Kakila
>

[OctDev] Octconf 2013

[JuanPi <aj...@gm...>]

Hello Space Coder!

During OctConf 2012, we kind of agreed that we should do OctConf
switch continent every year (so far America (south, central, north)
and Eurasia). Next year should be the turn for Eurasia and in
particular Europe.

It would be nice to know who is able and is willing to help organizing
the conference in their home country.

We are hearing suggestions, accompanied with volunteers!

The fact that the conference is in your local country doesn't mean you
have to take care of all the organization, we can all help, but the
local details (building, room , etc) will definitely be a
responsibility of the local(s).

So, lets the games begin!

See You Space Coders ...

Jpi, Kakila

Re: [OctDev] bug in csape (part of package splines)

[Nir K. <nkr...@cc...>]

Thanks very much. I fixed this as you indicate in the SVN repository,
and added tests to check for it happening again.

Re: [OctDev] bug in csape (part of package splines)

[Ted R. <ted...@gm...>]

Nir,

Setup two one dimensional variables, y1 and y2 and a 2-D variable y  
with the same points. In this case a circle with the 5th point equal  
to the first. Run csape with the periodic condition and then inspect  
the structures produced. y should yield the same coefficients as y1  
and y2, just stacked into an array:

 >>> x = linspace(0, 2*pi, 5);
 >>> y1 = cos(x);
 >>> y2 = sin(x);
 >>> pp1 = csape(x, y1, 'periodic');
 >>> pp2 = csape(x, y2, 'periodic');
 >>> y = [y1; y2];
 >>> pp = csape(x, y, 'periodic');
 >>> pp1.P
ans =

    0.12901  -0.60793   0.00000   1.00000
    0.12901   0.00000  -0.95493   0.00000
   -0.12901   0.60793   0.00000  -1.00000
   -0.12901   0.00000   0.95493  -0.00000

 >>> pp2.P
ans =

   -0.12901  -0.00000   0.95493   0.00000
    0.12901  -0.60793   0.00000   1.00000
    0.12901  -0.00000  -0.95493   0.00000
   -0.12901   0.60793  -0.00000  -1.00000

 >>> pp.P
ans =

   -0.12901  -0.00000  -0.31831   1.00000
    0.12901  -0.60793  -0.00000   0.00000
    0.12901  -0.00000   0.31831  -1.00000
   -0.12901   0.60793   0.00000  -0.00000
    0.00000   0.00000   0.63662   0.00000
    0.00000   0.00000  -0.63662   1.00000
    0.00000   0.00000  -0.63662   0.00000
    0.00000   0.00000   0.63662  -1.00000

As you see they are quite different. This is from a saved session  
using spline 1.0.7, but I have had similar results with the latest  
splines 1.1.0. Actually, it looks like the only thing that has changed  
between 1.0.7 and 1.1.0 is the function mkpp now has different  
filednames. The latest edit noted in the comments of csape.m is Feb.  
19th 2001 in both versions.

All this is easy to see in a plot of the points overlaid with the  
splines too:

 >>> xpp = linspace(0, 2*pi, 201);
 >>> plot(y1, y2, 'ko', ppval(pp1, xpp), ppval(pp2, xpp), 'b-')
 >>> figure
 >>> yy = ppval(pp, xpp);
 >>> plot(y(1,:), y(2,:), 'ko', yy(1,:), yy(2,:), 'b-')

Now, after editing csape.m per my recommendation:

 >>> pp = csape(x, y, 'periodic');
 >>> pp.P
ans =

    0.12901  -0.60793   0.00000   1.00000
    0.12901   0.00000  -0.95493   0.00000
   -0.12901   0.60793   0.00000  -1.00000
   -0.12901   0.00000   0.95493  -0.00000
   -0.12901  -0.00000   0.95493   0.00000
    0.12901  -0.60793   0.00000   1.00000
    0.12901  -0.00000  -0.95493   0.00000
   -0.12901   0.60793  -0.00000  -1.00000

Just looking at idx in csape.m ( idx = ones (columns(a),1); ), you can  
see that using it in a matrix index on the left side of an equation  
makes no sense anyway.

Ted

On Nov 21, 2012, at 1:09 PM, Nir Krakauer wrote:

> Dear Ted,
>
> Can you give an example where it fails?
>
> Nir
>
> On Wed, Nov 21, 2012 at 3:25 AM, Ted Rippert <ted...@gm...>  
> wrote:
>> csape(x, y, "cond") with a boundary condition of "periodic" will work
>> for a one dimensional vector, but not for a matrix value for y. This
>> is fixed by changing line 162 in csape.m from:
>>
>>   c(2:n,idx) = z(:,2:end) - z(:,1) * fact;
>>
>> to:
>>
>>   c(2:n,:) = z(:,2:end) - z(:,1) * fact;

Re: [OctDev] bug in csape (part of package splines)

[Nir K. <nkr...@cc...>]

Dear Ted,

Can you give an example where it fails?

Nir

On Wed, Nov 21, 2012 at 3:25 AM, Ted Rippert <ted...@gm...> wrote:
> csape(x, y, "cond") with a boundary condition of "periodic" will work
> for a one dimensional vector, but not for a matrix value for y. This
> is fixed by changing line 162 in csape.m from:
>
>    c(2:n,idx) = z(:,2:end) - z(:,1) * fact;
>
> to:
>
>    c(2:n,:) = z(:,2:end) - z(:,1) * fact;

Re: [OctDev] complex error function

[Steven G. J. <st...@al...>]

On 11/20/12 5:54 PM, Michael D. Godfrey wrote:
> Also keep in mind that this will need to be compatible with
> the Matlab complex erf(z).

The Matlab erf function does not support complex arguments:

     http://www.mathworks.com/help/matlab/ref/erf.html

(There are several complex erf implementations in the Matlab Central 
repository.)

However, any erf(z) for complex arguments will be compatible with my 
implementation because the extension to the complex plane is unique. 
(erf is an analytic function in the entire complex plane.)

--SGJ

Re: [OctDev] [Pkg-octave-devel] Bug#693873: Bug#693873: octave-common: pkg ("list") not compatible with 'warning error Octave:str-to-num'

[Juan P. C. <car...@if...>]

On Wed, Nov 21, 2012 at 3:40 PM, Juan Pablo Carbajal
<car...@if...> wrote:
> On Wed, Nov 21, 2012 at 11:11 AM, Marc Cromme <ma...@an...> wrote:
>> Package: octave-common
>> Version: 3.6.2-5
>> Severity: normal
>> Tags: upstream
>>
>> Dear Maintainer,
>>
>> It appears that the installation of the packages
>>
>>   octave-java 1.2.8-6   amd64
>>   octave-io   1.0.19-1  amd64
>>
>> together with the promotion of warnings to errors
>>
>>   warning error Octave:str-to-num
>>
>> triggers the error, as installation of octave-java makes the read of the octave-io package file
>>
>> /usr/lib/x86_64-linux-gnu/octave/packages/io-1.0.19/x86_64-pc-linux-gnu-api-v48+/PKG_ADD
>>
>> mandatory, which in turn crashes with an error in the
>>
>> /usr/share/octave/3.6.2/m/pkg/pkg.m at line 274, column 3
>>
>> A short script triggering the undesired behaviour directly is this one:
>>
>> --- snip ---
>> #!/usr/bin/octave -q
>> warning error Octave:str-to-num
>> pkg ("list");
>> --- snip ---
>>
>> I did expect the code contained in the octave-common packages to support all kind of
>> promotion from warnings to errors, as this helps developing clean code.
>>
>> best regards, and thanks for packaging octave,
>>
>> Marc Cromme
>>
>>
>> -- System Information:
>> Debian Release: wheezy/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>>
>> -- no debconf information
>>
>> _______________________________________________
>> Pkg-octave-devel mailing list
>> Pkg...@li...
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel
>
> Forwarding to Octave-Forge development mailing list.
>
>
> --
> Dr. sc. nat. Juan Pablo Carbajal
> -----
> University of Zürich
> http://ailab.ifi.uzh.ch/carbajal/
>
> _______________________________________________
> Pkg-octave-devel mailing list
> Pkg...@li...
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel

Sorry, it is not package related.


-- 
Dr. sc. nat. Juan Pablo Carbajal
-----
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] [Pkg-octave-devel] Bug#693873: octave-common: pkg ("list") not compatible with 'warning error Octave:str-to-num'

[Juan P. C. <car...@if...>]

On Wed, Nov 21, 2012 at 11:11 AM, Marc Cromme <ma...@an...> wrote:
> Package: octave-common
> Version: 3.6.2-5
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
> It appears that the installation of the packages
>
>   octave-java 1.2.8-6   amd64
>   octave-io   1.0.19-1  amd64
>
> together with the promotion of warnings to errors
>
>   warning error Octave:str-to-num
>
> triggers the error, as installation of octave-java makes the read of the octave-io package file
>
> /usr/lib/x86_64-linux-gnu/octave/packages/io-1.0.19/x86_64-pc-linux-gnu-api-v48+/PKG_ADD
>
> mandatory, which in turn crashes with an error in the
>
> /usr/share/octave/3.6.2/m/pkg/pkg.m at line 274, column 3
>
> A short script triggering the undesired behaviour directly is this one:
>
> --- snip ---
> #!/usr/bin/octave -q
> warning error Octave:str-to-num
> pkg ("list");
> --- snip ---
>
> I did expect the code contained in the octave-common packages to support all kind of
> promotion from warnings to errors, as this helps developing clean code.
>
> best regards, and thanks for packaging octave,
>
> Marc Cromme
>
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> -- no debconf information
>
> _______________________________________________
> Pkg-octave-devel mailing list
> Pkg...@li...
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel

Forwarding to Octave-Forge development mailing list.


-- 
Dr. sc. nat. Juan Pablo Carbajal
-----
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] segfault reading netcdf file

[Muhali <mu...@us...>]

Muhali wrote
> With the current octave tip and the most recent octcdf package the
> following program generates a segfault. My system is Ubuntu 12.04 x86_64.
> debug output is attached.

Solved. No segfault with the newest libnetcdf (4.2.1.1).



--
View this message in context: http://octave.1599824.n4.nabble.com/segfault-reading-netcdf-file-tp4646843p4646844.html
Sent from the Octave - Dev mailing list archive at Nabble.com.