octave-dev — GNU Octave developers' list

[Octave Forge] Octave Forge mailing lists

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

We have taken a significant step toward closer collaboration between
the Octave and Octave Forge projects today by closing the Octave Forge
mailing list and inviting the members of that list to subscribe to the
Octave help and maintainers lists.

>From now on, the he...@oc... list will be the place to ask for
help for Octave and all Octave Forge packages and the
mai...@oc... list will be the place for all discussions
about the development of Octave and Octave Forge packages.

Re: [OctDev] geometry: wrong computation of axes in cov2ellipse

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

* Juan Pablo Carbajal <aju...@gm...> [2012-11-27 12:54]:
>
> On Sun, Nov 25, 2012 at 2:54 PM, Rafael Laboissiere <ra...@la...> wrote:
>>
>> 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
>>
>> [snip]
>
> Thank you again Rafael!
>
> I applied the patch.
>
> How did you find this bug?

In the usual way: I tried to use the function and noticed it was buggy.

Rafael

Re: [OctDev] [PKG] Instrument control: GPIB, USBTMC, VXI11

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

On 27 November 2012 12:27, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:

> My instrument control is just for communicating with external
> (standalone) instruments over different interfaces. There's no
> direct driver support for DAQ devices.
>
> Some time ago I looked at comedi library, but there's no support for
> my NI-5421 DAC. Unfortunately, I had to build a standalone exe, link
> it to NI's fgen and made a system call from octave. Terrible
> workaround, but it should be GPL save. :)

The technical details (pipes or dynamic or static linking) aren't what
makes the exe a derivative work of Octave or not, but rather the
fundamental nature of the communication and the kind of the data
exchanged. For example, is your exe producing output that only Octave
would understand and is only meant to be used with Octave? If so, this
is a GPL violation.

What kind of effort would it take to make comedi support your NI
hardware? This is the real long-term solution.

- Jordi G. H.

Re: [OctDev] [PKG] Instrument control: GPIB, USBTMC, VXI11

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

Juan Pablo Carbajal wrote:
> I do not have a card to test around (old INES DAQ, but never got them
> to work under linux), I will take a look at the tcp part.
> [...]
> Stefan, have you ever look at comedi? They used to support many NI
> cards, where there also using proprietary libraries? Is there we can
> scavenge something from that project (it has been abandoned for a long
> while)?

My instrument control is just for communicating with external (standalone) instruments over different interfaces. There's no direct driver support for DAQ devices.

Some time ago I looked at comedi library, but there's no support for my NI-5421 DAC. Unfortunately, I had to build a standalone exe, link it to NI's fgen and made a system call from octave. Terrible workaround, but it should be GPL save. :)


> 1.- Integrate your code to the current instrument-control package
> (Andrius and Stefan, are you ok with this?)
>   a. I suggest we use the sub-package structure that, for example,
> geometry has
> (http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/main/geometry/inst/).
>   b. We will need to update the makefile in the top folder to deal
> with the new subfolders.

Just copy the content from tcp_tb/ or usbtmc_tb/ to OF instrument control respectively and add both subdirectories to top folder Makefile


> 2.- Update the wiki with Stefan contribution
> http://wiki.octave.org/Instrument_control_package (Stefan, do you
> think you can complete the box just at the beginning? Maybe add a new
> color for "Testing")

done

>   a. Ideal here is to have tutorials/demos (like the ones in the wiki
> or this one for serial http://youtu.be/d1If8XOL73c).

later




Stefan

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

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

On Tue, Nov 27, 2012 at 4:47 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
>>>> For those wanting an open source (GNU) alternative to NI closed
>>>> source code here is a VXI11 set of source code by Steve D.
>>>> Sharples. The linux package can be compiled on Cygwin/Windows.
>>>> Hopefully this can be of use to someone.
>>>
>>> Did you read the start of this thread?
>>>
>>> As you can see at
>>>
>>> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh
>>>
>>> I use this package for my octave VXI11 toolbox.
>>
>> Is this exclusively the only package you use? Does your code link to
>> non-free libraries? If it does link to non-free libraries, please take
>> it down, as this is a GPL violation.
>>
>
> vxi11_tb uses source code from Steve D. Sharples VXI11 library. Except of vxi11.x (which has it's own open source license) all GPL.
>
> gpib_tb uses linux-gpib (GPLv2)
>
> usbtmc_tb and tcp_tb uses libc
>
> dummy visa_tb uses openvisa (GPLv2)
>
>
>>>> 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?
>>>
>>> I have ported the TCP and USBTMC part. Could you take a look,
>>> please?
>>
>> Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
>> to judge this contribution. I am CC'ing them here.
>
> OK
>
>> As an aside, it's not "GNU/Octave". There should be no slash there.
>> The slash in "GNU/Linux" is meant to indicate that the operating
>> system is a combination of GNU with the Linux kernel. "GNU Octave"
>> isn't an operating system of which Octave is a kernel; it is merely a
>> GNU package.
>
> done
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

I moved this thread to "[PKG] Instrument control: GPIB, USBTMC, VXI11"

[OctDev] [PKG] Instrument control: GPIB, USBTMC, VXI11

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

On Tue, Nov 27, 2012 at 4:47 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
>>>> For those wanting an open source (GNU) alternative to NI closed
>>>> source code here is a VXI11 set of source code by Steve D.
>>>> Sharples. The linux package can be compiled on Cygwin/Windows.
>>>> Hopefully this can be of use to someone.
>>>
>>> Did you read the start of this thread?
>>>
>>> As you can see at
>>>
>>> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh
>>>
>>> I use this package for my octave VXI11 toolbox.
>>
>> Is this exclusively the only package you use? Does your code link to
>> non-free libraries? If it does link to non-free libraries, please take
>> it down, as this is a GPL violation.
>>
>
> vxi11_tb uses source code from Steve D. Sharples VXI11 library. Except of vxi11.x (which has it's own open source license) all GPL.
>
> gpib_tb uses linux-gpib (GPLv2)
>
> usbtmc_tb and tcp_tb uses libc
>
> dummy visa_tb uses openvisa (GPLv2)
>
>
>>>> 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?
>>>
>>> I have ported the TCP and USBTMC part. Could you take a look,
>>> please?
>>
>> Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
>> to judge this contribution. I am CC'ing them here.
>
> OK
>
>> As an aside, it's not "GNU/Octave". There should be no slash there.
>> The slash in "GNU/Linux" is meant to indicate that the operating
>> system is a combination of GNU with the Linux kernel. "GNU Octave"
>> isn't an operating system of which Octave is a kernel; it is merely a
>> GNU package.
>
> done
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

(I edited the topic to move out of the previous thread)

Hi Stefan,
This is so great!

I do not have a card to test around (old INES DAQ, but never got them
to work under linux), I will take a look at the tcp part.
I suggest the following plan:
1.- Integrate your code to the current instrument-control package
(Andrius and Stefan, are you ok with this?)
  a. I suggest we use the sub-package structure that, for example,
geometry has (http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/main/geometry/inst/).
  b. We will need to update the makefile in the top folder to deal
with the new subfolders.

2.- Update the wiki with Stefan contribution
http://wiki.octave.org/Instrument_control_package (Stefan, do you
think you can complete the box just at the beginning? Maybe add a new
color for "Testing")
  a. Ideal here is to have tutorials/demos (like the ones in the wiki
or this one for serial http://youtu.be/d1If8XOL73c).

Stefan, have you ever look at comedi? They used to support many NI
cards, where there also using proprietary libraries? Is there we can
scavenge something from that project (it has been abandoned for a long
while)?

We are on the move!

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

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

>>> For those wanting an open source (GNU) alternative to NI closed
>>> source code here is a VXI11 set of source code by Steve D.
>>> Sharples. The linux package can be compiled on Cygwin/Windows.
>>> Hopefully this can be of use to someone.
>>
>> Did you read the start of this thread?
>>
>> As you can see at
>>
>> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh
>> 
>> I use this package for my octave VXI11 toolbox.
> 
> Is this exclusively the only package you use? Does your code link to
> non-free libraries? If it does link to non-free libraries, please take
> it down, as this is a GPL violation.
>

vxi11_tb uses source code from Steve D. Sharples VXI11 library. Except of vxi11.x (which has it's own open source license) all GPL.

gpib_tb uses linux-gpib (GPLv2)

usbtmc_tb and tcp_tb uses libc

dummy visa_tb uses openvisa (GPLv2)


>>> 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?
>>
>> I have ported the TCP and USBTMC part. Could you take a look,
>> please?
> 
> Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
> to judge this contribution. I am CC'ing them here.

OK

> As an aside, it's not "GNU/Octave". There should be no slash there.
> The slash in "GNU/Linux" is meant to indicate that the operating
> system is a combination of GNU with the Linux kernel. "GNU Octave"
> isn't an operating system of which Octave is a kernel; it is merely a
> GNU package.

done

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

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

Removing maintainers and help from this thread; until the lists are
merged, this is purely something that interests the OF packages.

On 27 November 2012 10:09, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:

> "Ivan.Cousins" wrote:

>> For those wanting an open source (GNU) alternative to NI closed
>> source code here is a VXI11 set of source code by Steve D.
>> Sharples. The linux package can be compiled on Cygwin/Windows.
>> Hopefully this can be of use to someone.
>
> Did you read the start of this thread?
>
> As you can see at
> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh

> I use this package for my octave VXI11 toolbox.

Is this exclusively the only package you use? Does your code link to
non-free libraries? If it does link to non-free libraries, please take
it down, as this is a GPL violation.

On 27 November 2012 10:17, XXXXXXXXXXXXXXXXXXXXXXXXXXX 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?
>
> I have ported the TCP and USBTMC part. Could you take a look,
> please?

Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
to judge this contribution. I am CC'ing them here.

As an aside, it's not "GNU/Octave". There should be no slash there.
The slash in "GNU/Linux" is meant to indicate that the operating
system is a combination of GNU with the Linux kernel. "GNU Octave"
isn't an operating system of which Octave is a kernel; it is merely a
GNU package.

- Jordi G. H.

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

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

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?
> 
> - Jordi G. H.

I have ported the TCP and USBTMC part. Could you take a look, please?

You find it at the "port2forge" branch directory usbtmc_tb/ and tcp_tb/

https://github.com/dac922/octave-instrument-control-toolbox/tree/port2forge

I'm still working on GPIB, but transfers are not interruptable safely. No solution yet.

Stefan

Re: [OctDev] geometry: wrong computation of axes in cov2ellipse

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

On Sun, Nov 25, 2012 at 2:54 PM, Rafael Laboissiere
<ra...@la...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Thank you again Rafael!

I applied the patch.

How did you find this bug?

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

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

On 26 November 2012 04:37, Francesco Potortì <Po...@is...> wrote:
> Julien Salort:
>>> Now I have a bunch of Octave-only code that I can't share with
>>> anyone. If I had chosen Matlab in the first place, I would be able to
>>> publish the code without restriction. This is very paradoxical and I had
>>> not anticipated this problem.
>
> Jordi Gutiérrez Hermoso:
>>The problem isn't Octave. It's the license of the non-free libraries
>>it's linking to. Matlab's license is even more restrictive and I
>>imagine they would also consider you linking to both libraries to be
>>worse. The GPL is far more permissive than Matlab's license, so I
>>imagine Matlab's EULA would also pose the same problem.
>
> I definitely think not.  I can't imagine the Matlab lawyers ask anyone
> to unpublish code that allows Matlab to link with instrumentation.  That
> would be against their own interest.

The Matlab license is routinely violated and the Mathworks lawyers
selectively enforce it. Consider all of the students learning Matlab
worldwide and their primary method for acquiring it. Stating the the
GPL is more restrictive than the Matlab license might only be true if
you consider how seldom the Matlab EULA is enforced. I have seen far
more violations of the Matlab license in the wild than of Octave's
GPL, e.g. people modifying Matlab's m-files and publishing them or
distributing Matlab's Compile Runtime without permission.

This is a common tactic with non-free software: make the license terms
so restrictive, vague, and difficult to understand that almost anyone
has violated them at least in some small way. Thus anyone can be
pressured whenever there is need. We have a GPL FAQ that attempts to
clarify its terms. Where is the Matlab EULA FAQ, or even the license
text itself? They instead confuse, obfuscate, and selectively enforce
as suits their need.

> This is a real problem for Octave.  If really it is not currently
> possible to publish a wrapper that allows Octave to call an external
> instrumentation routine, then adding an exception to the Octave licence
> should be considered.

We can't change Octave's license, not without much effort. We don't do
copyright assignments, and even if we did, we have a number of
contributors who are dead. We would have to remove their contributions
if we wanted to change Octave's license.

This is a problem for Octave in the same way that the nVidia blob is a
problem for Linux users. If Linus wants nVidia to fuck off so badly,
why doesn't he enforce Linux's copyleft? You would quickly see nVidia
dancing to another tune if all of its Linux users couldn't use its
binary blob.

I am not sure much more can be done for our case than to pressure the
hardware companies to release free libraries or specs for
communicating with their hardware. Julien can still use his library
privately and Octave in the meantime has a free instrument control
package implemented by Andrius Sutas. It is unfortunate that Julien
can't share his code with us, but the GPL is not to blame here. Why
are the hardware manufacturers not allowing Julien to use his hardware
*and* software however he pleases?

I will nevertheless consult with the FSF and GNU; perhaps there is
another solution I have not seen here.

- Jordi G. H.

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

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

The mailing lists novel... KISS<http://en.wikipedia.org/wiki/KISS_principle>

us...@oc...
de...@oc...

That's enough.


2012/11/25 Juan Pablo Carbajal <aju...@gm...>

> On Mon, Nov 26, 2012 at 1:45 AM, Carnë Draug <car...@gm...>
> wrote:
> > On 26 November 2012 01:01, Daniel J Sebald <dan...@ie...>
> wrote:
> >> On 11/25/2012 04:10 PM, Carnė Draug wrote:
> >>>
> >>> On 25 November 2012 21:44, Daniel J Sebald<dan...@ie...>
>  wrote:
> >>> At the moment, the decision whether a thread belongs to the help or
> >>> octave-dev mailing list is whether the reply is "use package X from
> >>> octave forge". I'll argue that most Octave users already use at least
> >>> one of the Octave Forge packages. And I'll also argue that no one in
> >>> Octave Forge uses all the Octave Forge packages. So if the question is
> >>> how to use a function from an Octave Forge package, users on the help
> >>> mailing list already are the right people to answer it. Keeping them
> >>> separated makes no sense anymore.
> >>
> >> So there will be changes to the Octave webpage descriptions that
> >> consequently (or at least intend to) direct the bulk of OctDev to the
> >> "he...@oc..." mailing list?
> >
> > Yes. That's why this is being discussed in the maintainers mailing list.
> >
> >>>>> There's plenty of applications and packages for Octave that are not
> >>>>> part of Forge.
> >>>>
> >>>>
> >>>> That doesn't mean Octave Forge isn't primarily about packages and
> >>>> applications.
> >>>
> >>>
> >>> What is this applications you keep talking about? There's only
> packages.
> >>
> >> You are thinking of applications as in hunk of software, I suspect.  I'm
> >> speaking in terms of applied science, e.g., signal processing, civil
> >> engineering, image processing, statistics.
> >
> > Damn you homophones. Causing trouble since monkeys learned to talk.
> >
> >>>> Yes and no.  I often see discussions of bugs.  Some bugs are
> >>>> straightforward
> >>>> and remain on the tracker.  Some are either vague and difficult to
> solve
> >>>> and
> >>>> warrant help from others, hence discussion list.  Some bugs expose an
> >>>> underlying weakness in design and warrant discussion about design
> >>>> modifications.
> >>>
> >>>
> >>> That may be true in core. I do not remember that ever happening in
> >>> forge. Considering the way development is done in Forge, I wouldn't
> >>> consider this to ever be a problem.
> >>
> >>
> >> "install package" would be the conceptual development there--now stable.
> >
> > "install package" would already belong to the maintainers mailing list
> > since it's handled by pkg, itself part of core. It is, however, a very
> > good example of a maintainers discussion that developers of forge
> > should be involved.
> >
> >>> Yes it is. Not one big change though, but slowly slowly seems to be
> >>> the direction it's taking. It doesn't make sense to make that question
> >>> yet, maybe it never will. But in the mean time, when things start to
> >>> overlap, such as in the case of the mailing lists, it makes sense to
> >>> merge them. We are not discussing more than just that, mailing lists.
> >>
> >>
> >> Getting rid of an active mailing list is more than a name change.  That
> >> traffic has to go somewhere.  I doubt the package concept is going away.
> >
> > We are merging 3 mailing lists, whose subjects have been overlapping
> > too much and too often, into 2.
>
> I do agree with Carnë idea. In particular with the refinement proposed
> by jwe were everything gets merged to the current mailing lists.
>
> I do not really understand, the complication observed or proposed by
> Daniel (no ofense!). I think the issue is quite simple, so a simple
> solution should be enough.
>
> Cheers
>

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

[Francesco P. <Po...@is...>]

Julien Salort:
>> Now I have a bunch of Octave-only code that I can't share with
>> anyone. If I had chosen Matlab in the first place, I would be able to
>> publish the code without restriction. This is very paradoxical and I had
>> not anticipated this problem.

Jordi Gutiérrez Hermoso:
>The problem isn't Octave. It's the license of the non-free libraries
>it's linking to. Matlab's license is even more restrictive and I
>imagine they would also consider you linking to both libraries to be
>worse. The GPL is far more permissive than Matlab's license, so I
>imagine Matlab's EULA would also pose the same problem. 

I definitely think not.  I can't imagine the Matlab lawyers ask anyone
to unpublish code that allows Matlab to link with instrumentation.  That
would be against their own interest.

This is a real problem for Octave.  If really it is not currently
possible to publish a wrapper that allows Octave to call an external
instrumentation routine, then adding an exception to the Octave licence
should be considered.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.315.3058 (op.2111)
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it

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

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

On 25 November 2012 17:48, Julien Salort <li...@ju...> wrote:
> I'm not very amused personally. I was wrong to think that Octave was a
> good choice for instrument control. I wanted something free because I
> didn't want to rely on restricted licenses for my experimental setups:
> what happens if the network gets down ? No license server, no instrument
> control anymore. That seemed unacceptable to me. That's why I've been
> advocating for Octave to several colleagues.
>
> Now I have a bunch of Octave-only code that I can't share with
> anyone. If I had chosen Matlab in the first place, I would be able to
> publish the code without restriction. This is very paradoxical and I had
> not anticipated this problem.

The problem isn't Octave. It's the license of the non-free libraries
it's linking to. Matlab's license is even more restrictive and I
imagine they would also consider you linking to both libraries to be
worse. The GPL is far more permissive than Matlab's license, so I
imagine Matlab's EULA would also pose the same problem. If not, I
would be happy to be proven wrong and be pointed to the clause in the
Matlab EULA that allows you to make derivative work of both Matlab and
the non-free libraries you're linking to.

I agree that not being allowed to share your work seems problematic,
and I am not happy about this either. I am much less happy with how
you are forced to use non-free software to communicate with your
hardware. You shouldn't be unhappy with Octave. You should be unhappy
with the hardware manufacturers who won't let you freely use the
software for the hardware you've already bought.

- Jordi G. H.

[OctDev] splines 1.1.1 released

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

Hi everyone

a new release of splines package is out, version 1.1.1, by Nir Krakauer.
Enjoy Octave responsibly.

Carnë

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

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

On Mon, Nov 26, 2012 at 1:45 AM, Carnë Draug <car...@gm...> wrote:
> On 26 November 2012 01:01, Daniel J Sebald <dan...@ie...> wrote:
>> On 11/25/2012 04:10 PM, Carnė Draug wrote:
>>>
>>> On 25 November 2012 21:44, Daniel J Sebald<dan...@ie...>  wrote:
>>> At the moment, the decision whether a thread belongs to the help or
>>> octave-dev mailing list is whether the reply is "use package X from
>>> octave forge". I'll argue that most Octave users already use at least
>>> one of the Octave Forge packages. And I'll also argue that no one in
>>> Octave Forge uses all the Octave Forge packages. So if the question is
>>> how to use a function from an Octave Forge package, users on the help
>>> mailing list already are the right people to answer it. Keeping them
>>> separated makes no sense anymore.
>>
>> So there will be changes to the Octave webpage descriptions that
>> consequently (or at least intend to) direct the bulk of OctDev to the
>> "he...@oc..." mailing list?
>
> Yes. That's why this is being discussed in the maintainers mailing list.
>
>>>>> There's plenty of applications and packages for Octave that are not
>>>>> part of Forge.
>>>>
>>>>
>>>> That doesn't mean Octave Forge isn't primarily about packages and
>>>> applications.
>>>
>>>
>>> What is this applications you keep talking about? There's only packages.
>>
>> You are thinking of applications as in hunk of software, I suspect.  I'm
>> speaking in terms of applied science, e.g., signal processing, civil
>> engineering, image processing, statistics.
>
> Damn you homophones. Causing trouble since monkeys learned to talk.
>
>>>> Yes and no.  I often see discussions of bugs.  Some bugs are
>>>> straightforward
>>>> and remain on the tracker.  Some are either vague and difficult to solve
>>>> and
>>>> warrant help from others, hence discussion list.  Some bugs expose an
>>>> underlying weakness in design and warrant discussion about design
>>>> modifications.
>>>
>>>
>>> That may be true in core. I do not remember that ever happening in
>>> forge. Considering the way development is done in Forge, I wouldn't
>>> consider this to ever be a problem.
>>
>>
>> "install package" would be the conceptual development there--now stable.
>
> "install package" would already belong to the maintainers mailing list
> since it's handled by pkg, itself part of core. It is, however, a very
> good example of a maintainers discussion that developers of forge
> should be involved.
>
>>> Yes it is. Not one big change though, but slowly slowly seems to be
>>> the direction it's taking. It doesn't make sense to make that question
>>> yet, maybe it never will. But in the mean time, when things start to
>>> overlap, such as in the case of the mailing lists, it makes sense to
>>> merge them. We are not discussing more than just that, mailing lists.
>>
>>
>> Getting rid of an active mailing list is more than a name change.  That
>> traffic has to go somewhere.  I doubt the package concept is going away.
>
> We are merging 3 mailing lists, whose subjects have been overlapping
> too much and too often, into 2.

I do agree with Carnë idea. In particular with the refinement proposed
by jwe were everything gets merged to the current mailing lists.

I do not really understand, the complication observed or proposed by
Daniel (no ofense!). I think the issue is quite simple, so a simple
solution should be enough.

Cheers

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

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

On Sun, Nov 25, 2012 at 11:48 PM, Julien Salort <li...@ju...> wrote:
> Sergei Steshenko <ser...@ya...>
> writes:
>
>> I am wondering what is more amusing:
>>
>> 1) a puppy or a kitten trying to catch its own tail;
>> 2) a cat chasing laser pointer light spot on a wall or a floor;
>> 3) GPL proponents shooting themselves in the foot.
>
> I'm not very amused personally. I was wrong to think that Octave was a
> good choice for instrument control. I wanted something free because I
> didn't want to rely on restricted licenses for my experimental setups:
> what happens if the network gets down ? No license server, no instrument
> control anymore. That seemed unacceptable to me. That's why I've been
> advocating for Octave to several colleagues.
>
> Now I have a bunch of Octave-only code that I can't share with
> anyone. If I had chosen Matlab in the first place, I would be able to
> publish the code without restriction. This is very paradoxical and I had
> not anticipated this problem. I must admit that I should have read
> Octave license carefully in the first place. But I wrongly thought that
> careful reading of licenses was only necessary when using proprietary
> software, because the GPL was meant to protect me, as a user. And I was
> happy with publishing my own code under GPL too.
>
> Now I realise that I would not have had problem if I had gone with
> Python instead of Octave.  I understand why they have a GPL-phobia now.
>
> But I have several experimental setups that have been tuned with Octave
> scripts and switching to Matlab or Python will be too huge a work.
> So I'll have to stick with Octave, but with no possibility of sharing
> my code publicly.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Julien,

Jordi said it is a violation to GPl, but is the matter truly solved? I
see no answer regarding the example I sent to RMS. Maybe adding the
compiler directives may solve the problem. Lets wait to that answer.

Also, the fobia is unjustified, since it is an artifact created by the
existence of non-free licenses. The idea is that we do not want o
violate GPL to prevent the proliferation of non-free software.
Otehrwise, as oyu just said, the existence of the non-free software
makes the life hard for people trying to free software!

It is only the "practical" posture, not considering the ethical
aspects, that makes some people exasperated about free licenses. If
you believe in free software, then rally your courage and hold
together till the storm passes. This is maybe similar to people saying
that military research is good for everyone, just because they
willingly ignore the fact that their contributions will eventually
kill humans.

Btw, how is the situation with the comedi drivers? Did they also used
proprietary software, I think not! Can you double check?
http://comedi.org/
Please let us know what you find in a different thread (maybe subject Comedi)
Thank you.

JPi






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

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

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

On 26 November 2012 01:01, Daniel J Sebald <dan...@ie...> wrote:
> On 11/25/2012 04:10 PM, Carnė Draug wrote:
>>
>> On 25 November 2012 21:44, Daniel J Sebald<dan...@ie...>  wrote:
>> At the moment, the decision whether a thread belongs to the help or
>> octave-dev mailing list is whether the reply is "use package X from
>> octave forge". I'll argue that most Octave users already use at least
>> one of the Octave Forge packages. And I'll also argue that no one in
>> Octave Forge uses all the Octave Forge packages. So if the question is
>> how to use a function from an Octave Forge package, users on the help
>> mailing list already are the right people to answer it. Keeping them
>> separated makes no sense anymore.
>
> So there will be changes to the Octave webpage descriptions that
> consequently (or at least intend to) direct the bulk of OctDev to the
> "he...@oc..." mailing list?

Yes. That's why this is being discussed in the maintainers mailing list.

>>>> There's plenty of applications and packages for Octave that are not
>>>> part of Forge.
>>>
>>>
>>> That doesn't mean Octave Forge isn't primarily about packages and
>>> applications.
>>
>>
>> What is this applications you keep talking about? There's only packages.
>
> You are thinking of applications as in hunk of software, I suspect.  I'm
> speaking in terms of applied science, e.g., signal processing, civil
> engineering, image processing, statistics.

Damn you homophones. Causing trouble since monkeys learned to talk.

>>> Yes and no.  I often see discussions of bugs.  Some bugs are
>>> straightforward
>>> and remain on the tracker.  Some are either vague and difficult to solve
>>> and
>>> warrant help from others, hence discussion list.  Some bugs expose an
>>> underlying weakness in design and warrant discussion about design
>>> modifications.
>>
>>
>> That may be true in core. I do not remember that ever happening in
>> forge. Considering the way development is done in Forge, I wouldn't
>> consider this to ever be a problem.
>
>
> "install package" would be the conceptual development there--now stable.

"install package" would already belong to the maintainers mailing list
since it's handled by pkg, itself part of core. It is, however, a very
good example of a maintainers discussion that developers of forge
should be involved.

>> Yes it is. Not one big change though, but slowly slowly seems to be
>> the direction it's taking. It doesn't make sense to make that question
>> yet, maybe it never will. But in the mean time, when things start to
>> overlap, such as in the case of the mailing lists, it makes sense to
>> merge them. We are not discussing more than just that, mailing lists.
>
>
> Getting rid of an active mailing list is more than a name change.  That
> traffic has to go somewhere.  I doubt the package concept is going away.

We are merging 3 mailing lists, whose subjects have been overlapping
too much and too often, into 2.

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

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

Le 25 nov. 2012 à 19:30, Jordi Gutiérrez Hermoso <jo...@oc...> a écrit :

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

Done.

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

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

On 11/25/2012 04:10 PM, Carnë Draug wrote:
> On 25 November 2012 21:44, Daniel J Sebald<dan...@ie...>  wrote:
>> On 11/25/2012 01:48 PM, Carnë Draug wrote:
>>> You seem to be confused about what Octave Forge is.
>>
[snip]
>> I get a lot of email with OctDev tagged onto it (the name OctDev itself
>> leads to confusion given it is associated with Octave Forge...and I
>> understand this is why we are discussing name changes) and discussions seem
>> to be primarily about packages and Java and applications.  That seems like
>> advanced stuff.
>
> At the moment, the decision whether a thread belongs to the help or
> octave-dev mailing list is whether the reply is "use package X from
> octave forge". I'll argue that most Octave users already use at least
> one of the Octave Forge packages. And I'll also argue that no one in
> Octave Forge uses all the Octave Forge packages. So if the question is
> how to use a function from an Octave Forge package, users on the help
> mailing list already are the right people to answer it. Keeping them
> separated makes no sense anymore.

So there will be changes to the Octave webpage descriptions that 
consequently (or at least intend to) direct the bulk of OctDev to the 
"he...@oc..." mailing list?

Thoughts from others who have followed the "help" email list?


>>> There's plenty of applications and packages for Octave that are not
>>> part of Forge.
>>
>> That doesn't mean Octave Forge isn't primarily about packages and
>> applications.
>
> What is this applications you keep talking about? There's only packages.

You are thinking of applications as in hunk of software, I suspect.  I'm 
speaking in terms of applied science, e.g., signal processing, civil 
engineering, image processing, statistics.  However, looking at the list 
of packages just now, it does seem there are quite a few more geared 
toward software, e.g., tcl-octave.  Anyway, "pac...@oc..." was an 
alternative I tossed out there.


>> What is Forge?
>
> Forget that the word Forge means anything. It's just the name of the
> project. Maybe historically means it was hosted in SourceForge. Or
> maybe because the original idea behind the project was to develop and
> test new things which would be moved into core as they mature.

Both.


>> Yes and no.  I often see discussions of bugs.  Some bugs are straightforward
>> and remain on the tracker.  Some are either vague and difficult to solve and
>> warrant help from others, hence discussion list.  Some bugs expose an
>> underlying weakness in design and warrant discussion about design
>> modifications.
>
> That may be true in core. I do not remember that ever happening in
> forge. Considering the way development is done in Forge, I wouldn't
> consider this to ever be a problem.

"install package" would be the conceptual development there--now stable.


>>> 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:
>>
>> Yes, those all make sense.  There is some overlap, which is fine.
>> Occasional duplication hasn't struck me as a concern as of yet. Perhaps
>> others feel otherwise.
>
> It's not just occasional. Almost all of the forge threads related to
> development are also mentioned in the maintainers mailing list.
>
>> I guess the question is whether Octave Forge should be rolled into an all
>> inclusive Octave.  Presumably that's the way it will be someday, provided
>> things stabilize.  Is that day approaching?  Sort of, but not quite yet, I
>> would argue.
>
> Yes it is. Not one big change though, but slowly slowly seems to be
> the direction it's taking. It doesn't make sense to make that question
> yet, maybe it never will. But in the mean time, when things start to
> overlap, such as in the case of the mailing lists, it makes sense to
> merge them. We are not discussing more than just that, mailing lists.

Getting rid of an active mailing list is more than a name change.  That 
traffic has to go somewhere.  I doubt the package concept is going away.

Dan

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

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

Sergei Steshenko <ser...@ya...>
writes:

> I am wondering what is more amusing:
>
> 1) a puppy or a kitten trying to catch its own tail;
> 2) a cat chasing laser pointer light spot on a wall or a floor;
> 3) GPL proponents shooting themselves in the foot.

I'm not very amused personally. I was wrong to think that Octave was a
good choice for instrument control. I wanted something free because I
didn't want to rely on restricted licenses for my experimental setups:
what happens if the network gets down ? No license server, no instrument
control anymore. That seemed unacceptable to me. That's why I've been
advocating for Octave to several colleagues.

Now I have a bunch of Octave-only code that I can't share with
anyone. If I had chosen Matlab in the first place, I would be able to
publish the code without restriction. This is very paradoxical and I had
not anticipated this problem. I must admit that I should have read
Octave license carefully in the first place. But I wrongly thought that
careful reading of licenses was only necessary when using proprietary
software, because the GPL was meant to protect me, as a user. And I was
happy with publishing my own code under GPL too.

Now I realise that I would not have had problem if I had gone with
Python instead of Octave.  I understand why they have a GPL-phobia now.

But I have several experimental setups that have been tuned with Octave
scripts and switching to Matlab or Python will be too huge a work.
So I'll have to stick with Octave, but with no possibility of sharing
my code publicly.

[OctDev] octave, splines package, csaps, csaps_sel, nonequidistant sampling points

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

Dear Sebastian,

Thank you for letting me know of these problems. I think I fixed the
extrapolation now, and have posted corrected versions of csaps and
csaps_sel in the Subversion repository.

> (i) My usual call of
> "y_interp=csaps(t, y, -1, t_interp);"
> , i.e. automatic(?) relaxation between cubic spline interpolation and
> regression, produced different results for the "old" and "new" function.
> Indeed, this became a minor issue, when I noticed that the reproduction
> of the "old" results became better by applying
> "y_interp=csaps_sel(t, y, t_interp, [], "gcv");"

If I get the chance, I will take a look at the implementation in
spline-gcvspl to try and understand the reason for the difference.

> (Also, I am not sure if the documentation "p<0 or not given: an
> intermediate amount of smoothing is chosen (the smoothing term and the
> interpolation term are scaled to be of the same magnitude)" is not
> misleading.)

Why is it misleading?

> Additionally (but this is not an issue for me but might belong to any
> possible solution), there is a different method of extrapolation (csaps:
> constant, csaps_sel: spline). I am not sure if this should be mentioned
> in the documentation.

The extrapolation should be linear in both cases. I found some
mistakes in how I implemented this originally. I used the following
code (slightly non-equally-spaced points) to test the extrapolation:

x = ([1:10 10.5 11.3])'; y = sin(x);
xx = 0:0.1:12;
[yy, p] = csaps(x,y,1,xx);
plot(x, y, 's', xx, yy)

> (ii) In my point of view, there is a more severe issue: application of
> non-equidistant sampling points. In the latter case, the solution
> appears to be alright, but the first derivatives have discontinuities
> (at least for the difference quotient). In my testing file SmoothingSpline, the different
> behaviour (equidistant/non-equidistant) can be switched by
> commenting/uncommenting the line below "MAJOR ISSUE".

The first derivative of a cubic spline should be continuous and
piecewise quadratic. To get the derivative, you can use ppder. For the
test case above,

[pp, p] = csaps(x,y,1);
ppd = ppder(pp, 1);
yyd = ppval(ppd, xx);
plot(xx, yyd)

which looks to be continuous and, inside the domain, reasonably in
agreement with the derivative of sin(x).

Using csaps_sel in this case returns p=0.41 so there is some smoothing
compared with p = 1, but the derivative is still continuous:

x = ([1:10 10.5 11.3])'; y = sin(x);
xx = 0:0.1:12;
[pp, p] = csaps_sel(x,y);
yy = ppval(pp, xx);
ppd = ppder(pp, 1);
yyd = ppval(ppd, xx);
plot(xx, yyd)

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

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

----- Original Message -----
> From: Julien Salort <li...@ju...>
> To: Jordi Gutiérrez Hermoso <jo...@oc...>
> Cc: oct...@li...; "he...@oc... Help" <he...@oc...>; "rm...@gn..." <rm...@gn...>
> Sent: Sunday, November 25, 2012 11:42 PM
> Subject: Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)
> 
> Le 25 nov. 2012 à 19:30, Jordi Gutiérrez Hermoso <jo...@oc...> a 
> écrit :
> 
>>  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.
> 
> Done.
> _______________________________________________


I am wondering what is more amusing:

1) a puppy or a kitten trying to catch its own tail;
2) a cat chasing laser pointer light spot on a wall or a floor;
3) GPL proponents shooting themselves in the foot.

Regards,
  Sergei.

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

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

On 25 November 2012 21:44, Daniel J Sebald <dan...@ie...> wrote:
> On 11/25/2012 01:48 PM, Carnë Draug wrote:
>> You seem to be confused about what Octave Forge is.
>
> Yes, that is my point.  Developers talk of Octave Forge as though it is
> something other than packages, something more encompassing, etc.  I look at
> the website
>
> http://octave.sourceforge.net/
>
> and I see at the very top, first thing:
>
> "Octave-Forge - Extra packages for GNU Octave"
>
> Am I mistaken for assuming then that Octave Forge is primarily packages?
> What is this "forge" concept that I'm not understanding?

It's primarily for packages but only the ones that belong to Octave Forge.

> I get a lot of email with OctDev tagged onto it (the name OctDev itself
> leads to confusion given it is associated with Octave Forge...and I
> understand this is why we are discussing name changes) and discussions seem
> to be primarily about packages and Java and applications.  That seems like
> advanced stuff.

At the moment, the decision whether a thread belongs to the help or
octave-dev mailing list is whether the reply is "use package X from
octave forge". I'll argue that most Octave users already use at least
one of the Octave Forge packages. And I'll also argue that no one in
Octave Forge uses all the Octave Forge packages. So if the question is
how to use a function from an Octave Forge package, users on the help
mailing list already are the right people to answer it. Keeping them
separated makes no sense anymore.

About java, its package has been merged into core. About applications,
Octave Forge has no applications so such discussions should already be
directed to the help mailing list.

>> We are not the go
>> to place for all applications, packages and advanced Octave stuff.
>
> OK, that's not what it is.  What is it?

It's a place for development of Octave packages. But the keyword there
is *all*. Specially with Agora, we should redirect some stuff there. I
already have a couple of packages that I have been developing and do
not want to be part of Octave Forge. I will place them in Agora when I
have time.

We also distribute Octave binaries (it has been suggested that as of
4.0.0 Octave will handle this itself. We will see when that time
comes, no point in discussing this at the moment), and have an
alphabetic list of the functions in Octave (which jwe also suggested
could be moved to Octave as free time to make the change allows it).

>> There's plenty of applications and packages for Octave that are not
>> part of Forge.
>
> That doesn't mean Octave Forge isn't primarily about packages and
> applications.

What is this applications you keep talking about? There's only packages.

> What is Forge?

Forget that the word Forge means anything. It's just the name of the
project. Maybe historically means it was hosted in SourceForge. Or
maybe because the original idea behind the project was to develop and
test new things which would be moved into core as they mature. So
Octave Forge was the place where Octave code was forged (I used to
think the name came from there, I don't know anymore). But bottom line
is, it doesn't matter. It's just the name of the project.

>>> 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.
>
>
> Yes and no.  I often see discussions of bugs.  Some bugs are straightforward
> and remain on the tracker.  Some are either vague and difficult to solve and
> warrant help from others, hence discussion list.  Some bugs expose an
> underlying weakness in design and warrant discussion about design
> modifications.

That may be true in core. I do not remember that ever happening in
forge. Considering the way development is done in Forge, I wouldn't
consider this to ever be a problem.

>> 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:
>
> Yes, those all make sense.  There is some overlap, which is fine.
> Occasional duplication hasn't struck me as a concern as of yet. Perhaps
> others feel otherwise.

It's not just occasional. Almost all of the forge threads related to
development are also mentioned in the maintainers mailing list.

> I guess the question is whether Octave Forge should be rolled into an all
> inclusive Octave.  Presumably that's the way it will be someday, provided
> things stabilize.  Is that day approaching?  Sort of, but not quite yet, I
> would argue.

Yes it is. Not one big change though, but slowly slowly seems to be
the direction it's taking. It doesn't make sense to make that question
yet, maybe it never will. But in the mean time, when things start to
overlap, such as in the case of the mailing lists, it makes sense to
merge them. We are not discussing more than just that, mailing lists.

> However, the GUI will be a wave of issues in a
> multi-platform supported project.  If Forge-related posts get mixed with
> core-related posts with an increase due to GUI issues, could it be too much?

>From the last month example, having 4 extra posts from forge to the
maintainers mailing list shouldn't be much. If there is a problem it
would be the other way, people interested in forge only receiving
e-mails from core development. But developers of Octave Forge should
be aware of important changes in core, before a release is made. And
it makes sense that they add their voice in such discussions.

That the GUI may cause an increase in traffic should not be of concern
because it would either belong to help in building it (go to help), or
in the bug tracker.

Carnë

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

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

On 11/25/2012 01:48 PM, Carnë Draug wrote:
> 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.

Yes, that is my point.  Developers talk of Octave Forge as though it is 
something other than packages, something more encompassing, etc.  I look 
at the website

http://octave.sourceforge.net/

and I see at the very top, first thing:

"Octave-Forge - Extra packages for GNU Octave"

Am I mistaken for assuming then that Octave Forge is primarily packages? 
  What is this "forge" concept that I'm not understanding?

I get a lot of email with OctDev tagged onto it (the name OctDev itself 
leads to confusion given it is associated with Octave Forge...and I 
understand this is why we are discussing name changes) and discussions 
seem to be primarily about packages and Java and applications.  That 
seems like advanced stuff.


> We are not the go
> to place for all applications, packages and advanced Octave stuff.

OK, that's not what it is.  What is it?


> There's plenty of applications and packages for Octave that are not
> part of Forge.

That doesn't mean Octave Forge isn't primarily about packages and 
applications.  What is Forge?


>  Calling it advanced is insulting to core as if one
> could not do advanced stuff with core only.

No it isn't.  Packages encompass advanced fields of study.  Calling 
something advanced doesn't imply something else isn't advanced in its 
own way.



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

Yes and no.  I often see discussions of bugs.  Some bugs are 
straightforward and remain on the tracker.  Some are either vague and 
difficult to solve and warrant help from others, hence discussion list. 
  Some bugs expose an underlying weakness in design and warrant 
discussion about design modifications.


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

Yes, those all make sense.  There is some overlap, which is fine. 
Occassional duplication hasn't struck me as a concern as of yet. 
Perhaps others feel otherwise.

I guess the question is whether Octave Forge should be rolled into an 
all inclusive Octave.  Presumably that's the way it will be someday, 
provided things stabilize.  Is that day approaching?  Sort of, but not 
quite yet, I would argue.

2012 has certainly been one of the most active years of development, and 
I think the reorganization of the core code has gone a long way toward a 
more developer-friendly project.  However, the GUI will be a wave of 
issues in a multi-platform supported project.  If Forge-related posts 
get mixed with core-related posts with an increase due to GUI issues, 
could it be too much?

I propose a holding pattern with discussions about consolidation and 
rolling out the GUI as part of, or coincident with, OctConf 2013?

Dan



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