Mercurial > octave-nkf
changeset 14678:9fa8955ea79d gui
maint: Periodic merge of default to gui
| author | Jordi Gutiérrez Hermoso <jordigh@octave.org> |
|---|---|
| date | Wed, 23 May 2012 16:20:29 -0400 |
| parents | 2fb96afd7b34 (current diff) 757f729fd41d (diff) |
| children | 628eeaf879f7 |
| files | etc/README.devel etc/README.ftp etc/README.mirrors etc/README.snapshots |
| diffstat | 11 files changed, 46 insertions(+), 306 deletions(-) [+] |
line wrap: on
line diff
--- a/etc/README.devel Wed May 23 21:07:57 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,82 +0,0 @@ -This directory contains development releases of Octave. - -If you want a stable, well-tested version of Octave, you should be -looking at ftp://ftp.gnu.org/gnu/octave. - -Development releases are provided for people who want to help test, -debug, and improve Octave. Very little testing is done before making -the development releases and they may even be made when Octave is in -an inconsistent state. It is possible that you will encounter a -very obvious bug, such as a failure to compile on *any* machine. It is -likely that such bugs will be fixed by the next development release, -so it really isn't necessary to report them unless they persist over -more than one release. - -Please DO report other bugs in the development releases as soon as you -find them. Bugs should be reported to the bug tracker at -'http://bugs.octave.org'. Please read read the bug reporting -guidelines (http://www.gnu.org/software/octave/bugs.html) before -submitting an item. - -If you have a fix for a bug, or an enhancement to submit, send your -patch to maintainers@octave.org or submit it to the patch -tracker at 'http://savannah.gnu.org/patch/?group=octave'. - -By adhering to the following guidelines you can minimize the work that -Octave maintainers need to do to apply your patch. Maintaining Octave -is a lot of work in the best of circumstances, and we can't keep up -unless you do your best to help. - - * Send an explanation with your changes of what problem they fix or - what improvement they bring about. For a bug fix, just include a - copy of the bug report, and explain why the change fixes the bug. - - * Always include a proper bug report for the problem you think you - have fixed. We need to convince ourselves that the change is - right before installing it. Even if it is right, we might have - trouble judging it if we don't have a way to reproduce the problem. - - * Include all the comments that are appropriate to help people - reading the source in the future understand why this change was - needed. - - * Don't mix together changes made for different reasons. Send them - _individually_. - - If you make two changes for separate reasons, then we might not - want to install them both. We might want to install just one. - - * Use `diff -c' to make your diffs. Diffs without context are hard - for us to install reliably. More than that, they make it hard for - us to study the diffs to decide whether we want to install them. - Unified diff format is better than contextless diffs, but not as - easy to read as `-c' format. - - If you have GNU diff, use `diff -cp', which shows the name of the - function that each change occurs in. - - * Write the change log entries for your changes. - - Read the `ChangeLog' file to see what sorts of information to put - in, and to learn the style that we use. The purpose of the - change log is to show people where to find what was changed. So - you need to be specific about what functions you changed; in - large functions, it's often helpful to indicate where within the - function the change was made. - - On the other hand, once you have shown people where to find the - change, you need not explain its purpose. Thus, if you add a new - function, all you need to say about it is that it is new. If you - feel that the purpose needs explaining, it probably does--but the - explanation will be much more useful if you put it in comments in - the code. - - If you would like your name to appear in the header line for who - made the change, send us the header line. - -If you would like to be on the very sharpest part of the bleeding -edge, you can now use Mercurial to access Octave's current development -sources. Instructions for checking out a copy are available on the -web at http://www.gnu.org/software/octave/download.html. - -Last updated: Sat Jan 22 21:26:18 PST 2011
--- a/etc/README.ftp Wed May 23 21:07:57 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,38 +0,0 @@ -This directory contains the source for Octave, a high-level interactive -language for solving numerical problems. See the file README for more general -information, and the file NEWS for a list of recent changes. - -Binary distributions: --------------------- - -Octave binaries are not distributed from this site. - -Packaged versions of Octave for various GNU/Linux systems are available -with the major GNU/Linux distributions (Debian, Ubuntu, Red Hat, SUSE, etc.). - -Binary distributions of Octave for Mac OS X are available from both Fink -and MacPorts. - - http://www.finkproject.com - http://www.macports.org/ - -The file README.Windows provides instructions for installing Octave on -Windows systems. - -A note about .gz files: ----------------------- - -Files with names ending in `.gz' have been compressed with `gzip'. - -Unlike the compress utility, gzip is free of any known software -patents and tends to compress better anyway. Gzip can uncompress -`compress'-compressed files too, so you can install it as "uncompress" -and use it to handle both types of files. - -The gzip program is available in the directory /pub/gnu in shar, tar, -or gzipped tar format (for those who already have a prior version of -gzip and want faster data transmission). It works on virtually every -unix system, MSDOS, OS/2, and VMS. - - -Last updated: Thu Jan 20 10:14:49 PST 2011
--- a/etc/README.mirrors Wed May 23 21:07:57 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ -If you have trouble transferring Octave from this site, you might try -one of those listed below. They mirror the /pub/octave directory on -ftp.octave.org - -FTP: - - site directory - ---- --------- - ftp.u-aizu.ac.jp /pub/SciEng/numanal/Octave - mirrors.fe.up.pt /pub/octave - -Last updated: Mon Jan 10 21:26:17 PST 2011
--- a/etc/README.snapshots Wed May 23 21:07:57 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,161 +0,0 @@ -Octave Snapshots -- general info - -Snapshots are an "image" of the main Octave development tree, captured -at a particular random instant in time. When you use the snapshots, -you should be able to maintain a local copy of Octave that is -reasonably close to the official source tree used by the Octave -maintainers. - -The primary purpose of providing snapshots is to widen the group of -motivated developers that would like to help test, debug, and enhance -Octave, by providing you with access to the "latest and greatest" -source. This has several advantages, and several disadvantages. - - First the advantages: - - o Once we have a large base of motivated testers using the - snapshots, this should provide good coverage across all - currently supported Octave hosts and targets. If a new bug is - introduced in Octave due to fixing another bug or ongoing - development, it should become obvious much more quickly and - get fixed before the next general net release. This should - help to reduce the chances of Octave being released to the - general public with a major bug that went unnoticed during the - release cycle testing because they are machine dependent. We - hope to greatly improve Octave's stability and reliability by - involving more people and more execution environments in the - prerelease testing. - - o With access to the latest source, any diffs that you send to fix - bugs or add new features should be much easier for the Octave - maintainers to merge into the official source base (after - suitable review of course). This encourages us to merge your - changes quicker, while they are still "fresh". - - o Once your diffs are merged, you can obtain a new copy of Octave - containing your changes almost immediately. Thus you do not - have to maintain local copies of your changes for any longer - than it takes to get them merged into the official source - base. This encourages you to send in changes quicker. - - And the disadvantages: - - o The snapshot you get will be largely untested and of unknown - quality. It may fail to configure or compile. It may have - serious bugs. You should always keep a copy of the last known - working version before updating to the current snapshot, or at - least be able to regenerate a working version if the latest - snapshot is unusable in your environment for some reason. - - If a production version of Octave has a bug and a snapshot has - the fix, and you care about stability, you should put only the - fix for that particular problem into your production version. - Of course, if you are eager to test Octave, you can use the - snapshot versions in your daily work, but users who have not - been consulted about whether they feel like testing Octave should - generally have something which is at least as bug free as the - last released version. - - o Providing timely response to your questions, bug reports, and - submitted patches will require the Octave developers to - allocate time from an already thin time budget. Please try to - help us make this time as productive as possible. See the - section below about how to submit changes. - - -How to get the snapshots ------------------------- - -The current plan is to provide a full snapshot every week or so. For -now, diffs from previous versions will not be available. The files -will be available via anonymous ftp from ftp.octave.org, in the -directory /private/octave in the form of a tar files compressed with -GNU gzip. You can ftp gzip from ftp.octave.org in the directory -/pub/gnu. - -Even though the snapshots are available in a public place, we ask that -recipients not widely publicize the availability of the snapshots. -The motivation for this request is not to hoard them, but to avoid the -situation where the general Octave user base naively attempts to use -the snapshots, has trouble with them, complains publicly, and the -reputation of Octave declines because of a perception of instability -or lack of quality control. - - -Octave test suite ------------------ - -A test suite is distributed as an integral part of the snapshots. -However, to use it you will need to get a copy of the dejagnu testing -framework. Snapshots of dejagnu are available alongside the Octave -snapshots, using the same naming conventions as the Octave snapshots. -Once you have installed the dejagnu framework, a simple "make check" -in the Octave directory should be sufficient to run the tests. - -Note that the test suite is still quite limited. The test framework -itself might not install on your system if you have an environment -that is not similar to one that the Octave developers already use. -The tests themselves only cover a small portion of Octave features, -and what tests do exist for a feature are not exhaustive. New tests -are welcomed. - - -Bug reports ------------ - -Send bug reports to maintainers@octave.org. - -Note that since no testing is done on the snapshots, and snapshots may -even be made when Octave is in an inconsistent state, it may not be -unusual for an occasional snapshot to have a very obvious bug, such as -failure to compile on *any* machine. It is likely that such bugs will -be fixed by the next snapshot, so it really isn't necessary to report -them unless they persist over more than one snapshot. - -Missing files should always be reported, since they usually mean there -is a problem with the snapshot-generating process and we won't know -about them unless someone tells us. - -Bugs which are non-obvious, such as failure to compile on only a -specific machine, a new machine dependent or obscure bug (particularly -one not detected by the testsuite), etc. should be reported when you -discover them, or have a suggested patch to fix them. - - -FORMAT FOR PATCHES ------------------- - -If you have a fix for a bug, or an enhancement to submit, send your -patch to maintainers@octave.org. Here are some simple guidelines for -submitting patches: - - o Use "context diffs" for patches. A typical command for - generating context diffs is "diff -rc octave-old octave-new". - - o Use the "minimalist approach" for patches. That is, each patch - should address only one particular bug, new feature, etc. Do - not save up many unrelated changes and submit them all in one - big patch, since in general, the larger the patch the more - difficult it is for us to decide if the patch is either - correct or desirable. And if we find something about the - patch that needs to be corrected before it can be installed, - we would have to reject the entire patch, which might contain - changes which otherwise would be accepted if submitted - separately. - - o Submit a sample ChangeLog entry with your patch. See the - existing Octave ChangeLog for examples of what a ChangeLog - entry should look like. The emacs command ^X4A will create a - ChangeLog entry header for you. - - -Thanks, - -John W. Eaton -jwe@octave.org - -Wed, 31 Oct 2007 16:31:54 EDT - -This file was adapted from a similar document written by Fred Fish and -used by the GDB developers. -
--- a/scripts/pkg/private/load_package_dirs.m Wed May 23 21:07:57 2012 +0200 +++ b/scripts/pkg/private/load_package_dirs.m Wed May 23 16:20:29 2012 -0400 @@ -28,6 +28,11 @@ && installed_pkgs_lst{i}.loaded) continue; else + ## Insert this package at the front before recursing over dependencies. + if (! any (idx == i)) + idx = [i, idx]; + endif + if (handle_deps) deps = installed_pkgs_lst{i}.depends; if ((length (deps) > 1) @@ -36,8 +41,10 @@ for k = 1 : length (deps) for j = 1 : length (installed_pkgs_lst) if (strcmp (installed_pkgs_lst{j}.name, deps{k}.package)) - tmplidx (end + 1) = j; - break; + if (! any (idx == j)) + tmplidx (end + 1) = j; + break; + endif endif endfor endfor @@ -45,9 +52,6 @@ installed_pkgs_lst); endif endif - if (isempty (find(idx == i))) - idx (end + 1) = i; - endif endif endfor endfunction
--- a/scripts/plot/private/__go_draw_figure__.m Wed May 23 21:07:57 2012 +0200 +++ b/scripts/plot/private/__go_draw_figure__.m Wed May 23 16:20:29 2012 -0400 @@ -44,6 +44,7 @@ else bg_is_set = false; endif + fg_was_set = false; for i = nkids:-1:1 type = get (kids(i), "type"); @@ -142,6 +143,11 @@ if (isnumeric (fg) && strcmp (get (kids(i), "visible"), "on")) fprintf (plot_stream, "set obj 2 rectangle from graph 0,0 to graph 1,1 behind fc rgb \"#%02x%02x%02x\"\n", 255 * fg); fg_is_set = true; + fg_was_set = true; + elseif (fg_was_set) + fprintf (plot_stream, "unset obj 2\n"); + fg_is_set = false; + fg_was_set = false; else fg_is_set = false; endif
--- a/scripts/sparse/spdiags.m Wed May 23 21:07:57 2012 +0200 +++ b/scripts/sparse/spdiags.m Wed May 23 16:20:29 2012 -0400 @@ -79,8 +79,8 @@ ## Create new matrix of size mxn using v,c [j, i, v] = find (v); offset = max (min (c(:), n-m), 0); - j = j + offset(i); - i = j-c(:)(i); + j = j(:) + offset(i(:)); + i = j - c(:)(i(:)); idx = i > 0 & i <= m & j > 0 & j <= n; A = sparse (i(idx), j(idx), v(idx), m, n); endif @@ -90,4 +90,4 @@ %!assert (spdiags (zeros (1,0),1,1,1), sparse (0)) %!assert (spdiags (zeros (0,1),1,1,1), sparse (0)) - +%!assert (spdiags ([0.5 -1 0.5], 0:2, 1, 1), sparse(0.5))
--- a/scripts/time/datenum.m Wed May 23 21:07:57 2012 +0200 +++ b/scripts/time/datenum.m Wed May 23 16:20:29 2012 -0400 @@ -85,6 +85,7 @@ ## Days until start of month assuming year starts March 1. persistent monthstart = [306; 337; 0; 31; 61; 92; 122; 153; 184; 214; 245; 275]; + persistent monthlength = [31; 28; 31; 30; 31; 30; 31; 31; 30; 31; 30; 31]; if (nargin == 0 || nargin > 6 || (nargin > 2 && (ischar (year) || iscellstr (year)))) @@ -110,6 +111,19 @@ month(month<1) = 1; ## For compatibility. Otherwise allow negative months. + ## Treat fractional months, by converting the fraction to days + if (floor (month) != month) + fracmonth = month - floor (month); + month = floor (month); + if ((mod (month-1,12) + 1) == 2 && + (floor (year/4) - floor (year/100) + floor (year/400)) != 0) + ## leap year + day += fracmonth * 29; + else + day += fracmonth * monthlength ((mod (month-1,12) + 1)); + endif + endif + ## Set start of year to March by moving Jan. and Feb. to previous year. ## Correct for months > 12 by moving to subsequent years. year += fix ((month-14)/12);
--- a/scripts/time/datetick.m Wed May 23 21:07:57 2012 +0200 +++ b/scripts/time/datetick.m Wed May 23 16:20:29 2012 -0400 @@ -159,7 +159,7 @@ ## Day scale or less if (xmax - xmin < N / 24 / 60 / 60) scl = 1 / 24 / 60 / 60; - elseif (xmax - xmin < N / 24 / 6) + elseif (xmax - xmin < N / 24 / 60) scl = 1 / 24 / 60; else scl = 1 / 24; @@ -186,7 +186,7 @@ elseif (maxyear - minyear < N) sep = __calc_tick_sep__ (minmonth , maxmonth); xmin = datenum (ymin, sep * floor (minmonth / sep), 1); - xmax = datenum (ymin, sep * ceil (maxmonth / sep), 1); + xmax = datenum (ymax, sep * ceil (maxmonth / sep), 1); nticks = ceil (maxmonth / sep) - floor (minmonth / sep) + 1; else sep = __calc_tick_sep__ (minyear , maxyear);
--- a/src/oct-stream.cc Wed May 23 21:07:57 2012 +0200 +++ b/src/oct-stream.cc Wed May 23 16:20:29 2012 -0400 @@ -1107,9 +1107,12 @@ case 'i': { - int c1 = is.get (); - - if (! is.eof ()) + int c1 = EOF; + + while (is && (c1 = is.get ()) != EOF && isspace (c1)) + /* skip whitespace */; + + if (c1 != EOF) { if (c1 == '0') {
--- a/test/test_io.m Wed May 23 21:07:57 2012 +0200 +++ b/test/test_io.m Wed May 23 16:20:29 2012 -0400 @@ -250,6 +250,12 @@ %!assert (sscanf (['ab'; 'cd'], '%s'), 'acbd') +%!assert (sscanf ('02:08:30', '%i:%i:%i'), [2; 0]); +%!assert (sscanf ('02:08:30', '%d:%d:%d'), [2; 8; 30]); + +%!assert (sscanf ('0177 08', '%i'), [127; 0; 8]); +%!assert (sscanf ('0177 08', '%d'), [177; 8]); + %!test %! [val, count, msg, pos] = sscanf ("3I2", "%f"); %! assert (val, 3);