Thanks!
On Sep 24, 2011, at 2:18 PM, Brice Goglin wrote:
> I fixed one parsing bug in commit 3660 on the v1.2-ompi branch. Things
> should work better now.
>
> Parsing XML distance matrices was broken when the XML file came from the
> no-libxml exporter. That's why you had problems on your dual-
I fixed one parsing bug in commit 3660 on the v1.2-ompi branch. Things
should work better now.
Parsing XML distance matrices was broken when the XML file came from the
no-libxml exporter. That's why you had problems on your dual-amd machine
(those have distance matrices) and not on your mac (singl
This is 1.2-ompi, running on Linux 2.6.18-274.el5 on x86_64
$ uname -a
Linux xxx 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64
x86_64 GNU/Linux
On Sep 24, 2011, at 12:43 PM, Brice Goglin wrote:
> What platform and distribution do you have?
>
> Brice
>
>
>
> Le 24/09/2011
What platform and distribution do you have?
Brice
Le 24/09/2011 20:37, Ralph Castain a écrit :
> Yep, it fails. Runs on my Mac, but not under Linux.
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x2acdbedd in hwloc_bitmap_snprintf () from
> /nfs/rinfs/san/homedirs/rh
Yep, it fails. Runs on my Mac, but not under Linux.
Program terminated with signal 11, Segmentation fault.
#0 0x2acdbedd in hwloc_bitmap_snprintf () from
/nfs/rinfs/san/homedirs/rhc/lib/libhwloc.so.3
(gdb) where
#0 0x2acdbedd in hwloc_bitmap_snprintf () from
/nfs/rinfs/san/home
Indeed, this object contains invalid pointers.
Can you try to run tests/xmlbuffer.c from hwloc's tree? It does
export+import+export+compare on the same machine. It would be good to
know if it fails on one of the machines you're using here.
https://svn.open-mpi.org/trac/hwloc/browser/branches/v1.2
FWIW: I tried just printing out the contents of that root object immediately
after importing the xml, and it clearly has a problem:
(gdb) print *obj
$2 = {type = OPAL_HWLOC122_hwloc_OBJ_SYSTEM, os_index = 0, name = 0x101
, memory = {
total_memory = 46912502995240, local_memory = 469125029952
Here's the trace:
#0 0x2ae61737 in hwloc__xml_export_object (output=0x7fffd890,
topology=0x695f10, obj=0x2b139b28)
at topology-xml.c:1094
#1 0x2ae61b69 in hwloc___nolibxml_prepare_export (topology=0x695f10,
xmlbuffer=0x698a70 "\n\n\n memory.page_types[i].count)
Here's some feedback from Ralph -- any idea what's going wrong here?
-
1. I export a topology into xml using
hwloc_topology_export_xmlbuffer(t, &xmlbuffer, &len);
I then pack and send the string.
2. I unpack the string on the other end and import it into a topology
hwloc_topo
On Sep 22, 2011, at 11:41 AM, Brice Goglin wrote:
> This is strange. I just tried building the hwloc tree with prefixing
> enabled, I could not find any problem (except one missing symbol that
> doesn't matter here, see next commits).
>
> Basically nothing has changed outside of src/topology-xml.
Le 22/09/2011 16:14, Jeff Squyres a écrit :
> I have to run out ATM so I can't dig into this deeply for a few hours, but
> with a first take, I'm getting this error:
>
> Making all in src
> CC topology.lo
> topology.c: In function 'hwloc_discover':
> topology.c:1673: error: 'OPAL_HWLOC121hwl
I have to run out ATM so I can't dig into this deeply for a few hours, but with
a first take, I'm getting this error:
Making all in src
CC topology.lo
topology.c: In function 'hwloc_discover':
topology.c:1673: error: 'OPAL_HWLOC121hwloc_BACKEND_XML' undeclared (first use
in this function)
Yes, I can get some testing of the ompi branch pretty quickly. I can bring in
a new copy of this later today and see what we can see.
Many thanks!
On Sep 19, 2011, at 9:05 AM, Brice Goglin wrote:
> I pushed the new minimalistic XML import/export implementation without
> libxml2 to the nolibxm
I am preparing a v1.2.2 to flush all pending fixes because v1.3rc2
doesn't seem likely to happen very soon (see message below).
The v1.2.2rc1 tarballs are already being mirror'ed, I'll send the
official announce when the windows build will be ready.
Brice
Le 19/09/2011 15:05, Brice Goglin a éc
I pushed the new minimalistic XML import/export implementation without
libxml2 to the nolibxml branch. If libxml2 is available, it's still used
by default. --disable-libxml2 or some env variables can be used for
force the minimalistic implementation if needed. The minimalistic implem
is only guaran
My $0.02: for simplicity, let's force ASCII-only. If we get complaints/feature
requests, we can see about updating to include non-ASCII.
But then again, I'm biased because I'm an American. You guys might have
different views -- e.g., you need non-ASCII for your organization's name.
On Sep 5
Regarding XML encoding:
It seems that libxml2 rewrites the following characters as XML entities:
\n
\r
\t
"
<
>
&
hwloc already tells libxml2 to export as UTF-8. However, a quick check
seems to say that the output is not UTF8 when the locale isn't UTF8. We
may need to cdouble-check/clarify/fix t
On Sep 5, 2011, at 2:22 AM, Brice Goglin wrote:
> Samuel thinks we could stay with XML and reimplement our own
> parsing/dumping without libxml2.
>
> My feeling about this is:
> + We would have a single file format for import/export.
> + Saving would likely be easy (copy-paste from the current co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/09/11 19:54, Jeff Squyres wrote:
> Fail enough,
Nice Freudian slip. :-)
> but do the back-end nodes have libxml?
Apparently so..
rpm --root /bgsys/drivers/ppcfloor/linux/OS -qa | grep -i xml
libxml2-2.6.23-22
That's the I/O node filesystem,
Samuel thinks we could stay with XML and reimplement our own
parsing/dumping without libxml2.
My feeling about this is:
+ We would have a single file format for import/export.
+ Saving would likely be easy (copy-paste from the current code and/or
from the JSON export)
- Parsing would require some
JSON looks a bit more verbose than YAML, but JSON also looked better for
our hierarchical information, so I gave JSON a try. I just pushed the
result to the new json branch.
Notes:
* You can only load/save from/to a memory buffer (set_jsonbufffer and
export_jsonbuffer), but lstopo needed to load/s
On Fri, Sep 02, 2011 at 05:57:11AM -0400, Jeff Squyres wrote:
> JSON: sure, it's an easy format, but we're not really targeting web-ish kinds
> of things here, are we?
The format isn't only for web-ish. A lot of embebbed apps use it.
I send an example in attach and use this site to do it:
http
I don't know enough about either format to say.
Sent from my phone. No type good.
On Sep 2, 2011, at 6:03 AM, "Samuel Thibault" wrote:
> Jeff Squyres, le Fri 02 Sep 2011 11:58:05 +0200, a écrit :
>> JSON: sure, it's an easy format, but we're not really targeting web-ish
>> kinds of things he
Jeff Squyres, le Fri 02 Sep 2011 11:58:05 +0200, a écrit :
> JSON: sure, it's an easy format, but we're not really targeting web-ish kinds
> of things here, are we?
>
> YAML: ya, that's also an easy format.
>
> But the goal here is to do something utterly trivial that has no support
> library
JSON: sure, it's an easy format, but we're not really targeting web-ish kinds
of things here, are we?
YAML: ya, that's also an easy format.
But the goal here is to do something utterly trivial that has no support
library requirement. Unless someone has specific requirements for these
format
On Sep 1, 2011, at 9:40 PM, Christopher Samuel wrote:
> Well BG/P doesn't support Open-MPI, but the service
> (management) node and the front end (login) nodes are
> PPC SLES10 and libxml2 is there..
>
> tambo-m:~ # rpm -q libxml2
> libxml2-2.6.23-15.25.5
Fail enough, but do the back-end nodes h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/09/11 02:01, Jeff Squyres wrote:
> Blue Gene?
Well BG/P doesn't support Open-MPI, but the service
(management) node and the front end (login) nodes are
PPC SLES10 and libxml2 is there..
tambo-m:~ # rpm -q libxml2
libxml2-2.6.23-15.25.5
cheers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/09/11 01:30, Jeff Squyres wrote:
> Is there any chance that a lighter-weight, simple string
> parsing module could be added to hwloc?
What about something based on YAML ?
http://www.yaml.org/spec/1.2/spec.html
Designed to be easy to read by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Sep 01, 2011 at 05:49:33PM +0200, Brice Goglin wrote:
>Did you actually find many machines/distribs that don't have libxml2
>installed by default? There are literaly hundreds of packages that depend
>on libxml2 (at least in Debian)
Jeff Squyres, le Thu 01 Sep 2011 20:31:44 +0200, a écrit :
> hst: hwloc simple text
I like this one.
Samuel
On Sep 1, 2011, at 12:17 PM, Brice Goglin wrote:
> Support for the most useful attributes would be done within a couple
> hours. The annoying thing is to support all attributes, distances, ...
If you kruft up some of the infrastructure and some examples, I could volunteer
some grunt work to fill
Le 01/09/2011 18:01, Jeff Squyres a écrit :
> I could *probably* write this, but I'm guessing you guys could write it much
> faster than I could...
Support for the most useful attributes would be done within a couple
hours. The annoying thing is to support all attributes, distances, ...
Also we'
On Sep 1, 2011, at 11:49 AM, Brice Goglin wrote:
> Did you actually find many machines/distribs that don't have libxml2
> installed by default? There are literaly hundreds of packages that depend on
> libxml2 (at least in Debian) so I am not sure depending on it is really a
> problem.
Cray, fo
Jeff Squyres, le Thu 01 Sep 2011 17:31:05 +0200, a écrit :
> Do you think this would be easy to implement?
A quite strict format could probably be easy to implement and still be
extensible. The XML will probably remain useful for people who like XSLT
:)
Samuel
Did you actually find many machines/distribs that don't have libxml2
installed by default? There are literaly hundreds of packages that
depend on libxml2 (at least in Debian) so I am not sure depending on it
is really a problem.
Also are there really some string space problems? Even when talking
a
We're (finally) bringing full hwloc services up in Open MPI.
One of the things we want to do is send server topologies from back-end compute
nodes to the front-end node. The XML export/import functionality would work
for this, but a) it's a bit heavyweight, and b) it seems weird to require XML
36 matches
Mail list logo
