On Fri, 2011-01-21 at 17:09 +0100, Samuel Thibault wrote: > Bernd Kallies, le Thu 20 Jan 2011 20:35:04 +0100, a écrit : > > On Thu, 2011-01-20 at 20:22 +0100, Samuel Thibault wrote: > > > Bernd Kallies, le Thu 20 Jan 2011 20:13:03 +0100, a écrit : > > > > The only thing I was wondering about are these OO method names, which I > > > > had to invent them myself. If there is some need to synchronize these > > > > with the python binding, we may agree about them. Backwards > > > > compatibility of the Perl binding is not a real problem, since there may > > > > be many aliases for a function in the base XS code. > > > > > > Could you perhaps list those you have defined already, if any? > > > > See > > > > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Topology.pod > > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Obj.pod > > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Cpuset.pod > > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Bitmap.pod > > Well, I meant the ones for which you had to invent a name. These are > mostly the same as the C interface, hwloc_ prefix stripped. Are there > names that don't exactly map to a C function? I see there is a "not in > hwloc" section, I guess it is supposed to contain them all?
Yes, most of the OO methods are named like the C function with hwloc_ or hwloc_topology_ prefixes stripped. Sometimes _get_ was stripped, when it sounds better, e.g. $->depth instead of $t->get_depth Sometimes words are reversed, like hwloc_obj_type_sprintf($o) but $o->sprintf_type hwloc_obj_sprintf($t,$o) but $t->sprintf_obj($o) There also exist functions that operate with hwloc_obj_t and have a hwloc_topology_t as first argument, but it is unused. So I decided to put these functions in the Sys::Hwloc::Topology and in the Sys::Hwloc::Obj namespaces, e.g. hwloc_obj_is_in_subtree($t,$o1,$o2) $t->obj_is_in_subtree($o1,$o2) $o1->is_in_subtree($o2) > > > HWLOC_XSAPI_VERSION always returns a version number (may be 0) > > Ok > > > HWLOC_HAS_XML flag if hwloc was built with XML support > > Why do you need it? At worse the xml functions would fail. This is to be able to decide if coded calls of xml functions in a perl script should be executed or not. If the C lib was generated without xml, then the wrapper does not contain the wrapper functions. So the symbol table of a perl script is different. If one has a perl script that calls these functions, then it will not byte-compile. The HWLOC_HAS_XML constant can be used much like an #ifdef in C to provide alternatives for a perl script without having different scripts for every variant. It may be nice for C programmers to provide the value of the HWLOC_HAVE_XML cpp constant in hwloc.h for the same reason. > > hwloc_compare_objects compares two Sys::Hwloc::Obj by C pointer value > > Ok. > > > hwloc_bitmap_ids returns bitmap bits as list of decimal numbers > > That seems perl-specific indeed. > > > hwloc_bitmap_list_sscanf parses a list format cpuset ASCII string > > hwloc_bitmap_list_sprintf outputs a list format cpuset ASCII string > > hwloc_bitmap_includes reverse of hwloc_bitmap_isincluded > > I guess these could be added to the C API? Brice said that he tries to add the _list_ things in hwloc 1.2. > > > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc.pm > > Ok, that perl I can read :) > > I'd say you shouldn't care about providing all the hwloc_cpuset_* > functions, since these names are deprecated in the C API. Currently the wrapper compiles with hwloc 0.9 .. at least 1.1, and generates different version dependent codes from the same source. The cpuset API functions are only provided when one compiles the wrapper against hwloc 1.0. With 1.1 they are not provided. > > $mapa = hwloc_bitmap_dup($map) > > Same issue as in Python: when a const bitmap is returned by a hwloc > function, the user shouldn't be able to modify it. Hard to implement. In C this is achieved with prototypes via the C compiler. There exists no such pendant in Perl. One would have to work with proxy objects that have a readonly attribute, and maintain this. > > hwloc_bitmap_from_ulong($set,$mask) > > hwloc_bitmap_from_ith_ulong($set,$i,$mask) > > hwloc_bitmap_set_ith_ulong($set,$i,$mask) > > $val = hwloc_bitmap_to_ulong($set) > > $val = hwloc_bitmap_to_ith_ulong($set,$i) > > Same issue as in Python (but with different answer): AIUI, perl doesn't > have unbound integers, so has a limitation, but is possibly not exactly > like C longs. I guess these should just use the regular perl integer > name and size? Internally perl handles integers as long or ulong. The problem with wrappers is the correct cast between the content of a perl scalar (may be a long or ulong or string or double or ...) and the needed C type. I'll check what happens when one reaches UINT_MAX and the like. > About area membind, same remark as for python: if someone uses perl to > drive C-library computations, it may be useful, but else it probably > doesn't make sense in pure perl. Agreed, thatswhy these functions are currently not in the perl wrapper. > Samuel > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Dr. Bernd Kallies Konrad-Zuse-Zentrum für Informationstechnik Berlin Takustr. 7 14195 Berlin Tel: +49-30-84185-270 Fax: +49-30-84185-311 e-mail: kall...@zib.de
