<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.comp.gnome.mono.devel">
    <title>gmane.comp.gnome.mono.devel</title>
    <link>http://blog.gmane.org/gmane.comp.gnome.mono.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29894"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29893"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29892"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29891"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29890"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29889"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29888"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29887"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29886"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29885"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29884"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29883"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29882"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29881"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29880"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29879"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29878"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29877"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29876"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29875"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29894">
    <title>MIPS port update</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29894</link>
    <description>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&lt; at &gt;broadcom.com).

Cheers,
Mark
</description>
    <dc:creator>Mark Mason</dc:creator>
    <dc:date>2008-12-02T01:39:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29893">
    <title>Re: Tuning of assemblies in the mcs module</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29893</link>
    <description>
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,

</description>
    <dc:creator>Jb Evain</dc:creator>
    <dc:date>2008-12-01T23:25:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29892">
    <title>Re: Tuning of assemblies in the mcs module</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29892</link>
    <description>

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.
</description>
    <dc:creator>Miguel de Icaza</dc:creator>
    <dc:date>2008-12-01T22:59:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29891">
    <title>Re: SPAM-LOW: Re: NUnit migration and test failure status</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29891</link>
    <description>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 &gt; 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

</description>
    <dc:creator>Charlie Poole</dc:creator>
    <dc:date>2008-12-01T18:49:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29890">
    <title>String.GetHashCode on Mac</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29890</link>
    <description>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: [something to worry about]
  hash [9DA57994] line: [ing to worry about]
  hash [9DA57994] line: [to worry about]
  hash [9DA57994] line: [orry about]
  hash [9DA57994] line: [y about]
  hash [1DA57994] line: [ about]

It seems to me that the String.GetHashCode in String.cs is not getting 
called, because this method works fine (I tested separately). Is this 
happening to anybody else? Any clue on what code is being called on the 
mac for getting the hash code of strings?

Thanks,

David

Is this happening to anybody else??
</description>
    <dc:creator>David Suarez</dc:creator>
    <dc:date>2008-12-01T14:25:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29889">
    <title>Re: NUnit migration and test failure status</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29889</link>
    <description>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:
</description>
    <dc:creator>Atsushi Eno</dc:creator>
    <dc:date>2008-12-01T11:57:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29888">
    <title>Re: SPAM-LOW: Re: NUnit migration and test failure status</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29888</link>
    <description>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

</description>
    <dc:creator>Charlie Poole</dc:creator>
    <dc:date>2008-12-01T07:26:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29887">
    <title>Re: NUnit migration and test failure status</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29887</link>
    <description>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


</description>
    <dc:creator>Atsushi Eno</dc:creator>
    <dc:date>2008-12-01T04:14:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29886">
    <title>Re: Typed dataset serialization still failing in mono 2.0.1</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29886</link>
    <description>
I didn't. In fact, I attached it twice :). Look at the end of the message and
you'll see a link



&amp;quot;Andrés G. Aragoneses&amp;quot;-2 wrote:

</description>
    <dc:creator>marcos b</dc:creator>
    <dc:date>2008-12-01T01:56:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29885">
    <title>Re: MD not packaging binaries correctly though it couldbe mono at fault</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29885</link>
    <description>2008/11/30 Paul &lt;paul&lt; at &gt;all-the-johnsons.co.uk&gt;:

This is a MonoDevelop issue, not a mcs issue, and it's fixed post-1.0
(well before 1.9.1 anyway).

VS uses the parent directory as a "namespace" for the resource by
default. Note that even in MD 1.0, you can override the resource name
using the property pad.

</description>
    <dc:creator>Michael Hutchinson</dc:creator>
    <dc:date>2008-11-30T23:02:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29884">
    <title>Re: MD not packaging binaries correctly though it could be mono at fault</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29884</link>
    <description>_______________________________________________
Mono-devel-list mailing list
Mono-devel-list&lt; at &gt;lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
</description>
    <dc:creator>Paul</dc:creator>
    <dc:date>2008-11-30T21:11:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29883">
    <title>Re: MD not packaging binaries correctly though it couldbe mono at fault</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29883</link>
    <description>Ah, now this i have seen before. I think the problem is that when you
compile in resources with mono, the namespace isn't prefixed. So if
you compile in "foo.bmp", in mono you access it with "foo.bmp". If you
compile with VS, it appends a namespace by default, so you access with
"MyApplication.Resources.foo.bmp" or something like that.

I hit this issue a long enough time ago, so I don't remember the
specifics really. It'd be worth filing a bug report on this if this
really is the issue.

Alan.

2008/11/30 Paul &lt;paul&lt; at &gt;all-the-johnsons.co.uk&gt;:
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list&lt; at &gt;lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
</description>
    <dc:creator>Alan McGovern</dc:creator>
    <dc:date>2008-11-30T20:25:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29882">
    <title>Re: Typed dataset serialization still failing in mono2.0.1</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29882</link>
    <description>
You forgot the attachment.

But let's rather create a bug, and attach a simple .cs file that exposes
the problem.

Thanks,

Andrés


marcos b wrote:
&gt; TypedDataSetTest.rar </description>
    <dc:creator>Andrés G. Aragoneses</dc:creator>
    <dc:date>2008-11-30T19:47:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29881">
    <title>Re: MD not packaging binaries correctly though it could be mono at fault</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29881</link>
    <description>_______________________________________________
Mono-devel-list mailing list
Mono-devel-list&lt; at &gt;lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
</description>
    <dc:creator>Paul</dc:creator>
    <dc:date>2008-11-30T19:37:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29880">
    <title>Re: MD not packaging binaries correctly though it couldbe mono at fault</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29880</link>
    <description>What error? You're too vague with what is going wrong for a solution
to be proposed.

Alan.

2008/11/30 Paul &lt;paul&lt; at &gt;all-the-johnsons.co.uk&gt;:
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list&lt; at &gt;lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
</description>
    <dc:creator>Alan McGovern</dc:creator>
    <dc:date>2008-11-30T19:14:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29879">
    <title>MD not packaging binaries correctly though it could be mono at fault</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29879</link>
    <description>_______________________________________________
Mono-devel-list mailing list
Mono-devel-list&lt; at &gt;lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
</description>
    <dc:creator>Paul</dc:creator>
    <dc:date>2008-11-30T19:05:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29878">
    <title>Re: System.Data.OracleClient broken in mono 2.2 Preview1?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29878</link>
    <description>Do you have a simple, repeatable test case?  

In your cursor that is returned, what data types are involved?  Check to make sure OracleParameter can handle the data types you are being returned in the cursor.  For example, intervals are not yet implemented.  Character data involving multi-byte character sets are problematic.

You could not load a DataTable from a cursor prior to Mono 2.0.  The bits to support should be in there for Mono 2.2.


--- On Thu, 11/27/08, kray &lt;kray&lt; at &gt;landmarkdigital.com&gt; wrote:

</description>
    <dc:creator>Daniel Morgan</dc:creator>
    <dc:date>2008-11-30T01:26:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29877">
    <title>Re: build fails if AOT is disabled</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29877</link>
    <description>Hi Zoltan,

You sure?

I'm getting unresolved symbols in mini-trampolines.c ..all 3 unresolved functions have aot int their name...

Regards,
Miha

"Zoltan Varga" &lt;vargaz&lt; at &gt;gmail.com&gt; wrote on 29.11.2008 18:04:04:



</description>
    <dc:creator>Miha Vrhovnik</dc:creator>
    <dc:date>2008-11-29T19:49:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29876">
    <title>Re: build fails if AOT is disabled</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29876</link>
    <description>Hi,

  This is now fixed in HEAD and the 2.2 branch.

                Zoltan

On Sat, Nov 29, 2008 at 4:40 PM, Miha Vrhovnik &lt;miha.vrhovnik&lt; at &gt;cordia.si&gt; wrote:
</description>
    <dc:creator>Zoltan Varga</dc:creator>
    <dc:date>2008-11-29T17:04:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29875">
    <title>Re: Patch for monotools Gendarme makefiles</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29875</link>
    <description>
Thanks Paul. I'll discuss with the packagers next week since it seems
that half of the packaged mono applications installed on my system are
inside /usr/lib and not /usr/lib64.

Beside that there are two problems:

1) you're changing the documentation source from $(prefix) to $(libdir)
which is either untested or you have a monodoc that behave differently
than mine (since it's part of the applications that reside
under /usr/lib)

2) most of the patched files (all rules) are against the generated
Makefile.in files (not the Makefile.am files that resides in SVN).

﻿--- mono-tools-2.2/gendarme/rules/Gendarme.Rules.BadPractice/Makefile.in        2008-11-29 11:41:15.000000000 

Thanks
Sebastien


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list&lt; at &gt;lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
</description>
    <dc:creator>Sebastien Pouliot</dc:creator>
    <dc:date>2008-11-29T15:48:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29874">
    <title>build fails if AOT is disabled</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.mono.devel/29874</link>
    <description>Hi,

Both trunk and mono 2.2 tagged fail if you disable AOT.
Tried on both Ubuntu 8.10 and Windows....

Regards,
Miha

</description>
    <dc:creator>Miha Vrhovnik</dc:creator>
    <dc:date>2008-11-29T15:40:05</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.comp.gnome.mono.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gnome.mono.devel</link>
  </textinput>
</rdf:RDF>
