Re: [Mono-dev] Bug In MonoTorrent

2006-10-12 Thread Alan McGovern
Hi,I tried the MonoTorrent library and found a bug preventing if from working with large torrents or files. The torrent contained a file with 3GB size (Linux DVD image):System.IO.IOException was unhandled Message=An attempt was made to move the file pointer before the beginning of the file.\r\n

Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount

2006-10-25 Thread Alan McGovern
To my understanding, fixed pointers do not participate GC target. And- locally-allocated array anyways lives until its conversion finishes (and probably immediately disposed depending on the JIT optimization)- Usually this conversion do not take long timeSo I guess fixed pointer would work better

Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono

2006-10-31 Thread Alan McGovern
Is there a sample app the compiles slowly somewhere (and instructs on how to use VBNC) that i can download it and run a few tests myself to see if i could lend a hand? I'm interested in this kind of stuff, but probably won't be able to help much :p But i'll try. Thanks,Alan.On 10/31/06, Ben Maurer

Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono

2006-10-31 Thread Alan McGovern
What he needs and i need and anyone else who wants to help with this issue needs is a program that takes 5-15 minutes to compile using VBNC. Trying to profile a 1 hour compile that crashes is a waste of time. Profiling for 10 minutes allows reasonalby fast results when testing a new patch. Making

Re: [Mono-dev] [PATCH] System.Transactions.Transaction

2006-11-14 Thread Alan McGovern
Isn't it more usual to implement Equality and then for InEquality just: return !obj.Equals(otherObj); Easier to maintain ;)Alan.On 11/15/06, Raja R Harinath [EMAIL PROTECTED] wrote:Hi, Matthijs ter Woord [EMAIL PROTECTED] writes: In the attached diff file, is a change for implementing the == and

Re: [Mono-dev] Moma early results.

2006-11-27 Thread Alan McGovern
Not sure if this has been fixed already or not, but if you look at the largest file in the archive, it has the same methods reported multiple times (100's of times?). Is there any point to that? Alan. On 11/27/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hey folks, I have posted the 102

[Mono-dev] api-diff/api-info problems

2006-12-21 Thread Alan McGovern
Hi, Yesterday i compiled the mono/tools/corcompare tools in order to generate a class status page so i could compare Mono.XNA's status as compared to the Microsoft.Xna library, but i ran into a few problems. After compiling the tools, i ran mono-api-info on Mono.XNA (saved as monoxna.xml) and

Re: [Mono-dev] api-diff/api-info problems

2006-12-21 Thread Alan McGovern
the tool can fix their final HTML in order to make it work properly? Alan. On 12/21/06, Alan McGovern [EMAIL PROTECTED] wrote: Hi, Yesterday i compiled the mono/tools/corcompare tools in order to generate a class status page so i could compare Mono.XNA's status as compared to the Microsoft.Xna

[Mono-dev] [Patch] TreeView, TreeNode, TreeNodeCollection

2007-01-09 Thread Alan McGovern
:/programming/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2007-1-09 Alan McGovern [EMAIL PROTECTED] + * TreeNode.cs + * TreeView.cs + * TreeNodeCollection.cs + - Added some new .NET 2.0 methods + 2006-12-06 Jackson Harper [EMAIL PROTECTED

Re: [Mono-dev] Cross-platform fsync()

2007-01-09 Thread Alan McGovern
(sorry, just realised last message didn't go to mailing list) Hi, Have you tried FileStream.Flush()? ;) Alan. On 1/9/07, Patrick Earl [EMAIL PROTECTED] wrote: Greetings all. I've recently run into the need for a cross platform fsync() call. As far as I know, all of the flavors of unix that

Re: [Mono-dev] Cross-platform fsync()

2007-01-10 Thread Alan McGovern
Have you tried FileStream.Flush()? ;) Flush() intentionally doesn't call fsync nor FlushFileBuffers. Well, the original reason cited for a cross platform fsync() call was to perform a flush to disk operation on a filestream. I believe that's *exactly* what FileStream.Flush() is for. So

Re: [Mono-dev] [Patch] TreeView, TreeNode, TreeNodeCollection

2007-01-20 Thread Alan McGovern
on moma, so if you don't have time to do that, I'll probably write it. Thanks! jpobst Alan McGovern wrote: Hi, This is my first patch, so i want to make sure that everything is alright before i go committing. I will provide NUnit tests for the new functionality (i'll post the tests here

[Mono-dev] Optimising code breaks maths

2007-01-28 Thread Alan McGovern
Hi, While NUniting for Mono.XNA i came across a problem i have no real idea how to fix. The problem appears when i compile in Release mode with optimisations enabled. For example, when i coded a method which calculates the 8 corners of a cube when given the 6 sides of the cube, i get completely

Re: [Mono-dev] Patch for Math.cs

2007-03-04 Thread Alan McGovern
Just out of interest, could you check the performance of the method if you change code patterns like: if (value 0) return Floor (value + 0.5); else return Ceiling (value - 0.5); to: return (value 0) ? Floor(value+0.5) : Ceiling(value - 0.5); When i was profiling stuff before i think

Re: [Mono-dev] Patch for Math.cs

2007-03-04 Thread Alan McGovern
Forgive the terrible indenting on the code: http://pastebin.ca/381736 But that indicates a huge difference between performance when using turnary as opposed to if/else. Turns out if/else is much much faster. What the hell? Alan. On 3/5/07, Felipe Almeida Lessa [EMAIL PROTECTED] wrote: I'm

Re: [Mono-dev] Stop Garbage Collection for a Codeblock

2007-03-08 Thread Alan McGovern
Just my two cents, The only reason i can think of where you'd require this kind of behaviour is when you need real time processing and any kind of delay could be disasterous. In this case, i wouldn't think C# would be a good choice to implement in. What you could do is write a C program/library

Re: [Mono-dev] Example of an expected execption test

2007-03-09 Thread Alan McGovern
[Test] [ExpectedException(typeof(StupidException))] public void TestStupidException() { throw new StupidException(); } The above test should pass (unless i've done it wrong ;) ).You can also check to make sure the message is the same by doing the following: [Test]

Re: [Mono-dev] Bug in compiler?

2007-03-12 Thread Alan McGovern
Just so you know the this that is being complained about is the second one: public Path(Node startingNode) : this(new InitialStep(***this***, startingNode)) You can't use the object because it hasn't had it's constructor finish running. Alan. On 3/12/07, Steve Bjorg [EMAIL PROTECTED]

Re: [Mono-dev] Google SoC Q

2007-03-15 Thread Alan McGovern
(whoops, meant to send to the list) Hi, While i can't speak for everyone, i could say this: VB.NET http://vb.net/is widely used and definitely of use to a lot of people! Basicode died a horrible horrible death about 15 years ago and even that mailing list has had less than 20 posts in the last

[Mono-dev] Patch for IPAddress.cs

2007-03-24 Thread Alan McGovern
With all the talk of BitConverting recently i took a look at IPAddress.HostToNetwork(). I optimised the Swap*** methods to be a little faster. My own tests show that the SwapLong method is approximately 35% faster and the SwapInt method is approximately 25% faster. No NUnit tests are needed as i

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-24 Thread Alan McGovern
I'd just like to point out that HostToNetwork() is already covered by NUnit tests, hence why i didn't include new ones. Alan. On 3/24/07, Alan McGovern [EMAIL PROTECTED] wrote: With all the talk of BitConverting recently i took a look at IPAddress.HostToNetwork(). I optimised the Swap

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-24 Thread Alan McGovern
Ok, more performance ;) The SwapInt() method is now 40% faster than when i originally started and SwapLong() is now 50% faster than the original method. This means i do 15 iterations of converting a long in 8500ms, which isn't that much slower than the MS one (6700ms) All i did this time was

[Mono-dev] JIT Optimisations

2007-03-25 Thread Alan McGovern
The following two constructs should be identical from an IL point of view, yet the first performs far faster than the other: if(condition) return X; return Y; as compared to return (condition) ? X : Y; From my benchmarking, the first method is approximately 8% faster. Which shouldn't

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-25 Thread Alan McGovern
Ok, so this should be the final patch needed, i don't think i can possibly get it any faster. I removed an excess bitshift operation from each call and made things nicer. This version is a few % faster than the previous patch. Not a huge difference, but still a difference. Let me know if it's

[Mono-dev] Sparse files

2007-03-25 Thread Alan McGovern
Hi, I'm just wondering if there's a cross platform way of creating sparse files in c#. I was taking a look at the Mono.Unix namespace, but there doesn't seem to be anything there that'd do it. Thanks, Alan. ___ Mono-devel-list mailing list

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-25 Thread Alan McGovern
Hi, That should do it. Alan. On 3/25/07, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, Let me know if it's good to commit. The patch is unreadable, something happened when you attached it, please resend. Miguel Index: C:/programming/mcs/class/System/System.Net/IPAddress.cs

Re: [Mono-dev] Sparse files

2007-03-25 Thread Alan McGovern
Hi, Not quite, a sparse file is different to a normal file in how allocations happen. For example if i wanted to write 1 megabyte at an index of 100 megabytes, a seek + write would result in a 101 megabyte file on the disk. With a sparse file, there'd actually be 1 megabyte physically taken up

[Mono-dev] ListT Optimisations

2007-03-26 Thread Alan McGovern
I was just browsing through the ListT implementation and made a few speed optimisations. I'm not sure if changing from foreach(blah) to for(int i=0; i blah, i++) is ok or not, but it does offer a large speed increase. So let me know if that's ok or not. Optimised Methods: RemoveAll - from 0x up

Re: [Mono-dev] ListT Optimisations

2007-03-26 Thread Alan McGovern
Attached is a newer patch which removes the use of: this. as it's against the mono coding guidelines. Alan. On 3/26/07, Alan McGovern [EMAIL PROTECTED] wrote: I was just browsing through the ListT implementation and made a few speed optimisations. I'm not sure if changing from foreach(blah

Re: [Mono-dev] ListT Optimisations

2007-03-26 Thread Alan McGovern
Whoops, attaching the right patch this time... Alan. On 3/26/07, Alan McGovern [EMAIL PROTECTED] wrote: Attached is a newer patch which removes the use of: this. as it's against the mono coding guidelines. Alan. On 3/26/07, Alan McGovern [EMAIL PROTECTED] wrote: I was just browsing

Re: [Mono-dev] ListT Optimisations

2007-03-26 Thread Alan McGovern
Hi, Thats a brilliant idea. It'll be much faster than the current shifting. I'll test it out now. Thanks, Alan. On 3/26/07, Michael Poole [EMAIL PROTECTED] wrote: Alan McGovern writes: I was just browsing through the ListT implementation and made a few speed optimisations. I'm not sure

Re: [Mono-dev] ListT Optimisations

2007-03-26 Thread Alan McGovern
I applied the optimisation from Michael, and the speed increase is quite substantial. The original code running with a 9,000 element array took about 030 ms to process. The new code with a 900,000 element array takes 210ms. Attached is a new patch containing those changes. All comments welcome

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-26 Thread Alan McGovern
I was messing around with the BitArray class (patch to follow) when i realised that it might be faster to use unsafe code to swap the bytes. So i did a test or two and it turns out that for longs it's faster to use unsafe code and copy bytes around. This makes SwapLong ~20% faster (0.2x faster).

[Mono-dev] BitArray patch

2007-03-26 Thread Alan McGovern
I was just looking at the bitarray code and i thought that instead of a lot of bitshifting and messing to retrieve individual bytes from int's it would be faster (and easier?) to use unsafe code and mess with individual bytes that way. This patch makes it about 20% faster to create a bit array

[Mono-dev] Queue (bugfix + nunit)

2007-03-26 Thread Alan McGovern
I was looking at the Queue code and i noticed that version wasn't incremented when Queue.Clear() was called. Here's a patch and NUnit test to show the problem. Alan Index: C:/programming/mcs/class/System/System.Collections.Generic/Queue.cs

Re: [Mono-dev] Queue (bugfix + nunit)

2007-03-26 Thread Alan McGovern
Bah! Something went wrong on that patch, looks like an EOL-style thing. Better patch attached. Let me know if it's good to commit. Alan. On 3/27/07, Alan McGovern [EMAIL PROTECTED] wrote: I was looking at the Queue code and i noticed that version wasn't incremented when Queue.Clear

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-27 Thread Alan McGovern
Hi, It's quite possible that on a 64bit system this wouldn't be worthwhile, but without a 64bit system and a 64bit mono i can't test. For ints (on a 32bit system at least) it is faster to bitshift though. Alan. On 3/27/07, Gareth Pearce [EMAIL PROTECTED] wrote: Alan McGovern wrote: I

Re: [Mono-dev] BitArray patch

2007-03-27 Thread Alan McGovern
code, you'd get the same. (as far as i can make out). Alan. On 3/27/07, David Brown [EMAIL PROTECTED] wrote: Alan McGovern wrote: I was just looking at the bitarray code and i thought that instead of a lot of bitshifting and messing to retrieve individual bytes from int's it would be faster

[Mono-dev] Stack patch

2007-03-27 Thread Alan McGovern
There was a tiny bug in the StackT implementation in that when you Peek() at the first item the version was incremented. Attached is a patch + nunit test to show the problem. I'll commit this and the other similar patch i posted in an hour or so. Alan. Index:

Re: [Mono-dev] Patch for IPAddress.cs

2007-03-27 Thread Alan McGovern
On 32bit systems, the unsafe method is approximately 25-30% faster for longs, yet on 64bit systems the existing bitshifting method is *substantially* faster. As a result, i don't think it'd be worth applying this patch. Alan. ___ Mono-devel-list

[Mono-dev] Need help tracking this bug...

2007-03-29 Thread Alan McGovern
Hi, Basically, i have a major (ish) problem in monotorrent with Mono 1.2.1 and above. After spending a few hours backtracking through svn revisions, i've managed to place the origin of the problem to between revision 72227 and 72228 of monotorrent in the mono svn. To generate the diff just use:

Re: [Mono-dev] Need help tracking this bug...

2007-03-29 Thread Alan McGovern
seconds had runaway memory usage. Here's the stats, maybe they'll make sense to someone, or fire alarm bells for someone else: I attached the seperate HeapBuddy reports to the email. Alan. On 3/29/07, Joe Shaw [EMAIL PROTECTED] wrote: Hi Alan, On 3/29/07, Alan McGovern [EMAIL PROTECTED] wrote

Re: [Mono-dev] Need help tracking this bug...

2007-03-29 Thread Alan McGovern
of allocations from a System.Timers.Timer? Whats going on here!? type=System.MonoType 2826 542.8M 201403.8 0.6 Half a gigabyte of System.MonoType's? What causes these to be allocated, and what can i do to stop this? Alan. On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote: Hi, I finally managed to get

Re: [Mono-dev] Need help tracking this bug...

2007-03-30 Thread Alan McGovern
Hi, Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9 resizes going from a size of 2.8 megs to 322.6 megs. Yup, i had noticed that ;) There is something fishy, but i can't find out what it is. I've

Re: [Mono-dev] Need help tracking this bug...

2007-03-30 Thread Alan McGovern
=11y=15. From your e-mail, it seems to be those AsyncSockets not disposing as expected. Cheers, 2007/3/30, Alan McGovern [EMAIL PROTECTED]: Hi, Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9

Re: [Mono-dev] Need help tracking this bug...

2007-03-30 Thread Alan McGovern
From your e-mail, it seems to be those AsyncSockets not disposing as expected Even if i wasn't disposing of them at all, i connect to at most 5 people a second, so that's at most 5 sockets being created a second. There's no way that they would lead to such a huge allocation rate. Also, i can

Re: [Mono-dev] Need help tracking this bug...

2007-03-30 Thread Alan McGovern
=9bfa49bc-376b-4a54-95aa-73c9156706e7displaylang=en . This guide can also help: http://support.microsoft.com/?scid=kb%3Ben-us%3B919790x=11y=15. From your e-mail, it seems to be those AsyncSockets not disposing as expected. Cheers, 2007/3/30, Alan McGovern [EMAIL PROTECTED]: Hi, Yep, that's your

Re: [Mono-dev] Need help tracking this bug...

2007-03-30 Thread Alan McGovern
Hi, That leaves me with the question of how the hell a SocketAsyncResult is 10 megs in size! The size of the largest single object in my entire code is a 16kB byte[] buffer. If each SocketAsyncResult is 10 megabytes in size, i have to question the internal workings of mono, as i know from

Re: [Mono-dev] Need help tracking this bug...

2007-03-30 Thread Alan McGovern
really. A similar amount for Begin/EndSend. On 3/31/07, Alan McGovern [EMAIL PROTECTED] wrote: Hi, That leaves me with the question of how the hell a SocketAsyncResult is 10 megs in size! The size of the largest single object in my entire code is a 16kB byte[] buffer. If each SocketAsyncResult

[Mono-dev] Build broken?

2007-03-30 Thread Alan McGovern
I've been trying to compile SVN head on both windows and MacOS and it fails on both. Is this a problem on just my side, or is compilation actually broken? I've attached the last 100 or so lines of output when trying to build on Mac OS X. If anyone has any ideas, let me know. Thanks, Alan. gcc

Re: [Mono-dev] Need help tracking this bug...

2007-03-31 Thread Alan McGovern
to figure out what it was, i feel cheated that someone else fixed it before i could ;) Anyway, thanks for the help joe, i couldn't have gotten as far as i did without you. Alan. On 3/31/07, Alan McGovern [EMAIL PROTECTED] wrote: Ok, i did a quick bit of testing on my code. Firstly, the 54

Re: [Mono-dev] Probably a dumb question - DirectX and Mono and Linux

2007-04-17 Thread Alan McGovern
Mono.XNA won't support DirectX either, just so you know. It'll only support OpenGL. Alan. On 4/17/07, Anton Andreev [EMAIL PROTECTED] wrote: Check out the http://www.openxna.net/ Mono.XNA project. Anton ___ Mono-devel-list mailing list

Re: [Mono-dev] [PATCH] - System.IO.FileSystemWatcher Unit Tests for Events

2007-04-18 Thread Alan McGovern
Hi, One thing you should do is make sure your temp files and directories are cleaned up when your tests finish running. The best way to do this would be to use [TestFixtureSetup] and [TestFixtureTeardown] to create a setup and cleanup method. The first one creates your temp directory, the second

Re: [Mono-dev] patch to start bonding navigator and masked textbox

2007-04-23 Thread Alan McGovern
Hi Olivier, I'm actually working on the BindingNavigator to implement the rest of it's functionality (well, implement more of it anyway). I'm using your patch as the base to work off, so it will hit the tree in a few days (or maybe a bit more). I'll keep you posted on the status of it. Alan.

Re: [Mono-dev] patch to start bonding navigator and masked textbox

2007-04-24 Thread Alan McGovern
Olivier, the first revision of Binding Navigator has hit SVN. Thanks for the patch! Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Call for testing: -- Timer issue

2007-04-27 Thread Alan McGovern
Any update on this issue? Alan. On 4/21/07, Joshua Tauberer [EMAIL PROTECTED] wrote: With the 1.2.4 preview, I encountered something with the MySql Connector which I narrowed down to an issue with System.Threading.Timer. I don't know what the proper way to use the Timer is, so it may be

[Mono-dev] Oddity in C#

2007-06-29 Thread Alan McGovern
The MSDN documentation for Read might help here... http://msdn2.microsoft.com/en-us/library/system.console.read.aspx What you'll need to do is read in the console input as a string and use Convert.ToInt32() (or whatever) to get the input value. Alan. On 6/28/07, Paul F. Johnson [EMAIL

Re: [Mono-dev] Compiler bug with Generics and where constraints

2007-07-16 Thread Alan McGovern
I suggested the same thing, but was told the compiler didn't allow you to add constraints to the overridden method. Also, i believe his code compiles fine under csc, so unless it's a bug in CSC, there's definitely an issue here. Alan. On 7/16/07, Adar Wesley [EMAIL PROTECTED] wrote: Hi John,

Re: [Mono-dev] Mono memory problems!

2007-07-18 Thread Alan McGovern
Could you post up the detailed stats from heapshot? After the 12 hour run, how much memory are you using? Are we talking in the gigabyte range, or megabyte range? Alan. On 7/18/07, David Wolinsky [EMAIL PROTECTED] wrote: My lab works on a peer-to-peer network overlay and we've noticed

Re: [Mono-dev] Mono memory problems!

2007-07-18 Thread Alan McGovern
, I'll post those as soon as possible. David Alan McGovern wrote: Could you post up the detailed stats from heapshot? After the 12 hour run, how much memory are you using? Are we talking in the gigabyte range, or megabyte range? Alan. On 7/18/07, *David Wolinsky* [EMAIL PROTECTED] mailto:[EMAIL

Re: [Mono-dev] [Mono-gc-list] Mono memory problems!

2007-07-18 Thread Alan McGovern
Alan McGovern wrote: Well, after 12 hours at a consistent 25kB/sec, you'd expect to have over 1 gig of memory allocated. As you don't, i think what you're seeing is just 'normal usage' for the non-compacting GC that mono uses. I have a similar app which uses sockets extensively (50-150

Re: [Mono-dev] [PATCH] System.Net.NetworkInformation

2007-07-24 Thread Alan McGovern
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.

Re: [Mono-dev] [PATCH] System.Net.NetworkInformation

2007-07-24 Thread Alan McGovern
. On 7/24/07, Jae Stutzman [EMAIL PROTECTED] wrote: 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

Re: [Mono-dev] unable to run VB.NET or C# applications on OS X

2007-07-30 Thread Alan McGovern
Quick solution: Don't use VisualBasic dll's in your C# application. Problem solved. Alternatively refactor your code so you don't use the GetResourceString method found there. Is there an alternative method of getting at the required data? Even if the method were to be released in the next mono

Re: [Mono-dev] System.Media.SoundPlayer silent

2007-08-09 Thread Alan McGovern
File a bug report on bugzilla about the issue. I'm the one who coded in that support, and as far as i can tell, it should work fine. I need a reproduceable testcase. The actual code is here:

Re: [Mono-dev] gmcs regression in svn

2007-09-18 Thread Alan McGovern
I'll put a bug report up for htis for you. Alan. On 9/17/07, Joachim Ante [EMAIL PROTECTED] wrote: Hi, I currently can't log bugs in bugzilla because the new bug tracker is not sending my a verification mail. So i am logging it here, hoping someone can look at this asap. When compiling

Re: [Mono-dev] mbas

2007-11-14 Thread Alan McGovern
mbas is the old compiler and is now obsolete. It's been replaced by a new compiler as part of last summers SoC: http://www.mono-project.com/VisualBasic.NET_support Alan. On Nov 14, 2007 3:38 PM, Paul F. Johnson [EMAIL PROTECTED] wrote: Hi, Are there any plans to remerge mbas back into the

Re: [Mono-dev] Announcing Mono 1.2.6 Preview 2 !!

2007-11-18 Thread Alan McGovern
Works on MS.NET. This is a regression. File a bug report at bugzilla.novell.com on this and post the bug number here. Alan. On Nov 18, 2007 1:43 PM, Stephen Apostolopoulos [EMAIL PROTECTED] wrote: Regression: cannot cast IntPtr to enum. using System; namespace Test { enum Key { A }

[Mono-dev] Int32.CompareTo() enhancement

2007-11-22 Thread Alan McGovern
I was just looking at the source of int32, and i noticed that there was room for improvement in the implementation of CompareTo. This implementation is approx 33% faster than the existing one. Is this ok to commit? I can write the changelog and commit myself if i get the go-ahead: Index:

Re: [Mono-dev] Int32.CompareTo() enhancement

2007-11-22 Thread Alan McGovern
Actually, if that's acceptable, i can do the same thing for int16 and int16 which will give similar performance boosts there. Alan. On Nov 22, 2007 9:05 PM, Alan McGovern [EMAIL PROTECTED] wrote: I was just looking at the source of int32, and i noticed that there was room for improvement

Re: [Mono-dev] ToString() performace in Mono

2007-11-22 Thread Alan McGovern
On my system i got (about) an 8% improvement by passing by ref. The results were fairly variable though, which makes an exact figure harder to give. The difference was ~6500ms down to ~6000ms. It's not a huge, but it is roughly in line with what i was expecting. I wouldn't be surprised though if

Re: [Mono-dev] Int32.CompareTo() enhancement

2007-11-22 Thread Alan McGovern
Scratch that, it fails the NUnit tests :) Alan. On Nov 22, 2007 9:25 PM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, This looks ok to check in, altough the int xv = assignment is no longer needed. Zoltan On Nov 22, 2007 10:05 PM, Alan McGovern [EMAIL PROTECTED] wrote: I

Re: [Mono-dev] System.Collections.Generic.Dictionary.CopyTo inaccessible due to protection level

2007-11-25 Thread Alan McGovern
Thats invalid code. If you want to access the 'CopyTo' method, you have to cast the dictionarystring, object as an ICollectionKeyValuePairstring, object. Alan. *Sigh*. Let this test program demonstrate: [EMAIL PROTECTED]:~/mono-hacks% gmcs bug.cs -o bug.exe warning CS8029: Compatibility:

Re: [Mono-dev] [PATCH] Set hash algorithms block size

2007-11-29 Thread Alan McGovern
This fix is twofold: to begin with, I've modified the abstract base classes of all hash algorithms in Sys.Sec.Crypto to include a protected const field called SPEC_BLOKCSIZE and overriden InputBlockSize and OutputBlockSize to return this value. This would modify the public API and so

[Mono-dev] String.GetHashCode()

2007-11-30 Thread Alan McGovern
A thought struck me while i was dozing on the plane on the way home from the summit. Since strings are immutable, shouldn't it be possible to compute the hashcode once and store it rather than recomputing it over and over again? Is there some really obvious reason that i can't think of that would

Re: [Mono-dev] InterOp problems with 1.2.6pre2

2007-12-01 Thread Alan McGovern
If you find a bug that affects you that you need fixed, it's up to you to show that there is a bug. If you paste code in an email, of course people are going to look at it. If that code is wrong, well, that's not our fault. You shouldn't paste code which supposedly shows an issue when in fact that

Re: [Mono-dev] String.GetHashCode()

2007-12-01 Thread Alan McGovern
Also, just looking at the string source a bit more closely, it has a GetCaseInsensitiveHashcode method too, so i'd assume that would need to be cached too which would mean 8 bytes would be needed. This wouldn't scale well. Fair enough. Twas just an idea. Alan. On Dec 1, 2007 4:09 PM, Robert

Re: [Mono-dev] String.GetHashCode()

2007-12-01 Thread Alan McGovern
then put a lower bound on the string length to make it worthwhile. Alan. On Dec 1, 2007 5:29 PM, Robert Jordan [EMAIL PROTECTED] wrote: Hi Alan, Alan McGovern wrote: Also, just looking at the string source a bit more closely, it has a GetCaseInsensitiveHashcode method too, so i'd assume

Re: [Mono-dev] String.GetHashCode()

2007-12-01 Thread Alan McGovern
Also, worst case scenario for a zero length string would mean a 22% increase, not a 100% increase as was said before. Alan. On Dec 1, 2007 6:01 PM, Alan McGovern [EMAIL PROTECTED] wrote: Well, 'N' could be computed by asking what percent bloat is 'OK' or it could be computed by asking 'What

Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix.

2007-12-02 Thread Alan McGovern
Well, it is explicitly stated that instance members are not threadsafe by default. If you're modifying an object from multiple threads simultaneously, then you have a bug in your code (unless the docs for that object explicitly state that the methods/properties you are using are threadsafe).

Re: [Mono-dev] Mono.Security + SecureString

2007-12-12 Thread Alan McGovern
It'd break API compatibility, therefore it's a no-go. Alan. On Dec 12, 2007 12:55 PM, Vladimir Giszpenc [EMAIL PROTECTED] wrote: Hi, As you know, in .Net Framework 2.0 Microsoft added the SecureString class to keep passwords and other private data hidden. They did not add SecureString

Re: [Mono-dev] Moma 1.2.6 bug

2007-12-14 Thread Alan McGovern
This was actually answered a bit earlier in a separate thread. You need to grab the latest moma.exe from: http://www.mono-project.com/MoMA, Alan. On Dec 14, 2007 6:17 AM, Dennis Hayes [EMAIL PROTECTED] wrote: I downloaded the Moma 1.2.6 definitions, but when I try to run Moma withthe new

Re: [Mono-dev] Compile Mono Solaris

2007-12-18 Thread Alan McGovern
In your last email you were running mono 1.2.4 and an argument exception was being thrown. The email previous showed you running mono 1.2.5 tarball and it was a null reference being thrown there. Alan. On Dec 18, 2007 10:08 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Maybe you should read the

Re: [Mono-dev] Compile Mono Solaris

2007-12-18 Thread Alan McGovern
On Dec 13, 2007 5:29 PM, Steven Jeffs [EMAIL PROTECTED] wrote: I can now generate the exception I'm getting with dekihost with just a few lines of code. Should this be a bug submission? *Mono JIT compiler version 1.2.5.2 (tarball)* One thing worth trying (if you haven't already) is to grab

Re: [Mono-dev] Mono 1.9.0 Preview 2 is out!!

2008-02-09 Thread Alan McGovern
Bug with the macos installer and monodevelop: https://bugzilla.novell.com/show_bug.cgi?id=360351 On Feb 8, 2008 9:46 PM, Thomas Wiest [EMAIL PROTECTED] wrote: Hey Everyone, We've just released Mono 1.9.0 Preview 2 today! This preview has Windows and Mac OS X installers. Please help us out

Re: [Mono-dev] fix for bug #358987 in 1.9?

2008-02-21 Thread Alan McGovern
It may be closed automatically, but *when* will it be closed? There's no guarantee on when finalizers will be called which is why calling .Close() is a much better solution (where possible). Alan. On Thu, Feb 21, 2008 at 11:53 AM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, I applied the

Re: [Mono-dev] Deprecating some Mono commands, Cecil mono-api-info

2008-03-03 Thread Alan McGovern
Well, if you look at the output you'll see that the cecil one is considerably more condensed and readable than the SRE one, so that could easily explain the filesize difference. For example, the 'ClearProps(in System.Byte, in System.UInt32, in System.Guid, in System.Int32)' method is 7 lines in

Re: [Mono-dev] Problem with Odbc on 64 bit identified, please advise action

2008-03-18 Thread Alan McGovern
There's a slight issue with that unfortunately. If you're on Windows64, and int is still an int32. If you're on nix64, an int is an int64. So, if you *only* care about linux support, then the change you outlined is perfect, however if you want to retain Win64 support, you can't do that. There are

Re: [Mono-dev] Gtk# 2.8.4 runtime for windows?

2008-04-16 Thread Alan McGovern
Hi, You can work around it by using reflection to test whether that event exists, and if it does you can then register a handler to it. That way you can use the new feature without having to lose compatibility with 2.8. Alan. 2008/4/16 Vladimir Dimitrov [EMAIL PROTECTED]: Hey guys I have

Re: [Mono-dev] crashes in glib hangs (not exits) program

2008-04-21 Thread Alan McGovern
For some reason, catching the unmanaged exception has the correct behaviour even though it could be just a side effect. Zoltan pointed out that unmanaged exceptions are not converted to exceptions in mono even though the windows side seem to do it and recomment using

[Mono-dev] SHA1Managed speedups

2008-04-28 Thread Alan McGovern
Hi, I've been working a bit with scottp to try and improve the SHA1 performance in Mono. We figured that by unrolling two more of the loops, we could double performance as compared to what's in 1.9. Is this patch ok to commit. If so, i can write up the necessary changelogs and commit it myself,

Re: [Mono-dev] SHA1Managed speedups

2008-04-29 Thread Alan McGovern
Please remove the unsafe keyword from both methods. Ah, sorry. I attached the wrong patch. Kangaroo had already pointed out that i had left in the unsafe keyword as part of my copy/paste from my working copy and i thought i recreated the patch when i fixed that, but obviously not. Please

Re: [Mono-dev] SHA1Managed speedups

2008-04-29 Thread Alan McGovern
Hi igor, [1] The first numbers from Alan, on Sunday using unsafe code, were around 40% and he made more progress after that. The current unsafe code version is just over 3x faster than the default implementation in Mono 1.9. However this will never be committed to mono itself. So don't get

[Mono-dev] SHA256 - small perf boost

2008-04-29 Thread Alan McGovern
) @@ -1,3 +1,9 @@ +2008-04-30 Alan McGovern [EMAIL PROTECTED] + + * SHA256Managed.cs: Marked helper methods as static + removed unnecessary casts and made a field a local var. + Gives ~15% faster performance. + 2008-04-27 Alan McGovern [EMAIL PROTECTED] * SHA1CryptoServiceProvider.cs

Re: [Mono-dev] SHA256 - small perf boost

2008-04-30 Thread Alan McGovern
is deciding that the methods shouldn't be inlined when in this case the benefits are definately clear. Alan. On Wed, Apr 30, 2008 at 2:00 PM, Sebastien Pouliot [EMAIL PROTECTED] wrote: yes, go ahead. thanks again Sebastien On Wed, 2008-04-30 at 02:30 +0100, Alan McGovern wrote: Applying some

[Mono-dev] JIT and Inlining - why doesn't it happen?

2008-04-30 Thread Alan McGovern
I recently started doing a bit of optimisation work on the hashing/cryptography classes in mono. When working on the managed SHA256 class[1], i noticed that mono isn't inlining what i'd consider some *very* simple methods. The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) aren't

Re: [Mono-dev] JIT and Inlining - why doesn't it happen?

2008-04-30 Thread Alan McGovern
very short methods. Right now methods must have a body at most 20 bytes long. 2008/4/30 Alan McGovern [EMAIL PROTECTED]: I recently started doing a bit of optimisation work on the hashing/cryptography classes in mono. When working on the managed SHA256 class[1], i noticed that mono

Re: [Mono-dev] SHA256 - small perf boost

2008-04-30 Thread Alan McGovern
Looks great. I too wonder why they are not inlined (or if they were at one time). It turns out mono only inlines a method if it's body is 20 bytes or less. None of the helper functions met this requirement (unfortunately) so they never got inlined. You may want to check SHA384/512 which are

Re: [Mono-dev] JIT and Inlining - why doesn't it happen?

2008-05-01 Thread Alan McGovern
inlining. So it would significantly increase JIT time for diminishing gains. On Wed, Apr 30, 2008 at 6:38 PM, Alan McGovern [EMAIL PROTECTED] wrote: This method does not get inlined: private uint Ch (uint u, uint v, uint w) { return (uv) ^ (~uw); } If that isn't inlined

Re: [Mono-dev] JIT and Inlining - why doesn't it happen?

2008-05-01 Thread Alan McGovern
2008/4/30 Alan McGovern [EMAIL PROTECTED]: This method does not get inlined: private uint Ch (uint u, uint v, uint w) { return (uv) ^ (~uw); } If that isn't inlined then don't ask me what kind of method *could* be inlined by the JIT. Alan. On Wed, Apr 30, 2008

  1   2   >