[GRASS-dev] Unused files

Glynn_Clements1 · April 16, 2007, 5:03pm

There are currently 78 source files whose functions don't appear to be
used by anything.

Some of these may be used by components which aren't being compiled on
my system, and some have been added with the intention of future use.
OTOH, some of them may simply be obsolete.

Please provide comments as to whether specific files should or
shouldn't be removed.

The complete list is:

--
Glynn Clements <glynn@gclements.plus.com>

Soeren_Gebbert1 · April 16, 2007, 5:25pm

Hi,

Glynn Clements schrieb:

There are currently 78 source files whose functions don't appear to be
used by anything.

Some of these may be used by components which aren't being compiled on
my system, and some have been added with the intention of future use. OTOH, some of them may simply be obsolete.

Please provide comments as to whether specific files should or
shouldn't be removed.

The complete list is:

lib/g3d/changeprecision.c | G3d_changePrecision
lib/g3d/changetype.c | G3d_changeType
lib/g3d/filecompare.c | G3d_compareFiles
lib/g3d/g3ddoubleio.c | G3d_readDoubles
lib/g3d/g3ddoubleio.c | G3d_writeDoubles
lib/g3d/g3dvolume.c | G3d_getAllignedVolume
lib/g3d/g3dvolume.c | G3d_getVolume
lib/g3d/g3dvolume.c | G3d_getVolumeA
lib/g3d/g3dvolume.c | G3d_makeAllignedVolumeFile
lib/g3d/retile.c | G3d_retile
lib/g3d/writeascii.c | G3d_writeAscii

Those g3d files are still important. Only a small part of the features from the g3d library
are currently used by the raster3d modules.

lib/gpde/N_solute_transport.c | N_alloc_solute_transport_data2d
lib/gpde/N_solute_transport.c | N_alloc_solute_transport_data3d
lib/gpde/N_solute_transport.c | N_callback_solute_transport_2d
lib/gpde/N_solute_transport.c | N_callback_solute_transport_3d
lib/gpde/N_solute_transport.c | N_free_solute_transport_data2d
lib/gpde/N_solute_transport.c | N_free_solute_transport_data3d

Everything which is located in the gpde library directory is
under active development. These functions will be
used in modules which need to model solute transport in porous media.
A module which is doing this will be available in some months.
(this is a small impression of what this module will do:
http://video.google.de/videoplay?docid=7289891157754718168&q=grass+gis)
Besides of this, these functions are
used in the gpde test module (lib/gpde/test) which is not build by default.

Best regards
Soeren

Daniel_Calvelo · April 16, 2007, 7:12pm

On 4/16/07, Glynn Clements <glynn@gclements.plus.com> wrote:

There are currently 78 source files whose functions don't appear to be
used by anything.

Some of these may be used by components which aren't being compiled on
my system, and some have been added with the intention of future use.
OTOH, some of them may simply be obsolete.

Please provide comments as to whether specific files should or
shouldn't be removed.

[...]

lib/db/sqlp/print.c | sqpPrintStmt

This is used in sqlp/test and should be useful in debugging; I'd keep it.

lib/db/dbmi_client/c_add_col.c | db_add_column
lib/db/dbmi_client/c_bindupdate.c | db_bind_update
lib/db/dbmi_client/c_createdb.c | db_create_database
lib/db/dbmi_client/c_delete.c | db_delete
lib/db/dbmi_client/c_deletedb.c | db_delete_database
lib/db/dbmi_client/c_drop_col.c | db_drop_column
lib/db/dbmi_client/c_drop_index.c | db_drop_index
lib/db/dbmi_client/c_drop_tab.c | db_drop_table
lib/db/dbmi_client/c_finddb.c | db_find_database
lib/db/dbmi_client/c_insert.c | db_insert
lib/db/dbmi_client/c_list_idx.c | db_list_indexes
lib/db/dbmi_client/c_listdb.c | db_list_databases
lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor
lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor
lib/db/dbmi_client/c_update.c | db_update
lib/db/dbmi_client/c_version.c | db_gversion
lib/db/dbmi_client/printtab.c | db_print_column_definition
lib/db/dbmi_client/printtab.c | db_print_table_definition
lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir

Aren't these template functions and files to develop new drivers?

lib/external/shapelib/shpopen.c | SHPClose
lib/external/shapelib/shpopen.c | SHPComputeExtents
lib/external/shapelib/shpopen.c | SHPCreate
lib/external/shapelib/shpopen.c | SHPCreateObject
lib/external/shapelib/shpopen.c | SHPCreateSimpleObject
lib/external/shapelib/shpopen.c | SHPDestroyObject
lib/external/shapelib/shpopen.c | SHPGetInfo
lib/external/shapelib/shpopen.c | SHPOpen
lib/external/shapelib/shpopen.c | SHPPartTypeName
lib/external/shapelib/shpopen.c | SHPReadObject
lib/external/shapelib/shpopen.c | SHPRewindObject
lib/external/shapelib/shpopen.c | SHPTypeName
lib/external/shapelib/shpopen.c | SHPWriteHeader
lib/external/shapelib/shpopen.c | SHPWriteObject

Since we are relying on OGR for shapefile access, I suppose shapelib
is kept as a fallback. No point in keeping it, IMO.

Can't comment on the rest.

Daniel.

--
-- Daniel Calvelo Aros

Glynn_Clements1 · April 16, 2007, 8:14pm

Daniel Calvelo wrote:

> lib/db/dbmi_client/c_add_col.c | db_add_column
> lib/db/dbmi_client/c_bindupdate.c | db_bind_update
> lib/db/dbmi_client/c_createdb.c | db_create_database
> lib/db/dbmi_client/c_delete.c | db_delete
> lib/db/dbmi_client/c_deletedb.c | db_delete_database
> lib/db/dbmi_client/c_drop_col.c | db_drop_column
> lib/db/dbmi_client/c_drop_index.c | db_drop_index
> lib/db/dbmi_client/c_drop_tab.c | db_drop_table
> lib/db/dbmi_client/c_finddb.c | db_find_database
> lib/db/dbmi_client/c_insert.c | db_insert
> lib/db/dbmi_client/c_list_idx.c | db_list_indexes
> lib/db/dbmi_client/c_listdb.c | db_list_databases
> lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor
> lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor
> lib/db/dbmi_client/c_update.c | db_update
> lib/db/dbmi_client/c_version.c | db_gversion
> lib/db/dbmi_client/printtab.c | db_print_column_definition
> lib/db/dbmi_client/printtab.c | db_print_table_definition
> lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir

Aren't these template functions and files to develop new drivers?

No; they are the actual client-side DBMI interface.

I was surprised to find so many of them unused.

--
Glynn Clements <glynn@gclements.plus.com>

Markus_Neteler1 · April 16, 2007, 9:19pm

On Mon, Apr 16, 2007 at 06:03:12PM +0100, Glynn Clements wrote:

There are currently 78 source files whose functions don't appear to be
used by anything.

Some of these may be used by components which aren't being compiled on
my system, and some have been added with the intention of future use.
OTOH, some of them may simply be obsolete.

Please provide comments as to whether specific files should or
shouldn't be removed.

The complete list is:

lib/cdhc/enormp.c | enormp
lib/cdhc/shapiro2.c | shapiro_francia
lib/cdhc/shapiroe.c | shapiro_wilk_exp
lib/cdhc/cvmw2e.c | cramer_von_mises_exp
lib/cdhc/kse.c | kolmogorov_smirnov_exp
lib/cdhc/kuiprsve.c | kuipers_v_exp
lib/cdhc/watsonue.c | watson_u2_exp
lib/cdhc/andrsnde.c | anderson_darling_exp
lib/cdhc/chisqe.c | chi_square_exp

Probably these cdhc/ should go into gmath/ in any case for
future developments?

[ ... dbmi ...]
I feel that DBMI was left in the middle of its development,
in particular Radim was digging through and making it
functional (the needed parts). I have no idea which parts
can be savely abandoned.

lib/gmath/la.c | G__matrix_add

The la stuff us the LAPACK wrapper and needed for i.spec.unix
(Spectral Unmixing) on which Brad is working to make it
ready for GRASS 6 (it's one of my MSc modules). Please keep.

lib/gmath/svd.c | G_svbksb
lib/gmath/svd.c | G_svdcmp
lib/gmath/svd.c | G_svelim

Single Value Decomposition was originally in lib/gis/, I had
moved it there and originally used it for Spectral Unmixing
(matrix inversion). In the end I had to use a different
approach. But probably SVD is useful for someone in future.

lib/imagery/add_cov.c | I_add_covariances
lib/imagery/advance.c | I_tape_advance
lib/imagery/ask.c | I_ask
lib/imagery/ask_subgrp.c | I_ask_subgroup_new
lib/imagery/ask_subgrp.c | I_ask_subgroup_old
lib/imagery/band_io.c | I_close_band
lib/imagery/band_io.c | I_open_band_new
lib/imagery/colors.c | I_free_group_colors
lib/imagery/colors.c | I_read_group_blu_colors
lib/imagery/colors.c | I_read_group_colors
lib/imagery/colors.c | I_read_group_grn_colors
lib/imagery/colors.c | I_read_group_red_colors
lib/imagery/colors.c | I_write_group_blu_colors
lib/imagery/colors.c | I_write_group_colors
lib/imagery/colors.c | I_write_group_grn_colors
lib/imagery/colors.c | I_write_group_red_colors
lib/imagery/image.c | I_close_image
lib/imagery/image.c | I_get_image_row
lib/imagery/image.c | I_image_colors
lib/imagery/image.c | I_open_image
lib/imagery/image.c | I_translate_image_data
lib/imagery/open.c | I_open_group_file_new
lib/imagery/open.c | I_open_group_file_old
lib/imagery/percent.c | I_percent
lib/imagery/proj.c | I_must_be_imagery_projection
lib/imagery/sig2cats.c | I_signature_to_cats

These imagery functions, if really unused, are probably
delete candidates.

lib/vector/Vlib/dbcolumns.c | Vect_get_column_names
lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types
lib/vector/Vlib/dbcolumns.c | Vect_get_column_types
lib/vector/Vlib/graph.c | Vect_graph_add_edge
lib/vector/Vlib/graph.c | Vect_graph_build
lib/vector/Vlib/graph.c | Vect_graph_init
lib/vector/Vlib/graph.c | Vect_graph_set_node_costs
lib/vector/Vlib/graph.c | Vect_graph_shortest_path
lib/vector/Vlib/overlap.c | V__map_overlap
lib/vector/Vlib/overlay.c | Vect_overlay
lib/vector/Vlib/overlay.c | Vect_overlay_and
lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator

I am suprised to see these Vect functions unused. Really sure?

lib/vector/dglib/avl.c | avl_allocator_default

avl: libavl - library for manipulation of binary trees
I think we have also lib/btree/ is that's the same purpose?

No idea about the other functions.

Markus

Glynn_Clements1 · April 16, 2007, 10:21pm

Markus Neteler wrote:

These imagery functions, if really unused, are probably
delete candidates.

Apart from that, it would be nice to start 7.x with "rm -rf imagery/",
and telling people to clean stuff up before they put it back in.

If I'm making the same change to every file which uses a particular
function, I know I've reached the imagery directory when I start
seeing almost exactly the same file over and over again. E.g.:

  imagery/i.ortho.photo/photo.2image/analyze.c
  imagery/i.ortho.photo/photo.2target/analyze.c
  imagery/i.points/analyze.c
  imagery/i.vpoints/analyze.c
or:
  imagery/i.ortho.photo/photo.2image/ask_mag.c
  imagery/i.ortho.photo/photo.2target/ask_mag.c
  imagery/i.points/ask_mag.c
  imagery/i.vpoints/ask_mag.c
or:
  imagery/i.ortho.photo/photo.2image/call.c
  imagery/i.ortho.photo/photo.2target/call.c
  imagery/i.points/call.c
  imagery/i.vpoints/call.c
or:
  [well, you get the idea.]

> lib/vector/Vlib/dbcolumns.c | Vect_get_column_names
> lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types
> lib/vector/Vlib/dbcolumns.c | Vect_get_column_types
> lib/vector/Vlib/graph.c | Vect_graph_add_edge
> lib/vector/Vlib/graph.c | Vect_graph_build
> lib/vector/Vlib/graph.c | Vect_graph_init
> lib/vector/Vlib/graph.c | Vect_graph_set_node_costs
> lib/vector/Vlib/graph.c | Vect_graph_shortest_path
> lib/vector/Vlib/overlap.c | V__map_overlap
> lib/vector/Vlib/overlay.c | Vect_overlay
> lib/vector/Vlib/overlay.c | Vect_overlay_and
> lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator

I am suprised to see these Vect functions unused. Really sure?

I'm quite sure.

> lib/vector/dglib/avl.c | avl_allocator_default

avl: libavl - library for manipulation of binary trees
I think we have also lib/btree/ is that's the same purpose?

Yes; both provide essentially the same functionality.

AVL trees are balanced, so they have better worst-case performance.

Unbalanced trees are O(log(n)) for random data but degenerate to O(n)
for sorted data (you essentially end up with a linked list). Balanced
trees are always O(log(n)), although with a higher constant factor for
insertions due to the cost of rebalancing.

--
Glynn Clements <glynn@gclements.plus.com>

Thierry_Laronde · April 16, 2007, 10:58pm

On Mon, Apr 16, 2007 at 11:21:02PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> These imagery functions, if really unused, are probably
> delete candidates.

Apart from that, it would be nice to start 7.x with "rm -rf imagery/",
and telling people to clean stuff up before they put it back in.

If I'm making the same change to every file which uses a particular
function, I know I've reached the imagery directory when I start
seeing almost exactly the same file over and over again. E.g.:

  imagery/i.ortho.photo/photo.2image/analyze.c
  imagery/i.ortho.photo/photo.2target/analyze.c
  imagery/i.points/analyze.c
  imagery/i.vpoints/analyze.c
or:
  imagery/i.ortho.photo/photo.2image/ask_mag.c
  imagery/i.ortho.photo/photo.2target/ask_mag.c
  imagery/i.points/ask_mag.c
  imagery/i.vpoints/ask_mag.c
or:
  imagery/i.ortho.photo/photo.2image/call.c
  imagery/i.ortho.photo/photo.2target/call.c
  imagery/i.points/call.c
  imagery/i.vpoints/call.c
or:
  [well, you get the idea.]

FWIW, it is indeed a nightmare. I have already---in KerGIS---extracted
the duplicates in a dedicated library, but trying to fix the only 3
imargery modules that are left (for the complete resurrection of the
CERL GRASS), I have, one more time, to rework everything because they
are slighty different, with some modifications in the choice of colors
etc. Not to mention that the C programming skills are the lowest I have
ever seen (with even comments saying that "this function returns
something so that the program doesn't exit".

I have the finger on the trigger and a _huge_ temptation, but in this
case I will nuke the externally produced additions of imagery, and keep
the CERL original programs (Shapiro).

I'm at the moment simplifying v.digit(1) to put the curses interface
apart (to allow to throw, supplementary to it, an Athena and a Motif)
and I will come back to this... thing after that to see if I feel
courageaous enough.

Just to say that Glynn may seem rough, but I have the exact same feeling
and I think it is the correct solution (but keeping original modules
from CERL---at least that's what I will do in KerGIS; these are not
difficult to clean and fix and they are so much better written)!

Cleaning the CERL code, and understanding how it worked (and
reorganizing etc.) has, finally, taken me less time (or at least less
headache and no discouragement). And everytime I see the name of the
responsible for this in a module, life expectancy of the module drops
dramatically...

Well, seing that I have "lost" almost one year without being able to
finish this, I do think I will nuke the imagery additions.

Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

mlennert · April 17, 2007, 2:14pm

On 16/04/07 22:14, Glynn Clements wrote:

Daniel Calvelo wrote:

lib/db/dbmi_client/c_add_col.c | db_add_column
lib/db/dbmi_client/c_bindupdate.c | db_bind_update
lib/db/dbmi_client/c_createdb.c | db_create_database
lib/db/dbmi_client/c_delete.c | db_delete
lib/db/dbmi_client/c_deletedb.c | db_delete_database
lib/db/dbmi_client/c_drop_col.c | db_drop_column
lib/db/dbmi_client/c_drop_index.c | db_drop_index
lib/db/dbmi_client/c_drop_tab.c | db_drop_table
lib/db/dbmi_client/c_finddb.c | db_find_database
lib/db/dbmi_client/c_insert.c | db_insert
lib/db/dbmi_client/c_list_idx.c | db_list_indexes
lib/db/dbmi_client/c_listdb.c | db_list_databases
lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor
lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor
lib/db/dbmi_client/c_update.c | db_update
lib/db/dbmi_client/c_version.c | db_gversion
lib/db/dbmi_client/printtab.c | db_print_column_definition
lib/db/dbmi_client/printtab.c | db_print_table_definition
lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir

Aren't these template functions and files to develop new drivers?

No; they are the actual client-side DBMI interface.

I was surprised to find so many of them unused.

On 16/04/07 23:19, Markus Neteler wrote:
> [ ... dbmi ...]
> I feel that DBMI was left in the middle of its development,
> in particular Radim was digging through and making it
> functional (the needed parts). I have no idea which parts
> can be savely abandoned.

If they have useful code in them and could be potentially
used, why not keep them and hope than someone picks things up ? Unless we decide either

- that implementing these functionalities as scripts as we are doing now is better or at least just as good (e.g. the v.db.* scripts), or

- that database management should be done via relevant db client programs (independent of GRASS) or db.execute.

Moritz

Glynn_Clements1 · April 17, 2007, 4:00pm

Moritz Lennert wrote:

>>> lib/db/dbmi_client/c_add_col.c | db_add_column
>>> lib/db/dbmi_client/c_bindupdate.c | db_bind_update
>>> lib/db/dbmi_client/c_createdb.c | db_create_database
>>> lib/db/dbmi_client/c_delete.c | db_delete
>>> lib/db/dbmi_client/c_deletedb.c | db_delete_database
>>> lib/db/dbmi_client/c_drop_col.c | db_drop_column
>>> lib/db/dbmi_client/c_drop_index.c | db_drop_index
>>> lib/db/dbmi_client/c_drop_tab.c | db_drop_table
>>> lib/db/dbmi_client/c_finddb.c | db_find_database
>>> lib/db/dbmi_client/c_insert.c | db_insert
>>> lib/db/dbmi_client/c_list_idx.c | db_list_indexes
>>> lib/db/dbmi_client/c_listdb.c | db_list_databases
>>> lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor
>>> lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor
>>> lib/db/dbmi_client/c_update.c | db_update
>>> lib/db/dbmi_client/c_version.c | db_gversion
>>> lib/db/dbmi_client/printtab.c | db_print_column_definition
>>> lib/db/dbmi_client/printtab.c | db_print_table_definition
>>> lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir
>> Aren't these template functions and files to develop new drivers?
>
> No; they are the actual client-side DBMI interface.
>
> I was surprised to find so many of them unused.

On 16/04/07 23:19, Markus Neteler wrote:
> [ ... dbmi ...]
> I feel that DBMI was left in the middle of its development,
> in particular Radim was digging through and making it
> functional (the needed parts). I have no idea which parts
> can be savely abandoned.

If they have useful code in them and could be potentially
used, why not keep them and hope than someone picks things up ? Unless
we decide either

- that implementing these functionalities as scripts as we are doing now
is better or at least just as good (e.g. the v.db.* scripts), or

- that database management should be done via relevant db client
programs (independent of GRASS) or db.execute.

FWIW, I wasn't looking to remove the DBMI functions; I just posted the
unabridged list of unused library functions.

BTW, I suspect that some of the unused dbmi_client functions are due
to this in db/base/Makefile:

#not used: db.createdb db.dropdb db.databases db.droptable
PROGRAMS = db.columns db.copy db.describe db.drivers db.execute db.select db.tables db.connect

Also, some of the dbmi_base functions might only be used by the MySQL
or SQLite drivers, which I haven't compiled.

However, I did remove the unused display and imagery functions.

The display functions would never have been used, and the imagery code
is in dire need of cleaning up.

Removing unused code from lib/imagery required 3 or 4 iterations;
every time I removed the unused functions, a new batch of functions
would become unused.

As to what's left, roughly half of the imagery library is the
I_cluster_* functions, which are only used by i.cluster. I'm wondering
whether they should be moved to their own library, or even into
i.cluster.

--
Glynn Clements <glynn@gclements.plus.com>

Markus_Neteler1 · April 18, 2007, 7:24am

Glynn Clements wrote on 04/17/2007 12:21 AM:

Markus Neteler wrote:

These imagery functions, if really unused, are probably
delete candidates.

Apart from that, it would be nice to start 7.x with "rm -rf imagery/",
and telling people to clean stuff up before they put it back in.

If I'm making the same change to every file which uses a particular
function, I know I've reached the imagery directory when I start
seeing almost exactly the same file over and over again. E.g.:

  imagery/i.ortho.photo/photo.2image/analyze.c
  imagery/i.ortho.photo/photo.2target/analyze.c
  imagery/i.points/analyze.c
  imagery/i.vpoints/analyze.c
or:
  imagery/i.ortho.photo/photo.2image/ask_mag.c
  imagery/i.ortho.photo/photo.2target/ask_mag.c
  imagery/i.points/ask_mag.c
  imagery/i.vpoints/ask_mag.c
or:
  imagery/i.ortho.photo/photo.2image/call.c
  imagery/i.ortho.photo/photo.2target/call.c
  imagery/i.points/call.c
  imagery/i.vpoints/call.c
or:
  [well, you get the idea.]

Yes, the problem is well known - see the GRASS Quality Assessment site,
in particular the clone detection part therein:

http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/clone-browser.html

Maybe Brad has comments on his plans to polish the imagery part.

lib/vector/Vlib/dbcolumns.c | Vect_get_column_names
lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types
lib/vector/Vlib/dbcolumns.c | Vect_get_column_types
lib/vector/Vlib/graph.c | Vect_graph_add_edge
lib/vector/Vlib/graph.c | Vect_graph_build
lib/vector/Vlib/graph.c | Vect_graph_init
lib/vector/Vlib/graph.c | Vect_graph_set_node_costs
lib/vector/Vlib/graph.c | Vect_graph_shortest_path
lib/vector/Vlib/overlap.c | V__map_overlap
lib/vector/Vlib/overlay.c | Vect_overlay
lib/vector/Vlib/overlay.c | Vect_overlay_and
lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator


I am suprised to see these Vect functions unused. Really sure?

I'm quite sure.

lib/vector/dglib/avl.c | avl_allocator_default


avl: libavl - library for manipulation of binary trees
I think we have also lib/btree/ is that's the same purpose?

Yes; both provide essentially the same functionality.

AVL trees are balanced, so they have better worst-case performance.

Unbalanced trees are O(log(n)) for random data but degenerate to O(n)
for sorted data (you essentially end up with a linked list). Balanced
trees are always O(log(n)), although with a higher constant factor for
insertions due to the cost of rebalancing.

Could this be a reason to drop
lib/btree/
and to replace it by a wrapper to
lib/vector/dglib/

(wild guess)?

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

Glynn_Clements1 · April 18, 2007, 3:33pm

Markus Neteler wrote:

>>> lib/vector/dglib/avl.c | avl_allocator_default
>>>
>> avl: libavl - library for manipulation of binary trees
>> I think we have also lib/btree/ is that's the same purpose?
>>
>
> Yes; both provide essentially the same functionality.
>
> AVL trees are balanced, so they have better worst-case performance.
>
> Unbalanced trees are O(log(n)) for random data but degenerate to O(n)
> for sorted data (you essentially end up with a linked list). Balanced
> trees are always O(log(n)), although with a higher constant factor for
> insertions due to the cost of rebalancing.
>
Could this be a reason to drop
lib/btree/
and to replace it by a wrapper to
lib/vector/dglib/

The interface is quite different. lib/btree has separate key/value,
while avl.c has a monolithic "item", with the user-supplied compare
function being used to determine matches.

IMHO, it would be better to modify lib/btree to use AVL trees (or
B-trees etc) if performance is considered an issue.

--
Glynn Clements <glynn@gclements.plus.com>