Hi,
I have noticed that the following CharCategory related tests fails when
running on MS:
CharCategoryTest.IsDigit
CharCategoryTest.IsLower
CharCategoryTest.IsNumber
CharCategoryTest.IsPunctuation
CharCategoryTest.IsSeperator
CharCategoryTest.IsSymbol
CharCategoryTest.IsUpper
Hi all,
This has happened several times now. I'm adding some code to a unit
test class and want to use the fully qualified name (e.g.
System.Web.UI.Adapters.PageAdapter) for some type, either because (a)
I'm only using the type in a couple spots and I'd rather not pollute
the namespace with a
Thanks for the feedback!
I've reduced the patch to those spots where I'm adding real value to the
code.
Please review.
The patch is a lot shorter now...
- Juraj
On Tue, 2008-01-08 at 22:34 -0500, Miguel de Icaza wrote:
I don't like to change working code unnecessarily just for your
Those values are different between .NET 2.0 and 1.x.
In mono land they are embedded in our runtime, which does not
differentiate 2.0 and 1.x.
If we have both tables it increases the size of the runtime
almost unnecessarily.
You can't fix the tests. You don't pay any attention to the
Mono test
Hi Marek,
Attached is a patch that
- fixes a issue in HttpRequest.UrlReferrer
(it is not supposed to throw when the headers contain an invalid url)
- adds a unit test for that issue
- simplifies the code in HttpCookieCollection.AllKeys
All unit tests pass.
May I commit?
- Juraj
Index:
Hello,
Agreed. If there's no objection I'd welcome such a change (or will do if
no one does but not sure when).
Atsushi Eno
Hi, Atsushi.
So right now Mono 2.0 behaves like .Net 1.1.
What about making Mono compatible with .Net 2.0? This will make Mono 1.1
behave like .Net 2.0 but since
Hi, Atsushi.
So right now Mono 2.0 behaves like .Net 1.1.
What about making Mono compatible with .Net 2.0? This will make Mono 1.1
behave like .Net 2.0 but since most of the changes are bug fixes and
improvements this should not be a bigger problem then the one we
currently have.
Thanks, Eyal.
Have you tried installing the Win32 build of Mono on WINE? then calling
the program with mono program.exe?
On Wed, 2008-01-09 at 12:14 -0200, rod marola wrote:
I am in need to run a program on GNU/Linux that is a .NET application
but make calls of Win32 native API. I would like to know if there
On Wed, 2008-01-09 at 01:53 -0800, Dean Brettle wrote:
This has happened several times now. I'm adding some code to a unit
test class and want to use the fully qualified name (e.g.
System.Web.UI.Adapters.PageAdapter) for some type, either because (a)
I'm only using the type in a couple spots
rod marola wrote:
I am in need to run a program on GNU/Linux that is a .NET application but
make calls of Win32 native API. I would like to know if there is any work
made towards integrating MONO with WINE, in order to make such calls
possible. I am interested in developing such integration,
- Original Message -
From: Atsushi Eno [EMAIL PROTECTED]
To: Eyal Alaluf [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Sent: Wednesday, January 09, 2008 2:38 PM
Subject: Re: [Mono-dev] Tests failures when running on MS.NET
Hello,
Agreed. If there's no objection I'd welcome
On Tue, 2008-01-08 at 22:02 -0500, Jonathan Pryor wrote:
Thank you for the background on why signal handlers can't be made to
work with the current Stdlib.signal implementation.
However...
I don't see why we need a new API to support this. It seems that we
could retrofit the existing
On Wed, 2008-01-09 at 11:52 -0500, Avery Pennarun wrote:
On 08/01/2008, Jonathan Pryor [EMAIL PROTECTED] wrote:
I don't see why we need a new API to support this. It seems that we
could retrofit the existing Stdlib.signal() API to use the
implementation you described, with one difference:
I like the patch a lot and am looking forward to see some final speed
results.
On the other hand when taking into account the importance and size of the
patch several people should look over it ;)
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL
I've been doing a lot of work on monodocer, and (for some unknown
reason) decided that the warning about the deprecation of
Mono.GetOptions was annoying so I thought I'd come up with a
replacement.
This replacement is NOT currently intended to be stable, nor to be
bundled with Mono itself for
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag
von Gert Driesen
Gesendet: Mittwoch, 9. Januar 2008 18:06
An: Atsushi Eno; Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Betreff: [SPAM] Re: [Mono-dev] Tests failures when running on
Whats up guys,
Ok so I needed to use a hyperlink in a gridview and so I decided that I
needed to compile form src, have had a problem getting mod mono working from
src for about a week now. No one responds to my forum messages so I'm
giving this a try. So after reading and reading and reading
Hi,
About the corlib.dll version problem: version 64 means you are using mono SVN,
not 1.2.6. The probable fix is to recompile and reinstall mono. You probably has
incompatible monoversions lying around on your system.
Zoltan
On Jan 9, 2008 9:21 PM, Nate Barger [EMAIL PROTECTED]
Hello,
Attached you'll find patches for CodeGenerator.cs and quite a few
System.CodeDom classes. Also included is a new file ICodeDomVisitor.cs
which belongs into System/System.CodeDom. ChangeLog entries are
included.
These patches replace those (ugly ones) I posted on Jan 6th. They
implement
Hi,
I like the original version which contained managed arrays better.
The new version might use less memory, but it
contains lots of unsafe code using pointers, and this will become a
problem when we want to do a security audit for
moonlight.
Are you sure?
Besides the potential KB/MBs of memory wasted for that we pay a startup
performance penalty so that it is probably at least 500% slower than now
(Yes that is 5 Mio). Imho for ANYTHING but running on the server this would
be completely useless. In that situation I'd actually
21 matches
Mail list logo
