On Wed, Jun 17, 2009 at 5:30 AM, Travis Collier<[email protected]> wrote:
> Sorry, I've blasted that installed version so I can't test it again.
> However, very simple commands were hanging and/or core dumping with a
> broken pipe error:
> a = parcellfun( 2, @(x) (x+1), num2cell([1 2 3]) )
>
> What was a bit odd, and took me a minute to figure out, was that if
> nproc was set at 1, everything worked fine. I don't see an obvious
> "if nproc == 1 don't bother to fork" (which would actually make a lot
> of sense to include), so I don't know what was really causing the
> difference. Sorry, no time to investigate properly.
>
Works normally for me. However, if by any chance you compile Octave
from sources (like me), updating the sources from time to time, be
aware that a package often needs to be recompiled when the binary
interface changes, and that happens (and happened recently, in fact I
needed to recompile the package just now). When using releases, you
should actually get an error message of incompatible ABI, but of
course in development sources we don't bother to increase the ABI
counter after every change.
> Basically, don't just test with nproc = 1.
>
> Attached is that VerboseLevel patch one more time. It really is
> trivial, but I guess it is a good opportunity to learn the proper way
> of contributing to a distributed development project like this.
> The other way of doing it is to have the output as warnings which can
> be switched off, but that can get complicated and annoying really
> fast.
OK, thanks. I applied this but corrected a few typos (like "child
processes %d forked" -> "child process %d forked")
and actually you pleased all who believe in Murphy's law by managing
to make a bug here:
@@ -75,12 +79,17 @@
nargs -= 2;
continue;
endif
+ if (strcmp (args{nargs-1}, "VerboseLevel"))
+ error_handler = args{nargs}; <--- BUG
+ nargs -= 2;
+ continue;
+ endif
break;
until (nargs < 2);
endif
args = args(1:nargs);
But in any case, thanks for the extension.
> PS: Any reason the output is to stderr instead of stdout? Seems like
> a bad practice... especially using the '\r' trick on stderr. I'm
> surprised that actually works, since that is more of a bug-in-waiting
> than a feature.
> I personally like setting the nominal output stream as a variable up
> front (just set to stdout 99.9% of the time).
There's a very good reason actually, and it's the fact that normally,
what's written to stdout in Octave is piped through the pager (`less'
or `more'), which is totally useless for an "animated" progress track
(hence the '\r' trick). Stderr is output directly. Admittedly, it is
still a kind of abuse, but I think it's better than temporarily
disabling the pager (which is another solution), because then you need
to be careful to restore the state. Of course, even better would be if
Octave supported a default stream like stdoutnp bypassing the pager.
'\r' works well on UNIXes since the dawn of time, and I think Windows
terminal also supports it.
regards
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
