881c2a208669f096339d755d21c1a8d2d267ca40
1999-12-12 Martin Baulig <martin@home-of-linux.org> All functions which return an array now take a `glibtop_array *array' parameter instead of a `glibtop_<feature> *buf' one. For compatibility, we typedef the corresponding `glibtop_<feature>'s to `glibtop_array' in <glibtop/compat_10.h>. This has the advantage that scripting languages like Guile with an array implementation which stores the length of an array in the array don't need the `glibtop_array' parameter at all any longer. We'll also add convenient functions which return GPtrArray's here. * include/glibtop/proclist.h (glibtop_proclist): Removed. (glibtop_get_proclist_*): This now takes a `glibtop_array' parameter instead of a `glibtop_proclist' one. * include/glibtop/procmap.h (glibtop_proc_map): Removed. (glibtop_get_proc_map_*): This now takes a `glibtop_array' parameter instead of a `glibtop_proc_map' one. * include/glibtop/mountlist.h (glibtop_mountlist): Removed. (glibtop_get_mountlist_*): This now takes a `glibtop_array' parameter instead of a `glibtop_mountlist' one. * include/glibtop/interfaces.h (glibtop_interface_names): Removed. (glibtop_get_interface_names_*): This now takes a `glibtop_array' parameter instead of a `glibtop_interface_name' one. * include/glibtop/compat_10.h: New file. Contains some typedefs and #defines to keep compatibility until the big restructurement is completely done.
This is the *development* branch of LibGTop. It is indended for people who want to help with the development of LibGTop and not for end-users. Please use the LIBGTOP_STABLE_1_0 branch (which is LibGTop 1.0.x) unless you're really a developer. If you're using LibGTop from CVS simply do a cvs update -r LIBGTOP_STABLE_1_0 to get the latest version from the stable branch. However, I'll periodically make snapshot releases from the development branch for Solaris users of LibGTop. They can be found at ftp://ftp.home-of-linux.org/pub/libgtop/1.1/ in near future. Using released tarballs from the development branch is a lot better than compiling directly from CVS since things in CVS may not always work as expected. Note that releases from the developer branch are neither binary nor fully source compatible; you'll normally have to recompile everything that use them. October 1999 Martin Baulig
Description
Languages
C
87.9%
Shell
6.9%
M4
2.7%
Makefile
1.1%
Perl
0.9%
Other
0.5%