octave-dev — GNU Octave developers' list

Re: [OctDev] [instrument-control]

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

On Thu, Oct 18, 2012 at 9:14 AM, Juan Pablo Carbajal
<aju...@gm...> wrote:
> On Thu, Oct 18, 2012 at 12:31 AM, Juan Pablo Carbajal
> <aju...@gm...> wrote:
>> Hello,
>>
>> I am observing weird behaviors and I couldn't pin down at which level
>> things are going bad. Using instrument-control 0.1.0 from Forge.
>> Running Ubuntu 12.04 64 bit
>> Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012
>> x86_64 x86_64 x86_64 GNU/Linux
>>
>> I am using serial communications. I am testing with a physical
>> loopback (RxD connected to TxD) in this USB2Serial adapter
>> https://www.sparkfun.com/products/718.
>>
>> Problem 1 [Ring bufffer?]:
>>   s = serial (); # 8-N-1
>>   srl_baudrate (s,9600);
>>
>>   srl_write(s,"hello")
>>   ans = 5
>>
>>   char(srl_read (s,5))
>>   ans = hello
>>
>>   char(srl_read (s,5))
>>   ans = hello
>>
>>   char(srl_read (s,15))
>>   ans = hellohellohello
>>
>>   char(srl_read (s,4))
>>   ans = hell
>>
>>   char(srl_read (s,6))
>>   ans = ohello
>>
>> It looks like as if the buffer is a ring buffer or is really big and
>> filled with "hello". Maybe flushing the input after reading will solve
>> the problem? Continued from the example before I got this
>>
>> Problem 2 [Hang after flush]:
>>   srl_flush (s, 1)
>>
>>   char(srl_read (s,5)) # This blocks as expected but ...
>>   srl_read: Interrupting...
>>   ans =
>>
>>   srl_write(s,"hello")
>>   ans =  5
>>
>>   char(srl_read (s,5)) # This also blocks!!!!
>>   srl_read: Interrupting...
>>   ans =
>>
>> The only way of getting things to work from this point on is to close
>> the port and open it again.
>>
>> Can anybody reproduce this? any suggestions of tests to run to see
>> whether the problem is at hardware level?
>>
>> I also tested with a virtual loopback (command "socat -d -d PTY:
>> PTY:", this is simpler than the suggestion in the wiki. I can update
>> that), I do not observe Problem 1, but I can't interrupt the second
>> call to srl_read
>>
>> s = serial("/dev/ptmx", 9600);
>> srl_write(s,"hello")
>> ans =  5
>> char(srl_read (s,5))
>> ans = hello
>> octave:5> char(srl_read (s,5))
>> srl_read: Interrupting...
>> srl_read: Interrupting...
>> srl_read: Interrupting...
>> srl_read: Interrupting...
>>
>>
>> Thanks
>
> Testing in Debian Squeeze 2.6.32-5-686 with the same hardware
> configuration doesn't show Problem 1
> Note that:
>
> - Ubuntu 12.04 uses kernel 3.2.0 and the driver controlling the adapter is
> ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
>
> - Debian Squeeze uses kernel 2.6.32 and
> ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver
>
>
> In Debian the problem observed is the following (opening the port the
> same as before)
>> srl_write(s,uint8(127)); srl_read(s,1)
> ans = 127
>> srl_write(s,uint8(128)); srl_read(s,1)
> ans = 0
>
> Should it go up to 255?

Additional update.

Checking the code of srl_write.cc and srl_read.cc I noticed that while
srl_write writes "unsigned char" srl_read reads "char". Is this
intentional?

Additionally there is a C style cast in srl_write line 63. I assume it
should be a static cast and therefore it should be

buf[i] = static_cast<unsigned char>(data(i));

Or is there a reason why to do it the C way?

Re: [OctDev] [instrument-control]

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

On Thu, Oct 18, 2012 at 12:31 AM, Juan Pablo Carbajal
<aju...@gm...> wrote:
> Hello,
>
> I am observing weird behaviors and I couldn't pin down at which level
> things are going bad. Using instrument-control 0.1.0 from Forge.
> Running Ubuntu 12.04 64 bit
> Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> I am using serial communications. I am testing with a physical
> loopback (RxD connected to TxD) in this USB2Serial adapter
> https://www.sparkfun.com/products/718.
>
> Problem 1 [Ring bufffer?]:
>   s = serial (); # 8-N-1
>   srl_baudrate (s,9600);
>
>   srl_write(s,"hello")
>   ans = 5
>
>   char(srl_read (s,5))
>   ans = hello
>
>   char(srl_read (s,5))
>   ans = hello
>
>   char(srl_read (s,15))
>   ans = hellohellohello
>
>   char(srl_read (s,4))
>   ans = hell
>
>   char(srl_read (s,6))
>   ans = ohello
>
> It looks like as if the buffer is a ring buffer or is really big and
> filled with "hello". Maybe flushing the input after reading will solve
> the problem? Continued from the example before I got this
>
> Problem 2 [Hang after flush]:
>   srl_flush (s, 1)
>
>   char(srl_read (s,5)) # This blocks as expected but ...
>   srl_read: Interrupting...
>   ans =
>
>   srl_write(s,"hello")
>   ans =  5
>
>   char(srl_read (s,5)) # This also blocks!!!!
>   srl_read: Interrupting...
>   ans =
>
> The only way of getting things to work from this point on is to close
> the port and open it again.
>
> Can anybody reproduce this? any suggestions of tests to run to see
> whether the problem is at hardware level?
>
> I also tested with a virtual loopback (command "socat -d -d PTY:
> PTY:", this is simpler than the suggestion in the wiki. I can update
> that), I do not observe Problem 1, but I can't interrupt the second
> call to srl_read
>
> s = serial("/dev/ptmx", 9600);
> srl_write(s,"hello")
> ans =  5
> char(srl_read (s,5))
> ans = hello
> octave:5> char(srl_read (s,5))
> srl_read: Interrupting...
> srl_read: Interrupting...
> srl_read: Interrupting...
> srl_read: Interrupting...
>
>
> Thanks

Testing in Debian Squeeze 2.6.32-5-686 with the same hardware
configuration doesn't show Problem 1
Note that:

- Ubuntu 12.04 uses kernel 3.2.0 and the driver controlling the adapter is
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

- Debian Squeeze uses kernel 2.6.32 and
ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver


In Debian the problem observed is the following (opening the port the
same as before)
> srl_write(s,uint8(127)); srl_read(s,1)
ans = 127
> srl_write(s,uint8(128)); srl_read(s,1)
ans = 0

Should it go up to 255?

[OctDev] [instrument-control]

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

Hello,

I am observing weird behaviors and I couldn't pin down at which level
things are going bad. Using instrument-control 0.1.0 from Forge.
Running Ubuntu 12.04 64 bit
Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

I am using serial communications. I am testing with a physical
loopback (RxD connected to TxD) in this USB2Serial adapter
https://www.sparkfun.com/products/718.

Problem 1 [Ring bufffer?]:
  s = serial (); # 8-N-1
  srl_baudrate (s,9600);

  srl_write(s,"hello")
  ans = 5

  char(srl_read (s,5))
  ans = hello

  char(srl_read (s,5))
  ans = hello

  char(srl_read (s,15))
  ans = hellohellohello

  char(srl_read (s,4))
  ans = hell

  char(srl_read (s,6))
  ans = ohello

It looks like as if the buffer is a ring buffer or is really big and
filled with "hello". Maybe flushing the input after reading will solve
the problem? Continued from the example before I got this

Problem 2 [Hang after flush]:
  srl_flush (s, 1)

  char(srl_read (s,5)) # This blocks as expected but ...
  srl_read: Interrupting...
  ans =

  srl_write(s,"hello")
  ans =  5

  char(srl_read (s,5)) # This also blocks!!!!
  srl_read: Interrupting...
  ans =

The only way of getting things to work from this point on is to close
the port and open it again.

Can anybody reproduce this? any suggestions of tests to run to see
whether the problem is at hardware level?

I also tested with a virtual loopback (command "socat -d -d PTY:
PTY:", this is simpler than the suggestion in the wiki. I can update
that), I do not observe Problem 1, but I can't interrupt the second
call to srl_read

s = serial("/dev/ptmx", 9600);
srl_write(s,"hello")
ans =  5
char(srl_read (s,5))
ans = hello
octave:5> char(srl_read (s,5))
srl_read: Interrupting...
srl_read: Interrupting...
srl_read: Interrupting...
srl_read: Interrupting...


Thanks

Re: [OctDev] Using leasqr to fit experimental data. Question about weighing

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

On Wed, Oct 17, 2012 at 03:20:30PM +0200, Timo Bretten wrote:
> Thanks Olaf,
> you are of course right. It was late yesterday and I didn't take
> enough time to actually think before asking.
> 
> Maybe I wasn't clear in the discription of my problem. The absolute
> error is the same for every data-point, i.e. I measure voltages
> something like 0.10 +/- 0.05 V, the +/-0.05 stays the same for each
> x-y pair (this is waht I called "noize" in my initial eMail).
> In the tail of the exponential, the voltages I measure are small, like
> 0.06 +/- 0.05 V and thus have a much greater relative error associated
> with them.

Actually I wouldn't take the greater _relative_ variance as a reason
to assign different weights.

> In my fit, I want those low, tail voltage values to be weighted less
> strongly. Actuallly the weight w_i for data point y_i should be equal
> to (y_i / noize)^2, so can I just use wt=ones(size(y)).*(y/noize).^2 ?

The choice of weights is outside the scope of this optimization
algorithm. Other weights than suggested in the help of leasqr can be
reasonable (but I don't see this in your case, as I said). Only the
reasonable computation of some additional statistics (corp, covp,
covr, Z) depends on the specification of weights as suggested in the
help text.

I consider nonlin_residmin (or nonlin_curvefit) as preferable to
leasqr (while their default backend algorithm is identical to that of
leasqr). They delegate the computation of statistics into an extra
function (residmin_stat) and so do not mention any restriction on the
weights in their help text.

Olaf

> Thanks once more,
> Timo

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

Re: [OctDev] Using leasqr to fit experimental data. Question about weighing

[Timo B. <t.b...@gm...>]

Thanks Olaf,
you are of course right. It was late yesterday and I didn't take
enough time to actually think before asking.

Maybe I wasn't clear in the discription of my problem. The absolute
error is the same for every data-point, i.e. I measure voltages
something like 0.10 +/- 0.05 V, the +/-0.05 stays the same for each
x-y pair (this is waht I called "noize" in my initial eMail).
In the tail of the exponential, the voltages I measure are small, like
0.06 +/- 0.05 V and thus have a much greater relative error associated
with them.
In my fit, I want those low, tail voltage values to be weighted less
strongly. Actuallly the weight w_i for data point y_i should be equal
to (y_i / noize)^2, so can I just use wt=ones(size(y)).*(y/noize).^2 ?

Thanks once more,
Timo

2012/10/17 Olaf Till <i7...@t-...>:
> On Wed, Oct 17, 2012 at 12:23:12AM +0200, Timo Bretten wrote:
>> That works indeed, cheers Nir!
>> I was confused because by default, wt is set to ones(size(y)) ... also
>
> ones(size(y)) have the same dimensions as y
>
>> from the documentation - which kind of clashed with the initial
>> statement, that wt should be of the same dimension as y ...
>
> so there should be no clash of these statements.
>
>> Anyways, thanks for the quick reply, I consider my problem fixed.
>
> But for the record, you do not need to specify weights if they are
> constant.
>
> Olaf

Re: [OctDev] Using leasqr to fit experimental data. Question about weighing

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

On Wed, Oct 17, 2012 at 12:23:12AM +0200, Timo Bretten wrote:
> That works indeed, cheers Nir!
> I was confused because by default, wt is set to ones(size(y)) ... also

ones(size(y)) have the same dimensions as y

> from the documentation - which kind of clashed with the initial
> statement, that wt should be of the same dimension as y ...

so there should be no clash of these statements.

> Anyways, thanks for the quick reply, I consider my problem fixed.

But for the record, you do not need to specify weights if they are
constant.

Olaf
 
> Timo
> 
> 2012/10/17 Nir Krakauer <nkr...@cc...>:
> > Hi Timo,
> >
> > As far as I can tell from the documentation (
> > http://octave.sourceforge.net/optim/function/leasqr.html ), wt is an N*1
> > vector. If your estimated error standard deviation is constant and equal to
> > noize, you would set wt = ones(n, 1) / noize
> >
> > Nir
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

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

Re: [OctDev] no more combinatorics and physical-constants package

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

* c. <car...@gm...> [2012-10-17 09:23]:
>
> On 16 Oct 2012, at 02:21, Carnë Draug wrote:
>
>> I have removed the combinatorics and physical-constants packages.
>>
>> They had been moved into the miscellaneous package some months ago and 
>> since a new release of it was made, I have also released these two as 
>> well. They are empty packages, only have a dummy file and are 
>> dependent on the new version of miscellaneous just to ease transition.
>
> I do agree with the move of physical_constant into the miscellaneous package 
> as it reduces the total number of packages.

Another obvious candidate for removal is the special-matrix package, 
which contains currently only two files (arecibo.m and lauchli.m). They 
could also be moved into miscellaneous.

Rafael

Re: [OctDev] no more combinatorics and physical-constants package

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

On 17 Oct 2012, at 13:01, Carnë Draug wrote:

>> Carnë,
>> 
>> I do agree with the move of physical_constant into the miscellaneous package
>> as it reduces the total number of packages.
>> Was it really necessary, though, to change the names of all the constants?
>> This breaks all existing code using "physical_constant" (and I have a lot of that around),
>> would you mind if check-in a patch to allow using both the new and the old format for the names?
>> It would also have been nice if this change was mentioned somewhere, for example in the "news".
> 
> Sorry, I forgot to mention this on the file. The reason for the name
> change was that the previous code actually had a bug and when there
> was more than one constant (for different temperature or pressure
> conditions), only the last on the list would be used. If you commit a
> change, do it on the python script that generates the whole function
> file.
> 
> Carnë

OK, I'll try to do so.
c.

Re: [OctDev] no more combinatorics and physical-constants package

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

On 17 October 2012 09:23, c. <car...@gm...> wrote:
>
> On 16 Oct 2012, at 02:21, Carnë Draug wrote:
>
>> Hi everyone
>>
>> I have removed the combinatorics and physical-constants packages.
>>
>> They had been moved into the miscellaneous package some months ago and
>> since a new release of it was made, I have also released these two as
>> well. They are empty packages, only have a dummy file and are
>> dependent on the new version of miscellaneous just to ease transition.
>>
>> Carnë
>>
>
> Carnë,
>
> I do agree with the move of physical_constant into the miscellaneous package
> as it reduces the total number of packages.
> Was it really necessary, though, to change the names of all the constants?
> This breaks all existing code using "physical_constant" (and I have a lot of that around),
> would you mind if check-in a patch to allow using both the new and the old format for the names?
> It would also have been nice if this change was mentioned somewhere, for example in the "news".

Sorry, I forgot to mention this on the file. The reason for the name
change was that the previous code actually had a bug and when there
was more than one constant (for different temperature or pressure
conditions), only the last on the list would be used. If you commit a
change, do it on the python script that generates the whole function
file.

Carnë

Re: [OctDev] no more combinatorics and physical-constants package

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

On 16 Oct 2012, at 02:21, Carnë Draug wrote:

> Hi everyone
> 
> I have removed the combinatorics and physical-constants packages.
> 
> They had been moved into the miscellaneous package some months ago and
> since a new release of it was made, I have also released these two as
> well. They are empty packages, only have a dummy file and are
> dependent on the new version of miscellaneous just to ease transition.
> 
> Carnë
> 

Carnë,

I do agree with the move of physical_constant into the miscellaneous package
as it reduces the total number of packages.
Was it really necessary, though, to change the names of all the constants?
This breaks all existing code using "physical_constant" (and I have a lot of that around), 
would you mind if check-in a patch to allow using both the new and the old format for the names?
It would also have been nice if this change was mentioned somewhere, for example in the "news". 

c.

Re: [OctDev] Using leasqr to fit experimental data. Question about weighing

[Timo B. <t.b...@gm...>]

That works indeed, cheers Nir!
I was confused because by default, wt is set to ones(size(y)) ... also
from the documentation - which kind of clashed with the initial
statement, that wt should be of the same dimension as y ...

Anyways, thanks for the quick reply, I consider my problem fixed.

Timo

2012/10/17 Nir Krakauer <nkr...@cc...>:
> Hi Timo,
>
> As far as I can tell from the documentation (
> http://octave.sourceforge.net/optim/function/leasqr.html ), wt is an N*1
> vector. If your estimated error standard deviation is constant and equal to
> noize, you would set wt = ones(n, 1) / noize
>
> Nir

Re: [OctDev] Using leasqr to fit experimental data. Question about weighing

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

Hi Timo,

As far as I can tell from the documentation (
http://octave.sourceforge.net/optim/function/leasqr.html ), wt is an N*1
vector. If your estimated error standard deviation is constant and equal to
noize, you would set wt = ones(n, 1) / noize

Nir

[OctDev] Using leasqr to fit experimental data. Question about weighing

[Timo B. <t.b...@gm...>]

Hey guys & girls,

I found a script on the net that uses leasqr to fit experimental data
to a function and adapted it to my needs. Works like a charm =)

I do still have some trouble with understanding/using the weighing
properly and hoped maybe someone could help me out.
Here is my situation:
I have experimental x-y data, the process is roughly an exponential
decay. As always with real life data, its noisy and especially in the
tail of the exponential, the noise is a problem. I know the absolute
size of noise, let's call this number "noize". What I am used to doing
in experimental data fitting is to take the weighing factor for each
y-point as the inverse of its relative error, i.e. noize/yvalue.
But the "wt" used in leasqr has to be an N*N-matrix, where N is the
number of y-values ... I am a bit confused as to how I would construct
the proper wt-matrix for the problem at hand.

Help would be much appreciated,
thanks in advance,
Timo

Re: [OctDev] extra colormaps: OF or core?

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

On Tue, Oct 16, 2012 at 9:04 PM, Juan Pablo Carbajal
<aju...@gm...> wrote:
> Hi all,
>
> Not long ago we received a GPL version of the toolbox real2rgb[1]. My
> question is whether to add this as an OF package/module or directly
> into scripts/image in core.
>
> real2rgb extends the functionality of colormaps by making them accept
> Inf as the length argument (it will fail in the current colormaps).
> This option makes the colormpa return the "concise description", i.e.
> the minimum information needed to recreate a colormap of any length
> (the data points of the interpolation if you wish). It also provides a
> function to "deform" the colormaps according to color-bin sizes (this
> allows nonlinear scaling of colormaps).
>
> Should I continue with the orginial idea of making all this a new OF
> package/module or shall I work to put this into core?
>
> Thank you very much
>
> [1] http://www.mathworks.com/matlabcentral/fileexchange/23342-real2rgb-colormaps

btw, Oliver Woodford is happy to send us any of his packages under
GPL, we just need to let him know.

He has this other one that looks interesting (note the "Matlab's nasty
discretization artifacts" do we have them too?)
http://www.mathworks.com/matlabcentral/fileexchange/16233-sc-powerful-image-rendering

In his page you can see more
http://www.robots.ox.ac.uk/~ojw/software.htm

Cheers

[OctDev] extra colormaps: OF or core?

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

Hi all,

Not long ago we received a GPL version of the toolbox real2rgb[1]. My
question is whether to add this as an OF package/module or directly
into scripts/image in core.

real2rgb extends the functionality of colormaps by making them accept
Inf as the length argument (it will fail in the current colormaps).
This option makes the colormpa return the "concise description", i.e.
the minimum information needed to recreate a colormap of any length
(the data points of the interpolation if you wish). It also provides a
function to "deform" the colormaps according to color-bin sizes (this
allows nonlinear scaling of colormaps).

Should I continue with the orginial idea of making all this a new OF
package/module or shall I work to put this into core?

Thank you very much

[1] http://www.mathworks.com/matlabcentral/fileexchange/23342-real2rgb-colormaps

Re: [OctDev] OctaveForge for project of the month

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

Sarcasm's not going to help us :) But Sergei, if you would like to
improve the interface or code, you're very welcome to contribute.

Re: [OctDev] OctaveForge for project of the month

[Isak D. D. <isa...@gm...>]

On 16 October 2012 12:00, Søren Hauberg <so...@ha...> wrote:

>
> On Oct 16, 2012, at 11:32 AM, Sergei Steshenko wrote:
> > Here are the reasons:
> >
> > 1) visit http://octave.sourceforge.net/functions_by_package.php and
> _patiently_ scroll down;
> > 2) if you are patient enough, you'll notice that the text left margin
> moves to the right, i.e. at the top the text is left-justified as it should
> be, bu then the text moves to the right;
> > 3) when I was taught by various people how to develop and test the code,
> I was explained that number of test cases is typically (quite) big, but at
> least _obvious_ corner cases should be tested, and the number of obvious
> corner cases is typically _much_ less than the full number of test cases;
> > 4) in this particular instance there are just _two_ corner cases: top
> and bottom, and the developers didn't bother to check even them.
> >
> > So, because of _gross_ disrespect for very basic QA guidelines on the
> side of the developers I am fully opposed to nominating this project for
> "project of the month".
>
> Sergei,
>
> as the author of the code in question I do apologize: I am truly sorry
> that I forced you into using code that I developed in my (non-existing)
> spare-time. I really did not mean to force you to depend on this code.
> Please forgive me! I promise I will never ever release any code code that
> you could be interested in using, such that you shall never be forced to
> use my terrible code again. Please accept my apology for making something
> that serves a practical purpose, yet is imperfect. I shall never be
> practical again!
>
> Yours truly,
> Søren
> _______________________________________________
> Help-octave mailing list
> Hel...@oc...
> https://mailman.cae.wisc.edu/listinfo/help-octave
>


> I will never ever release any code that you could be interested in using

*No, disagreed. We do not have to code in a way that satisfies me or the
guy in the next office or Sergei (for that matter)--- do we have do?*

Re: [OctDev] OctaveForge for project of the month

[Søren H. <so...@ha...>]

On Oct 16, 2012, at 11:52 AM, Paul Dreik wrote:

> Well,
> I do not think a minor webpage layout issue disqualifies a project from
> being selected as project of the month. The text is still in order and
> searchable.

Well, the mighty Sergei is always right about everything (after all, he has at some point had a real job unlike the rest of us idiot teenagers)… :-) 

> Can you suggest a fix for the web page? I do not know how the list is
> generated, but maybe you can spot a css error or something.

In the specific case, the problem as that text is not being escaped correctly. The problem happens when the first line of a help text contains "<" or ">". In practice this happens when the first line contains an e-mail address, e.g.  "Author <myname@myspace>".

Søren


> Paul
> 
> 2012-10-16 11:32, Sergei Steshenko skrev:
>> 
>> 
>> ----- Original Message -----
>> 
>>> From: Carnë Draug <car...@gm...>
>>> To: Octave Help <hel...@oc...>; Octave Forge <oct...@li...>
>>> Cc: 
>>> Sent: Tuesday, October 16, 2012 2:52 AM
>>> Subject: OctaveForge for project of the month
>>> 
>>> Hi everyone
>>> 
>>> SourceForge has a "project of the month" voting pool going on which
>>> includes OctaveForge. If you guys want to vote, the link for the post
>>> and pool are
>>> 
>>> http://sourceforge.net/blog/potm-vote-201211/
>>> http://twtpoll.com/vvntro
>>> 
>>> Note 1: it requires a twitter account (it sucks, I already complained)
>>> Note 2: Octave Forge is listed as GNU Octave repository. I have also
>>> complained about this and they have fixed it on their blog. However
>>> they could not change the name on the voting after it started (the
>>> name is incorrect because the description of the project on
>>> SourceForge was also incorrect. That has already been fixed).
>>> 
>>> Carnë
>>> _______________________________________________
>>> Help-octave mailing list
>>> Hel...@oc...
>>> https://mailman.cae.wisc.edu/listinfo/help-octave
>>> 
>> 
>> Absolutely and definitely _____no_____.
>> 
>> I.e. I am wholeheartedly _against_.
>> 
>> Here are the reasons:
>> 
>> 1) visit http://octave.sourceforge.net/functions_by_package.php and _patiently_ scroll down;
>> 2) if you are patient enough, you'll notice that the text left margin moves to the right, i.e. at the top the text is left-justified as it should be, bu then the text moves to the right;
>> 3) when I was taught by various people how to develop and test the code, I was explained that number of test cases is typically (quite) big, but at least _obvious_ corner cases should be tested, and the number of obvious corner cases is typically _much_ less than the full number of test cases;
>> 4) in this particular instance there are just _two_ corner cases: top and bottom, and the developers didn't bother to check even them.
>> 
>> So, because of _gross_ disrespect for very basic QA guidelines on the side of the developers I am fully opposed to nominating this project for "project of the month".
>> 
>> 
>> Regards,
>>  Sergei.
>> 
>> P.S. Kindergarten .....
>> 
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> Octave-dev mailing list
>> Oct...@li...
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] OctaveForge for project of the month

[Søren H. <so...@ha...>]

On Oct 16, 2012, at 11:32 AM, Sergei Steshenko wrote:
> Here are the reasons:
> 
> 1) visit http://octave.sourceforge.net/functions_by_package.php and _patiently_ scroll down;
> 2) if you are patient enough, you'll notice that the text left margin moves to the right, i.e. at the top the text is left-justified as it should be, bu then the text moves to the right;
> 3) when I was taught by various people how to develop and test the code, I was explained that number of test cases is typically (quite) big, but at least _obvious_ corner cases should be tested, and the number of obvious corner cases is typically _much_ less than the full number of test cases;
> 4) in this particular instance there are just _two_ corner cases: top and bottom, and the developers didn't bother to check even them.
> 
> So, because of _gross_ disrespect for very basic QA guidelines on the side of the developers I am fully opposed to nominating this project for "project of the month".

Sergei,

as the author of the code in question I do apologize: I am truly sorry that I forced you into using code that I developed in my (non-existing) spare-time. I really did not mean to force you to depend on this code. Please forgive me! I promise I will never ever release any code code that you could be interested in using, such that you shall never be forced to use my terrible code again. Please accept my apology for making something that serves a practical purpose, yet is imperfect. I shall never be practical again!

Yours truly,
Søren

Re: [OctDev] OctaveForge for project of the month

[Paul D. <sl...@pa...>]

Well,
I do not think a minor webpage layout issue disqualifies a project from
being selected as project of the month. The text is still in order and
searchable.

Can you suggest a fix for the web page? I do not know how the list is
generated, but maybe you can spot a css error or something.

Paul

2012-10-16 11:32, Sergei Steshenko skrev:
> 
> 
> ----- Original Message -----
> 
>> From: Carnë Draug <car...@gm...>
>> To: Octave Help <hel...@oc...>; Octave Forge <oct...@li...>
>> Cc: 
>> Sent: Tuesday, October 16, 2012 2:52 AM
>> Subject: OctaveForge for project of the month
>>
>> Hi everyone
>>
>> SourceForge has a "project of the month" voting pool going on which
>> includes OctaveForge. If you guys want to vote, the link for the post
>> and pool are
>>
>> http://sourceforge.net/blog/potm-vote-201211/
>> http://twtpoll.com/vvntro
>>
>> Note 1: it requires a twitter account (it sucks, I already complained)
>> Note 2: Octave Forge is listed as GNU Octave repository. I have also
>> complained about this and they have fixed it on their blog. However
>> they could not change the name on the voting after it started (the
>> name is incorrect because the description of the project on
>> SourceForge was also incorrect. That has already been fixed).
>>
>> Carnë
>> _______________________________________________
>> Help-octave mailing list
>> Hel...@oc...
>> https://mailman.cae.wisc.edu/listinfo/help-octave
>>
> 
> Absolutely and definitely _____no_____.
> 
> I.e. I am wholeheartedly _against_.
> 
> Here are the reasons:
> 
> 1) visit http://octave.sourceforge.net/functions_by_package.php and _patiently_ scroll down;
> 2) if you are patient enough, you'll notice that the text left margin moves to the right, i.e. at the top the text is left-justified as it should be, bu then the text moves to the right;
> 3) when I was taught by various people how to develop and test the code, I was explained that number of test cases is typically (quite) big, but at least _obvious_ corner cases should be tested, and the number of obvious corner cases is typically _much_ less than the full number of test cases;
> 4) in this particular instance there are just _two_ corner cases: top and bottom, and the developers didn't bother to check even them.
> 
> So, because of _gross_ disrespect for very basic QA guidelines on the side of the developers I am fully opposed to nominating this project for "project of the month".
> 
> 
> Regards,
>   Sergei.
> 
> P.S. Kindergarten .....
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
> 

Re: [OctDev] OctaveForge for project of the month

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

----- Original Message -----

> From: Carnë Draug <car...@gm...>
> To: Octave Help <hel...@oc...>; Octave Forge <oct...@li...>
> Cc: 
> Sent: Tuesday, October 16, 2012 2:52 AM
> Subject: OctaveForge for project of the month
> 
> Hi everyone
> 
> SourceForge has a "project of the month" voting pool going on which
> includes OctaveForge. If you guys want to vote, the link for the post
> and pool are
> 
> http://sourceforge.net/blog/potm-vote-201211/
> http://twtpoll.com/vvntro
> 
> Note 1: it requires a twitter account (it sucks, I already complained)
> Note 2: Octave Forge is listed as GNU Octave repository. I have also
> complained about this and they have fixed it on their blog. However
> they could not change the name on the voting after it started (the
> name is incorrect because the description of the project on
> SourceForge was also incorrect. That has already been fixed).
> 
> Carnë
> _______________________________________________
> Help-octave mailing list
> Hel...@oc...
> https://mailman.cae.wisc.edu/listinfo/help-octave
>

Absolutely and definitely _____no_____.

I.e. I am wholeheartedly _against_.

Here are the reasons:

1) visit http://octave.sourceforge.net/functions_by_package.php and _patiently_ scroll down;
2) if you are patient enough, you'll notice that the text left margin moves to the right, i.e. at the top the text is left-justified as it should be, bu then the text moves to the right;
3) when I was taught by various people how to develop and test the code, I was explained that number of test cases is typically (quite) big, but at least _obvious_ corner cases should be tested, and the number of obvious corner cases is typically _much_ less than the full number of test cases;
4) in this particular instance there are just _two_ corner cases: top and bottom, and the developers didn't bother to check even them.

So, because of _gross_ disrespect for very basic QA guidelines on the side of the developers I am fully opposed to nominating this project for "project of the month".


Regards,
  Sergei.

P.S. Kindergarten .....

[OctDev] OctaveForge for project of the month

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

Hi everyone

SourceForge has a "project of the month" voting pool going on which
includes OctaveForge. If you guys want to vote, the link for the post
and pool are

http://sourceforge.net/blog/potm-vote-201211/
http://twtpoll.com/vvntro

Note 1: it requires a twitter account (it sucks, I already complained)
Note 2: Octave Forge is listed as GNU Octave repository. I have also
complained about this and they have fixed it on their blog. However
they could not change the name on the voting after it started (the
name is incorrect because the description of the project on
SourceForge was also incorrect. That has already been fixed).

Carnë

[OctDev] no more combinatorics and physical-constants package

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

Hi everyone

I have removed the combinatorics and physical-constants packages.

They had been moved into the miscellaneous package some months ago and
since a new release of it was made, I have also released these two as
well. They are empty packages, only have a dummy file and are
dependent on the new version of miscellaneous just to ease transition.

Carnë

[OctDev] miscellaneous 1.2.0 released

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

Hi everyone

a new release of the miscellaneous package is out, version 1.2.0, by
Carnë Draug. Among other changes, this version incorporates the
combinatorics and physical-constants packages which have now been
removed.

Enjoy Octave responsibly.

Carnë

Re: [OctDev] Broken link on OF website

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

On 15 October 2012 22:22, Philip Nienhuis <pr....@hc...> wrote:
> Hi there,
>
> c. wrote:
>  > The "SVN" link in the navigation bar on all Octave-forge points to:
>  >
>  > http://sourceforge.net/svn/?group_id=2888
>  >
>  > the correct link has now changed to
>  >
>  > https://sourceforge.net/p/octave/code
>
> Right, but to what URL should I point my TortoiseSVN client to be able
> to commit changes?
>
> I used to be able to commit changed files directly to the individual
> package directories at
> https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/main/io
>
> Currently I only get:
> "Unable to connect to a repository at URL
> 'https://sourceforge.net/p/octave/code/11246/tree/trunk/octave-forge/main/io'
> Repository moved temporarily to
> 'http://sourceforge.net/p/octave/code/11246/tree/trunk/octave-forge/main/io';
> please relocate"
>
> I've "relocated" (changed URL) quite a bit but no luck.
>
> Thanks,
>
> Philip

Hi Philip

you may need to reclone the repository. See
http://octave.1599824.n4.nabble.com/very-important-all-developers-reclone-Octave-Forge-td4644503.html

When you go to https://sourceforge.net/p/octave/code/ there should
appear a text box with the command you can use to make a new clone
(seems nabble hides part of the command because of the e-mail
address).

Carnë