I strongly encourage you to not lie.
SharpDevelop does support debugging and refactoring.
Atsushi Eno
Antonello Provenzano wrote:
Peter,
SharpDevelop is by far the best one for Windows: it is (IMHO)
comparable with VS.NET for most of the main features a developer need
(debugger, code
Atsushi,
I strongly encourage you to not lie.
What do you mean? :|
On 3/26/07, Atsushi Eno [EMAIL PROTECTED] wrote:
I strongly encourage you to not lie.
SharpDevelop does support debugging and refactoring.
Atsushi Eno
Antonello Provenzano wrote:
Peter,
SharpDevelop is by far the
Oops, I apologize. I misunderstood comparable that you meant
SD is not usable.
Atsushi Eno
Antonello Provenzano wrote:
Atsushi,
I strongly encourage you to not lie.
What do you mean? :|
On 3/26/07, Atsushi Eno [EMAIL PROTECTED] wrote:
I strongly encourage you to not lie.
Atsushi,
Oops, I apologize. I misunderstood comparable that you meant
SD is not usable.
No problems, but I meant the exact opposite: IMHO #D is one of the
best IDe for developing Mono and .NET code under Windows.
What I wanted to say was that doing a transition from VS.NEt to #D is
a good
Some time ago (before MS release of the utility shipped with .NET
framework) I wrote a complete application for pings: I could try
adapting it, since I've never released it and this could be a good use
for it.
I will let you know (even you're interested in).
Cheers.
Antonello
On 3/26/07,
Lie? Do you have anything against SharpDevelop or is it some kind of
policy to attack people talking about SD?
You should check http://icsharpcode.net/OpenSource/SD/Features.aspx for
more information.
Radek
I strongly encourage you to not lie.
SharpDevelop does support debugging and
Radek,
Lie? Do you have anything against SharpDevelop or is it some kind of
policy to attack people talking about SD?
There has been a *huge* misunderstanding: I was speaking of #D in a
good way, saying it is comparable to VS.NET for most of the features
needed by developers, while Atsushi
Nah, what I've originally thought was the quite opposite, as I wrote
that it *does* support debugging and refactoring.
Atsushi Eno
Radek Polak wrote:
Lie? Do you have anything against SharpDevelop or is it some kind of
policy to attack people talking about SD?
You should check
Hi,
i misunderstood too :-). Sorry for my stupid answer. Have a nice day
Radek
Radek,
Lie? Do you have anything against SharpDevelop or is it some kind of
policy to attack people talking about SD?
There has been a *huge* misunderstanding: I was speaking of #D in a
good way, saying it is
Hi,
There was a guy who tried to use the method in the subject, so
I've created a cosmetic patch to implement it.
Atsushi Eno
Index: System.Web.UI/TemplateControl.cs
===
--- System.Web.UI/TemplateControl.cs(revision 74928)
+++
Hi,
I'm not sure where to post this, I want to know status of api which are
needed in my application, so I'm posting here.
I want to build a parental control in C#. I want to know which will be the
best approach for me ( from the point of api completion in mono).
Should I use browser based
Hi,
Mono's String class has great managed memcpy and memset methods that
internal. cpblk and initblk opcodes map to these two methods when cannot
be
easily inlined. But I know no way to make a C# compiler emit either cpblk
or
initblk using my own pointer parameters.
Which ones do you
Hi,
I'm totally against the introduction of new mono-only C# keywords. Access to
mentioned function calls should, if really needed, be provided in the form
of a class residing in some mono namespace.
Best Regards,
Cetin Sert
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To:
On 3/25/07, Paul [EMAIL PROTECTED] wrote:
First, really sorry about posting this between two different mailing
lists, but it's an important problem!
http://nodoid.homelinux.org/csharp/dl/ctrix.exe
Could you publish the code somewhere so we can test and see what's
wrong? It would also be good
Ah, I see you posted a source snippet. Nevermind that part then :)
On 3/26/07, Andreia Gaita [EMAIL PROTECTED] wrote:
On 3/25/07, Paul [EMAIL PROTECTED] wrote:
First, really sorry about posting this between two different mailing
lists, but it's an important problem!
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
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)
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
Hi,
First, really sorry about posting this between two different mailing
lists, but it's an important problem!
http://nodoid.homelinux.org/csharp/dl/ctrix.exe
Could you publish the code somewhere so we can test and see what's
wrong? It would also be good if you tried it with the
Alan McGovern writes:
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
Hi,
During WCF hacking I found that Mono.Security.Protocol.Ntlm looks
based on somewhat old analysis.
Currently the code does not look version aware. According to
http://davenport.sourceforge.net/ntlm.html , there seems three
ntlm versions and the message layout is diffrent for each version.
And
On Monday 26 March 2007 09:35, Antonello Provenzano wrote:
Some time ago (before MS release of the utility shipped with .NET
framework) I wrote a complete application for pings: I could try
adapting it, since I've never released it and this could be a good use
for it.
I would really like to
Has anyone had a chance to look at these? No rush, of course.
Thanks,
Kevin
On 3/18/07, Kevin Reay [EMAIL PROTECTED] wrote:
Hi all,
I've attached two patches relating to monodoc; one affecting the
docbrowser, and the other affecting the monodoc engine.
The first one (for the docbrowser)
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
You could always test with System.Data.SqlClient using
INTEGRATED SECURITY=SSPI provided that you connect to
SQL Server 2000 or 2005 on a real Windows NT/2000/2003
Domain and that SQL Server accepts mix-mode
authentication.
--- Atsushi Eno [EMAIL PROTECTED] wrote:
Hi,
During WCF hacking I
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
On Sun, 2007-03-25 at 02:14 -0400, Miguel de Icaza wrote:
We do not have plans of implementing the Ping method at this point. On
Unix issuing Ping requires root privileges. For making this work, we
would have to write a setuid program and launch it every time this call
is made.
Couldn't we
Hello!
Whoops, attaching the right patch this time...
I love it!
We should go class-by-class and have Optimization-thons!
Miguel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
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).
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
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 (and easier?) to use unsafe code and
mess with individual bytes that way. This patch makes it about 20%
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
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() was
33 matches
Mail list logo
