octave-dev — GNU Octave developers' list

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

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

On 25 November 2012 19:58, Daniel J Sebald <dan...@ie...> wrote:
> On 11/25/2012 11:47 AM, Carnė Draug wrote:
>>
>> On 23 November 2012 19:17, Carnė Draug<car...@gm...>  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 spoke with JWE about this and he suggested to keep only the
>> maintainers and help mailing lists, moving the development discussions
>> of Octave Forge to the Octave core maintainers mailing list. That
>> should avoid any confusion new users may have.
>>
>> I do not oppose to it, after all there's not that many Octave Forge
>> only development threads.
>
>
> Traffic fluctuates.  Sometimes one is more active than the other. Before
> combining these two, how about considering some alternate names?  I get both
> mailing lists at the moment.  I do like the separation for the reason you
> explained very well a month or two ago, i.e., folks tend to gravitate toward
> one list because it is too much to pay attention to everything.
>
> To me, "forge" is simply too generic.  That the term "forge" may be common
> for other projects doesn't change that fact.  We feel these two are good:

Forge is not too generic since the project name is Octave Forge.
Therefore, no doubt should come out of an address such as
fo...@oc....

> As the third category, how about:
>
> pac...@oc...
> app...@oc...
> adv...@oc...
>
> [snip]
>
> applications: For advanced features such as packages and interface to other
> software.

You seem to be confused about what Octave Forge is. We are not the go
to place for all applications, packages and advanced Octave stuff.
There's plenty of applications and packages for Octave that are not
part of Forge. Calling it advanced is insulting to core as if one
could not do advanced stuff with core only.

> Now, if we want to combine bug reports for applications and maintainers in
> the same tracker,

Tracker? We are only talking about mailing list. Bug reports are to be
discussed on the bug trackers so they should never appear on the
mailing list. I'll make sure to direct any discussion of Octave Forge
bugs to the Octave Forge bug tracker.

That said, the only type of threads from the current Octave Forge
mailing list that would now appear in maintainers would be license
stuff, adding of new packages, google summer of code, etc... As an
example, for the month of November, these are the threads:

- these ones were in both maintainers and forge mailing list and don't
really count (this seems to becoming more common over time) :

* this very own thread
* http://octave.1599824.n4.nabble.com/Octconf-2013-td4646964.html -
discussion of OctConf2013
* http://octave.1599824.n4.nabble.com/low-level-I-O-GPIB-USBTMC-VXI11-td4646993.html
- about various instrument control packages that are not part of
OctaveForge and whether they could be merged (descended into
discussion of legal stuff and was eventually moved to the maintainers
mailing list)
* http://octave.1599824.n4.nabble.com/complex-error-function-td4645714.html
- someone shared code for Octave and it was discussed where it should
go

- http://octave.1599824.n4.nabble.com/removing-java-package-from-SVN-tree-td4647021.html
- this ones was about the removal of the java package from Octave
Forge since it was moved to Octave core. It was not mentioned in the
maintainers mailing list but I wouldn't not have been out of place
together with an announcement of its move

- the following 4 e-mails were all on the same subject. We decide to
restrict the licenses in forge and sent a couple of e-mails to the
copyright owners asking to relicense their code

* http://octave.1599824.n4.nabble.com/removal-of-non-standard-licenses-in-Octave-Forge-td4645841.html
* http://octave.1599824.n4.nabble.com/Re-License-Andy-Adler-s-code-in-Octave-Forge-td4646143.html
* http://octave.1599824.n4.nabble.com/License-of-medfilt1-in-Octave-Forge-td4646144.html
* http://octave.1599824.n4.nabble.com/FreeBSD-vs-simplified-BSD-td4645843.html

Carnë

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

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

On 11/25/2012 11:47 AM, Carnë Draug wrote:
> On 23 November 2012 19:17, Carnë Draug<car...@gm...>  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 spoke with JWE about this and he suggested to keep only the
> maintainers and help mailing lists, moving the development discussions
> of Octave Forge to the Octave core maintainers mailing list. That
> should avoid any confusion new users may have.
>
> I do not oppose to it, after all there's not that many Octave Forge
> only development threads.

Traffic fluctuates.  Sometimes one is more active than the other. 
Before combining these two, how about considering some alternate names? 
  I get both mailing lists at the moment.  I do like the separation for 
the reason you explained very well a month or two ago, i.e., folks tend 
to gravitate toward one list because it is too much to pay attention to 
everything.

To me, "forge" is simply too generic.  That the term "forge" may be 
common for other projects doesn't change that fact.  We feel these two 
are good:

mai...@oc...
he...@oc...

As the third category, how about:

pac...@oc...
app...@oc...
adv...@oc...

Any confusion could be cleared up as part of the Octave.org web page. 
Although the web page does explain matters well in terms of expected 
help, it doesn't present mailing list info in a succinct and clear way. 
  If instead the "Mailing Lists" info were organized either graphically 
or in table format:

he...@oc...     app...@oc...     mai...@oc...

     blurb                    blurb                       blurb

where the blurbs might be something like

help: For introductory and operational details slightly beyond program 
syntax.

applications: For advanced features such as packages and interface to 
other software.

maintainers: For programming specifics related to the core C++ code.

Now, if we want to combine bug reports for applications and maintainers 
in the same tracker, that's fine, but have a drop-down category that 
makes the distinction.  Also, for the HTML shortcut for 
"he...@oc..." we could replace launching an email to a link of the 
explanation about expected help, i.e., a short little detour to help 
weed out beginners asking rudimentary syntax questions.  Put the email 
launch shortcut there.

Dan

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

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

On 25 November 2012 06:15, Julien Salort <li...@ju...> wrote:
> Jordi Gutiérrez Hermoso
> <jo...@oc...> writes:
>
>> I've never been clear if this is really ok, but it seems to be a
>> common interpretation.
>
> Fine.
> But then, why did you encourage me publicly, on Feb. 8th, to publish the
> sources ?
> In case you don't remember, here is a link to the thread, entitled "Data
> Acquisition with Octave":
> http://thread.gmane.org/gmane.comp.gnu.octave.devel/6512/focus=39562
>
> Personally, I was very reluctant to publish the sources because I feared
> there would be a legal issue. You are one of the people who convinced me
> that it is ok and that I should publish the source anyway.

I'm sorry. I made a mistake. I misunderstood the GPL. I got
uncomfortable with now how there is Octave code that is meant to be
linked to non-free libraries, so I asked again, and it seems I was
wrong about it.

Please unpublish this code. We do not want GPL-infringing Octave code
out there. Instead, pressure the hardware providers to give you free
libraries to the hardware that you already bought and thus you should
own and do whatever you please with, including modfiying the libraries
that talk to it.

- Jordi G. H.

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

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

On 23 November 2012 19:17, Carnë Draug <car...@gm...> 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 spoke with JWE about this and he suggested to keep only the
maintainers and help mailing lists, moving the development discussions
of Octave Forge to the Octave core maintainers mailing list. That
should avoid any confusion new users may have.

I do not oppose to it, after all there's not that many Octave Forge
only development threads.

Carnë

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

[Richard <r.c...@ed...>]

On 25/11/2012 15:51, c. wrote:
> On 25 Nov 2012, at 16:43, Richard wrote:
>
>> Really? so i can have a C++ class, and call it and its methods from an m-file in Octave, and have it persist like a real C++ object from one call of its methods to the next?
> Actually I was referring to using the class from an .oct file not from an .m file ...
> anyway yes you can construct a new class in c++ and have it accessible in the interpreter
> an be persistent between calls.
> In order to do this your class must inherit from the octave_base_value class.
>
>> This is not possible with plain mex files in Matlab because you must create an instance of a C++ class which will be destroyed once the mex file completes (which is the problem that using handle classes in the linked example solves). As I understood it Octave has the same limitation, but since it does not yet have classdef, there is no way to do the same thing. I'd be very interested hear if there was though, or that I have misunderstood something about oct files.
> The instrument control package is a working example of how this can be done,
> for a much simpler example you can have a look at these files:
>
>    http://inversethought.com/hg/what-is-octave/file/f8c352d9af2d/PoliMI2012/examples/myobject.h
>    http://inversethought.com/hg/what-is-octave/file/f8c352d9af2d/PoliMI2012/examples/myobject.cc
>
> which are examples taken from this presentation
>
>    http://jordi.platinum.linux.pl/octave/what-is-octave.pdf
>
>> Richard
> c.

Thanks, maybe I will copy some of this info to the wiki.
Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

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

On 25 Nov 2012, at 16:43, Richard wrote:

> Really? so i can have a C++ class, and call it and its methods from an m-file in Octave, and have it persist like a real C++ object from one call of its methods to the next?

Actually I was referring to using the class from an .oct file not from an .m file ...
anyway yes you can construct a new class in c++ and have it accessible in the interpreter
an be persistent between calls. 
In order to do this your class must inherit from the octave_base_value class.

> This is not possible with plain mex files in Matlab because you must create an instance of a C++ class which will be destroyed once the mex file completes (which is the problem that using handle classes in the linked example solves). As I understood it Octave has the same limitation, but since it does not yet have classdef, there is no way to do the same thing. I'd be very interested hear if there was though, or that I have misunderstood something about oct files.

The instrument control package is a working example of how this can be done, 
for a much simpler example you can have a look at these files:

  http://inversethought.com/hg/what-is-octave/file/f8c352d9af2d/PoliMI2012/examples/myobject.h
  http://inversethought.com/hg/what-is-octave/file/f8c352d9af2d/PoliMI2012/examples/myobject.cc

which are examples taken from this presentation

  http://jordi.platinum.linux.pl/octave/what-is-octave.pdf

> Richard
c.

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

[Richard <r.c...@ed...>]

On 25/11/2012 15:29, c. wrote:
> On 25 Nov 2012, at 12:49, Richard wrote:
>
>> I suspect he wants to do something like this:
>>
>> http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
>> http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243
>>
>> Richard
> There is nothing special to be done to link C++ with Octave,
> Octave itself is written in C++ so classes have no need to be "encapsulated"
> in an oct file you can just use them as in any other C++ program.
>
> c.
>
>

Really? so i can have a C++ class, and call it and its methods from an 
m-file in Octave, and have it persist like a real C++ object from one 
call of its methods to the next?

This is not possible with plain mex files in Matlab because you must 
create an instance of a C++ class which will be destroyed once the mex 
file completes (which is the problem that using handle classes in the 
linked example solves). As I understood it Octave has the same 
limitation, but since it does not yet have classdef, there is no way to 
do the same thing. I'd be very interested hear if there was though, or 
that I have misunderstood something about oct files.

Richard



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

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

On 25 Nov 2012, at 12:49, Richard wrote:

> I suspect he wants to do something like this:
> 
> http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243
> 
> Richard

There is nothing special to be done to link C++ with Octave, 
Octave itself is written in C++ so classes have no need to be "encapsulated"
in an oct file you can just use them as in any other C++ program.

c.

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

[Julien S. <li...@ju...>]

Le 25 nov. 2012 à 05:46, Richard Stallman <rm...@gn...> a écrit :

>> It is my understanding you can link with whatever you want for your personal usage.
>> However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
>> That is why I don't distribute binaries, only source code.
> 
> The user, on his own initiative, is free to link GPL-covered code with
> nonfree code and use that privately.  However, to modify a GPL-covered
> program so that it is meant to link to some non-free code, and
> distribute that, is not a private action.  It is a way of combining
> the program with nonfree code.  That violates the GPL.

I didn't modify any existing GPL sources, specifically I didn't modify Octave sources. Octave already had the ability to run compiled functions linked to whatever library you wish. Those compiled functions behave a bit like plug-ins, by the way.

What I did, is create wrappers that allows calling some of the 488.2, VISA and DAQmx functions.

Those are very simple: the oct file just #include <visa.h> and calls one VISA function, eg. viOpen for example.
There is nothing that prevents someone from linking this wrapper to OpenVISA instead of NI VISA.
The same is true for 488.2. The oct files are wrapper that #include <ni488.h> and call, eg. ibdev. The free libgpib library defines the same function. So someone can link the wrappers against libgpib or NI 488.2.

It happens that I personally only tested with NI VISA, NI 488-2 and NI DAQmx because this allows me to get support from NI if there is a problem, and their libraries are compatible with all the acquisition cards they sell. Those libraries are free like in free beer but closed source and they require to agree to a restrictive license. I don't particularly like this but I don't really have a choice (my first requirement is to be able to acquire data). I filed a complaint requesting that they open their source already.

The files I distribute are:
- CPP source files of the wrappers;
- Octave script files that implement high-level functions that rely on these wrappers.

All the files that I distribute are distributed under the GPL license.

If someone wishes to test them with alternative free library and modify the configure.ac to ease the linking with those, I will be very happy. If someone has the knowledge to implement a free alternative to NI-DAQmx does so, I will be very happy. Installing these NI libraries under linux is a pain because they cannot be packaged easily, they have their own installers that don't work with all linux distributions, they don't support the way the latest Linux kernels handle USB, etc.
Whenever a full-featured alternative free library is available, I'll switch to it enthusiastically. My code is written in such a way that I think it should be easy to link against some other library: only the wrappers might have to be modified (presumably) and their number is limited.

Now. I'm free to do what I want for my personal usage. I feel it is nice to distribute these files, in case someone else is interested. But it wouldn't make much difference to me if I don't distribute them. So, if distributing source files (without even the implied warranty that it fits a particular purpose) violates the GPL, I will just stop distributing them.

Please tell me if you feel this is the case.

Julien

[OctDev] geometry: wrong computation of axes in cov2ellipse

[Rafael L. <ra...@la...>]

The function cov2ellipse in the geometry package is not computing the 
ellipse axes correctly.  The first problem is that the scale of the 
axes is wrong.  This can be demonstrated with the code below

   ######################################################################
   function cov2ellipse_demo (K)
       L = chol(K,'lower');
       u = randn(1e3,2)*L';
       elli = cov2ellipse (K);
       figure(1)
       plot(u(:,1),u(:,2),'.r');
       hold on;
       drawEllipse(elli,'linewidth',2);
       hold off;
       axis tight;
   endfunction
   cov2ellipse_demo (K); ## This is what we get with "demo cov2ellipse"
   cov2ellipse_demo (10*K);
   cov2ellipse_demo (0.1*K);
   ######################################################################

This is fixed by taking the square root of the eigenvalues obtained by 
svd().

The second problem is that the axis orientation is wrong, evidenced in 
the code below:

   ######################################################################
   K = [2 -1; -1 2];
   cov2ellipse_demo (K)
   ######################################################################

This happens because the wrong elements of the eigenvectors are taken.

The patch attached below fixes both problems.

Rafael

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

[Juan P. C. <aju...@gm...>]

>     Richard, can you comment on this? A number of Octave users create oct
>     files to talk to non-free libraries for external hardware. An oct file
>     is basically a C++ program that uses Octave's headers and links to
>     Octave. It is my understanding that these oct files are also linking
>     to non-free libraries. I am uncomfortable that people do this and
>     distribute the results. What do you think?
>
> That could be a GPL violation.  We need to look at the specific
> details.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call
>
> _______________________________________________
> Help-octave mailing list
> Hel...@oc...
> https://mailman.cae.wisc.edu/listinfo/help-octave

Richard,

This is an example of the code in the package in question.
https://github.com/jsalort/OctMI/blob/master/Low-level/GPIB/src/ibdev.cpp
(Julien correct me if I am wrong)

It includes octave/oct.h and ni488.h.
It uses a macro defined in octave/oct.h, some functions and several
datatypes. finally it uses a function from the ni488.h

to me it looks like a wrapper to a library function. Is this a GPL violation?

What about if one would add compiler directives in the header

#ifndef FREE_BEER
#include <free_gpib.h>
#else
#include <ni488.h>
#endif

and in the body of the function

#ifndef FREE_BEER
ud = free_ibdev(BdIndx,pad,sad,tmp,eot,eos);
#else
ud = ibdev(BdIndx,pad,sad,tmp,eot,eos);
#endif

Would this be a violation? clearly the user is not being forced to
link to the non-free library, just he "can".

Thanks

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

[Richard <r.c...@ed...>]

On 25/11/2012 11:25, c. wrote:
> On 25 Nov 2012, at 10:21, XXXXXXXXXXX wrote:
>
>> The instrument control package at octave forge creates a class as kind of file descriptor. While there are methods to access read, write, etc. from C++ / oct-File, there are no methods when using from octave.
>>
>> I know that classdef for .m file is not ready yet. Is it the same for .oct files?
> I am not completely sure what you mean, is it something related to these threads?
>
>      https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054970.html
>      https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030767.html
>      https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030775.html
>      https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html
>      
> could you please explain a bit better?
>
>> Stefan
> c.

I suspect he wants to do something like this:

http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243

Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

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

On 25 Nov 2012, at 10:21, XXXXXXXXXXX wrote:

> The instrument control package at octave forge creates a class as kind of file descriptor. While there are methods to access read, write, etc. from C++ / oct-File, there are no methods when using from octave.
> 
> I know that classdef for .m file is not ready yet. Is it the same for .oct files?

I am not completely sure what you mean, is it something related to these threads?

    https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054970.html
    https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030767.html
    https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030775.html
    https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html
    
could you please explain a bit better?

> Stefan
c.

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

[Julien S. <li...@ju...>]

Jordi Gutiérrez Hermoso
<jo...@oc...> writes:

> I've never been clear if this is really ok, but it seems to be a
> common interpretation.

Fine.
But then, why did you encourage me publicly, on Feb. 8th, to publish the
sources ?
In case you don't remember, here is a link to the thread, entitled "Data
Acquisition with Octave":
http://thread.gmane.org/gmane.comp.gnu.octave.devel/6512/focus=39562

Personally, I was very reluctant to publish the sources because I feared
there would be a legal issue. You are one of the people who convinced me
that it is ok and that I should publish the source anyway.

Specifically, you wrote:

> There is no legal problem sharing your source code, as long as you
> don't distribute binaries compiled to the non-free driver. The only
> social problem would be encouraging more people to use the non-free
> drivers instead of demanding a free driver from NI, but it looks like
> your code is encouraging people to look into the possibility of free
> drivers, so it's probably beneficial if you share it.

So now, I don't understand your strong reaction.

Julien

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

[XXXXXXXXXXXXXXXXXXXXXXXXXXX]

The instrument control package at octave forge creates a class as kind 
of file descriptor. While there are methods to access read, write, etc. 
from C++ / oct-File, there are no methods when using from octave.

I know that classdef for .m file is not ready yet. Is it the same for 
.oct files?


Stefan

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

[Sergei S. <ser...@ya...>]

----- Original Message -----
> From: Richard Stallman <rm...@gn...>
> To: Jordi Gutiérrez Hermoso <jo...@oc...>
> Cc: oct...@li...; he...@oc...; li...@ju...
> Sent: Sunday, November 25, 2012 6:46 AM
> Subject: Re: low level I/O (GPIB, USBTMC, VXI11)
[snip]
> The user, on his own initiative, is free to link GPL-covered code with
> nonfree code and use that privately.  However, to modify a GPL-covered
> program so that it is meant to link to some non-free code, and
> distribute that, is not a private action.  It is a way of combining
> the program with nonfree code.  That violates the GPL.
[snip]
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call
> 
> _______________________________________________
> Help-octave mailing list
> Hel...@oc...
> https://mailman.cae.wisc.edu/listinfo/help-octave
> 

No, "It is a way of combining the program with nonfree code.  That violates the GPL", it does _not_violate GPL.

One of the greatest GPL features is that it does _not_ require the distributed code to work.

So, the modified GPL code is to be distributed with free in FOSS sense _non_-working code which quite incidentally happens to have the same interface as the non-free code the GPL program is supposed to work with.

And then on site the GPL program is easily (re)linked with proprietary code using all kinds of tools/approaches, the easiest of the being LD_PRELOAD trick (e.g. http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick ).

Regards,
  Sergei.

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

[Richard S. <rm...@gn...>]

    > It is my understanding you can link with whatever you want for your personal usage.
    > However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
    > That is why I don't distribute binaries, only source code.

The user, on his own initiative, is free to link GPL-covered code with
nonfree code and use that privately.  However, to modify a GPL-covered
program so that it is meant to link to some non-free code, and
distribute that, is not a private action.  It is a way of combining
the program with nonfree code.  That violates the GPL.

    I've never been clear if this is really ok, but it seems to be a
    common interpretation. It seems to be, for example, how nvidia gets
    around Linux's copyleft and the nvidia blob.

nVidia's nonfree driver violates the GPL, but the Linux developers
choose not to object.  We can't force them to enforce their license.

As for the firmware blobs, there is an argument that firmware programs
are separate programs merely packaged together with Linux, and thus
not violations of the GPL.  However, the issue is moot since the
copyright holders of Linux choose not to enforce the GPL anyway.

    Richard, can you comment on this? A number of Octave users create oct
    files to talk to non-free libraries for external hardware. An oct file
    is basically a C++ program that uses Octave's headers and links to
    Octave. It is my understanding that these oct files are also linking
    to non-free libraries. I am uncomfortable that people do this and
    distribute the results. What do you think?

That could be a GPL violation.  We need to look at the specific
details.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

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

On 24 November 2012 03:33, Julien Salort <li...@ju...> wrote:
> It is my understanding you can link with whatever you want for your personal usage.
> However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
> That is why I don't distribute binaries, only source code.

I've never been clear if this is really ok, but it seems to be a
common interpretation. It seems to be, for example, how nvidia gets
around Linux's copyleft and the nvidia blob.

Richard, can you comment on this? A number of Octave users create oct
files to talk to non-free libraries for external hardware. An oct file
is basically a C++ program that uses Octave's headers and links to
Octave. It is my understanding that these oct files are also linking
to non-free libraries. I am uncomfortable that people do this and
distribute the results. What do you think?

- Jordi G. H.

Re: [OctDev] removing java package from SVN tree

[Alexander H. <ale...@gm...>]

On 11/24/12 2:11 PM, Michael Goffioul wrote:
> On Sat, Nov 24, 2012 at 1:50 PM, Alexander Hansen
> <ale...@gm... <mailto:ale...@gm...>> wrote:
> 
>     I'm curious whether anybody has tried Octave-Java on Mac OS X using an
>     Oracle JDK/JRE rather than what Apple provides to see if it also
>     produces the runtime threading error indicated by
>     http://lists.apple.com/archives/java-dev/2005/Mar/msg00506.html.
> 
>     Right now that renders the Octave-Java package essentially nonfunctional
>     on OS X when using Apple's Java.
> 
> 
> Only the GUI aspects of Java are unusable. But there's much more than
> that in Java.
> 
> Michael.
> 

The last time I tried I couldn't get the spreadsheet import tools to
work, either.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

Re: [OctDev] removing java package from SVN tree

[Michael G. <mic...@gm...>]

On Sat, Nov 24, 2012 at 1:50 PM, Alexander Hansen <
ale...@gm...> wrote:

> I'm curious whether anybody has tried Octave-Java on Mac OS X using an
> Oracle JDK/JRE rather than what Apple provides to see if it also
> produces the runtime threading error indicated by
> http://lists.apple.com/archives/java-dev/2005/Mar/msg00506.html.
>
> Right now that renders the Octave-Java package essentially nonfunctional
> on OS X when using Apple's Java.
>

Only the GUI aspects of Java are unusable. But there's much more than that
in Java.

Michael.

Re: [OctDev] removing java package from SVN tree

[Alexander H. <ale...@gm...>]

On 11/24/12 10:38 AM, Philip Nienhuis wrote:
> Martin Helm wrote:
>> Am 23.11.2012 21:52, schrieb Carnë Draug:
>>> Hi everyone
>>>
>>> the java package as been moved to Octave core (see
> 
> Hmm.... surprise.
> 
>>> 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?
> 
> Apparently, exactly that has been done; Octave-Java-package's 
> idiosyncrasies permitting.
> 
> That is, Matlab ships with a JRE so that Java is always guaranteed to 
> work with ML. (The ML GUI was (still is?) Java-based so I can understand 
> why TMW needed to do that.)
> 
> AFAICS Octave is dependent on an independently installed JDK. Moreover, 
> once Octave has been built from source w/o JDK, adding in a JRE or JDK 
> later on and then expecting Java to work automagically from Octave may 
> be a tad optimistic.
> Of course, for users invoking a binary distribution package this 
> shouldn't be a problem.
> 
> Philip
> 

I'm curious whether anybody has tried Octave-Java on Mac OS X using an
Oracle JDK/JRE rather than what Apple provides to see if it also
produces the runtime threading error indicated by
http://lists.apple.com/archives/java-dev/2005/Mar/msg00506.html.

Right now that renders the Octave-Java package essentially nonfunctional
on OS X when using Apple's Java.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

Re: [OctDev] removing java package from SVN tree

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

Martin Helm wrote:
> Am 23.11.2012 21:52, schrieb Carnë Draug:
>> Hi everyone
>>
>> the java package as been moved to Octave core (see

Hmm.... surprise.

>> 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?

Apparently, exactly that has been done; Octave-Java-package's 
idiosyncrasies permitting.

That is, Matlab ships with a JRE so that Java is always guaranteed to 
work with ML. (The ML GUI was (still is?) Java-based so I can understand 
why TMW needed to do that.)

AFAICS Octave is dependent on an independently installed JDK. Moreover, 
once Octave has been built from source w/o JDK, adding in a JRE or JDK 
later on and then expecting Java to work automagically from Octave may 
be a tad optimistic.
Of course, for users invoking a binary distribution package this 
shouldn't be a problem.

Philip

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

[Julien S. <li...@ju...>]

Le 23 nov. 2012 à 23:18, XXXXXXXXXXXXXXXXXXXXXXXXXXX a écrit :

> 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.

It is my understanding you can link with whatever you want for your personal usage.
However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
That is why I don't distribute binaries, only source code.

Besides, my code should compile with libgpib and openvisa, even though I haven't tested. The source code in itself does not forbid anything.

Personnally, I haven't been able to install NI VISA on Ubuntu reliably. That is why I use Scientific Linux, which is an officially supported distribution. It is much easier to install National Instruments drivers of Scientific Linux (it installs right out of the box). Of course, it would be easier if their drivers were free. I filed a complaint already. You may complain too. Maybe if many people complain, they might change their way ?

> 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.

I have a very heterogeneous environment for my experimental setups (Windows XP, Macintosh and Linux). The nice thing with NI drivers is that the same code works on those three platforms out of the box, and it allows to communicate with a very wide range of devices. Considering how expensive a PXI is (for example), I definitely need a driver that allows me to use all its functions... My colleagues wouldn't understand if I use a driver that wouldn't allow me to use all its capabilities.

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

I agree a free VISA (and DAQmx) would be much nicer. I personally don't have the time nor the knowledge to work on that.

In a mean time, I need to work, and the NI VISA (and DAQmx) library does work on many platforms, and can be freely downloaded. I regret that it is not free and that you have to agree to their restrictive license terms.

[OctDev] (no subject)

[Ole J. H. <wat...@ya...>]

http://artoffthemain.com/wp-content/themes/aom/lgbwif.php?qief=qief

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

[XXXXXXXXXXXXXXXXXXXXXXXXXXX]

XXXXXXXXXXX wrote:
> 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.
>

Well, I take a short look to i2c package. At least for USBTMC you don't 
even have to change code. :-)