[Mono-list] Re: There are still problems with the XMLDocument class...
This bug has been marked as duplicated and solved, but I'm still not able to compile NAnt on Linux: Sure. It goes diffent logic. I assume I fixed it in cvs now, so please check it again. Oops, it seems missing the points. Just wait a moment... Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: There are still problems with the XMLDocument class...
This bug has been marked as duplicated and solved, but I'm still not able to compile NAnt on Linux: Sure. It goes diffent logic. I assume I fixed it in cvs now, so please check it again. Oops, it seems missing the points. Just wait a moment... I tried to reproduce on Linux (Redhat 8.0), but I couldn't found such problem with the latest cvs ;-( I would ask you whether testcase XmlTextReaderTests.ExternalDocument() failed or not. Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: There are still problems with the XMLDocument class...
Hello, Rien a faire... I've checked out Mono from CVS and reinstalled from scratch, but when trying to compile NAnt, I always get the following error messages: Hmm... it is curious that you made it well on Gentoo, but couldn't build on Redhat9. I guess each of them might be incorrect ;-) Have you tried to check out NAnt and compile it? I've been trying nant-20030621. I have no problem to build it (with some customization), but could not succeed to use it, because of some config stuff (it seems undocumented as yet...). As to mcs-included nant (mcs/nant), I could build, and it reads .build file well (though I couldn't make all good). I'll report if I could find the reason. Thanks, Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: How often is the class status page updated?
Hello, Why don't we build XSLT into the C# tool using System.Xml.Xsl? I would volunteer to do this if it will get the thing working on Linux. I think what Miguel saying is to rewrite this simple transform.js in C#, isn't it? No stylesheet extension seems to be used in the stylesheet. It is 3 minutes hacking. Atsushi Eno transform.cs Description: Binary data
[Mono-list] Re: request for trial: DTMXPathNavigator
To run with Mono, download the archive, rename XPathDocument.cs.txt to XPathDocument.cs and replace existing XPathDocument with it, and copy the others to anyplace to be compiled (e.g. System.Xml.XPath). I forgot to say that you have to add those new files to list.unix to build them ;) Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] request for trial: DTMXPathNavigator
Hello, Recently I was working on a new XPathNavigator and XPathDocument and has done most of the work (it is very small stuff). Now I would ask any of you to try before I check them into cvs. I temporarily put the sources here: http://www24.brinkster.com/ginga/DTMXPathNavigator/ http://www24.brinkster.com/ginga/DTMXPathNavigator/DTMXPathNavigator_0.2.zip To run with Mono, download the archive, rename XPathDocument.cs.txt to XPathDocument.cs and replace existing XPathDocument with it, and copy the others to anyplace to be compiled (e.g. System.Xml.XPath). To run with MS.NET, create XPathNavigator referencing Usage section of the above site. The best thing I want to hear is whether it works well as an input to XslTransform. (Note that current mono's xslt doesn't use XPathNavigator in transformation.) In some (most?) cases, it runs much faster than MS.NET's XPathDocument. Regards, Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] revised XML status description
Hello, Some people might be interested in (or confused about) the current status of XML, so I revised the status description what I once posted before. Wishing it helps you. Atsushi Eno xml-feature Description: Binary data
[Mono-list] Re: Possible bug in XmlDocument
Hi, I think I've found a bug in function RemoveChild from XmlNode. I don't know if it really is a bug because i hadn't enough time to test it on ms .net. It was a bug of either XmlNode.RemoveChild() or XmlNodeListChildren. It seems a bit complicated. I'll look tomorrow. Thanks, Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-docs-list] Re: Monodoc bug Redux
Hello,
If the XmlReader fails with genuine XML, we should have a test case, and
work from that to fix it.
I agree. Sorry to say I couldn't make monodoc nor libxslt on windows
yet and have no enough time. (Hmm... as to xslt, only I need to do is
copy rename libxslt.dll to xslt.dll and copy it to SYSTEM32, isn't it?
libxml2.dll is OK ...)
I just noticed that Monodoc is in fact failing for most Xml documents,
with a crash like this:
At least this XslTransform patch would be well. (It is the same
patch that I sent to Hector to try. It seems work well.)
And ecma-provider.cs... Hmm, cannot connect to anoncvs.
It is ecma-provider workaround:
- transformed_doc.Load (transformed);
- return transformed_doc.InnerXml;
+ XmlDocument transformed_doc = new XmlDocument ();
+ transformed_doc.LoadXml (dummy_root /);
+ while (!transformed.EOF) {
+ XmlNode n = transformed_doc.ReadNode (transformed);
+ if (n != null)
+ transformed_doc.DocumentElement.AppendChild (n);
+ }
+ return transformed_doc.DocumentElement.InnerXml;
Atsushi Eno
XslTransform.patch
Description: Binary data
[Mono-list] Re: patch: XML Deserialization
Hi Elan. I sent this patch almost a week ago and have not seen it be merged into CVS or rejected. Hence this keep-alive email 8-) Thanks for your patch and sorry to be too late! Unfortunately I don't know much of xml serializer and now cannot make enough time to check all your code. Would you like to write some testcases? I prepared an unsolicited template and your name is already set here :) Regards, Atsushi Eno XmlSerializerTests.cs Description: Binary data
[Mono-list] XmlDocument.SelectSingleNode(ancestor::foo)
Hi,
I found that mono's XPath feature is incompatible with MS .NET.
XPath specification defines ancestor axis as to find ancestor nodes
by document reversal order. MS's XmlDocument.SelectSingleNode ()
doesn't, while Mono's current implementation does.
This method is documented as always return a node by document
(non-reversal) order. (I wonder if there are rational reason for
them to break W3C recommendation...)
using System;
using System.Xml;
public class Test
{
public static void Main(string[] args) {
XmlDocument doc = new XmlDocument ();
doc.LoadXml (foo a='1'foo a='2'foo a='3'bar
//foo/foo/foo);
XmlElement bar = doc.SelectSingleNode (//bar) as XmlElement;
XmlElement foo = bar.SelectSingleNode (ancestor::foo) as
XmlElement;
Console.WriteLine (foo.GetAttribute (a));
foo = bar.SelectSingleNode (ancestor::foo [1]) as XmlElement;
Console.WriteLine (foo.GetAttribute (a));
}
}
Interesting to say, the last SelectSingleNode(ancestor::foo[1])
is consistent with XPath recommendation (returns 3).
I cannot say that it is bug of mono, but this inconsistency
will be problematic.
Regards,
Atsushi Eno
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: MemoryStream problem
Hi, It may (or may not) be a MemoryStream issue. The current CryptoStream implementation is very rudimentary - it was able to run some samples from MS but it's still far from complete. It's also one of the few crypto class that still doesn't have any unit tests. I assume it is because MemoryStream.Close() resets its internal buffer and CryptoStream.FlushFinalBlock() closes the stream. I don't know that Close() disposes internal buffer by ECMA spec. MS stream apparently holds. Regards, Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: someone, please clear out that patents issue
Hello, Even if keeping going on any researches and discussions are significant, this list might not be proper place to go on. Almost all subscribers, including myself, are interested in more technological topics. That is also part of the reason why I am not interested in the debate, because at this point *every* scenario is possible, and having an argument about this under the scenario of *anything goes* is a rather futile experiment. Yes. We need not apparently fight with Microsoft. We should only *correct* the patent application to their benefits. It is harmful for any patent owners that their patents turned out to be invalid in later stages. We might not have to deny *all* of the claims in that patent application. I consider them to be off-topic because there is no certainty at this point about what the effects are. That is where my unwillingness stems from. I would have not problem in discussing real solutions once we knew what conditions we were operating under, hence my suggestion to have a patent attorney look at these issues as a preamble for an informed debate. Sure. I personally feel sorry to you, I already knew well that you don't like these talks. Nonetheless, I dare post in this list because many people who interested in the news are saying: How about Mono? Obviously this project is expected to do something. Then how about creating dotnet-innovation-historical or dotnet -tech-talk mail-list? (Hmm... maybe much better name for it ...) It treats .NET technological studies including prior technologies. For such list, that patent claims are *good start* to discuss because they are regarded as new technologies by Microsoft itself. It don't have to talk about patent issues -- of course, sometimes, some participants may want to talk about patent itself :) You might think that we need attorney to discuss more. However as I wrote, there are many things we can do as only developers, and maybe cannot be done by .NET-amateur attorney and/or agents. They are skilled in writing patent applications, but once the application was written, such highly special skill isn't required to read the basics of the claims. I think Anyone can contribute to the research and studies. Best wishes, Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] RE: System.Xml.Serialization.XmlSerializer
Hello, That's a shame :(, but at least we have a sample to fix it. Who is working on the XmlSerializer again? Currently no person is working continuously with it. Whoever noticed anything is commiting. I'm not kinda serializer person, so sorry to say I may miss the point. Well first of all, why should [XmlInclude(typeof(S))] not work, since it works on an abstract class that cannot be constructed as well. I'm a compiler constructor myself, and would argue that an abstract class with just abstract methods/properties and an interface should be very similar if not equal. At runtime the class of the property is known and it can be serialized as such. OK, now I know I should separate two problems. (1)If a target field/property is specified as an interface or an abstract class, then that serialization must be impossible. But (2)even if the instance-typed field is instantiated as a concrete class, and if the serialization attribute for it specifies a concrete class, then it may be (or should be) possible to serialize. You are talking about (2). Then it seems better that when it is going to serialize an interface field/property, XmlSerializer only rejects if the target is not accessible, right? Thanks a lot for that link. I already saw that, and hoped that the mono implementation would be better. Sorry to say, these areas hadn't proceed so fast as you expected ;-) Oops, I must write up plans for XML... Thanks, -- Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
