Re: [Mono-dev] Saving custom user settings (from ApplicationSettingsBase) saves erroneous data in .local user.config file
clarification Funny, i just read what i wrote. It sounds like I intentionally wrote a duplicate bug. I didn't, for some reason my searching abilities improved after I wrote the bug. My mail is what was intended to bring attention to this issue. /clarification Cheers, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Saving custom user settings (from ApplicationSettingsBase) saves erroneous data in .local user.config file
This bug was initially found a year ago. I just stumbled on it last week using Mono 2.4.3. Not sure how many people are using ApplicationSettings with mono, but this seems kind of critical to folks using custom user.config. https://bugzilla.novell.com/show_bug.cgi?id=468658 https://bugzilla.novell.com/show_bug.cgi?id=471289 https://bugzilla.novell.com/show_bug.cgi?id=492831 and the dupe i wrote :) https://bugzilla.novell.com/show_bug.cgi?id=576565 I just wanted to bring some attention to it... Cheers, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
We actually looked at the way Bansee was using gstreamer to display video. IIRC, Banshee's use of GStreamer is very specific and isn't really a gstreamer library. It can be useful to do the kind's of things that banshee does. We are looking at using gstreamer in a limited DVR type app. This requires more pieces of gstreamer. It is a little sad that my python friends like to take jabs at the lack of a decent gstreamer wrapper in mono. Maybe us gstreamer consumers need to step up to the plate! Cheers, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
I believe the missing gstreamer# is a huge hole in the development stack. We also p/invoke the c lib in our apps. It would be nice to see this project revived and become a first-class citizen like gtk#. Maybe we can garner some folks together! GSoc Mono.Media is another option, perhaps. Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cross-compile Mono and Msc
I'm trying to cross compile mono for powerpc, compiling runtime is ok, but I was unable to compile msc and corresponding libraries. I've got sources from svn via anonymous access. Can anyone give me some suggestions how to do this? Thank for answers. IIRC, the mcs must be compiled under x86. They are managed libraries. We've been working the last week on getting mono on the latest Maemo platform (N810 et al). Someone else with better insight can chime in! Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 1.2.6 on Maemo OS2008 help
I saw in some of the logs that this is currently being worked on by a few folks. Does anyone know the status of this? I'm thinking I may have to build it myself, but I'd rather not :) Thanks, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.6 on Maemo OS2008 help
The guy you're after is Everaldo Canuto - you'll find a handful of interested parties hanging out on irc (mono-maemo) including yours truly. IIRC he's close to getting it all together... As far as building goes, it's not as bad as it seems. But still pretty bad ;P Tim I've been on the IRC, not much traffic :) Well, I got a little ways into it! Unfortunately I don't seem to have what it takes to compile with GC support. The Chinook-Armel scratchbox target keeps errorring out with the undefined reference GC_local_maloc. The Chinook-x86 target compiles fine. Any help on compiling this would be greatly appreciated. It is probably something small at this point. Thanks, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Versioning
I agree with this assertion. The Mono versioning doesn't need to track MS. However, a matrix of what .NET features Mono supports for a given version number should be prominently displayed. This page with a short url can be thrown out to help non-Mono devs understand what is and is NOT supported by mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .net library shared source
On 10/3/07, Jonathan Chambers [EMAIL PROTECTED] wrote: See Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.html Also, the rules for contributing are still in effect: http://www.mono-project.com/Contributing If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono. - Jonathan Regardless of the personal friendly contacts within MS, the lawyers are never friendly! We need to be more diligent now than ever that we do NOT look at the code EVER. It may be good to have an independent 3rd party org that does not contribute to mono to run code analysis between mono's impl and the .net src on regular basis to make sure that the mono implementation remains clean. MS releasing this just gives more ammo to the naysayers. There is enough bad press from the folks that think mono is MS pandering. This kinda thing is starting to make me annoyed! Sometimes I wish that the relationship between Mono and MS was NOT so friendly :) Maybe we should start name calling...heheh Cheers, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono recipe in OpenEmbedded
Super sweet...will try them now! Thanks for your work on this. Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono recipe in OpenEmbedded
On 8/23/07, Jae Stutzman [EMAIL PROTECTED] wrote: Super sweet...will try them now! Thanks for your work on this. Jae How do we target the NET_2_0 profile with bitbake? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono recipe in OpenEmbedded
make PROFILE=net_2_0 See this page for more info: http://www.mono-project.com/Parallel_Mono_Environments Thanks again. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting with DateTime
Actually it is the upper 2 bits of the 64 bit value. I've attached logs taken from a .NET 2.0 client and updated the bug with the info... http://bugzilla.ximian.com/show_bug.cgi?id=8240 A fix is just around the corner! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting with DateTime
Ok added bug# 82400 to help track this. I've been playing with Lionel's patch. What i've found out so far is that the ObjectReader from System.Runtime.Serialization.Formatters.Binary has a method that is executed when trying to de-serialize the DateTime struct. The method is ReadPrimitiveTypeValue, which has a case: case TypeCode.DateTime: return new DateTime (reader.ReadInt64()); This is causing an explosion because now the DateTimeKind is included. This is quite a mess at present. Needless to say if you try to remote a DateTime that has a kind of Local or Utc it will die. The ObjectReader is not using the ISerializable interface, just calling the DateTime ctor with ticks, but they are not ticks yet! I'll keep looking, but someone familiar with why it was done this way should speak up if possible. Thanks, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting with DateTime
Replying to my own mail... The failure happens when using TCP remoting, when I tried with HTTP the sample worked. BTW this is with SVN rev 83316. Something going on in the binary serialization i reckon. Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Remoting with DateTime
Is DateTime supposed to be supported as a parameter in remote calls? I'm getting an ArgumentOutOfRangeException like this: Note: This was just passing DateTime.Now Value -8590148590525713308 is outside the valid range [0,31553789759]. Parameter name: ticks Maybe DateTime is not viewed as a primitive type here...if not let me know and I'll do something else. Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Net.NetworkInformation
Added patch to buzilla # 82403 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting with DateTime
I can solve it multiple ways. :) This was with .NET 2.0 and svn with the NET_2.0 profile. I filled out bug # 82400. Like i said first, if this is not a supposed to be supported, fine. Since remoting is supposed to be an abstract interface, the channel shouldn't matter. Since it works with SOAP, it should with binary too...IMHO Thanks for the info, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Remoting serialization problem with array of arrays
We are passing array of array of our custom object (ie not framework) as a parameter to remote methods. This works fine between to .NET boxes or if the server is running on mono (linux), but fails if one of the server is running on windows and client on mono (linux). We are actually using interfaces, but the behavior is the same. Example: Client: HappyHello[][] hello = testRemoteMethod.Hello(hello); The exception that is returned is a rethrown exception (coming from the server) as a serialization error: at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetAssemblyNameId( System.String assembly) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetAssemblyId ( System.Reflection.Assembly assembly) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteTypeSpec ( System.IO.BinaryWriter writer, System.Type type) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteGenericArray( System.IO.BinaryWriter writer, Int64 id, System.Array array) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteArray( System.IO.BinaryWriter writer, Int64 id, System.Array array) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance( System.IO.BinaryWriter writer, System.Object obj, Boolean isValueObject) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects( System.IO.BinaryWriter writer) [0x0] at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph( System.IO.BinaryWriter writer, System.Object obj, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] at System.Runtime.Serialization.Formatters.Binary.MessageFormatter.WriteMethodCall( System.IO.BinaryWriter writer, System.Object obj, System.Runtime.Remoting.Messaging.Header[] headers, ISurrogateSelector surrogateSelector, StreamingContext context, FormatterAssemblyStyle assemblyFormat, FormatterTypeStyle typeFormat) [0x0] at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize ( System.IO.Stream serializationStream, System.Object graph, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg) [0x0] This is what I think is happening: The client is not serializing the object[][] properly which causes the server to throw the exception. Like I mentioned above, if the server is running on mono, the windows client serializes properly and the server does not throw and error. Also, if I change it to only be one array of HappyHello, the code works fine on both platforms. I hope this is clear... I can write a bug for this. Cheers, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Net.NetworkInformation
Ok, here is the patch for the System.Net.NetInformation.PhysicalAddress.
This is a big rewrite from the one revision 82491. I've also included a unit
test class (as there wasn't one) which passes all tests in both .NET 2.0 and
the patched version of PhysicalAddress. During the testing I found some
interesting MS behavior which is documented in the asserts of the test (the
tests can be refactored if needed, i ran out of time). For what it is worth
the GetHashCode also returns the same value in both .NET and the patched
file.
Cheers,
Jae
Index: System.Net.NetworkInformation/PhysicalAddress.cs
===
--- System.Net.NetworkInformation/PhysicalAddress.cs (revision 82491)
+++ System.Net.NetworkInformation/PhysicalAddress.cs (working copy)
@@ -32,6 +32,7 @@
namespace System.Net.NetworkInformation {
public class PhysicalAddress {
public static readonly PhysicalAddress None = new PhysicalAddress (new byte [0]);
+ private const int numberOfBytes = 6;
byte [] bytes;
public PhysicalAddress (byte [] address)
@@ -44,28 +45,34 @@
if (address == null)
return None;
- if (address == )
-throw new FormatException (Invalid physical address.);
+ if (address == string.Empty)
+throw new FormatException(An invalid physical address was specified.);
- // MS fails with IndexOutOfRange for something like: 00-0
- int ndashes = 0;
- foreach (char c in address) {
-if (c == '-')
- ndashes++;
+ string[] addrSplit = address.Split('-');
+
+ if (addrSplit.Length == 1) {
+if (address.Length != numberOfBytes * 2)
+ throw new FormatException(An invalid physical address was specified.);
+
+addrSplit = new string[numberOfBytes];
+for (int index = 0; index addrSplit.Length; index++) {
+ addrSplit[index] = address.Substring(index * 2, 2);
+}
}
- int len = address.Length;
- if (((len - 2) / 3) != ndashes)
-throw new FormatException (Invalid physical address.);
+ if (addrSplit.Length == numberOfBytes) {
+foreach (string str in addrSplit)
+ if (str.Length != 2)
+ throw new FormatException(An invalid physical address was specified.);
+ }
+ else
+throw new FormatException(An invalid physical address was specified.);
- byte [] data = new byte [ndashes + 1];
- int idx = 0;
- for (int i = 0; i len; i++) {
-byte b = (byte) (GetValue (address [i++]) 8);
-b += GetValue (address [i++]);
-if (address [i] != '-')
- throw new FormatException (Invalid physical address.);
-data [idx++] = b;
+ byte[] data = new byte[numberOfBytes];
+ for (int i = 0; i numberOfBytes; i++) {
+byte b = (byte)(GetValue(addrSplit[i][0]) 4);
+b += GetValue(addrSplit[i][1]);
+data[i] = b;
}
return new PhysicalAddress (data);
@@ -73,7 +80,7 @@
static byte GetValue (char c)
{
- if (c = 0 c = 9)
+ if (c = '0' c = '9')
return (byte) (c - '0');
if (c = 'a' c = 'f')
@@ -91,20 +98,25 @@
if (other == null)
return false;
- // new byte [0] != new byte [0]
- return (bytes == other.bytes);
+ if (bytes.Length == 0 other.bytes.Length == 0)
+return true;
+
+ if (bytes.Length == other.bytes.Length)
+ {
+for (int index = 0; index bytes.Length; index++)
+{
+ if (bytes[index] != other.bytes[index])
+ return false;
+}
+return true;
+ }
+ else
+return false;
}
public override int GetHashCode ()
{
- if (bytes == null)
-return 0;
-
- int a = 5;
- foreach (byte b in bytes)
-a = (a 3) + b;
-
- return a;
+ return (bytes[5] 8) ^ (bytes[4]) ^ (bytes[3] 24) ^ (bytes[2] 16) ^ (bytes[1] 8) ^ (bytes[0]);
}
public byte [] GetAddressBytes ()
@@ -119,7 +131,7 @@
StringBuilder sb = new StringBuilder ();
foreach (byte b in bytes)
-sb.AppendFormat ({0:2X}, (uint) b);
+sb.AppendFormat({0:X2}, b);
return sb.ToString ();
}
}
#if NET_2_0
using System;
using System.Net.NetworkInformation;
using NUnit.Framework;
namespace MonoTests.System.Net.NetworkInformation
{
[TestFixture]
public class PhysicalAddressTest
{
[Test]
public void CreatePhysicalAddress()
{
PhysicalAddress phys = new PhysicalAddress(new byte [] { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 });
bool created = false;
try {
phys = new PhysicalAddress(new byte[] { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07});
created = true;
}
catch (Exception e) {}
if (!created)
Assert.Fail(MS.NET 2.0 Allows Physical Address to be created if array larger than normal.);
created = false;
try {
phys = new PhysicalAddress(new byte[] { 0x01, 0x02, 0x03, 0x04, 0x05 });
created = true;
}
catch (Exception e) {}
if (!created)
Assert.Fail(MS.NET 2.0 Allows Physical Address to be created if array smaller than normal.);
}
[Test]
public void ParsePhysicalAddress()
{
try {
PhysicalAddress phys = PhysicalAddress.Parse(010203040506);
[Mono-dev] [PATCH] System.Transactions
I realize that not all transaction support is done. We are using
CommitableTransaction and in MS the Dispose() causes a Rollback if not yet
Committed. In mono this throws a NotImplementedException. I understand there
is more to do with Dispose when the rest of the transaction stuff comes
online, but for now I need the same behavior for our app.
Jae
Index: Transaction.cs
===
--- Transaction.cs (revision 82491)
+++ Transaction.cs (working copy)
@@ -109,7 +109,9 @@
[MonoTODO]
public void Dispose ()
{
- throw new NotImplementedException ();
+ //throw new NotImplementedException ();
+ if (TransactionInformation.Status == TransactionStatus.Active)
+Rollback();
}
[MonoTODO]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.Net.NetworkInformation
This small patch makes the Equals(...) override more like MS behavior. First if both addresses are empty it returns true, also the comparison now uses the hashcode. This was changed as part of the porting a windows .net app. Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Net.NetworkInformation
Quite possible, it was a quick pass. The GetHashCode() is overridden to provide its answer based on the underlying address bytes. On 7/24/07, Alan McGovern [EMAIL PROTECTED] wrote: Doing a comparison by comparing the hashcodes sounds very broken to me. It's quite possible for two objects to give the same hashcode without actually being equal. Alan. On 7/24/07, Jae Stutzman [EMAIL PROTECTED] wrote: This small patch makes the Equals(...) override more like MS behavior. First if both addresses are empty it returns true, also the comparison now uses the hashcode. This was changed as part of the porting a windows .net app. Jae ___ 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] [PATCH] System.Net.NetworkInformation
Fair enough :) (the hash code is a shift/add mangling approach) I didn't realize I forgot my attachment! oops. Changed it to use straight elemental compares and upon testing found other problems with the original class. So I will do some more work on it and attach the patch tomorrow. Thx, Jae ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] BitConverter differences
Observe the following snippet:
byte[] test = { 3, 15, 3, 2, 5, 6, 4, 3 };
string value = BitConverter.ToString(test, 4, 0);
Console.WriteLine(value);
On MS the BitConverter.ToString returns an empty string if the (third param)
length is 0, on mono it throws a:
Unhandled Exception: System.ArgumentOutOfRangeException: capacity must be
greater than zero.
Parameter name: capacity
-1
at System.Text.StringBuilder..ctor (System.String value, Int32 startIndex,
Int32 length, Int32 capacity) [0x0]
at System.Text.StringBuilder..ctor (Int32 capacity) [0x0]
at System.BitConverter.ToString (System.Byte[] value, Int32 startIndex,
Int32 length) [0x0]
Known? Expected?
I don't want to annoy on the list, so you can stop me anytime.
Jae
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
