Hi,
(B
(BI want monkeyguide to support better localization. Here is a patch
(Bfor stylesheet and makefile to make it possible. To build localized
(Bhandbook, for example, use "make LOCALE=ja" .
(BHere's an example sshot:
(Bhttp://monkey.workarea.jp/tmp/20050203/monkeyguide-ja-sshot.jpg
(B
parameters. Does the updating happen
in such cases?
If it looks good, I'll commit this patch later.
Atsushi Eno
Index: monodocer.cs
===
--- monodocer.cs (revision 47922)
+++ monodocer.cs (working copy)
@@ -848,13 +848,13
is well-tailored for
monodoc would be better.)
Atsushi Eno
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
xsl:output method=text /
xsl:strip-space elements=* /
xsl:template match=/
xsl:for-each select=*
xsl:choose
xsl:when test=name()='Type
+ submission form, or kind of
web applications).
If it is just a matter of input syntax, no further thought is needed ;-)
Atsushi Eno
___
Mono-docs-list maillist - Mono-docs-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-docs-list
for
practical use (it unexpectedly merges sequential paras), so am
really going to rewrite the code in C#.
Atsushi Eno
using System;
using System.Globalization;
using System.IO;
using System.Text;
using System.Xml;
namespace Monodoc
{
public class WikiStyleDocParser
- add old wrong XmlTextWriter to be used in monodocer to replace
correct XmlTextWriter.
Grab XmlTextWriter.cs and XmlTextWriterOpenElement.cs from
branches/mono-1-1-16/mcs/class/System.XML/System.Xml.
Which would be better?
Atsushi Eno
___
Mono
for months :-/ /top-secret
Atsushi Eno
___
Mono-docs-list maillist - Mono-docs-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-docs-list
in the future, NET_2_0 will be still defined.
Cheers,
Atsushi Eno
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
commit the patch (or feel free to apply it).
Atsushi Eno
Index: System.Windows.Forms/XplatUIStructs.cs
===
--- System.Windows.Forms/XplatUIStructs.cs (ãªãã¸ã§ã³ 92488)
+++ System.Windows.Forms/XplatUIStructs.cs (ä½æ¥ã³ãã
get its UI show up, but I can differentiate
its XIM-ish mode and
non-XIM-ish mode by not seeing keyboard inputs to a textbox.
I still need some more changes, but I think those changes could be applied.
Atsushi Eno
Index: System.Windows.Forms/X11Keyboard.cs
startup sometimes.
- XFilterEvent() is required for non-KeyPress/KeyRelease event for some
(or every?) IM engine(s)
especially as for ClientMessageEvent.
Atsushi Eno
Index: System.Windows.Forms/X11Keyboard.cs
===
--- System.Windows.Forms
/xlibi18n/* or modules/im/* ?) please give us them :)
Atsushi Eno
Doug Rintoul wrote:
Atsushi Eno wrote:
Hello,
The first problem has to do with the tracking of the control, shift,
and alt key. These keys will currently get stuck because if
FosterParent filters the key release event
Hello,
Doug Rintoul wrote:
Atsushi Eno wrote:
Thanks for the details. Though I don't think I completely understand
the second issue
(XIM event order matter), I am persuaded. Your patch is in svn (along
with my patch
of course too).
Thanks for this. I am assuming that only the patch
Oops, I've already applied it to svn.
FYI the patch file contained the compared svn revision, like:
--- System.Windows.Forms/X11Keyboard.cs (revision 100698)
+++ System.Windows.Forms/X11Keyboard.cs (working copy)
Atsushi Eno
Doug Rintoul wrote:
Atsushi Eno wrote:
Hello,
Doug Rintoul wrote
, as there are still pending fixes on bugzilla[*2] and there
seems another MDI issue that needs fix too.
Atsushi Eno
*1 http://monoport.com/9806
*2 #325033 and #387693
Atsushi Eno wrote:
Hi,
I'm posting it as I've been stuck with this issue for couple of days and
I still don't have a fix.
Now
for bugs I wrote earlier are applied, I could
finally checkin this XIM change.
Atsushi Eno
Atsushi Eno wrote:
Hello,
After fixing couple of issues, I found a fix for this
WaitForHwndMessage()
issue. The situation is that (in some cases?) WM_SHOWWINDOW could be
processed
synchronously inside
That's even greater news :) Thanks for your effort over TextBox hell.
I lately found that libgdiplus on OSX fails to render characters
with Japanese default font. I wonder if pango-based implementation
may solve the issue (I seem to have filed a bug as #371861).
Atsushi Eno
Jonathan Anderson
Hello,
In case you need multi byte text input, here is my patch:
https://bugzilla.novell.com/show_bug.cgi?id=501276
(I'm posting here just to notify that a patch exists.)
Atsushi Eno
___
Mono-winforms-list maillist - Mono-winforms-list
a feature is not good but it should be
done for everything else.
Attached such a (simple) workaround. Feel free to apply, or in case no
one cares, I'll do it.
Atsushi Eno
diff --git
a/mcs/class/Managed.Windows.Forms/System.Windows.Forms.CarbonInternal/Dnd.cs
b/mcs/class/Managed.Windows.Forms
for asmx and WCF.
All dependent changes other than this patch is already made in mcs trunk.
Please review - I feel sorry to have such a large change though... ;/
Atsushi Eno
Index: System.Web.Script.Services/RestHandler.cs
drew Skiba wrote:
(B Hello,
(B
(B Atsushi Eno wrote:
(B
(BI'm investigating this case, and it confuses me a little bit. Code
(B
(B XmlElement b = d.CreateElement ("b");
(B b.SetAttribute ("xmlns","probe");
(B
(Bproduces element b wi
Hi,
(B
(BI noticed that TypeBuilder never throws InvalidOperationException
(Bwhen CreateType() is invoked twice. It is because of this change:
(B
(B2004-12-06 Ben Maurer [EMAIL PROTECTED]
(B* TypeBuilder.cs (CreateType): Creating a type twice does not
(Bthrow in msft.
(B
Ben Maurer wrote:
(B On Fri, 2005-03-11 at 04:41 +0900, Atsushi Eno wrote:
(B
(BHi,
(B
(BI noticed that TypeBuilder never throws InvalidOperationException
(Bwhen CreateType() is invoked twice. It is because of this change:
(B
(B2004-12-06 Ben Maurer [EMAIL PROTECTED]
(B
Hi,
(B
(BI wonder which is the best way to have "almost duplicate" but
(Bdifferent parser/tokenizer pair for XSLT "Pattern" apart from
(BXPath (I'm going to fix a bug that allows improper XPath for
(BXSLT pattern e.g. namespace::*).
(B
(BWith my way to do, they could be generated by
Hi,
(B
(BHmm, I think there is no preprocessor directive for jay. And those
(Bfiles are compiled at a time in shape of .cs files.
(B
(BAtsushi Eno
(B
(BBen Maurer wrote:
(B On Thu, 2005-03-17 at 06:43 +0900, Atsushi Eno wrote:
(B
(BHi,
(B
(BI wonder which is the best way to have
Hi,
(B
(BHmm, I think there is no preprocessor directive for jay. And those
(Bfiles are compiled at a time in shape of .cs files.
(B
(B By that I mean, maybe we could add support for such a directive. I would
(B think that it would not be too hard of an addition.
(B
(BOkay. So I made tiny
Hi Marek,
Oh, what you pointed out is really important. Because if all
the contributors don't want to fix any of assemblies because of
the number of warnings, it is so important matter for all the
hackers and thus we can let people hacking on mono.
OK, I'll look into all the warnings.
Atsushi Eno
mcs should not let developers to be puritan
that believes ALL unused members MUST be eliminated.
- As I noted above, there are unexpected unused field check
that at least csc does not regard as should-be-warned.
Atsushi Eno
Hi Hari,
Ohh, sure ;-) Will take this easy way2go.
Thanks,
Atsushi Eno
Raja R Harinath wrote:
Hi Eno,
Atsushi Eno [EMAIL PROTECTED] writes:
Okay. So I made tiny patch for jay (am so lazy to make big changes).
Attached patch for jay adds -d BlahBlah to insert #define BlahBlah
on top of the output
. It sounds like design principle
difference.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Hello,
(B
(BMiguel de Icaza wrote:
(B Hello,
(B
(BI am preparing the 1.1.5 release; Please let me know what features
(B should be highlighted in this new release since our 1.1.4 release.
(B
(BXML:
(B- XSLT QA task; Andrew Skiba and Konstantin Triger from
(B
.
Atsushi Eno
Konstantin Triger wrote:
Hello Eno,
I looked into XmlUrlResolver and found this code:
// Methods
public override object GetEntity (Uri absoluteUri, string role,
Type ofObjectToReturn)
{
if (ofObjectToReturn == null)
ofObjectToReturn = typeof
impossible?
Anyways if you mean Compiler.cs, it looked unnecessary so I just
removed it. If you mean ScriptCompilerInfo.cs, we can't remove
the line (it is in use for msxsl:script support), so please post
a patch for the Java switch you guys want to add.
Cheers,
Atsushi Eno
Hi,
Yes, that's what I meant. Other similar thing is at
System.Xml.Schema/BuiltInDatatype.cs:36. Does it really need
System.Security.Cryptography?
Yes. It uses FromBase64Transform.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list
Eno
Andrew Skiba wrote:
Atsushi Eno wrote:
Yes, that's what I meant. Other similar thing is at
System.Xml.Schema/BuiltInDatatype.cs:36. Does it really need
System.Security.Cryptography?
Yes. It uses FromBase64Transform.
I see that FromBase64Transform was inserted there at svn revision 22077.
What
= new ArrayList ();
XmlDocument doc = new XmlDocument ();
al.Add (doc.CreateElement (foo));
al.Add (doc.CreateAttribute (attr));
al.Add (doc.CreateEntityReference (ent));
XmlNode [] nodes = (XmlNode []) al.ToArray (typeof (XmlNode));
}
}
Atsushi Eno
Hi Miguel,
I think r42885 broke cs0208 tests in mcs/errors (verified that
r42884 does not break them and r42885 does).
Atsushi Eno
Original Message
Subject: [Mono-patches] r42885 - trunk/mcs/mcs
Date: Tue, 12 Apr 2005 21:38:46 -0400 (EDT)
From: Miguel de Icaza [EMAIL PROTECTED
Hello,
(B
(BKonstantin Triger wrote:
(B Hello,
(B
(B Attached the RegionDataSet.cs and a region.xml files.
(B When the following code is run, this type should be outputted:
(B tests.RegionDataSet+RegionRow
(B
(B static void testTypedDS() {
(BRegionDataSet regionDataSet1 =
estination type.
(B in 0x0008b tests.RegionDataSet:Main ()
(B
(B I hope this clarifies my suggestion
(B
(B This is my first participation within your List, so i hope i did it right
(B
(B Regards,
(B Gerhard Rittweger
(B
(B Atsushi Eno schrieb:
(B
(BHello,
(B
(BKonstantin T
to identify more...
Atsushi Eno
Help Please,
My site is down.
I just pulled down the latest code form svn and now
only 1 of my web sites works, whichever one is
requested first. I think this is a regression as I
recall this problem in a previous version of mono.
I have 2 sites
http
().
If the problem still happens, it is possible 1) to build xsp with
mcs -debug+ and 2) run mono with --debug option so that the
stack trace contains error location?
Thanks,
Atsushi Eno
Joe Audette wrote:
I sent this to the list but its taking a while for it
to show up so thought I would forward directly
it helps.
Atsushi Eno
Joe Audette wrote:
Hi Atsushi,
I pulled down the code from svn again but I got rev
43146 not 43147
after build and restart apache
http://www.mojoportal.com works
http://www.joeaudette.com works
htpp://demo.mojoportal.com broken with same error as
before
at least the 2 most
Hi,
I made a fix for this problem; the type for Finalize() is not
System.Object unless the type which is being added is System.Object.
Atsushi Eno
Raja R Harinath wrote:
Hi,
Gert Driesen [EMAIL PROTECTED] writes:
As of recently, I get the following warning (numerous times) when using mcs
svn
version of mono you are talking about here,
and we won't fix anything without concrete examples.
Regards,
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Andrew Skiba wrote:
(B take care of timestamps to achieve minimal necessary build
(B
(B If no one objects, I will commit
(B
(BThis patch looks ok too. Thanks.
(B
(BAtsushi Eno
(B___
(BMono-devel-list mailing list
Andrew Skiba wrote:
(B This patch fixes the following things:
(B
(B * eliminates the need to run xsltproc on catalog.xml to produce
(B catalog-out.xml
(B * fixes the hack that distinguishes between Xalan and Microsoft
(B compliance tests
(B * changes the output of the test: instead of
Hi Andrew,
(B
(B - static readonly ArrayList skipTargets;
(B + static readonly ArrayList skipTargets = new ArrayList (new
(B string
(B[] { });
(B + static readonly ArrayList knownFailures = new ArrayList (new
(B string
(B[] { });
(B...
(B -
Hi,
(B
(BIs there any problem if we move Stack and Queue (and related tests)
(Bin System.Collections.Generic from mscorlib.dll to System.dll?
(B
(BIn .NET 2.0 beta2, they are moved to System.dll.
(B
(BAtsushi Eno
(B___
(BMono-devel-list mailing
Hello,
(B
(B If it looks good, I'll apply the previous patch and put this one.
(B
(BI've checked in this new stuff. Please tell me if any of you
(Bgot problem, especially who use crypto XML stuff and/or custom
(Bremoting configuration stuff.
(B
(BSebastien, maybe we had better do the same
Hello,
(B
(BWith related to XSLT standalone tests, I talked with Andrew and Ben,
(Band we think about having separate "standalone_tests" module, since
(Bthose tests are likely to increate mono's tarball size extraneously
(Bwhen we just put them inside mcs module.
(B
(BThings we should note
/Coding_Guidelines )
I don't think having '_' everywhere rule is enforceable. Some
people want to maintain field names equivalent to that of MS.NET
to enable runtime serialization interoperability.
Atsushi Eno
Konstantin Triger wrote:
Hello Uma,
You are absolutely right: having the same code base is very
comparing strings) and
thus the output should be like the reference output.
XSLTFunctions__emptyParameters
This is also rejected in MS.NET.
We should try to compile the stylesheet and expect error here.
I have no idea why it worked fine before and it does not today.
Atsushi Eno
). If it is allowed in MS.NET, maybe attached patch will
fix it.
Lluis: maybe you can check the patch sanity?
Atsushi Eno
Index: XmlCustomFormatter.cs
===
--- XmlCustomFormatter.cs (revision 45046)
+++ XmlCustomFormatter.cs
Hi,
(B
(BI created a patch for mcs that 1) adds Location property to
(BParameterBase, and 2) removes Location property from Parameters.
(BOn Parameter class there was a comment:
(B
(B//TODO: Add location member to this or base class for better error
(Blocation and all methods
proving my precise location
(B patch which I created once upon a time.)
(B
(B Atsushi Eno
(B___
(BMono-devel-list mailing list
(BMono-devel-list@lists.ximian.com
(Bhttp://lists.ximian.com/mailman/listinfo/mono-devel-list
Hi,
I have never tried to use Delphi.NET but it is really weird if it
really tries to validate(?) non-CLSCompliant types while it should
not (MiniParser is not CLS compliant) and rejects them because
of that.
It sounds like a bug in Delphi.NET.
Atsushi Eno
Matthijs ter Woord (meddochat
;)
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Hi,
We will never add those massive standalone tests into NUnit test
(note that they are going to be separate module).
But it still sounds nice to develop such integration as long
as it is *optional* run.
Note that the discussion also applies to the whole standalone
test things BTW.
Atsushi
Oh, forgot to mention the patch. It is fine, especially it is nice
to have the description on the test output in README :-)
Atsushi Eno
Better yet, have the whole patch, I hope, it's self-explaining. If not,
we'll talk.
___
Mono-devel-list mailing
which only has
True or False. It would be mapped to [Category (NotWorking)]
which is not reported in our NUnit tests. Or alternatively it
could be mapped to [Ignore], but there are another set of
ignore.lst file which holds tests to be ignored.
Atsushi Eno
results (known failures, ignore-lists etc.)
into NUnit-like output? It would be simpler than modifying existing
output and (more importantly) keep things more human-readable.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
and critical tests can be included.
I have no idea what you have in mind, but I don't think there are
such concrete thresholds.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel
That's even worse. We don't want to ship it in our mono-*.tar.gz.
Atsushi Eno
Yaacov Akiba Slama wrote:
Hello,
The testsuite from w3c is only 675KB if packaged as a tar.bz2 (instead
of 1.5 MB for the zip).
A solution would be to add the tar.bz2 to the source tree.
What do you think ?
--yas
or fixme.lst, or we might miss regressions
in the future.
You can see similar messages in mcs (compiler) tests.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
further check).
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
)
{
- ReadXml (reader);
+ ReadXml (reader, XmlReadMode.DiffGram);
}
Is this correct?
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel
Yeah, I knew. However what I meant is
String.CompareOrdinal (
s1.ToLower (invariantCulture),
s2.ToLower (invariantCulture))
It is not good for performance but safe.
Atsushi Eno
Konstantin Triger wrote:
Hi Eno,
The CompareOrdinal does not have a case
in the
comparison (and sometimes culture-sensitive comparison is buggy, at
least with MS.NET) or regarded equivalent to other character
sequences.
Try
Console.WriteLine (String.Compare (\u00C6, AE,
true, CultureInfo.InvariantCulture));
under MS.NET.
Atsushi Eno
in the near future.
Atsushi Eno
Hans Kratz wrote:
Hi!
I just implemented support for hyperlinking Mono exception stacktraces
in X-develop and noticed that line numbers in stacktraces are off by one.
E.g. for the following program...
---
class Program
{
static void Main(string[] args
Hello,
Hans Kratz wrote:
Hi!
Atsushi Eno wrote:
I was (well, I should say am) working on that matter (aka
precise location patch) but currently it is not done yet.
I created mcs patch 6 months ago and mcs has greatly improved,
it is not impossible to merge directly (and not successful).
I
Atsushi Eno wrote:
Hi,
String comparison with
invariant culture does not mean that it has no other side effect
than case insensitivity. With CultureInfo dependent (including
InvariantCulture) there are some characters that are ignored in the
comparison (and sometimes culture-sensitive
Hi Andrew,
Andrew Skiba wrote:
Atsushi Eno wrote:
Well, it is not analysis ;) Any progress or difficulty on fixage?
The old testsuite reported some regressions when .net throws an
exception. I think, we can ignore them for now.
Are they really such testcases? I think those tests listed up
Hello,
Andrew Skiba wrote:
Atsushi Eno wrote:
Are they really such testcases? I think those tests listed up
there are bug in your sed script. The previous catalog.xml which
I manually edited was pointing to the correct file names. Just
compare old catalog.xml and your catalog-fixed.xml.
Can
up ignoring overflow.
It is design failure of Windows.
Am going to introduce that crappy comparison into mono though :-/
You can check that java.text.Collator in JDK never regards them
as equal.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel
Yeah, please go ahead. Thanks.
Atsushi Eno
Andrew Skiba wrote:
Hi, Eno.
I want to commit TARGET_JVM for roundtrip bug.
Andrew.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel
Hi,
Andrew Skiba wrote:
Atsushi Eno wrote:
insensitice, MS.NET will pass this testcase. Anyways this is not
Mono's regression and should be ignored instead.
That's what I said ;-)
The old testsuite reported some regressions when .net throws an
exception. I think, we can ignore them
It will result in the same if we forget the existence itself ;-)
Anyways the switch is simple and there are not so many places
that TARGET_JVM is used.
Andrew: I think there was a similar problem in XmlConvert.cs.
Thanks,
Atsushi Eno
Eyal Alaluf wrote:
Maybe we should use a new define here
If you want please feel free to do so.
Atsushi Eno
Eyal Alaluf wrote:
Hi, Atsushi.
O.K. Let's use the TARGET_JVM then. Shouldn't we ad some kind of FIXME or
MonoTODO in this case? I'd like to still keep track of this issue and get rid
of the '#if TARGET_JVM' when Mono and Grasshopper behave
testcase?
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
.
Atsushi Eno
Matthijs ter Woord (meddochat) wrote:
Hi Atsushi,
I get your point. MiniParser isn't CLS Compliant.
[Error] E2421 Imported identifier 'Names' conflicts with 'names' in
'MiniParser.AttrListImpl'
[Error] E2421 Imported identifier 'Values' conflicts with 'values' in
'MiniParser.AttrListImpl
Performed:2162
Passed:1424
Failed:709
Regressions:488
Fixed:66
and from the latest 45852
*
Total:2162
Performed:2162
Passed:1865
Failed:268
Regressions:0
Fixed:10
Of course I tested both on the same environment and the same
runtime (version and configuration).
Atsushi Eno
Andrew Skiba wrote
to whitespace
Maybe description on what is logged onto failed.lst (in README)
would be helpful? :-)
Thanks
Atsushi Eno
Andrew Skiba wrote:
Hello.
Atsushi Eno wrote:
I need concrete number unlike just saying there are regressions.
I did not just say there are regressions. I spent few hours
it is
very easy; just comment out them.
That happens because Assert can be interpreted as
Assertion.Assert() instead of NUnit.Framework.Assert.
Am not sure if Suresh likes that solution ;-)
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list
to examine those non-CLSCompliant types. If you were right,
then ANY types that is not CLSCompliant must not contain such
case-insensitively equivalent names, no?
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http
, the namespace of the document element is OK.
Yeah, currently namespace handling is fine only at the
declaring element.
Thanks,
Atsushi Eno
Joshua Tauberer wrote:
Atsushi,
A while back I raised some issues with entity handling, but I think some
problems remain with entities in namespaces
Forgot to mention.
MS.NET throws, Mono does not. What says the standard?
There is no W3C standard about XmlTextReader.Normalization.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman
Hi again,
Atsushi Eno wrote:
Hi Joshua,
Yeah, it is likely to happen. Yesterday I found that there is a
problem on namespace handling in DTDValidatingReader and
XmlValidatingReader with kangaroo's help. I think there should
be something similar to what XmlTextReader does. It's not a tiny
fix
that the patch makes things inconsistent.
Here I attach it so that anyone can try.
Atsushi Eno
using System;
using System.Xml;
public class Test
{
public static void Main ()
{
string xml = !DOCTYPE root [!ELEMENT root
(#PCDATA)*!ENTITY ent 'val']root attr='a ent
that .NET does not work fine). There are some cases
that (at least) XmlTextReader.Read() and XmlDocument.Load() differ
in rejecting input xml or not e.g. XmlDocument.Load() rejects
undeclared entities while XmlTextReader does not.
Atsushi Eno
___
Mono
them).
For now the workaround is
- run make under mcs (to build default profile)
- run make under mono
The breakage seems to happen between 46034 (works fine) and
46041 (broken). Martin, any ideas why this happens?
Atsushi Eno
Gert Driesen wrote:
Hi,
Apparently the bootstrap
as it is the top-level content of the
document element. I am not aware of practical cases that such
schemas in further depth are consumed (since 99.999% of .NET
DataSet users is not likely to have such documents).
Atsushi Eno
___
Mono-devel-list mailing
).
Atsushi Eno
Atsushi Eno wrote:
Hello Konstantin,
Konstantin Triger wrote:
Hi Eno,
I committed the code before I saw your comments on Boris email.
Actually I missed it at all and Boris forwarded it to me. In any case
I didn't want to ignore it and would like, with your help, create the
best
will return the table.
In fact the same discussion also applies to string Normalization
tables (to support String.Normalize() introduced in .NET 2.0).
Any good ideas for this problem?
Thanks,
Atsushi Eno
Index: corlib.dll.sources
.
Please feel free to commit. Thanks.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Oops, am sorry that was my bad that I failed to commit the first
patch and it was kept uncommitted :(
Atsushi Eno
Andrew Skiba wrote:
Atsushi Enomoto ([EMAIL PROTECTED]) wrote:
Don't remove ChangeLog entry BTW.
I did not remove anything from ChangeLog: svn diff -r46346:46347
A bug
Ok, it is an interesting tip. Now checked in svn as r46380. Thanks.
Atsushi Eno
I think this needs to be changed to make it optimal for the normal case.
Gonzalo's situation is a corner case: 1 huge field in the middle of tons
of stuff. However, normally, there are many, small, similarly sized
Hey,
Ben Maurer wrote:
On Wed, 2005-06-22 at 04:26 +0900, Atsushi Eno wrote:
3. run make. It will automatically downloads some files
from some sites. For now without this step the build
b0rks.
Of course, this will need to be changed ;-).
duh ;-) It will be checked
in several breakage in
standalone tests.
Thanks,
Atsushi Eno
Index: Test/System.Xml/XmlTextReaderTests.cs
===
--- Test/System.Xml/XmlTextReaderTests.cs (revision 46370)
+++ Test/System.Xml/XmlTextReaderTests.cs (working copy
for now, and once the
table is stable, moving it into C if that makes a substantial
performance difference.
Ok, then right now I need to hack on corlib Makefile to run make
under Mono.Globalization.Unicode.
Atsushi Eno
___
Mono-devel-list mailing list
be taken care as a whole. Please feel free to
commit this patch but I'll look into them at some stage again.
Thanks
Atsushi Eno
Konstantin Triger wrote:
Hi Eno,
I don't see it in mailing list so resending.
I made the changes we talked about, bt it turns out they probably won't
make a big diff (see
1 - 100 of 1323 matches
Mail list logo
