Sun 26 Jun 2016 12:37:25 PM UTC, comment #13:
@Carne,
In hindsight ... should the registration process be reinstated and "__list__" be used in order to obtain a list of registered colormaps?
|
Sun 26 Jun 2016 12:22:06 PM UTC, comment #12:
Sorry about that. I believe it's fixed now
http://hg.savannah.gnu.org/hgweb/octave/rev/19cfad4e4112
|
Sat 25 Jun 2016 02:19:11 PM UTC, comment #11:
Also, make check gives
|
Sat 25 Jun 2016 01:18:35 PM UTC, comment #10:
Carnë, I now get
when I start Octave. I deleted the PKG_ADD file, but it seems to be regenerated by make, and contains a colourmap registration.
Could you fix that? Thanks :)
|
Sat 25 Jun 2016 10:07:42 AM UTC, comment #9:
@Carnë:
Got distracted, sorry.
Looking into your final Q in comment #3 (real use case):
Yes I can come up with one, but in the end it turns out that registering etc. is nice but not really required.
Anyway I'm OK with you having removed it.
|
Fri 24 Jun 2016 09:52:47 PM UTC, comment #8:
Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/894239974868
|
Tue 21 Jun 2016 08:48:04 PM UTC, comment #7:
> What about adding a new function ("colormap_list"?), that will print all available colormaps?
No. That would allow to have a colormap named list but it doesn't address the other issues with this functionality that make it unreliable. Also, if this feature wasn't useful until now, any new function to do the same thing will go just as unused, and we have enough code to maintain as it is.
Do you have a real current case that could be simplified with this functionality?
|
Tue 21 Jun 2016 08:37:31 PM UTC, comment #6:
Lachlan: if the (un)register options will be removed,
there will be only core colormaps.
BTW the persistent cell cmap_list contains all colormaps (see colormap.m)
|
Tue 21 Jun 2016 07:33:07 AM UTC, comment #5:
I like the idea of reducing feature clutter.
The fastest, least memory hungry, and easiest to maintain lines of code are the ones that aren't there.
Avinoam, it would be simple to have a .m function that lists all of the core colourmaps. Would that suffice? (It would for me.) Otherwise, all of the machinery of registering would still be required.
|
Tue 21 Jun 2016 05:03:15 AM UTC, comment #4:
What about adding a new function ("colormap_list"?), that will print all available colormaps?
|
Mon 20 Jun 2016 04:44:12 PM UTC, comment #3:
> Is your plan to remove all of the extensions (incl. (un)register), or just the "list" option?
All. Because there's no point in registering if there's no use for the registry.
> In principle the "list" option is fairly useful on its own as it is an easy way to find out available colormaps. Does the manual contain an overview like e.g. in the on-line Matlab docs? I suppose there is.
> (I don't know the manual by heart, I just googled through the on-line manual but haven't found an overview there).
In principle is it useful, but in practice is unused. And yes, there's a section in the manual that includes a list of all colormaps. If you run "doc colormap", it is followed by rgbplot (a function that maps a colormap), and then by all the core colormaps.
> Speaking for myself, limitations are rarely a problem as long as they're properly documented and don't provoke crashes or errors.
An example of an error is what happens with a colormap named list.
> GIS raster files read with the mapping package can have colormaps ("anonymous" ones until they are, well, "registered" as you call it); so I can imagine the register / list features could be helpful when doing much work with such files.
Do you have a real use case now where this is useful?
|
Mon 20 Jun 2016 03:44:41 PM UTC, comment #2:
Is your plan to remove all of the extensions (incl. (un)register), or just the "list" option?
In principle the "list" option is fairly useful on its own as it is an easy way to find out available colormaps. Does the manual contain an overview like e.g. in the on-line Matlab docs? I suppose there is.
(I don't know the manual by heart, I just googled through the on-line manual but haven't found an overview there).
Speaking for myself, limitations are rarely a problem as long as they're properly documented and don't provoke crashes or errors.
GIS raster files read with the mapping package can have colormaps ("anonymous" ones until they are, well, "registered" as you call it); so I can imagine the register / list features could be helpful when doing much work with such files.
|
Mon 20 Jun 2016 10:49:07 AM UTC, comment #1:
Here's the rest of the bug report because of problems with markdown
Some years ago, I thought it would be nice to have a way to retrieve a list of
available colormaps programatically. For that, I added the option "list" to
colormap().
The bad result of it is that a colormap named list cannot exist (well, it
can't be set by name via colormap). I know colormap() already has the
limitation of a colormap named default (and we can't change that for Matlab
compatibility) but that's not a good example to follow.
So I'm proposing removing it.
I'm not sure that this feature is useful. I never heard of anyone making use
of it. Even if it is used, it only lists colormaps that are registered, and
again, I've never heard of anyone registering colormaps since that's also an
Octave only feature. In addition, the list may return missing colormaps since
it's possible that a user shadowed a colormap since it was registered.
So unless anyone thinks this is a useful feature, I will remove it. It also
means less initialization code since Octave won't have to register all of its
core colormaps anymore (not that this would have any significant impact on
time).
|
Mon 20 Jun 2016 03:09:02 AM UTC, original submission:
The colormap function will not accept a colormap named list because it conflicts with the "list" option.
|