Re: [Mono-winforms-list] TextBox error
What version is your windows.forms? Remember that Windows.Forms is under heavy development. Miguel dont know how to check that, but Ive went to '/usr/lib/mono/gac/System.Windows.Forms' and there were these folders: 1.0.5000.0__b77a5c561934e089, 2.0.0.0__b77a5c561934e089. maybe its what You wanted. I use mono-1.1.12.1 and I didnt install any SVN version, just packages. and I know there are under havey developmnet, but there was the same problem with 1.1.10 version too, I have a feeling that the error is caused by one of the Mono dependencies, but dont know which one. Regards Sent from the Mono - WinForms forum at Nabble.com: Re: TextBox error ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Atsushi Eno
Sent: zaterdag 24 december 2005 3:47
To: Gert Driesen
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
Gert Driesen wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Atsushi Eno
Sent: vrijdag 23 december 2005 19:29
To: Gert Driesen
Cc: mono-devel-list@lists.ximian.com
Subject: RE: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: vrijdag 23 december 2005 18:54
To: Gert Driesen
Cc: [EMAIL PROTECTED]
Subject: RE: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
Comments inline
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Atsushi Eno
Sent: dinsdag 20 december 2005 6:26
To: Gert Driesen
Cc: [EMAIL PROTECTED]
Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
Hi,
The attached patch implements validation for xsl:output
attributes, and
adds unit tests.
Thanks!
I've also added some unit tests for XsltCompileException
and XslException.
Some test are marked NotWorking, due to bugs in Mono (for
which I'll report
bug reports later).
Some comments:
- You can try Mainsoft XSLT standalone tests. Go to
Test/System.Xml.Xsl/standalone and run make
run-test, then
you can find some regressions.
- Your code that checks attributes is good.
- indent in xsl:output is yes by default
when the output
method is html, unlike when it is xml
(no). That's why
we have string value instead of boolean in
XslOutput class.
I now use an enum for this internally, which allows us to
continue exposing
Intend as a bool.
- unindent cases in switches, i.e.
switch (foo) {
case bar:
...
Done.
- The reason why you marked [NotWorking] on
XsltExceptionTests.Constructor2() is because
xsltException = new XsltException
((string) null,cause);
Assert.AreEqual (string.Empty,
xsltException.Message);
fails, right? Hmm, It's still okay to keep
this test, but
I don't think it is kind of thing we should
fix. Having empty
message for an exception does not make sense.
I guess, most of the reason in NotWorking are
like that. If
so, you don't have to file bugs for them.
Just add some
comments in the sources.
I've fixes these bugs, and all tests now pass.
Lemme say again, it is not kind of thing we should fix.
After your
fix,
no one can understand what is going on from the Message property.
If you actually specify a zero-length or null message, then
this not really
that odd behaviour. No ?
No. Your test reports like
expected null
but actually XSLT compile error ...
that is, it expects not to explain that it is XSLT compile
error, but
not to tell
anything. Why on earth it could be better?
I'm not saying that an empty (or null) message is better.
But I'm saying
that it makes sense that if you construct an exception with
a null or
zero-length message, you actually get a zero-length message.
You are saying the same idea with different words.
BTW it should not be the reason you could change code in
advance without
further discussion.
All I did was, instead of reporting a bug report, I fixed
the issue
myself. I got the impression that you did not consider it
to be an important
bug (and I agree that its not), and that you wanted me to
file a bug report
as a reminder (for when you'd have time to fix it). I
thought I'd help you
by fixing it myself ... But well, guess not :(
You wrote a lot of helpful tests here and there, but it's
not. Also this
bug is usually not worthy of spending much words. You committed
changes without further discussion, which is a bad sign.
The only way to ensure compatibility, and to discover (undocumented) changes
between versions of .NET is by following the MS implementation as close as
possible. Only then can you have meaningful tests (that pass on both Mono
and MS.NET), which allow you to catch regressions/changes in either
implementation.
I don't want to waste more time of my vacation on this, so why don't you
just rollback all my changes ... I'm sure that would please you the most.
Regards
Gert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Dropping privileges in linux
Hi Robert, I understand that the problem is related to the linux setXid() implementation in a multi-threaded environment but I also realise that this behaviour shows only in certain situations. So can you please give me some more information about your linux and mono installations: - What version of mono are you using, did you compile mono yourself and if yes with what parameters? - What are your OS and kernel versions? - What are your glibc, pthreads and mono's libgc versions? Regards, Georgi Moskov On 12/21/05, Robert Jordan [EMAIL PROTECTED] wrote: Georgi, I am looking for a way to drop privileges of an assembly started as 'root' to a normal user. I found two possible solutions, but didn't succeed with either of them ... a) Using Syscall Syscall.setgid(1000); Syscall.setuid(1000); there 1000 is the uid and gid of an existing user. b) Using WindowsIdentity the way it is described here: http://pages.infinit.net/ctech/20040405-1133.html In either way I get a 'Segmentation fault' when I execute the assembly. I think there are some kind of memory permissions involved, because when I strace the execution of the assembly I see that the actual seuid and setgid calls are executed. Can anyone give me some hint what I'm doing wrong, or a way to surroud the problem? I'm running Debian 3.1 with mono 1.1.10. Both (a) and (b) work for me. You may delete root's .wapi directory and retry. If it still doesn't work, please post the native stack trace you can obtain with gdb. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Dropping privileges in linux
Hi Miguel, On 12/24/05, Miguel de Icaza [EMAIL PROTECTED] wrote: We recently discovered that Linux is pretty broken when it comes to setuid. The brokeness does not show up in most programs, but it *might* show up with things like Mono. The problem is that setuid in Linux has no kernel support beyond the current thread. So they had to come up with a hack which essentially uses a signal from the invoking thread to all the known threads of the application to change their uid. This works most of the time, but it does not work if any of the threads are suspended (for example if the GC has stopped the threads). Thanks for your answer, I think that now I understand the problem. I noticed that in mono the GC is implemented in the libgc library and as it is written in the readme the libgc implementation can safely work with threads and can also cope with signals by deferring them. Can you please tell me if there is any way to make the setXid() system calls work with mono (maybe by recompiling mono and/or libgc with different compile-time options)? Regards, Georgi Moskov ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
HA: [Mono-dev] System.Threading.Thread:MemoryBarrier() and XSP
Title: HA: [Mono-dev] System.Threading.Thread:MemoryBarrier() and XSP
Hi,
I built 1.1.12 for Solaris on SPARCv9. And it works.
To compleate the build I used gcc 3.4.2, GNU make, GNU tar.
The only undocumented feature I used - it requires enviroment variable CC to be defined (for me it was CC=gcc).
-Исходное сообщение-
От: [EMAIL PROTECTED] от имени [EMAIL PROTECTED]
Отправлено: Пт, 23.12.2005 15:53
Кому: mono-devel-list@lists.ximian.com
Тема: Re: [Mono-dev] System.Threading.Thread:MemoryBarrier() and XSP
Hi,
So, you were able to build mono 1.1.12 on Solaris??? Could you please tell the steps? Are you trying on Solaris x86??
When I try to compile I still have problems with exceptions-x86.c and the like...
pablo
- Original Message -
From: Vorobiev Maksim
To: mono-devel-list@lists.ximian.com
Sent: Thursday, December 22, 2005 5:22 PM
Subject: [Mono-dev] System.Threading.Thread:MemoryBarrier() and XSP
Good day.
I've built Mono 1.1.12 and XSP under Solaris, but there is a problem. Then I try to start XSP, it crashes with such message:
Unhandled Exception: System.NotImplementedException: The requested feature is not implemented.
in 0x0 unknown method
in (wrapper managed-to-native) System.Threading.Thread:MemoryBarrier ()
in 0x0004c System.Diagnostics.TraceImpl:InitOnce ()
in 0x4 System.Diagnostics.TraceImpl:get_Listeners ()
in 0x4 System.Diagnostics.Trace:get_Listeners ()
in 0x0008c Mono.XSP.Server:Main (System.String[] args)
Native implementation for MemoryBarrier contains (lines numbered with cat):
1360 void
1361 ves_icall_System_Threading_Thread_MemoryBarrier (void)
1362 {
1363 /* Should be implemented as a JIT intrinsic */
1364 mono_raise_exception (mono_get_exception_not_implemented (NULL))
;
1365 }
Listeners property implementation in TraceImpl calls this method (as in listed stack). How can I make XSP working? It seems that I need to rebuild Mono in some non-default way.
Thank you.
--
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Dropping privileges in linux
Hello, Thanks for your answer, I think that now I understand the problem. I noticed that in mono the GC is implemented in the libgc library and as it is written in the readme the libgc implementation can safely work with threads and can also cope with signals by deferring them. Can you please tell me if there is any way to make the setXid() system calls work with mono (maybe by recompiling mono and/or libgc with different compile-time options)? I do not know. I was just passing along the information that we found recently, as the debugger would misteriously lock up with the gnome-vfs. It turned out that the gnome-vfs does a *lot* of setuid calls when running as root. This was painful to find and in the end we added a workaround to the debugger. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
Comments inline
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Atsushi Eno
Sent: dinsdag 20 december 2005 6:26
To: Gert Driesen
Cc: [EMAIL PROTECTED]
Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
Hi,
The attached patch implements validation for xsl:output
attributes, and
adds unit tests.
Thanks!
I've also added some unit tests for XsltCompileException
and XslException.
Some test are marked NotWorking, due to bugs in Mono (for
which I'll report
bug reports later).
Some comments:
- You can try Mainsoft XSLT standalone tests. Go to
Test/System.Xml.Xsl/standalone and run make run-test, then
you can find some regressions.
- Your code that checks attributes is good.
- indent in xsl:output is yes by default when the output
method is html, unlike when it is xml (no). That's why
we have string value instead of boolean in XslOutput class.
I now use an enum for this internally, which allows us to continue exposing
Intend as a bool.
- unindent cases in switches, i.e.
switch (foo) {
case bar:
...
Done.
- The reason why you marked [NotWorking] on
XsltExceptionTests.Constructor2() is because
xsltException = new XsltException ((string) null,cause);
Assert.AreEqual (string.Empty, xsltException.Message);
fails, right? Hmm, It's still okay to keep this test, but
I don't think it is kind of thing we should fix. Having empty
message for an exception does not make sense.
I guess, most of the reason in NotWorking are like that. If
so, you don't have to file bugs for them. Just add some
comments in the sources.
I've fixes these bugs, and all tests now pass.
Please commit the patch after fixing them.
Committed in svn (revision 54780).
Gert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: vrijdag 23 december 2005 18:54
To: Gert Driesen
Cc: [EMAIL PROTECTED]
Subject: RE: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
Comments inline
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Atsushi Eno
Sent: dinsdag 20 december 2005 6:26
To: Gert Driesen
Cc: [EMAIL PROTECTED]
Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output
attributes.
Hi,
The attached patch implements validation for xsl:output
attributes, and
adds unit tests.
Thanks!
I've also added some unit tests for XsltCompileException
and XslException.
Some test are marked NotWorking, due to bugs in Mono (for
which I'll report
bug reports later).
Some comments:
- You can try Mainsoft XSLT standalone tests. Go to
Test/System.Xml.Xsl/standalone and run make run-test, then
you can find some regressions.
- Your code that checks attributes is good.
- indent in xsl:output is yes by default when the output
method is html, unlike when it is xml (no). That's why
we have string value instead of boolean in XslOutput class.
I now use an enum for this internally, which allows us to
continue exposing
Intend as a bool.
- unindent cases in switches, i.e.
switch (foo) {
case bar:
...
Done.
- The reason why you marked [NotWorking] on
XsltExceptionTests.Constructor2() is because
xsltException = new XsltException ((string) null,cause);
Assert.AreEqual (string.Empty, xsltException.Message);
fails, right? Hmm, It's still okay to keep this test, but
I don't think it is kind of thing we should fix. Having empty
message for an exception does not make sense.
I guess, most of the reason in NotWorking are like that. If
so, you don't have to file bugs for them. Just add some
comments in the sources.
I've fixes these bugs, and all tests now pass.
Lemme say again, it is not kind of thing we should fix. After your
fix,
no one can understand what is going on from the Message property.
If you actually specify a zero-length or null message, then this not really
that odd behaviour. No ?
Gert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Validation for xsl:output attributes.
Gert Driesen wrote: Comments inline -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: dinsdag 20 december 2005 6:26 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Hi, The attached patch implements validation for xsl:output attributes, and adds unit tests. Thanks! I've also added some unit tests for XsltCompileException and XslException. Some test are marked NotWorking, due to bugs in Mono (for which I'll report bug reports later). Some comments: - You can try Mainsoft XSLT standalone tests. Go to Test/System.Xml.Xsl/standalone and run make run-test, then you can find some regressions. - Your code that checks attributes is good. - indent in xsl:output is yes by default when the output method is html, unlike when it is xml (no). That's why we have string value instead of boolean in XslOutput class. I now use an enum for this internally, which allows us to continue exposing Intend as a bool. Please checkin this change as well. Some of Mainsoft XSLT tests started to fail after r54780. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
-Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: vrijdag 23 december 2005 20:31 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: Comments inline -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: dinsdag 20 december 2005 6:26 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Hi, The attached patch implements validation for xsl:output attributes, and adds unit tests. Thanks! I've also added some unit tests for XsltCompileException and XslException. Some test are marked NotWorking, due to bugs in Mono (for which I'll report bug reports later). Some comments: - You can try Mainsoft XSLT standalone tests. Go to Test/System.Xml.Xsl/standalone and run make run-test, then you can find some regressions. - Your code that checks attributes is good. - indent in xsl:output is yes by default when the output method is html, unlike when it is xml (no). That's why we have string value instead of boolean in XslOutput class. I now use an enum for this internally, which allows us to continue exposing Intend as a bool. Please checkin this change as well. Some of Mainsoft XSLT tests started to fail after r54780. Hmm, that change was part of r54780. I tried to run the Mainsoft XSLT tests, but patching of testsuite/TESTS/catalog-fixed.xml failed for some reason :( I've just added two more tests for XML/HTML indentation (indent explictly set to yes/no, and default value) that work fine on both Mono and MS.NET 1.x/2.0. Can you tell me what failures you get in the Mainsoft XSLT tests ? Sorry if I my changes caused regressions, but I really added lots of tests to make sure that they did not :(:( Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Validation for xsl:output attributes.
Gert Driesen wrote: -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: vrijdag 23 december 2005 20:31 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: Comments inline -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: dinsdag 20 december 2005 6:26 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Hi, The attached patch implements validation for xsl:output attributes, and adds unit tests. Thanks! I've also added some unit tests for XsltCompileException and XslException. Some test are marked NotWorking, due to bugs in Mono (for which I'll report bug reports later). Some comments: - You can try Mainsoft XSLT standalone tests. Go to Test/System.Xml.Xsl/standalone and run make run-test, then you can find some regressions. - Your code that checks attributes is good. - indent in xsl:output is yes by default when the output method is html, unlike when it is xml (no). That's why we have string value instead of boolean in XslOutput class. I now use an enum for this internally, which allows us to continue exposing Intend as a bool. Please checkin this change as well. Some of Mainsoft XSLT tests started to fail after r54780. Hmm, that change was part of r54780. I tried to run the Mainsoft XSLT tests, but patching of testsuite/TESTS/catalog-fixed.xml failed for some reason :( Then you could just ask me to see it, instead of ignoring it. I've just added two more tests for XML/HTML indentation (indent explictly set to yes/no, and default value) that work fine on both Mono and MS.NET 1.x/2.0. Can you tell me what failures you get in the Mainsoft XSLT tests ? 1) output_output05 : Different. 2) BVTs_bvt098 : Different. 3) ForwardComp__91848 : Unexpected exception: Especially 3) tells that previous solution was better (did you ever think about forward compatibility?): System.Xml.Xsl.XsltCompileException: file:///C:/cygwin/home/atsushi/svn/mcs/class/System.XML/Test/System.Xml.Xsl/s tandalone_tests/testsuite/TESTS/MSFT_Conformance_Tests/ForwardComp/91848.xsl(4,40) : --- System.Xml.Xsl.XsltException: 'sure' is an invalid value for 'indent' attribute.--- End of inner exception stack trace --- Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
It indeed is indent part matter. Anyways you don't have to touch the code anymore. I fixed the bug. There is no failing NUnit tests and no more regressions in standalone tests now. As I said, checking attributes on xsl:output and reject extraneous ones is indeed good, so I didn't want to revert the entire changes. So, now that all problems should have gone, I hope you have a merry X'mas (it's a bit too late for me and Santa does not seem coming to this bad boy ;-) Atsushi Eno -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 14:48 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 11:16 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: I submitted my initial patch the the mono-dev list, and you definitely reviewed this part. It is incorrect. It was the first reply I precisely pointed out that HTML output is broken here, and after my reply you committed what you haven't posted. Our behaviour now matches that of MSFT, is that bad ? We now have unit tests that validate our behaviour and that of MSFT (as these unit tests now pass on both implementations). You're saying that the MSFT implementation is not forward compatible, so I'd suggest filing a bug report with them. If they ever change the implementation, you'll immediately know as the unit tests will start failing. The standalone tests deny what you say. Note that our standalone tests are using whatever MS.NET outputs. Thus, there is something your code does not match with MS.NET, or MS.NET has changed their implementation. (BTW I never said that MS implementation is not forward compatible.) I guess MS does perform the same level of validation if the version is not equal to 1.0. Problem is that I cannot seem to succeed in executing the standalone XSLT test suite :( Yes; Sorry for the inconvenience. It just doesn't build fine under LF environment (you could still try cygwin environment as I as well as Mainsoft guys used to do). No problem, I'll tests it later (after x-mas). I made a quick fix (attached) which is however untested under Windows (this time) since the latest svn seems broken to run NUnit tests. I'm working on linux, so that's not a problem. After this patch there are still some failing tests which incorrectly expects Plants.xml and Outputtest.xml (you will understand what am saying here after seeing the test results). If our implementation does not match that of MSFT, then you can't have any unit tests that allow you to discover this. Another reason that string is better than enumeration (like Yes/No/Default/Other I guess) is that it becomes a mess when someone or ourself want to reuse the code to implement his or her own XSLT implementation that supports custom output.µ Again, I just followed the behaviour of the MS implementation here, and got your approval for the validation changes. What I asked is to fix the problem and commit. You might have thought you *fixed* it, but it is not right. Thus am asking you to revert it. I don't see any reason that you should stick to the broken changes. I'll see if I can find time to look into the broken changes. With broken I mean broken compared to the MSFT implementation. Is that ok for you ? If not, it might be best to revert all validation changes. Unless you find something soon, no, please just revert indent part from enum to string (it is the best that everyone would agree.) It doesn't make sense to just revert the indent part. Forward compatibility does not just apply to the intend attribute. I've added some tests to XslTransformTests that prove this. Can you tell me how I can access the XSLT version (as defined on the stylesheet document element) from XslOutput to make the validations optional if the version is different from 1.0 ? I really must be missing something here. If you don't want me to work on this, you could've said so from the start ... There is no reason you should feel you are rejected. I just keep pointing out that your fix is not right. Ok. Point taken. (I, of course, don't like the altitude that compatibility is God and it can throw better behavior away. I'm not here to reinvent MS bugs.) I agree with you. We should not implement MS bugs, but we should stick to their implementation as close as possible (as this will allow tests to pass on both implementations, therefore allowing us to catch
Re: [Mono-dev] [PATCH] Validation for xsl:output attributes.
Gert Driesen wrote: I submitted my initial patch the the mono-dev list, and you definitely reviewed this part. It is incorrect. It was the first reply I precisely pointed out that HTML output is broken here, and after my reply you committed what you haven't posted. Our behaviour now matches that of MSFT, is that bad ? We now have unit tests that validate our behaviour and that of MSFT (as these unit tests now pass on both implementations). You're saying that the MSFT implementation is not forward compatible, so I'd suggest filing a bug report with them. If they ever change the implementation, you'll immediately know as the unit tests will start failing. The standalone tests deny what you say. Note that our standalone tests are using whatever MS.NET outputs. Thus, there is something your code does not match with MS.NET, or MS.NET has changed their implementation. (BTW I never said that MS implementation is not forward compatible.) If our implementation does not match that of MSFT, then you can't have any unit tests that allow you to discover this. Another reason that string is better than enumeration (like Yes/No/Default/Other I guess) is that it becomes a mess when someone or ourself want to reuse the code to implement his or her own XSLT implementation that supports custom output.µ Again, I just followed the behaviour of the MS implementation here, and got your approval for the validation changes. What I asked is to fix the problem and commit. You might have thought you *fixed* it, but it is not right. Thus am asking you to revert it. I don't see any reason that you should stick to the broken changes. I really must be missing something here. If you don't want me to work on this, you could've said so from the start ... There is no reason you should feel you are rejected. I just keep pointing out that your fix is not right. (I, of course, don't like the altitude that compatibility is God and it can throw better behavior away. I'm not here to reinvent MS bugs.) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
-Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 11:16 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: I submitted my initial patch the the mono-dev list, and you definitely reviewed this part. It is incorrect. It was the first reply I precisely pointed out that HTML output is broken here, and after my reply you committed what you haven't posted. Our behaviour now matches that of MSFT, is that bad ? We now have unit tests that validate our behaviour and that of MSFT (as these unit tests now pass on both implementations). You're saying that the MSFT implementation is not forward compatible, so I'd suggest filing a bug report with them. If they ever change the implementation, you'll immediately know as the unit tests will start failing. The standalone tests deny what you say. Note that our standalone tests are using whatever MS.NET outputs. Thus, there is something your code does not match with MS.NET, or MS.NET has changed their implementation. (BTW I never said that MS implementation is not forward compatible.) I guess MS does perform the same level of validation if the version is not equal to 1.0. Problem is that I cannot seem to succeed in executing the standalone XSLT test suite :( If our implementation does not match that of MSFT, then you can't have any unit tests that allow you to discover this. Another reason that string is better than enumeration (like Yes/No/Default/Other I guess) is that it becomes a mess when someone or ourself want to reuse the code to implement his or her own XSLT implementation that supports custom output.µ Again, I just followed the behaviour of the MS implementation here, and got your approval for the validation changes. What I asked is to fix the problem and commit. You might have thought you *fixed* it, but it is not right. Thus am asking you to revert it. I don't see any reason that you should stick to the broken changes. I'll see if I can find time to look into the broken changes. With broken I mean broken compared to the MSFT implementation. Is that ok for you ? If not, it might be best to revert all validation changes. I really must be missing something here. If you don't want me to work on this, you could've said so from the start ... There is no reason you should feel you are rejected. I just keep pointing out that your fix is not right. Ok. Point taken. (I, of course, don't like the altitude that compatibility is God and it can throw better behavior away. I'm not here to reinvent MS bugs.) I agree with you. We should not implement MS bugs, but we should stick to their implementation as close as possible (as this will allow tests to pass on both implementations, therefore allowing us to catch regressions/changes in both implementations). Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
-Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 17:27 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: RE: [Mono-dev] [PATCH] Validation for xsl:output attributes. It indeed is indent part matter. Anyways you don't have to touch the code anymore. I fixed the bug. There is no failing NUnit tests and no more regressions in standalone tests now. It also applies to standalone and omit-xml-declaration attributes (see the new tests I added to XslTransformTests), and extranous attributes. As I said, checking attributes on xsl:output and reject extraneous ones is indeed good, so I didn't want to revert the entire changes. We still needed some additional changes to achieve forwards compatibility. Patch attached. So, now that all problems should have gone, I hope you have a merry X'mas (it's a bit too late for me and Santa does not seem coming to this bad boy ;-) Lol One more question: apart from lack of support for forwards compatibility (which is not directly related/limited to indent attribute), what was buggy about my change for indent attribute ? Gert -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 14:48 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 11:16 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: I submitted my initial patch the the mono-dev list, and you definitely reviewed this part. It is incorrect. It was the first reply I precisely pointed out that HTML output is broken here, and after my reply you committed what you haven't posted. Our behaviour now matches that of MSFT, is that bad ? We now have unit tests that validate our behaviour and that of MSFT (as these unit tests now pass on both implementations). You're saying that the MSFT implementation is not forward compatible, so I'd suggest filing a bug report with them. If they ever change the implementation, you'll immediately know as the unit tests will start failing. The standalone tests deny what you say. Note that our standalone tests are using whatever MS.NET outputs. Thus, there is something your code does not match with MS.NET, or MS.NET has changed their implementation. (BTW I never said that MS implementation is not forward compatible.) I guess MS does perform the same level of validation if the version is not equal to 1.0. Problem is that I cannot seem to succeed in executing the standalone XSLT test suite :( Yes; Sorry for the inconvenience. It just doesn't build fine under LF environment (you could still try cygwin environment as I as well as Mainsoft guys used to do). No problem, I'll tests it later (after x-mas). I made a quick fix (attached) which is however untested under Windows (this time) since the latest svn seems broken to run NUnit tests. I'm working on linux, so that's not a problem. After this patch there are still some failing tests which incorrectly expects Plants.xml and Outputtest.xml (you will understand what am saying here after seeing the test results). If our implementation does not match that of MSFT, then you can't have any unit tests that allow you to discover this. Another reason that string is better than enumeration (like Yes/No/Default/Other I guess) is that it becomes a mess when someone or ourself want to reuse the code to implement his or her own XSLT implementation that supports custom output.µ Again, I just followed the behaviour of the MS implementation here, and got your approval for the validation changes. What I asked is to fix the problem and commit. You might have thought you *fixed* it, but it is not right. Thus am asking you to revert it. I don't see any reason that you should stick to the broken changes. I'll see if I can find time to look into the broken changes. With broken I mean broken compared to the MSFT implementation. Is that ok for you ? If not, it might be best to revert all validation changes. Unless you find something soon, no, please just revert indent part from enum to string (it is the best that everyone would agree.) It doesn't make sense to just revert the indent part. Forward compatibility does not just apply to the intend attribute. I've added some tests to XslTransformTests that prove this. Can you tell me how I can access the XSLT version (as defined
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
-Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 14:48 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: zaterdag 24 december 2005 11:16 To: Gert Driesen Cc: [EMAIL PROTECTED] Subject: Re: [Mono-dev] [PATCH] Validation for xsl:output attributes. Gert Driesen wrote: I submitted my initial patch the the mono-dev list, and you definitely reviewed this part. It is incorrect. It was the first reply I precisely pointed out that HTML output is broken here, and after my reply you committed what you haven't posted. Our behaviour now matches that of MSFT, is that bad ? We now have unit tests that validate our behaviour and that of MSFT (as these unit tests now pass on both implementations). You're saying that the MSFT implementation is not forward compatible, so I'd suggest filing a bug report with them. If they ever change the implementation, you'll immediately know as the unit tests will start failing. The standalone tests deny what you say. Note that our standalone tests are using whatever MS.NET outputs. Thus, there is something your code does not match with MS.NET, or MS.NET has changed their implementation. (BTW I never said that MS implementation is not forward compatible.) I guess MS does perform the same level of validation if the version is not equal to 1.0. Problem is that I cannot seem to succeed in executing the standalone XSLT test suite :( Yes; Sorry for the inconvenience. It just doesn't build fine under LF environment (you could still try cygwin environment as I as well as Mainsoft guys used to do). No problem, I'll tests it later (after x-mas). I made a quick fix (attached) which is however untested under Windows (this time) since the latest svn seems broken to run NUnit tests. I'm working on linux, so that's not a problem. After this patch there are still some failing tests which incorrectly expects Plants.xml and Outputtest.xml (you will understand what am saying here after seeing the test results). If our implementation does not match that of MSFT, then you can't have any unit tests that allow you to discover this. Another reason that string is better than enumeration (like Yes/No/Default/Other I guess) is that it becomes a mess when someone or ourself want to reuse the code to implement his or her own XSLT implementation that supports custom output.µ Again, I just followed the behaviour of the MS implementation here, and got your approval for the validation changes. What I asked is to fix the problem and commit. You might have thought you *fixed* it, but it is not right. Thus am asking you to revert it. I don't see any reason that you should stick to the broken changes. I'll see if I can find time to look into the broken changes. With broken I mean broken compared to the MSFT implementation. Is that ok for you ? If not, it might be best to revert all validation changes. Unless you find something soon, no, please just revert indent part from enum to string (it is the best that everyone would agree.) It doesn't make sense to just revert the indent part. Forward compatibility does not just apply to the intend attribute. I've added some tests to XslTransformTests that prove this. Can you tell me how I can access the XSLT version (as defined on the stylesheet document element) from XslOutput to make the validations optional if the version is different from 1.0 ? I really must be missing something here. If you don't want me to work on this, you could've said so from the start ... There is no reason you should feel you are rejected. I just keep pointing out that your fix is not right. Ok. Point taken. (I, of course, don't like the altitude that compatibility is God and it can throw better behavior away. I'm not here to reinvent MS bugs.) I agree with you. We should not implement MS bugs, but we should stick to their implementation as close as possible (as this will allow tests to pass on both implementations, therefore allowing us to catch regressions/changes in both implementations). I don't think you agreed with me on this case. You are still saying that showing empty message is better than XSLT compile error because it is MS compatible. Am not interested in general thoughts since I am sure that we will never agree. You might be right on that one ! just kidding ;-) I agree that an empty message is not good, but you must also agree that creating an Exception with an empty message is not good (and should not be done anyway). So, I really think this is an academical discussion. You don't want an XsltCompileException with no message ?
Re: [Mono-dev] mod_mono on Windows
Hello Angel, I'm glad to hear that we are one issue shorter in order to release a full win32 compliant mod_mono ... Thanks to the nice work of all mono hackers/developers/contributors ... Em Sex, 2005-12-23 s 18:22 +0100, Angel Marin escreveu: Hi, Alexandre Rocha Lima e Marcondes escribi: * With some releases you can configure the directives with spaces and backslashes and then in the next one the behavior changes, the directive that accepted spaces, makes mono fail and the one that gave problems starts accepting them, for example on 1.1.10 MonoDocumentRootDir does not work if you configure it with a path that has spaces, mono gives exceptions until you use the old 8.3 format for the path. On 1.1.9 MonoExecutablePath gave similar problems, but in 1.1.10 it works. (on a first impression I would say it could be some platform path mapping glitch on the base classlib) With 1.1.12.1 all settings play well with spaces and backslashes, and I haven't found any regressions, so looks like this is no longer an issue :) -- Regards, Alexandre Rocha Lima e Marcondes P4 Tecnologia e Desenvolvimento Humano [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.p4tecnologia.com alexandre.p4tecnologia.com Projetos: MonoBrasil MonoBASIC ACBr Freedom ERP To validate this message's signature follow the instructions: http://www.cacert.org/index.php?id=3lang=en_US smime.p7s Description: S/MIME cryptographic signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
It indeed is indent part matter. Anyways you don't have to touch the code anymore. I fixed the bug. There is no failing NUnit tests and no more regressions in standalone tests now. It also applies to standalone and omit-xml-declaration attributes (see the new tests I added to XslTransformTests), and extranous attributes. Mmm, did you ever mention it when you posted the patch and before committing your massive changes which were mostly just changing CRLF/LF and message format changes in SVN? One more question: apart from lack of support for forwards compatibility (which is not directly related/limited to indent attribute), what was buggy about my change for indent attribute ? Am too lazy so I just paste it again. It is incorrect. It was the first reply I precisely pointed out that HTML output is broken here, and after my reply you committed what you haven't posted. You could have just run standalone tests and see what happens. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [PATCH] Validation for xsl:output attributes.
... and here's the patch ;-) Sorry for the noise ! It looks good. Please apply exactly the same patch by the time you commit anything else. Thanks, Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] System.Data.Common.DbDataAdapter
Hi, Anyone have any clue to as when this class will be implemented? It is a fairly usefull class - especially the fill function :) Or does anyone have some code that will give the same result? (i.e. given connection and SQL statement result in a DataTable with named columns) I'm trying to use ASP.NET 2.0 Thanks // Fredrik ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Opening user's browser
On Thu, 2005-12-22 at 19:55 -0500, Aaron Bockover wrote: Not sure of the scope of your app, but you could of course enable the Gnome call conditionally. The unix version for trying a chain of browsers seems really hackish, but I don't know of an alternative aside from Gnome.Url.show. feed the url to 'gnome-open', and on the mac you want to use 'open' its pretty simple. --Todd ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mary Chirstimas!
Hi all, I know that this is a international list and not all people have same religion or calendar but... Mary Christimas, a happy new year and a big success in 2006!! Everaldo. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Opening user's browser
On 12/24/05, Todd Berman [EMAIL PROTECTED] wrote: On Thu, 2005-12-22 at 19:55 -0500, Aaron Bockover wrote: Not sure of the scope of your app, but you could of course enable the Gnome call conditionally. The unix version for trying a chain of browsers seems really hackish, but I don't know of an alternative aside from Gnome.Url.show.feed the url to 'gnome-open', and on the mac you want to use 'open'its pretty simple. This works perfectly for me, thank you! =D!--Todd Cya,Felipe.-- Quem excele em empregar a força militar subjulga os exércitos dos outrospovos sem travar batalha, toma cidades fortificadas dos outros povos sem asatacar e destrói os estados dos outros povos sem lutas prolongadas. Deve lutar sob o Céu com o propósito primordial da 'preservação'. Desse modo suasarmas não se embotarão, e os ganhos poderão ser preservados. Essa é a estratégia para planejar ofensivas.-- Sun Tzu, em A arte da guerra ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
