Menu
▾
▴
octave-dev
|
From: Quentin S. <qsp...@ie...> - 2006-03-28 18:02:13
|
Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there are incompatibilities, as recently pointed out with the system function (should be fixed in CVS now), so I think we should make another release for 2.9.5+ soon. I'm willing to spend a little time doing some de-crufting, but I just wanted to ask first if there is anything I shouldn't touch. The obvious stuff is all of the Makefiles and .m.in files for things that are now in octave, but even that is incomplete (most of the stuff in the main/time directory appears to be in octave now, and there are probably more examples). I also was inclined to just remove the whole sparse directory, but I thought David said we needed to keep the superLU stuff. Any objections? -Quentin |
|
From: Bill D. <de...@se...> - 2006-03-28 19:08:58
|
Since (IIRC) the current o-f tree is supposed to be heading to 2.9.x/3.0, I'd very much like for this to happen. One other thing that I'd really like is for the functions that are going to move to octave to move (I think that there are some functions that are to be permanent o-f fixtures). I know at one point a list was made of functions that were to be moved over-- is there a current version of this list? It strikes me as something that would be good to have on the wiki. Bill On Tue, 28 Mar 2006, Quentin Spencer wrote: > Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there > are incompatibilities, as recently pointed out with the system function > (should be fixed in CVS now), so I think we should make another release > for 2.9.5+ soon. I'm willing to spend a little time doing some > de-crufting, but I just wanted to ask first if there is anything I > shouldn't touch. The obvious stuff is all of the Makefiles and .m.in > files for things that are now in octave, but even that is incomplete > (most of the stuff in the main/time directory appears to be in octave > now, and there are probably more examples). I also was inclined to just > remove the whole sparse directory, but I thought David said we needed to > keep the superLU stuff. Any objections? > > -Quentin > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > -- From Dumblaws.com: In Guelph, Ontario, Canada, the city is classified as a no-pee zone. |
|
From: Quentin S. <qsp...@ie...> - 2006-03-29 14:08:50
|
Bill Denney wrote: > Since (IIRC) the current o-f tree is supposed to be heading to > 2.9.x/3.0, I'd very much like for this to happen. One other thing > that I'd really like is for the functions that are going to move to > octave to move (I think that there are some functions that are to be > permanent o-f fixtures). > > I know at one point a list was made of functions that were to be moved > over-- is there a current version of this list? It strikes me as > something that would be good to have on the wiki. I don't think the list was updated. Seems like someone sent it to one of the octave mailing lists. I agree it would be nice to put it on the wiki and update it during the conversion process. -Quentin |
|
From: Paul K. <pki...@us...> - 2006-03-29 00:21:13
|
On Mar 28, 2006, at 1:00 PM, Quentin Spencer wrote: > Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there > are incompatibilities, as recently pointed out with the system > function (should be fixed in CVS now), so I think we should make > another release for 2.9.5+ soon. I'm willing to spend a little time > doing some de-crufting, but I just wanted to ask first if there is > anything I shouldn't touch. The obvious stuff is all of the Makefiles > and .m.in files for things that are now in octave, but even that is > incomplete (most of the stuff in the main/time directory appears to be > in octave now, and there are probably more examples). I also was > inclined to just remove the whole sparse directory, but I thought > David said we needed to keep the superLU stuff. Any objections? No objections from me. - Paul |
|
From: David B. <Dav...@mo...> - 2006-03-29 09:53:30
|
Quentin Spencer wrote:
> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there
> are incompatibilities, as recently pointed out with the system
> function (should be fixed in CVS now), so I think we should make
> another release for 2.9.5+ soon. I'm willing to spend a little time
> doing some de-crufting, but I just wanted to ask first if there is
> anything I shouldn't touch. The obvious stuff is all of the Makefiles
> and .m.in files for things that are now in octave, but even that is
> incomplete (most of the stuff in the main/time directory appears to be
> in octave now, and there are probably more examples). I also was
> inclined to just remove the whole sparse directory, but I thought
> David said we needed to keep the superLU stuff. Any objections?
>
> -Quentin
>
A lot of stuff is conditionally built, and that can be removed. Also for
the sparse stuff the iteration stuff should be kept for 2.9, but not the
rest. That is the pcg.m and pcr.m functions, but nothing else. You can
also remove the extra/test directory completely but move the pretty.cc
function somewhere else unless Paul wants to drop it. I'd also like to
eventually see the FIXES and extra/patches directories completely gone
and anything in these should either be in octave or dropped. Though we
can't do that completely until certain code is ported to octave. So
there are several files in these two directories that must be treated
before being dropped. In extra/patches these are
M-v-ops-2.1.31.patch: This allows things like rand(3).*[1:3] to make
sense and be allowed, however there is a fundamental question of whether
we want this, given the other products behavior, regardless of how
attractive this is and further more the ages of the patch means that its
more of an idea of what needs to be done rather than a working patch
against a current version of octave. If we had an issues database, this
should go there but for now keep it in o-f
octave-mod-2.1.31.patch: I'm not sure the octave emacs mode has been
updated to handle the test/assert stuff. Now that this is in octave
itself, if it doesn't it should be adapted and included in octave. I
think Paul has to make a call on this one. In any case the current patch
needs serious updating as it doesn't apply at all to the current CVS.
For FIXES, the problem files are
fsolve.cc: I've already attacked this one with the inclusion of the
function handles and inline functions. The multiple arguments accepted
by the o-f version might be easier enough to include in octave.
grid.m: This is a compatibility extension of grid.m to allow 1)
recovering the previous state with the gget function and toggling grid
state if no input arguments are used. It also supports minor tics if you
have an argument like "x#y#z#" where # is a digit. This is not
texinfo-fied, so based on a very old octave version of grid.m, it used
gget which I don't see ever going into octave as it has some possibly
nasty race conditions on temporary files. Perhaps with gnuplot 4.1
something similar might be implemented with a pipe and be accepted in
octave. So in its current implementation I don't see this code being
accepted. That being the case, the minor tick stuff might be included,
just not the probing of the existing settings.
hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed
for memory usage. The o-f versions also have the advantage that they
work for user types (eg galois fields) as they don't use zeros(m,n) to
create the initial matrix. There's a thread about this about a year ago
between Paul and myself on the maintainers list. I don't think John is
concerned about the speed issue, but the compatibility with user types
is a real problem for me. In the octave versions of tril.m and triu.m
what is currently done is
if (isa (x, "sparse"))
retval = sparse (nr, nc);
else
retval = zeros (nr, nc, class (x));
endif
however, this can't be done with the galois of fixed types, and there is
additional information that is not contained in the class. That is the
primitive polynomial, etc for galois fields. If we created a new type
for every primitive polynomial, then the number of user types would
explode, which is why its done in this manner. Thinking about it further
what I propose is to create a helper function, like
DEFUN (resize, args, ,
"-*- texinfo -*-\n\
@deftypefn {Built-in Function} {} resize (@var{x}, @var{m})\n\
@deftypefnx {Built-in Function} {} resize (@var{x}, @var{m}, @var{n})\n\
Resize @var{x} to be dimension @var{m}-by-@var{n} where @var{m}\n\
and @var{n} are scalar. If @var{n} is not supplied, then resize @var{x}\n\
to be dimension @var{m}-by-@var{m} if @var{m} is scalar, or if\n\
@var{m} is a vector, then the values of this vector respresent the\n\
dimensions of the resized matrix.\n\
@end deftypefn")
{
octave_value retval;
int nargin = args.length ();
if (nargin == 2)
{
Array<double> vec = args(1).vector_value ();
int ndim = vec.length ();
if (ndim == 1)
{
octave_idx_type m = static_cast<octave_idx_type> (vec(0));
retval = args (0). resize (dim_vector (m, m));
}
else
{
dim_vector dv (ndim);
for (int i = 0; i < ndim; i++)
{
dv(i) = static_cast<octave_idx_type> (vec(i));
retval = args (0). resize (dv);
}
}
else if (nargin == 3)
{
octave_idx_type m = args(1).scalar_value();
octave_idx_type n = args(2).scalar_value();
if (!error_state)
retval = args (0).resize (dim_vector (m, n))
}
else
print_usage (resize);
return retval;
}
which I wrote straight into the mailer and so is untested. Then
if (isa (x, "sparse"))
retval = sparse (nr, nc);
else
retval = zeros (nr, nc, class (x));
endif
can be written as
retval = resize (resize (x, 0), nr, nc);
and the o-f functions can be dropped.
rand*: These need to be included in octave, though the question of
allowing the old sequences to be generated needs to be addressed. I
believe the way to handle this is to keep the old generators in octave,
include the new ones, and if the keyword "seed" is used the old
generators will be used to maintain the old sequences for people who
force the seed of the generator, otherwise the new generators will be
used. Also the octave statistic functions should be updated to use these
functions
tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the
bug should be fixed in octave. Paul what is the reason for these?
Everything else in FIXES can be removed without question, including the
sort code, the mu2lin, lin2mu function the poly*.m functions
Cleaning up the above and getting what should be in octave sent to John
is on my TODO list, but relatively low priority :-). So if you want to
at least get rid of the stuff I marked above that would be a good start.
Regards
David
--
David Bateman Dav...@mo...
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
|
|
From: Paul K. <pki...@us...> - 2006-03-29 12:59:47
|
On Mar 29, 2006, at 4:53 AM, David Bateman wrote:
> Quentin Spencer wrote:
>
>> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there
>> are incompatibilities, as recently pointed out with the system
>> function (should be fixed in CVS now), so I think we should make
>> another release for 2.9.5+ soon. I'm willing to spend a little time
>> doing some de-crufting, but I just wanted to ask first if there is
>> anything I shouldn't touch. The obvious stuff is all of the Makefiles
>> and .m.in files for things that are now in octave, but even that is
>> incomplete (most of the stuff in the main/time directory appears to be
>> in octave now, and there are probably more examples). I also was
>> inclined to just remove the whole sparse directory, but I thought
>> David said we needed to keep the superLU stuff. Any objections?
>>
>> -Quentin
>>
> A lot of stuff is conditionally built, and that can be removed. Also
> for
> the sparse stuff the iteration stuff should be kept for 2.9, but not
> the
> rest. That is the pcg.m and pcr.m functions, but nothing else. You can
> also remove the extra/test directory completely but move the pretty.cc
> function somewhere else unless Paul wants to drop it.
Prettty was there because disp didn't return a value. I believe the
current version does and pretty is no longer needed.
> I'd also like to
> eventually see the FIXES and extra/patches directories completely gone
> and anything in these should either be in octave or dropped. Though we
> can't do that completely until certain code is ported to octave. So
> there are several files in these two directories that must be treated
> before being dropped. In extra/patches these are
>
> M-v-ops-2.1.31.patch: This allows things like rand(3).*[1:3] to make
> sense and be allowed, however there is a fundamental question of
> whether
> we want this, given the other products behavior, regardless of how
> attractive this is and further more the ages of the patch means that
> its
> more of an idea of what needs to be done rather than a working patch
> against a current version of octave. If we had an issues database, this
> should go there but for now keep it in o-f
You are correct that this patch is old and irrelevant at this point.
Also I never completed it --- I have no interest in maintaining a
fork of octave. I still believe it would be nice to write, e.g.,
(A - mean(A))./std(A)
Perhaps a better alternative is to leave matrices as they are, but
provide full numerical support for cell arrays. That would allow the
different data sets to have different lengths rather than relying on
NaN and missing data functions.
> octave-mod-2.1.31.patch: I'm not sure the octave emacs mode has been
> updated to handle the test/assert stuff. Now that this is in octave
> itself, if it doesn't it should be adapted and included in octave. I
> think Paul has to make a call on this one. In any case the current
> patch
> needs serious updating as it doesn't apply at all to the current CVS.
I've been living with the current octave-mod.
> For FIXES, the problem files are
>
> fsolve.cc: I've already attacked this one with the inclusion of the
> function handles and inline functions. The multiple arguments accepted
> by the o-f version might be easier enough to include in octave.
This has been refused in the past. I agree with John that it is
an ugly hack, and with anonymous functions supported in both Octave
and matlab, we can ask users to convert their code.
> grid.m: This is a compatibility extension of grid.m to allow 1)
> recovering the previous state with the gget function and toggling grid
> state if no input arguments are used. It also supports minor tics if
> you
> have an argument like "x#y#z#" where # is a digit. This is not
> texinfo-fied, so based on a very old octave version of grid.m, it used
> gget which I don't see ever going into octave as it has some possibly
> nasty race conditions on temporary files. Perhaps with gnuplot 4.1
> something similar might be implemented with a pipe and be accepted in
> octave. So in its current implementation I don't see this code being
> accepted. That being the case, the minor tick stuff might be included,
> just not the probing of the existing settings.
Rather than querying we could try keeping track of state on the
octave side.
The syntax for minor tics is a bit hackish and may be rejected.
> hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed
> for memory usage. The o-f versions also have the advantage that they
> work for user types (eg galois fields) as they don't use zeros(m,n) to
> create the initial matrix. There's a thread about this about a year ago
> between Paul and myself on the maintainers list. I don't think John is
> concerned about the speed issue, but the compatibility with user types
> is a real problem for me. In the octave versions of tril.m and triu.m
> what is currently done is
>
> if (isa (x, "sparse"))
> retval = sparse (nr, nc);
> else
> retval = zeros (nr, nc, class (x));
> endif
>
> however, this can't be done with the galois of fixed types, and there
> is
> additional information that is not contained in the class.
Rather than building up from zeros, can you chop down from a full
matrix. E.g., triu
for i = 1:columns(x)
x(i+1:end,i) = 0;
end
A resize function will still be needed to grow the matrix.
> rand*: These need to be included in octave, though the question of
> allowing the old sequences to be generated needs to be addressed. I
> believe the way to handle this is to keep the old generators in octave,
> include the new ones, and if the keyword "seed" is used the old
> generators will be used to maintain the old sequences for people who
> force the seed of the generator, otherwise the new generators will be
> used. Also the octave statistic functions should be updated to use
> these
> functions
Preserving the old random number generator seems crufty. Could it
be made into an external package that the few people who care
about it can download it separately?
That is not to say we shouldn't support different random
number generators. GSL supports several. However, a
"seed" vs. "state" selector seems like the wrong way to do it.
> tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the
> bug should be fixed in octave. Paul what is the reason for these?
I will have to dig through the mailing list to find the cases
where octave's functions fail.
> Everything else in FIXES can be removed without question, including the
> sort code, the mu2lin, lin2mu function the poly*.m functions
Because octave now includes these functions?
> Cleaning up the above and getting what should be in octave sent to John
> is on my TODO list, but relatively low priority :-). So if you want to
> at least get rid of the stuff I marked above that would be a good
> start.
- Paul
|
|
From: David B. <Dav...@mo...> - 2006-03-29 14:36:55
|
Paul Kienzle wrote:
>
> Prettty was there because disp didn't return a value. I believe the
> current version does and pretty is no longer needed.
>
Yes the current disp returns a string if given an output arg. So
pretty.cc goes..
>
> You are correct that this patch is old and irrelevant at this point.
> Also I never completed it --- I have no interest in maintaining a
> fork of octave. I still believe it would be nice to write, e.g.,
> (A - mean(A))./std(A)
>
> Perhaps a better alternative is to leave matrices as they are, but
> provide full numerical support for cell arrays. That would allow the
> different data sets to have different lengths rather than relying on
> NaN and missing data functions.
I think that although the patch itself is now useless due to age, the
ideas encapsulated in it should be kept somewhere for future reference.
If the PROJECTS file is converted to an issues database based then
ideally this patch would form part of that.
>
> I've been living with the current octave-mod.
So the octave-mod in extras/patches goes..
>
>> For FIXES, the problem files are
>>
>> fsolve.cc: I've already attacked this one with the inclusion of the
>> function handles and inline functions. The multiple arguments accepted
>> by the o-f version might be easier enough to include in octave.
>
>
> This has been refused in the past. I agree with John that it is
> an ugly hack, and with anonymous functions supported in both Octave
> and matlab, we can ask users to convert their code.
What I propose if just the additional arguments bits, not the anonymous
function handles and inline functions that cause all of the mess.
>
>> grid.m: This is a compatibility extension of grid.m to allow 1)
>> recovering the previous state with the gget function and toggling grid
>> state if no input arguments are used. It also supports minor tics if you
>> have an argument like "x#y#z#" where # is a digit. This is not
>> texinfo-fied, so based on a very old octave version of grid.m, it used
>> gget which I don't see ever going into octave as it has some possibly
>> nasty race conditions on temporary files. Perhaps with gnuplot 4.1
>> something similar might be implemented with a pipe and be accepted in
>> octave. So in its current implementation I don't see this code being
>> accepted. That being the case, the minor tick stuff might be included,
>> just not the probing of the existing settings.
>
>
> Rather than querying we could try keeping track of state on the
> octave side.
I suppose if there is a "PKG_ADD grid('off')" command in grid.m and a
persistent variable tracking its state this would make sense. Easy
enough to propose a patch.
>
> The syntax for minor tics is a bit hackish and may be rejected.
John what do you want to do about the minors tics in o-f's grid.m?
>
>> hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed
>> for memory usage. The o-f versions also have the advantage that they
>> work for user types (eg galois fields) as they don't use zeros(m,n) to
>> create the initial matrix. There's a thread about this about a year ago
>> between Paul and myself on the maintainers list. I don't think John is
>> concerned about the speed issue, but the compatibility with user types
>> is a real problem for me. In the octave versions of tril.m and triu.m
>> what is currently done is
>>
>> if (isa (x, "sparse"))
>> retval = sparse (nr, nc);
>> else
>> retval = zeros (nr, nc, class (x));
>> endif
>>
>> however, this can't be done with the galois of fixed types, and there is
>> additional information that is not contained in the class.
>
>
> Rather than building up from zeros, can you chop down from a full
> matrix. E.g., triu
>
> for i = 1:columns(x)
> x(i+1:end,i) = 0;
> end
Yes but which value of "0"? In the implementation of galois field the
above makes sense and there is only one field for the entire matrix.
However, for the fixed-point type it does as each element of the matrix
can have a different fixed point representation.
>
> Preserving the old random number generator seems crufty. Could it
> be made into an external package that the few people who care
> about it can download it separately?
>
John's stated he want to keep the capability to generate the same
sequences as the old generators. That being the case I don't see a way
around having both.
> That is not to say we shouldn't support different random
> number generators. GSL supports several. However, a
> "seed" vs. "state" selector seems like the wrong way to do it.
That is the way Matlab does it, so it made sense in a compatibility way.
>
>> tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the
>> bug should be fixed in octave. Paul what is the reason for these?
>
>
> I will have to dig through the mailing list to find the cases
> where octave's functions fail.
Ok.
>
>> Everything else in FIXES can be removed without question, including the
>> sort code, the mu2lin, lin2mu function the poly*.m functions
>
>
> Because octave now includes these functions?
Yes
D.
--
David Bateman Dav...@mo...
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
|
|
From: Paul K. <pki...@us...> - 2006-03-30 03:44:58
|
On Mar 29, 2006, at 9:36 AM, David Bateman wrote: >> I've been living with the current octave-mod. > > So the octave-mod in extras/patches goes.. I think it might be worth keeping, but I've been living without it. The amount of octave work I'm doing is minimal and much of that is over a ssh link using vi. - Paul |
|
From: Paul K. <pki...@us...> - 2006-03-30 03:53:24
|
>> Preserving the old random number generator seems crufty. Could it >> be made into an external package that the few people who care >> about it can download it separately? >> > John's stated he want to keep the capability to generate the same > sequences as the old generators. That being the case I don't see a way > around having both. One can have the capability in an external package if one really needs it. I'm not going to argue too much though since I'm not the one maintaining the cruft. - Paul |
|
From: Paul K. <pki...@us...> - 2006-03-30 03:55:47
|
John, the context is the decrufting of octave-forge.
David, I don't believe John follows the octave-dev list.
- Paul
On Mar 29, 2006, at 9:36 AM, David Bateman wrote:
>>> grid.m: This is a compatibility extension of grid.m to allow 1)
>>> recovering the previous state with the gget function and toggling
>>> grid
>>> state if no input arguments are used. It also supports minor tics if
>>> you
>>> have an argument like "x#y#z#" where # is a digit. This is not
>>> texinfo-fied, so based on a very old octave version of grid.m, it
>>> used
>>> gget which I don't see ever going into octave as it has some possibly
>>> nasty race conditions on temporary files. Perhaps with gnuplot 4.1
>>> something similar might be implemented with a pipe and be accepted in
>>> octave. So in its current implementation I don't see this code being
>>> accepted. That being the case, the minor tick stuff might be
>>> included,
>>> just not the probing of the existing settings.
>>
>>
>> Rather than querying we could try keeping track of state on the
>> octave side.
>
> I suppose if there is a "PKG_ADD grid('off')" command in grid.m and a
> persistent variable tracking its state this would make sense. Easy
> enough to propose a patch.
>
>>
>> The syntax for minor tics is a bit hackish and may be rejected.
>
> John what do you want to do about the minors tics in o-f's grid.m?
|
|
From: Quentin S. <qsp...@ie...> - 2006-03-29 15:44:28
|
David Bateman wrote: >Quentin Spencer wrote: > > > >>Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there >>are incompatibilities, as recently pointed out with the system >>function (should be fixed in CVS now), so I think we should make >>another release for 2.9.5+ soon. I'm willing to spend a little time >>doing some de-crufting, but I just wanted to ask first if there is >>anything I shouldn't touch. The obvious stuff is all of the Makefiles >>and .m.in files for things that are now in octave, but even that is >>incomplete (most of the stuff in the main/time directory appears to be >>in octave now, and there are probably more examples). I also was >>inclined to just remove the whole sparse directory, but I thought >>David said we needed to keep the superLU stuff. Any objections? >> >>-Quentin >> >> >> >A lot of stuff is conditionally built, and that can be removed. Also for >the sparse stuff the iteration stuff should be kept for 2.9, but not the >rest. That is the pcg.m and pcr.m functions, but nothing else. > I have now cleaned out everything in main/sparse except for these two files. -Quentin |
|
From: Andy A. <ad...@nc...> - 2006-03-29 16:43:11
|
On 3/29/06, Quentin Spencer <qsp...@ie...> wrote: > David Bateman wrote: > >A lot of stuff is conditionally built, and that can be removed. Also for > >the sparse stuff the iteration stuff should be kept for 2.9, but not the > >rest. That is the pcg.m and pcr.m functions, but nothing else. > > > > I have now cleaned out everything in main/sparse except for these two fil= es. Note that the old sparse stuff is required for sparse support for 2.1.x. Do we still intend to provide o-f for 2.1.x, and if so, is there a branch of o-f to support it? -- Andy |
|
From: Paul K. <pki...@us...> - 2006-03-30 03:31:10
|
On Mar 29, 2006, at 11:43 AM, Andy Adler wrote: > On 3/29/06, Quentin Spencer <qsp...@ie...> wrote: >> David Bateman wrote: >>> A lot of stuff is conditionally built, and that can be removed. Also >>> for >>> the sparse stuff the iteration stuff should be kept for 2.9, but not >>> the >>> rest. That is the pcg.m and pcr.m functions, but nothing else. >>> >> >> I have now cleaned out everything in main/sparse except for these two >> files. > > Note that the old sparse stuff is required for sparse support > for 2.1.x. Do we still intend to provide o-f for 2.1.x, No. > and if so, is there a branch of o-f to support it? Yes. - Paul |
|
From: David B. <Dav...@mo...> - 2006-04-04 19:23:19
|
Quentin Spencer wrote: > David Bateman wrote: > >> Quentin Spencer wrote: >> >> >> >>> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there >>> are incompatibilities, as recently pointed out with the system >>> function (should be fixed in CVS now), so I think we should make >>> another release for 2.9.5+ soon. I'm willing to spend a little time >>> doing some de-crufting, but I just wanted to ask first if there is >>> anything I shouldn't touch. The obvious stuff is all of the Makefiles >>> and .m.in files for things that are now in octave, but even that is >>> incomplete (most of the stuff in the main/time directory appears to be >>> in octave now, and there are probably more examples). I also was >>> inclined to just remove the whole sparse directory, but I thought >>> David said we needed to keep the superLU stuff. Any objections? >>> >>> -Quentin >>> >>> >> >> A lot of stuff is conditionally built, and that can be removed. Also for >> the sparse stuff the iteration stuff should be kept for 2.9, but not the >> rest. That is the pcg.m and pcr.m functions, but nothing else. >> > > I have now cleaned out everything in main/sparse except for these two > files. > > -Quentin > > With all of the patches that John accepted you can completely remove the FIXES directory... D. -- David Bateman Dav...@mo... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob) 91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax) The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Quentin S. <qsp...@ie...> - 2006-04-04 23:23:11
|
David Bateman wrote: >Quentin Spencer wrote: > > > >>David Bateman wrote: >> >> >> >>>Quentin Spencer wrote: >>> >>> >>> >>> >>> >>>>Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there >>>>are incompatibilities, as recently pointed out with the system >>>>function (should be fixed in CVS now), so I think we should make >>>>another release for 2.9.5+ soon. I'm willing to spend a little time >>>>doing some de-crufting, but I just wanted to ask first if there is >>>>anything I shouldn't touch. The obvious stuff is all of the Makefiles >>>>and .m.in files for things that are now in octave, but even that is >>>>incomplete (most of the stuff in the main/time directory appears to be >>>>in octave now, and there are probably more examples). I also was >>>>inclined to just remove the whole sparse directory, but I thought >>>>David said we needed to keep the superLU stuff. Any objections? >>>> >>>>-Quentin >>>> >>>> >>>> >>>> >>>A lot of stuff is conditionally built, and that can be removed. Also for >>>the sparse stuff the iteration stuff should be kept for 2.9, but not the >>>rest. That is the pcg.m and pcr.m functions, but nothing else. >>> >>> >>> >>I have now cleaned out everything in main/sparse except for these two >>files. >> >>-Quentin >> >> >> >> >With all of the patches that John accepted you can completely remove the >FIXES directory... > > I think we should have a new release before removing this, since the changes aren't in 2.9.5, and the 2006.03.17 release has some incompatibilities with 2.9.5 (with the system function, for example), which have been fixed in CVS. By the way, I just did some more removals: the extras/ver20 and extras/fake-sparse. -Quentin |
|
From: Paul K. <pki...@us...> - 2006-04-05 11:02:22
|
On Apr 4, 2006, at 7:23 PM, Quentin Spencer wrote: > David Bateman wrote: > >> Quentin Spencer wrote: >> >> >>> David Bateman wrote: >>> >>> >>>> Quentin Spencer wrote: >>>> >>>> >>>> >>>>> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but >>>>> there >>>>> are incompatibilities, as recently pointed out with the system >>>>> function (should be fixed in CVS now), so I think we should make >>>>> another release for 2.9.5+ soon. I'm willing to spend a little time >>>>> doing some de-crufting, but I just wanted to ask first if there is >>>>> anything I shouldn't touch. The obvious stuff is all of the >>>>> Makefiles >>>>> and .m.in files for things that are now in octave, but even that is >>>>> incomplete (most of the stuff in the main/time directory appears >>>>> to be >>>>> in octave now, and there are probably more examples). I also was >>>>> inclined to just remove the whole sparse directory, but I thought >>>>> David said we needed to keep the superLU stuff. Any objections? >>>>> >>>>> -Quentin >>>>> >>>>> >>>> A lot of stuff is conditionally built, and that can be removed. >>>> Also for >>>> the sparse stuff the iteration stuff should be kept for 2.9, but >>>> not the >>>> rest. That is the pcg.m and pcr.m functions, but nothing else. >>>> >>>> >>> I have now cleaned out everything in main/sparse except for these two >>> files. >>> >>> -Quentin >>> >>> >>> >> With all of the patches that John accepted you can completely remove >> the >> FIXES directory... >> > > I think we should have a new release before removing this, since the > changes aren't in 2.9.5, and the 2006.03.17 release has some > incompatibilities with 2.9.5 (with the system function, for example), > which have been fixed in CVS. By the way, I just did some more > removals: the extras/ver20 and extras/fake-sparse. So you want a new 2.9.5 only release of octave-forge? You are welcome to run through the instructions in release.sh whenever you think we are ready for a new release. The main/path directory can be removed after the next release of octave. - Paul |
|
From: Quentin S. <qsp...@ie...> - 2006-03-29 14:10:42
|
I've started the process by removing the following files that are either conditionally compiled or now found in octave: main/audio/wavread.m main/audio/wavwrite.m main/cell/cell2mat.m.in main/cell/cellfun.cc main/cell/Makefile main/cell/.cvsignore main/general/bitand.cc main/general/bitcmp.m.in main/general/bitget.m.in main/general/bitset.m.in main/general/bitshift.m.in main/general/blkdiag.m.in main/general/isequal.m.in main/general/sortrows.m.in main/miscellaneous/dispatch.cc main/miscellaneous/dispatch.m.in main/miscellaneous/inline.m main/plot/clf.m main/plot/orient.m main/plot/print.m.in main/set/.cvsignore main/set/Makefile main/set/unique.m.in main/set/setdiff.m.in main/set/ismember.m.in main/strings/regexp.cc main/strings/str2double.m.in main/strings/strcmpi.m.in main/strings/strmatch.m.in main/strings/strfind.m main/strings/strncmpi.m main/time/Makefile main/time/calender.m main/time/datenum.m.in main/time/datestr.m main/time/datevec.m main/time/eomday.m main/time/now.m main/time/weekday.m I have edited the following to reflect the above deletions: main/miscellaneous/Makefile main/miscellaneous/.cvsignore main/string/Makefile main/string/.cvsignore main/general/Makefile main/general/.cvsignore main/plot/Makefile I'll start into the sparse stuff and the other files that David pointed out next time I have time to work on this. -Quentin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X