Menu
▾
▴
libxmlplusplus-general — Open discusions about libXML++
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(157) |
Dec
(87) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(78) |
Feb
(246) |
Mar
(83) |
Apr
(32) |
May
(99) |
Jun
(85) |
Jul
(34) |
Aug
(24) |
Sep
(65) |
Oct
(60) |
Nov
(45) |
Dec
(90) |
| 2004 |
Jan
(8) |
Feb
(40) |
Mar
(12) |
Apr
(17) |
May
(56) |
Jun
(13) |
Jul
(5) |
Aug
(30) |
Sep
(51) |
Oct
(17) |
Nov
(9) |
Dec
(20) |
| 2005 |
Jan
(16) |
Feb
(22) |
Mar
(14) |
Apr
(6) |
May
(12) |
Jun
(41) |
Jul
(21) |
Aug
(26) |
Sep
(7) |
Oct
(42) |
Nov
(10) |
Dec
(7) |
| 2006 |
Jan
(6) |
Feb
(9) |
Mar
(19) |
Apr
(7) |
May
(1) |
Jun
(10) |
Jul
(5) |
Aug
|
Sep
|
Oct
(8) |
Nov
(9) |
Dec
(3) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(10) |
Jun
(32) |
Jul
(6) |
Aug
(8) |
Sep
(10) |
Oct
(3) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(11) |
Apr
|
May
(6) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(3) |
| 2010 |
Jan
(3) |
Feb
(6) |
Mar
(16) |
Apr
(2) |
May
|
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christophe de V. <cde...@al...> - 2002-11-21 13:46:40
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 21 Novembre 2002 13:24, Paul Davis a =E9crit : > >Personally, I have tried to avoid using add_child(Node* node) for this > >reason. I think it would be best to say > >"All Nodes must be created by DomParser, not by yourself." > > i believe that this doesn't work when you are trying to build a tree > yourself before saving it back to disk. if you have a subtree built by > function B that is returned to function A for incorporation into the > nascent tree, its hard to see how you can get DomParser to handle > anything for you. i think. > =46or me it's more the owner of the Node (which could the DOMParser, but al= so=20 another node) which should handle creation and deletion of a node. On the other hand, let a method in Node to add a child without copying it=20 could be usefull if we, for example, merge a part of a tree in another : th= is=20 would avoid a copy of nodes that would be anyway deleted just after the=20 merge. But in this case the method should have an explicit name. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3c444ACgkQB+sU3TyOQjD0KQCeNOzsoidQvHtV7ofnTQ5h+s41 6E8AmgJbgQaEFUIWVcPDyBLF+W08Oj4B =3Dbr8J =2D----END PGP SIGNATURE----- |
|
From: Paul D. <pa...@li...> - 2002-11-21 12:22:38
|
>Personally, I have tried to avoid using add_child(Node* node) for this >reason. I think it would be best to say >"All Nodes must be created by DomParser, not by yourself." i believe that this doesn't work when you are trying to build a tree yourself before saving it back to disk. if you have a subtree built by function B that is returned to function A for incorporation into the nascent tree, its hard to see how you can get DomParser to handle anything for you. i think. --p |
|
From: Christophe de V. <cde...@al...> - 2002-11-21 09:38:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murray, Unless you see any problem with that, I will add and implement a Parser::parse_stream(istream &). I think this will give much flexibility on the possible data source. I plan to implement that using the push method (now we have real reasons to use it). I may ask your help if I fall back on the problems you had previously with this method. Cheers, Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3cqV8ACgkQB+sU3TyOQjDiiACeJO6xqlVriJ43s5ZmPRtjN8y0 sVcAn20yxBYZq/Axj7eDljm/aLi49MOb =00Il -----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@ne...> - 2002-11-20 23:24:47
|
On Jeudi 21 Novembre 2002 00:12, Stefan Seefeld wrote: > Paul Davis wrote: [...] > > const Node * add_child (const std::string &name) > > Node * add_child (Node *node) > > > > has caused dozens of stupid bugs in my code, because it doesn't make > > it clear whether the added child is copied or not (its not). > > A good way to make the intention clear would be to pass > 'std::auto_ptr<Node>' instead of raw pointers, whenever you want it > to be adopted. > The problem with auto_ptr is that it's absolutely not recommended to use them inside the STL containers. Another way would be to use map<std::string, Attribute> instead of map<std::string, Attribute *> The result is the same, although we'll have to be carefull about how copy constructors are implemented. But this will not apply to Node, if we want to implement this : > I, too, have an API enhancement suggestion: Please consider a method > 'Node::lookup(const std::string &xpath)' that does an xpath lookup > (surprize !) and returns a NodeSet. I'v written my own C++ wrapper > around libxml2 and this method is incredibly useful in my work... Once we agree on a name for this method (lookup, find, xpath, evaluate, evalateXPath... ?), we'll add it. > > Stefan > Christophe |
|
From: Christophe de V. <cde...@ne...> - 2002-11-20 23:11:26
|
On Mercredi 20 Novembre 2002 23:14, you wrote: > Hi, Hi Chris, > > As way of introduction, I'm the debian maintainer of the libxml++ package. nice to meet you ;-) > One of our users recently reported a memory leak in the 0.13 version of > the libxml++ code, and I checked and found the leak still present in the > 0.16.0 release (which I am currently packaging for debian). > > For a full description of the bug, see the following URL: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149422 > > Attached to this email is a patch against the 0.16.0 release. I will be > releasing a binary package of the 0.16.0 version to debian with this patch > already applied. > Your patch has been included in the cvs, so the fix will be included in the next release. Thanks for reporting it. For furure patch/comments/questions, I invite you to use the mailing list and/or the patch tracker on the sourceforge project pages. Regards, Christophe |
|
From: Christophe de V. <cde...@ne...> - 2002-11-20 22:52:34
|
On Mercredi 20 Novembre 2002 22:57, Paul Davis wrote: > > const Node * add_child (const std::string &name) > Node * add_child (Node *node) > > has caused dozens of stupid bugs in my code, because it doesn't make > it clear whether the added child is copied or not (its not). > It's one thing I wanted to improve. For me, if not not standalone, a node should have all it's life cycle managed by its owner : creation and deletion. We'll try to do somethind about this soon, probably partly based on your patch if your could post it again in the patch tracker. Regards, Christophe |
|
From: Paul D. <pa...@li...> - 2002-11-20 21:55:31
|
>libxml++ was a mess in the past but it has been overhauled recently. The
>new 0.16.0 release is now organised and usable. I invite you to try it
>and help us to improve it by submitting patches (to the sourceforge
>patch manager).
if you're going to try to improve it, i would pass on one
recommendation. this API:
const Node * add_child (const std::string &name)
Node * add_child (Node *node)
has caused dozens of stupid bugs in my code, because it doesn't make
it clear whether the added child is copied or not (its not).
ardour has had its own copy of libxml++ for some time, and we have
been unable to get the author to accept any of our patches. we changed
the API to:
XMLNode *add_child(const string &);
XMLNode *add_child_copy(const XMLNode&);
void add_child_nocopy (XMLNode&);
--p
|
|
From: Christophe de V. <cde...@ne...> - 2002-11-20 19:05:46
|
On Mercredi 20 Novembre 2002 18:47, you wrote: > Christophe, Hi Thomas > > we are using the libxml++ in the KMyMoney2 project since a few weeks. > Yesterday, I switched from gcc 2.95 to gcc 3.2 and noticed, that the extra > > -I/usr/local/include > > created by 'xml++-config --cflags' causes warnings all over the place as > gcc 3.2 knows /usr/local/include as a 'system include directory' and does > not need it to be specified separate on the command line. > Thanks for your help. We've just release 0.16 version which now supports pkg-config. The old 'xml++-config is still in use, but may disappear in a next release. You will notice that the API evolved quite a bit in this release ;-) > Please note my patch below, which fixes this problem. If you find another > solution to the problem, please feel free to dump it. Otherwise, I hope it > helps to make your software working w/o warnings in more environments. > > ----%<----- ----%<----- ----%<----- ----%<----- ----%<----- > --- xml++-config.in 2002-10-13 15:52:05.000000000 +0200 > +++ xml++-config.in.new 2002-11-20 12:37:37.000000000 +0100 > @@ -53,7 +53,9 @@ > ;; > > --cflags) > - echo -I@includedir@ > + if [ x@includedir@ != x/usr/local/include ]; then > + echo -I@includedir@ > + fi > ;; > > --libs) > ----%<----- ----%<----- ----%<----- ----%<----- ----%<----- > This will indeed correct the problem when using xml++-config, but not when compiling the lib itself... I'll see what we can do about it. Cheers, Christophe PS: there is now a mailing-list that you can use if you have questions/remarks/comments. If you ever have other patchs, use the patch manager on sourceforge. |
|
From: Peter J. <xml...@pm...> - 2002-11-20 18:17:57
|
I have noticed that the latest release of libxml++ is starting to look a lot like xmlwrapp (http://pmade.org/pjones/software/xmlwrapp/). Does anyone think that we should find a way to combine these two projects? -- Peter Jones, xmlwrapp Senior Developer http://pmade.org/pjones/software/xmlwrapp/ |
|
From: Edd D. <ed...@us...> - 2002-11-20 14:27:29
|
Hi there libxml++ doesn't have a SAX2 API, which is really the baseline API for stream parsing these days. The most important thing it buys the user is support for XML namespaces. The question is how to implement this. libxml has no direct support for namespaces in its SAX API. The file SAX.c in libxml is an actual implementation of namespaces, so some of that code could be used. It is possible to write a SAX2 API by layering on the SAX one. http://www.saxproject.org/?selected=3Dsax2 shows the changes from SAX1 to SAX2 (read from the bottom up). Aside from namespace support the major feature additions are SAX filters, which can sit in the event stream and filter data, and "features and properties", mechanisms for controlling parser behaviour. There's already a BSD-licensed wrapper for libxml that provides SAX2, http://www.jezuk.co.uk/cgi-bin/view/arabica, but of course that's not GPL. Perhaps the most useful starting point could be the ParserAdapter class -- see http://www.saxproject.org/apidoc/org/xml/sax/helpers/ParserAdapter.html This is a class that layers on a SAX parser to make it a SAX2 one. The license says "public domain" so I've no idea what the licensing status of a direct port to C++ would be. http://www.saxproject.org/?selected=3Dpd -- Edd |
|
From: Christophe de V. <cde...@al...> - 2002-11-20 13:17:44
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm pleased to announce the release of libxml++ 0.16.
This new release comes with consequent changes,
in the API and in the packaging.
* The XML prefix has been removed from class names
* The Tree class has been replaced by DomParser
* Exceptions have been added
* Two new classes, DomParser and SaxParser have been introduced.
* The documentation is now generated by Doxygen
* Some examples has been added.
* pkg-config support.
Best regards,
Christophe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj3bi04ACgkQB+sU3TyOQjAoOACfYpSXIZPVSFQhiJbHOlDOdALY
0MsAoIvZ/EoNjDqGuq5SieNlUKl3Qs/n
=+Ii3
-----END PGP SIGNATURE-----
|
|
From: Christophe de V. <cde...@ne...> - 2002-11-18 23:37:33
|
On Lundi 18 Novembre 2002 23:45, Christophe de Vienne wrote: > > I can put the source in the docs directory and create a make target to > > upload it via rsync. I have done this successfully for other projects. > > But I don't think I can actually upload it with my current permissions. > > why not using the cvs repositery ? I was thinking of doing like this. > Anyway just tell me what rights you need I'll put them. > ahem... I've read too fast. I was thinking of the CVS for the website of course, not for the documentation... Agree with you on the rsync method. Tell me which rights you need. |
|
From: Christophe de V. <cde...@ne...> - 2002-11-17 14:00:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just added some exception classes : exception, libxml_error and internal_error in the xmlpp namespace. I did not integrate them at all. In fact I'm not sure about how to handle libxml errors in fact. I'm currently reading the doc but I don't find anything very complete. Should we use, for example, xmlSetGenericErrorFunc () ? this would permit to handle at ones all errors by parse errors and validating ones. For theses, how to do properly ? Moreover, should we add a error_number attribute to the libxml_error class ? I'm waiting for your comments, Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE916DpoNwgyKmVCd0RAmroAJ992WPLlcbKnOQRxg/GBR73V1OpAQCeJAm4 qUH2IpBHl0tN2iQYNXnb8TQ= =rVyD -----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@ne...> - 2002-11-16 15:03:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to rename this method to parse_file. do you agree ? Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE91l5JoNwgyKmVCd0RAot8AJ4ilW12/CbZp3d3kcYfqdtoO7GQQgCfd+2u jdVruETs5T2gDfoQC0v2JZ0= =UBRA -----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@ne...> - 2002-11-16 15:02:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi murray, I just reimplemented parse and parse_memory in sax_parser without the use of xmlParseChunc. The example now works. I need to do a bit of cleaning (10mins max.), but before commiting I want to be sure you're not working on it right now. Cheers, Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE91l4AoNwgyKmVCd0RAvPUAJ9Dfv+Y7gkfz3x8aXrAiHNcvfr22ACeLCyX urViWi1Fb5jRMcEMGnx+4N0= =avKV -----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@ne...> - 2002-11-16 14:30:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Property class has been renamed to Attribute. However, since it's like this in libxml, I kept the 'properties' word instead of attributes. Cheers, Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE91laSoNwgyKmVCd0RAkbOAJ9oPw7ZKK1t4PbCOs2+fq7H9TmljQCdE6We Vc5qcUPA2tRn1Z1Al9AiiEc= =Q0kX -----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@ne...> - 2002-11-16 13:48:42
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It's ok I understood. Sorry for disturbing...
On Samedi 16 Novembre 2002 14:46, Christophe de Vienne wrote:
> Hi murray,
>
> Changing property to attribute in the code, I found this, which I do not
> understand :
>
> 240 const Attribute * Node::property(const std::string& n) const
> 241 {
> 242 return const_cast<Node *>(this)->property(n);
> 243 }
>
> How this method is supposed to return one day the good result ?
>
> Cheers,
>
> Christophe
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE91kyuoNwgyKmVCd0RAslTAJ9/JojdAtt3hByPjFExo3vDflRiAQCfQ8Xe
BVbwDFQq2sgJw5YYdSeC7Es=
=lkir
-----END PGP SIGNATURE-----
|
|
From: Christophe de V. <cde...@ne...> - 2002-11-16 13:46:34
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi murray,
Changing property to attribute in the code, I found this, which I do not
understand :
240 const Attribute * Node::property(const std::string& n) const
241 {
242 return const_cast<Node *>(this)->property(n);
243 }
How this method is supposed to return one day the good result ?
Cheers,
Christophe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE91kwtoNwgyKmVCd0RAlxdAJ9irTT7EQEgcZGNR3a+ZsEuEPD5sgCeOahF
+mcXVTuCOrWCgJDe9yJ8Q9I=
=MArL
-----END PGP SIGNATURE-----
|
|
From: Christophe de V. <cde...@al...> - 2002-11-15 15:03:41
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murray, Don't you think we should add an exception to report the parse errors instead of a simple bool ? This would give much more information, and if the user really don't want of them, we can simply add a bool _use_exception; attribute to the parser class. What's you point of view on that ? Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3VDKcACgkQB+sU3TyOQjANqQCeI3lLBoncAZWZIWae8IGNBG81 S/gAoOLsD4vYvq6oItiTO03VtE4Osy14 =7M4s -----END PGP SIGNATURE----- |
|
From: <jul...@ho...> - 2002-11-15 12:19:13
|
Hello. > > > Why do we push mode, for instance with xmlCreatePushParserCtxt() instead > > > of just xmlSAXParseDoc(). I think "push mode" allows us to provide data > > > piece by piece, instead of all-at-once, but I don't think we need that. > > > > It allows to write programas that process long documents with low memory > > consumption. I think is important to have such possibility. > > The possibility might be nice, but I don't think we use it so far. Am I > right? It can be a minority of uses, I don't know, but if is important to libxml to support it I think it will be eqully important to libxml++. Regards. |
|
From: <jul...@ho...> - 2002-11-15 11:55:13
|
Hello. > Why do we push mode, for instance with xmlCreatePushParserCtxt() instead > of just xmlSAXParseDoc(). I think "push mode" allows us to provide data > piece by piece, instead of all-at-once, but I don't think we need that. It allows to write programas that process long documents with low memory consumption. I think is important to have such possibility. Regards. |
|
From: <jul...@ho...> - 2002-11-14 08:14:39
|
Hello. > > I compiled libxml++ on hp-ux 10.20. Is there some simple project (program > > and xml files) to quickly test it? > No, but we hope to have examples in the next version. Maybe some > application uses it already. Never mind, I wrote the simple test attached and it compiles a run succesfully on hp-ux 10.20 using gcc 2.95.2, libxml 2.4.26 and libxml++ 0.15.0. Regards. |
|
From: <jul...@ho...> - 2002-11-13 08:55:13
|
Hello. I compiled libxml++ on hp-ux 10.20. Is there some simple project (program and xml files) to quickly test it? Regards. |
|
From: Greg S <gr...@ho...> - 2002-11-12 23:31:43
|
Hi,
It's great to see libxml++ being maintained again.
I've been using the library for a couple of years now,
and find it very useful. There are a few things here
and there that are inconsistent, and I think need to
be fixed. I'll iterate through them with my proposed
fixes.
1. Behaviour of read_buffer() is not consistent with
read() in that it does not have the
xmlKeepBlanksDefault(0); clause. This results in
formatting problems when reading from memory. To fix
this I had to insert xmlKeepBlanksDefault(0); before
line 81 of xml++.cc
2. Behaviour of write_buffer() is also not consistent
with that of write() in that it performs
xmlDocDumpMemory instead of xmlDocDumpFormatMemory.
This results in formatting problems when dumping to
memory. To fix this problem, replace xmlDocDumpMemory
(doc, (xmlChar **) &ptr, &len); with
xmlDocDumpFormatMemory(doc, (xmlChar **) &ptr, &len,
1); on line 131 of xml++.cc
3. Using free(ptr) on line 136 of xml++.cc is
incorrect since ptr is allocated by libxml. xmlFree
(ptr); should be used instead.
4. You can save some effort of maintaining an extra
XMLNode constructor by using a default value for the
line argument. Get rid of XMLNode(const std::string
&); constructor, and rewrite the XMLNode(const
std::string &, int line); to XMLNode(const std::string
&, int line = 0); in the header file.
5. I would rewrite writenode() like so: (comments
accompany changes)
static void writenode(xmlDocPtr doc, XMLNode *n,
xmlNodePtr p, int root) {
XMLPropertyList props;
XMLPropertyIterator curprop;
XMLNodeList children;
XMLNodeIterator curchild;
xmlNodePtr node;
if(root)
{
// root node can not have content, so we can
safely change
// (xmlChar *) n->content().c_str() to NULL
node = doc->children = xmlNewDocNode(doc, NULL,
(xmlChar *) n->name
().c_str(),
NULL);
}
else
{
// changed this because TEXT_NODE was not
constructed properly in lxml++ 0.13
// this resulted in a memory leak...
if(n->is_content())
{
node = xmlNewTextLen ((xmlChar *) n->content
().c_str(), n->content().length());
xmlAddChild(p,node);
}
else
{
// xml formatting fixes in the if statement
// changed (xmlChar *) n->content().c_str
() to NULL since n->is_content == false
node = xmlNewChild(p, NULL, (xmlChar *) n->name
().c_str(), NULL);
}
}
props = n->properties();
for(curprop = props.begin(); curprop != props.end();
curprop++)
xmlSetProp(node, (xmlChar *) (*curprop)->name
().c_str(),
(xmlChar *) (*curprop)->value().c_str
());
children = n->children();
for(curchild = children.begin(); curchild !=
children.end(); curchild++)
writenode(doc, *curchild, node);
}
There are also a couple of API extensions I think
would be useful, but more on those later.
Thanks,
Greg
|
|
From: Rolf D. <dub...@pk...> - 2002-11-12 13:49:47
|
On Tuesday 12 November 2002 02:31 pm, Christophe de Vienne wrote: > In the next releases, it will change for sure, and quite much, but the > general design will remain the same (I mean people who used previous > releases shouldn't be disturbed with the new API). Great. > About API staying stable, we should have something quite stable by the end > of the year (I hope), Great. Thanx. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rol...@Ph... s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
949 messages has been excluded from this view by a project administrator.
