Hi,
Can you please file a bug report in bugzilla.ximian.com, attaching a
simple test application that can be used to reproduce the issue?
The solution will be to be compatible with MS.NET, even if that means
not being fully compatible with the specs.
Lluis.
On dj, 2005-05-26 at 16:05 +0100, Hic
Hi Jordi, (and mono devs)
Mainsoft wish to invest some effort in testing System.Drawing.
We wish to enhance the test suite with an image compare component which will
compare the difference between the expected .NET image and the mono image.
The comparer (which we just started prototyping it) will
Hi,
Is there any official or unofficial but working way to determine what kind
of CLI runtime environment is executing the assembly?
There are at least three of them:
-Microsoft .NET Framework
-Mono
-DotGNU Portable.NET
They have different interfaces to low level runtime functionality and it is
Hi, Atsushi.
I want to propose the idea of policy regarding running tests before
commit for preventing regressions. I have to go right now for a few
hours, so I simply post the draft of README, if it's not clear enough,
we'll discuss it when I return. If everything is fine for you, let me
kno
Hi Andrew and Atsushi,
I suggest that all stand_alone test suites will output NUnit report.
This way they can be included in build, regression reports etc' .
-
Rafi
Mainsoft
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Beh
Hello,
There is a static method in the 2.0 .NET reflection API:
MethodInfo TypeBuilder.GetMethod (System.Type t, MethodInfo m)
there is no documentation on msdn, so I'll skip the link.
What it does is take instanciated generic type and a method taken from
the non instanciated generic type m.
On Mon, 2005-05-30 at 14:00 +0300, RafaelMizrahi wrote:
> Hi Andrew and Atsushi,
> I suggest that all stand_alone test suites will output NUnit report.
> This way they can be included in build, regression reports etc' .
It's probably enough that they return a non-0 exit status. That way, a
makefil
Hello,
I don't think your proposal changes anything. That's what we have
actually had.
Note that it not *me* to *accept* your proposal, since your
discussion is for the whole tests (and I don't think there is
any reason to limit the scope of discussion only for xml tests).
I want to propose the
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 En
On Mon, 2005-05-30 at 11:05 +0300, RafaelMizrahi wrote:
> Hi Jordi, (and mono devs)
> Mainsoft wish to invest some effort in testing System.Drawing.
> We wish to enhance the test suite with an image compare component which will
> compare the difference between the expected .NET image and the mono i
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 li
Atsushi,
I did not suggest to convert or to run them as NUnit,
I just suggest that it is better to have their output as NUnit report.
-
Mizrahi Rafael
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Monday, May 30, 2005 5:12 PM
Hi Rafi,
RafaelMizrahi wrote:
Atsushi,
I did not suggest to convert or to run them as NUnit,
I just suggest that it is better to have their output as NUnit report.
Well, then how better is it?
We don't have "time" data.
"asserts" are always "1".
There are "known failures" rather than "succ
Hello all
As a part of an effort to share a common code base between Mono and
Mainsoft, we've moved our System.Data development entirely to SVN.
Also we aim to have as more common code as possible, its completely
clear that because of our willing to base a connected mode
implementation on JDB
Hello again.
My goal is avoiding regressions while committing and during night builds
of System.XML assembly. In order to achieve this goal I propose to add
all known testsuites to run-test target (slow testcases will be disabled
by default).
The testsuites I want to include in addition to c
Hi Atsushi,
> We don't have "time" data.
If I understand you, "time" can be Now().
> "asserts" are always "1".
Why is that ? the stand_alone test suite report will have one test with an
assert for each xml test, that can pass or fail.
> There are "known failures" rather than "success"
In this ca
On Mon, 2005-05-30 at 18:44 +0300, Andrew Skiba wrote:
> Hello again.
>
> My goal is avoiding regressions while committing and during night builds
> of System.XML assembly. In order to achieve this goal I propose to add
> all known testsuites to run-test target (slow testcases will be disabled
../frontend/Interpreter.cs(101) error CS0117:
`Mono.Debugger.ThreadManager' does not contain a definition for
`TargetOutputEvent'
After a fresh checkout. Everything (mono/mcs/debugger) are uptodate
(rev. 45194).
Rodrigo
___
Mono-devel-list mailing list
Hi Rafi,
Ohh, ok, I should first say that I was talking about the results
on comparing NUnit's resulting xml (TestResult-*.xml) structures.
We don't have "time" data.
If I understand you, "time" can be Now().
Well, when it is about element, you are right.
"time" attribute on each element
My two cents:
I think this should apply to the rest of the code base: the only real
solution is to run everything with each build. The Mythical Man Month
comes to mind.
Excluding the slowest test will be risky. They are slow because they
hit critical/complex paths more often than not. A bug caugh
Ok, I have no problems with stylesheet'ing the stand_alone outputs into
NUnit xml report.
In fact, at mainsoft, we already did that before. We transformed the xml
tests catalog output to our reports system.
The least I can ask for is that they will be CSV format (comma separated
value).
rafi
---
Hi Brian,
Just delete that line in Interpreter.cs. Hopefully I will get the OK
from Chris Toshok to commit this change to SVN soon.
Peter
On Sun, 2005-05-29 at 12:29 +0100, Brian Pickles wrote:
> Hi,
>
> Have just downloaded the debugger from svn and when I compile it I get
> this error messag
Ben,
* Manually comparing the difference between 2 outputs (mono and msft) can
suffer from the same problems that the automatic comparer will (anti-alias
etc')
* A binary comparison (pixel to pixel) is too strict, and can fail a lot of
test.
This is why I wish to combine (or to GPL ;) a collection
El dl 30 de 05 del 2005 a les 11:05 +0300, en/na RafaelMizrahi va
escriure:
> Hi Jordi, (and mono devs)
Hi Rafael.
> Mainsoft wish to invest some effort in testing System.Drawing.
> We wish to enhance the test suite with an image compare component which will
> compare the difference between the e
At 11:05 AM 30/05/2005 +0300, Mizrahi Rafael wrote:
>Hi Jordi, (and mono devs)
>Mainsoft wish to invest some effort in testing System.Drawing.
>We wish to enhance the test suite with an image compare component which will
>compare the difference between the expected .NET image and the mono image.
>
Hi All,
Mainsoft wish to invest the time and contribute (and move) our System.Web
framework to mono SVN.
To remind you, the current framework cannot be contributed since it use
components like:
* Automation of Internet Explorer
* Microsoft XMLDiffPatch and SGML Reader(XHTML)(need to check l
Hello
I have been trying to build ( and cross build ) MONO for a PPC target and have
had quite a few problems. What is the state of MONO for PPC? One build I am
trying to perform ( not the cross-build ) is on a G4 box with the
following "/proc/version" (I know, it's a bit old):
Linux version 2
Hey,
attached is the patch with the changes.
Carlos.
El jue, 26-05-2005 a las 12:04 +0200, Zoltan Varga escribió:
> Hey,
>
> This looks ok, one comment:
> - it would be better to create a helper function in icall.c to avoid the code
> duplication.
>
>
RafaelMizrahi wrote:
* Microsoft XMLDiffPatch and SGML Reader(XHTML)(need to check license)
I've written something like that XML diff tool (which I hadn't seen
before) which you might be able to use instead, if you need to switch.
It doesn't detect reordering of XML nodes, but it picks out
I have a MethodInfo instance that I would like to emit into IL code.
Basically I need to emit a method call which takes a MethodInfo as an
argument, and the MethodInfo will be static when the IL code is
created. Is there an easy way to emit a MethodInfo instance?
The method I need to provide loo
With the Mono 1.1.7 Windows Installer, I can run programs okay from the
command-line, but I can not get it to work under Cygwin. Does anyone
know why? Even if I try to set it via mono --config, it still does not
work.
[EMAIL PROTECTED] ~/monosvn/sqlsharpgtk/sqlsharpgtk
$ mono --config E:\Mo
From: "Rodrigo B. de Oliveira"
My only problem is "Mono.Runtime" is seems not to been always there.
Could anyone suggest a better class name in mscorlib.dll?
I use Mono.Type but I'm not sure about its availability on earlier
releases.
I was looking for Mono.Type but the I realized it is Syste
On 5/30/05, Valient Gough <[EMAIL PROTECTED]> wrote:
> void Emit_MethodInfo( ILGenerator ig, MethodInfo method )
>
> It looks like it could be done by emitting code which looks something
> like "typeof([type]).GetMethod([name], [args])", but that is
> non-trivial and is not efficient:
Forgot to
On Mon, 2005-05-30 at 10:31 +0200, Kornél Pál wrote:
> Hi,
>
> Is there any official or unofficial but working way to determine what kind
> of CLI runtime environment is executing the assembly?
>
> There are at least three of them:
> -Microsoft .NET Framework
> -Mono
> -DotGNU Portable.NET
>
> T
Hello,
I think this should apply to the rest of the code base: the only real
solution is to run everything with each build. The Mythical Man Month
comes to mind.
It is not only about automated builds but also about hackers' builds.
Have you ever tried bugfixing and accumulative test run? Am p
I cooked this pair of classes for my use, binding simple arrays to my
TreeView widgets.
It may be a starting point either to something useful but still
packaged separately from gtk-sharp, or to grow TreeView/*Store into
something more palatable for those addicted to RAD simplicity.
Also a StringsL
36 matches
Mail list logo
