gmane.comp.gnome.mono.devel

Re: Incoming changes to Mono.Simd

Jonathan Pryor — 2008-12-04T01:37:28

Silly question, but why? Since Mono.Simd will only be accelerated under Mono, and Mono supports C# 3, I don't see much use for the restriction. Furthermore, even if you did want to use Mono.Simd under .NET, and you wanted to use VS.NET 2005 (.NET 2.0), that's still no reason to avoid using extension methods -- you just need to bundle Mono's System.Core.dll with your app (which will allow .NET to resolve the ExtensionAttribute type), and invoke the extension method as a static method (extension methods can still be called as static methods, they don't need to be called as instance methods). So I really don't see the point in avoiding extension methods. - Jon

Re: MIPS port update

Miguel de Icaza — 2008-12-04T00:57:43

Hello Mark! These are great news! Will be waiting for the rest of the tests to work ;-) Miguel.

Re: Incoming changes to Mono.Simd

StApostol — 2008-12-04T00:26:20

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Incoming changes to Mono.Simd

Jonathan Pryor — 2008-12-03T21:16:46

Then there's documentation-wise, in which the use of extension methods permits at-a-glance comparison on which operations are supported on the various Vector* types (instead of needing to compare Vector* type member documentation between types for comparisons). - Jon

Re: Incoming changes to Mono.Simd

Rodrigo Kumpera — 2008-12-03T17:59:23

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Compile monodevelop-debugger from SVN on Debian

jago — 2008-12-03T17:41:57

I also had this problem. I installed libncurses5-dev on Ubuntu and it worked. j Alexander M. Batishchev wrote:

Re: Incoming changes to Mono.Simd

Alan McGovern — 2008-12-03T17:24:17

Well, I'd vote for using the method which is *cleaner* and easier to use/maintain regardless of whether it's an API breaking change or not. I personally love the extension methds on the array types. I would also much prefer a.AddWithSaturation (b) rather than the fully qualified way it is done now. Out of interest, why do we use static methods currently rather than instance methods? Would using instance methods instead of extension methods complicate things jit-wise, as API-wise it'd be essentially the same. Alan.

Re: Incoming changes to Mono.Simd

Hurliman, John — 2008-12-03T17:12:24

I think more extension methods would be a nice addition to Mono.Simd. I'm pretty sure everyone who is using Mono.Simd at this point is prepared for bugs, quirks, and breaking API changes. John

Incoming changes to Mono.Simd

Rodrigo Kumpera — 2008-12-03T16:18:58

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Proposed change to TestDriver.dll

Zoltan Varga — 2008-12-02T17:56:16

Hi, The regression tests can be ran using mono --regression , which avoids calling any code in TestDriver.dll. This is the recommended way of running the JIT tests. Zoltan On Tue, Dec 2, 2008 at 11:01 AM, Mark Mason upwardaccess.com> wrote:

Re: String.GetHashCode on Mac

Bill Holmes — 2008-12-02T16:07:41

David, We may have hit this before. See http://www.nabble.com/String.GetHashCode-Discussion.-to18496625ef1367.html#a18496625 I lost tack of this issue after that thread but maybe it will help someone else remember. -bill On Mon, Dec 1, 2008 at 9:25 AM, David Suarez codicesoftware.com> wrote:

Proposed change to TestDriver.dll

Mark Mason — 2008-12-02T10:01:58

Hello all, I'd like to propose the following change to TestDriver.dll. The purpose of this patch is to avoid using the DateTime class unless timings are explicitly called for. DateTime pulls in a lot of additional infrastructure code which may cause the test harness itself to fail. With this change, it's a lot easier to run the regression tests such as basic.cs & others with a JIT port in progress. [Which is where the MIPS port is right now. There's something failing waaaay down in the guts of DateTime, daylight savings time computations, and such. It'd be a lot better to be able to uncover these problems with the simple test cases in basic*.cs] Thanks in advance, Mark Index: TestDriver.cs =================================================================== --- TestDriver.cs (revision 120080) +++ TestDriver.cs (working copy) < at >< at > -13,7 +13,6 < at >< at > bool do_timings = false; bool verbose = false; int tms = 0; - DateTime start, end = DateTim

MIPS port update

Mark Mason — 2008-12-02T01:39:09

Hello all, The MIPS port is coming along nicely. Hello, World! now works, the tests in basic.exe all pass if run manually and not by using the reflection technique that the test harness normally uses. There's still a lot to do - a lot of the logic that was in the old style brg files for MIPS still needs to be ported to the new JIT, and there's a number of additional tweaks that are needed, but it should at least be fairly straightforward from here on out. All of this is checked into svn. I'll be out of town for a few days w/o access to this email account (but still reachable at mason< at >broadcom.com). Cheers, Mark

Re: Tuning of assemblies in the mcs module

Jb Evain — 2008-12-01T23:25:34

Fine with me :) Oh well, I guess my french sophisticated palate has some other course to deal with in our menu :) I'll just go for the first option then, decoupling the tuner and the tuning of the net_2_1 assemblies. Thanks,

Re: Tuning of assemblies in the mcs module

Miguel de Icaza — 2008-12-01T22:59:36

Not worth the effort, and it does not matter that much. Just because we have class libraries in mcs/class does not mean that this is the only place that they could be generated from. I do not have a problem with mcs/tools generating the assemblies. Now, if mcs/tools is too unpleasant to the sophisticated palate of some people we could add an extra stage in mcs/secondstagelibraries or something like that and build the libraries there. Miguel.

Re: SPAM-LOW: Re: NUnit migration and test failure status

Charlie Poole — 2008-12-01T18:49:10

Hi Atsushi, I'm confused about what change you could be refering to. NUnit-console still outputs error summaries to the console in 2.4.8 (and 2.5 for that matter). But some things have changed in the 18 releases since 2.2. :-) I'm guessing, but I suspect you have redirected output using -out on the command line. In 2.4.8, this *only* redirects the actual test output, not the summary report, which still goes to stdout. If you want everything in one file, stop using -out and use shell redirection instead. If you want to separate the summary from the test output, then you can use both methods, like... nunit-console ... -out:TestDetails.log > TestSummary.log If this doesn't help, send me some more info and we'll either figure out how to do it or change for 2.4.9. Charlie

String.GetHashCode on Mac

David Suarez — 2008-12-01T14:25:46

Hi, I've run into a problem with the String.GetHashCode method in macosx (10.5.3, intel). The point is I get the same hashcode for very different strings, apparently only taking into account the last 7 chars of the string. This happens with mono 2.0 installer. Consider this test case: using System; namespace hashtest { class Class2 { private static string[] testStrings2 = new string[] { "something to worry about", "ing to worry about", "to worry about", "orry about", "y about", " about" }; [STAThread] static void Main(string[] args) { foreach (string s in testStrings2) PrintHash(s, s.GetHashCode()); } private static void PrintHash(string str, int hash) { Console.WriteLine(" hash [{1}] line: [{0}]", str, hash.ToString("X8")); } } } Running on mac, I get this result: hash [9DA57994] line: [someth

Re: NUnit migration and test failure status

Atsushi Eno — 2008-12-01T11:57:41

Another limitation brought by this migration is that to see meaningful TestResult-*.log you will have to install xsltproc (in general in libxslt) as nunit-console itself does not output test failure summaries to console output anymore and we sort of needed xslt output. It is not required unless you run tests. And if you run tests it will be anyways needed to see meaningful logs. Atsushi Eno Atsushi Eno wrote:

Re: SPAM-LOW: Re: NUnit migration and test failure status

Charlie Poole — 2008-12-01T07:26:40

As you may remember from Madrid, I'm planning a GTK version of NUnit as part of the new NUnit 3.0 Platform. I thought I'd call it nunit-gtk and depending on licensing I might be able to use pieces of gnunit, so the work won't be lost in any case. Charlie

Re: NUnit migration and test failure status

Atsushi Eno — 2008-12-01T04:14:41

NUnit migration was actually more painful than I have expected :( and now I have to drop gnunit from mono-tools since it is based on existing nunit20 and does not build with nunit24 anymore. I have removed it from the build process of mono-tools, and possibly it will be removed from mono-tools at some stage unless its build get fixed. Winforms version of NUnit GUI should work if you build it or copy executables. Atsushi Eno

Re: Typed dataset serialization still failing in mono 2.0.1

marcos b — 2008-12-01T01:56:00

I didn't. In fact, I attached it twice :). Look at the end of the message and you'll see a link "Andrés G. Aragoneses"-2 wrote: