Re: [Mono-dev] Problem in SvcHttpHandler.cs ?
The reason why there are no synchronous calls in silverlight is (I
believe) because you can easily deadlock the plugin by attempting a
synchronous call when using the browser http stack. For the web
request to be completed, the browser has to be able to iterate and if
a plugin is blocking, there's nothing the browser can do.
If I remeber correctly there is an explanation of this on msdn
somewhere.
Alan
On 6 Jul 2010, at 05:08, Atsushi Eno atsushi...@veritas-vos-liberabit.com
wrote:
Hello Thiago,
Thanks, there's a lot of major and minor missing functionalities all
around. Our class status
describes large part of those missing stuff (primarily in
System.ServiceModel.dll):
http://go-mono.com/status/
Right now we have no plan to build mono specific WCF libraries. IMO
libraries like
what you said should be released cross platform, at places like
codeplex.
Instead you might have some useful code that could be used in our own
core WCF
assemblies (imagine if you have implemented WS-AtomicTransaction aside
TransactionFlowBindingElement, and we don't have working code now.)
Atsushi Eno
On 2010/07/05 21:27, Thiago Padilha wrote:
Hi Atsushi,
I have started messing with WCF last week but I'm very interested in
learning, If you need help with anything just send me a message.
Also, today I'm starting to develop an http binding/channel to allow
REST syncronous programming of WCF Services/Clients(compatible with
moonlight/silverlight 2/3). I know syncronous service calls aren't
officially supported by Silverlight, but(correct me if I'm wrong) I
don't see why that should'nt work if I extend at channel level. If
you
want to integrate my source code in the Mono specific libraries I'd
be
happy to send you.
On Fri, Jul 2, 2010 at 3:54 PM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Hi,
Right, thanks for the analysis, that should be fixed, and I have
an idea.
Though I am now rewriting ASP.NET channel support based on our new
HTTP
(non-ASP.NET) channel stack and it does not use the code path you
mentioned,
I'd rather finish the rewrite first and then fix the actual issue.
The idea above is to use Uri comparison using UriComponents based on
HostNameComparisonMode value (which is ignored so far).
Atsushi Eno
On 2010/06/29 21:46, Thiago Padilha wrote:
Hi,
I'm hosting a WCF service using asp.net/mono from trunk
(r159644)
but encountered a problem when accessing the service from a virtual
machine :
The argument HTTP context did not match any of the registered
listener manager (could be mismatch in URL, method etc.)
http://172.16.122.2:8080/Person.svc
Description: HTTP 500. Error processing request.
Stack Trace:
System.InvalidOperationException: The argument HTTP context did not
match any of the registered listener manager (could be mismatch in
URL, method etc.) http://172.16.122.2:8080/Person.svc
at
System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
(System.Web.HttpContext ctx) [0x00120] in
/home/thiago/monotrunk/mcs/class/System.ServiceModel/
System.ServiceModel.Channels/SvcHttpHandler.cs:141
at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
(System.Web.HttpContext context) [0xd] in
/home/thiago/monotrunk/mcs/class/System.ServiceModel/
System.ServiceModel.Channels/SvcHttpHandler.cs:156
at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext ()
[0x00ce5] in
/home/thiago/monotrunk/mcs/class/System.Web/System.Web/
HttpApplication.cs:1344
at System.Web.HttpApplication.Tick () [0x0] in
/home/thiago/monotrunk/mcs/class/System.Web/System.Web/
HttpApplication.cs:914
I think this happened because I tried to access the service trough
the 172.16.122.0 network which is the virtual network for my VMs.
The service works well if I access it on the local machine using
the
http://127.0.0.1:8080/Person.svc; Url, but fails with the same
error
if I use http://localhost:8080/Person.svc;. After looking into the
source code I think the problem may be on the following
conditionals
(method 'FindBestMatchListener') :
if (l.Uri.Equals (ctx.Request.Url)) {
best = l;
break;
}
//
if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
StringComparison.Ordinal))
continue;
Maybe it should check the Uris for all the network interfaces?(I
have
no idea on how to do that).
___
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] Bug 470120 - Socket.EndSend unexpectedly fails with WSAEWOULDBLOCK
So the patch fixes the Begin/EndSend issue but breaks BeginConnect? Maybe that's a good reason to not commit the patch until the issue with BeginConnect is fixed. Would you be capable of diagnosing andor fixing the issue or do we need another OSX guy to look at it? You should probably add information about exactly what's broken to the bug report. Alan. On Thu, Jun 10, 2010 at 3:01 PM, yoni shalom silve...@gmail.com wrote: shameless ping... On Mon, Jun 7, 2010 at 11:03 AM, yoni shalom silve...@gmail.com wrote: Does anyone know the status of this bug ? It was found in 2.4.x, theres a patch there but it hasn't seen its way into trunk, can someone take a look please ? https://bugzilla.novell.com/show_bug.cgi?id=470120 Thanks. ___ 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] Compiler bug in foreach
There was a regression in trunk about 2 weeks ago which was fixed
about 4 days ago which was very similar to this. However your testcase
appears to fail on both mono 2.6.4 and svn trunk. Would you be able to
file a bug report with this testcase?
Thanks!
Alan.
On Sat, May 29, 2010 at 2:11 AM, Robert Jordan robe...@gmx.net wrote:
On 29.05.2010 01:44, Mehrdad Reshadi wrote:
I found the following bug, wondering if others have seen this, or anything
is being done to solve it. foreach is too common to have such a bug!
public static void Main(string[] args)
{
var o = new Y();
foreach (var c in new A[3] { new A(), new B(), new C() })
c.f(o);
new B().f(o);
}
foreach is obviously not the culprit, because the issue can
be reproduced with an unrolled loop:
public static void Main(string[] args)
{
var o = new Y();
var a = new A[3] { new A(), new B(), new C() };
a[0].f(o);
a[1].f(o);
a[2].f(o);
new B().f(o);
}
Please visit http://mono-project.com/Bugs and file a bug.
Robert
___
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] Compiler bug in foreach
Hey,
I filed a bug and then realised you had already filed it. I marked
mine as a duplicate of yours and changed the severity of yours to a
more appropriate level. Generally speaking we reserve 'critical' for
bugs which affect a large proportion of applications ( 50%) and cause
major issues or security holes in those applications.
Thanks for filing the bug and hopefully it'll get sorted soon. If you
need a workaround *right now* then the easiest thing to do would be to
compile using the microsoft compiler and then run the resulting
assembly under mono. This is purely a compile time bug.
Alan.
On Sun, May 30, 2010 at 4:53 PM, Alan McGovern alan.mcgov...@gmail.com wrote:
There was a regression in trunk about 2 weeks ago which was fixed
about 4 days ago which was very similar to this. However your testcase
appears to fail on both mono 2.6.4 and svn trunk. Would you be able to
file a bug report with this testcase?
Thanks!
Alan.
On Sat, May 29, 2010 at 2:11 AM, Robert Jordan robe...@gmx.net wrote:
On 29.05.2010 01:44, Mehrdad Reshadi wrote:
I found the following bug, wondering if others have seen this, or anything
is being done to solve it. foreach is too common to have such a bug!
public static void Main(string[] args)
{
var o = new Y();
foreach (var c in new A[3] { new A(), new B(), new C() })
c.f(o);
new B().f(o);
}
foreach is obviously not the culprit, because the issue can
be reproduced with an unrolled loop:
public static void Main(string[] args)
{
var o = new Y();
var a = new A[3] { new A(), new B(), new C() };
a[0].f(o);
a[1].f(o);
a[2].f(o);
new B().f(o);
}
Please visit http://mono-project.com/Bugs and file a bug.
Robert
___
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] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration
I am thinking of a Java/.NET split if you will where we keep what we can that WILL run under Mono and port the rest to Java. That assumes we can get the two to play nicely together. Depending on what it is that doesn't work, it's possible that it'd only take you a couple of days could fix your issue. That'd be significantly less time than porting to java. You'd have to way up the pros and cons of rewriting in java. The biggest con is that you have doubled your maintainance burden if you have the same code in two languages. Alan. On Tue, May 25, 2010 at 9:09 PM, Greg Robinson gregarobin...@gmail.com wrote: Matt, it looks like most of the ClientCredentials class is done so you might be able to configure the necessary ClientCredentials in code rather than using .config files. So are you stating Mono is not app.config file friendly? So it's possible if we hard code these bits will run under Mono? On Tue, May 25, 2010 at 3:40 PM, Matt Dargavel m...@shout-telecoms.com wrote: Hi Greg, Have you tried running MoMA (http://www.mono-project.com/MoMa) against your application? This should give you an idea of how much is missing from Mono. With respect to WCF and the specific problem you saw, I’ve not used the security stuff at all but it looks like most of the ClientCredentials class is done so you might be able to configure the necessary ClientCredentials in code rather than using .config files. I don’t think the System.ServiceModel.Configuration namespace is as complete as some of the other bits. You can find information on the implementation status at the links below. http://go-mono.com/status/status.aspx?reference=3.5profile=2.0assembly=System.ServiceModel http://www.mono-project.com/WCF Regards, Matt. From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Greg Robinson Sent: 25 May 2010 7:09 PM To: Stifu Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration Understood, and that was my first thought. Was just wondering if there were alternative solutions. I am thinking of a Java/.NET split if you will where we keep what we can that WILL run under Mono and port the rest to Java. That assumes we can get the two to play nicely together. Is there a way to see if someone is already working on the bits in Mono we need? On Tue, May 25, 2010 at 2:05 PM, Stifu st...@free.fr wrote: The obvious answer: contribute to Mono and help implement it. Or pay someone to do it. That's what some companies do. If you can afford it, that's an option (which might turn out to be cheaper than rewriting everything in Java; that said, I have no idea how much work is needed here). Greg Robinson wrote: I am new to Linux, new to Mono. I am really hoping we can use Mono for our .NET application to Linux port/migration. The other option on the table is to totally re-write in Java. So what do folks usually do at this point; the point where they find that something they need, our .NET Server application calling a WCF Service using System.ServiceModel bits, not implemented in Mono? It seems a shame to just give up and do a port to Java; is that my only solution though? On Tue, May 25, 2010 at 12:45 PM, Miguel de Icaza mig...@novell.com wrote: When I go to: http://mono-project.com/DistroPackages/Ubuntu it tells me Mono comes installed by default. We are running Ubuntu 10.04. What do I need to do to upgrade to Mono 2.6 on Ubuntu 10.04? I am told that there are no 2.6 packages available for Ubuntu by the Debian/Ubuntu community. The bad news is that you need to compile from source code; The good news is that this is a trivial process (as long as you use released tarballs): http://www.mono-project.com/Parallel_Mono_Environments Migue. On Mon, May 24, 2010 at 8:50 AM, Oskar Berggren oskar.bergg...@gmail.com wrote: 2.2 is fairly old. Have you checked with 2.4 or 2.6? Try searching for moma and mono class library status. /Oskar 2010/5/24 Greg Robinson gregarobin...@gmail.com: I have been making good progress on moving our .NET server application over to Mono 2.2 running on Ubuntu 2.2. Friday, I ported the WCF pieces over where all the server application does is make calls to a WCF service running on a windows server outside of our office. I am getting the following, which suggests to me these pieces of client side WCF are not implemented in Mono 2.2:
Re: [Mono-dev] bug or wrong mono compilation?
It works fine with r156922 from SVN. When building from trunk, always
give the svn revision that you built with.
Alan.
On Sat, May 22, 2010 at 5:36 PM, xplicit s...@ngs.ru wrote:
I have compiled mono 2.7 from trunk and try to use C# 4.0 features. I wrote
simple program:
using System;
namespace test2
{
class MainClass
{
public static void Main (string[] args)
{
dynamic a=new object();
Console.WriteLine(a.ToString());
}
}
}
and run it. I expect System.Object instead of it the exception occurs:
Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException:
`string' does not contain a definition for `WriteLine'
at (wrapper dynamic-method) object.CallSite.Target
(System.Runtime.CompilerServices.Closure,System.Runtime.CompilerServices.CallSite,object)
IL 0x0004e, 0x000a6
at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1
(System.Runtime.CompilerServices.CallSite,object) 0x00365
at test2.MainClass.Main (string[]) [0x0005d] in
/home/sergey/Projects/test2/test2/Main.cs:11
What is this: bug in the mono, or I have wrongly compiled mono?
--
View this message in context:
http://mono.1490590.n4.nabble.com/bug-or-wrong-mono-compilation-tp2227282p2227282.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] mono debugger
You're installing a trunk build of mono with a 2.6.3 release of the debugger. This is a mismatch. As Michael said, SDB is built into the runtime these days so could more than likely just use that. Alan. On Wed, May 12, 2010 at 7:03 PM, sberryman sh...@golfsigma.com wrote: I don't have a parallel environment though. The trunk build is the only copy of mono running on the box. -- View this message in context: http://mono.1490590.n4.nabble.com/mono-debugger-tp2196491p2196512.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] mono debugger
Follow this guide: http://www.mono-project.com/Parallel_Mono_Environments and enter your parallel environment before compiling the debugger. Also don't mix SVN versions of mono with released versions of the debugger. You need to keep everything in sync. Either use 2.6.3 of both mono and the debugger or svn of both mono and the debugger. Alan. On Wed, May 12, 2010 at 6:53 PM, sberryman sh...@golfsigma.com wrote: I've got the trunk build of mono running: Mono JIT compiler version 2.7 (/trunk/mono r157252 Wed May 12 05:23:59 UTC 2010) Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com TLS: normal GC: Included Boehm (with typed GC and Parallel Mark) SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: debugger softdebug LLVM supported I'm trying to get the debugger built and I've tried using http://ftp.novell.com/pub/mono/sources/mono-debugger/mono-debugger-2.6.3.tar.bz2 and from the svn trunk (http://anonsvn.mono-project.com/viewvc/trunk/debugger/) When I try and use ./configure or autogen.sh I get the following error: checking Whether your Mono is working... no configure: error: *** Your Mono is too old for this version of the debugger. -- View this message in context: http://mono.1490590.n4.nabble.com/mono-debugger-tp2196491p2196491.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] - optimization for System.Xml.XmlNode::SelectSingleNode
Why would a c-cast be so much slower than an 'as' cast? Surely they should be equivalent or the c-cast should be faster. Alan. On Mon, May 10, 2010 at 7:24 PM, Atsushi Eno atsushi...@veritas-vos-liberabit.com wrote: Well, it wasn't really internal, but that does not affect my statement. Atsushi Eno On 2010/05/11 2:55, Atsushi Eno wrote: Hi, Thanks Tom, it looks like a good catch. The interface is internal, and cast exceptions should not happen there anyways. Once the build got fixed, I'll verify the patch and apply it unless it regresses. Atsushi Eno On 2010/05/11 2:09, tom hindle wrote: Hi, While performance profiling our code, with mono's nice profiling tools :), I noticed System.Xml.XmlNode::SelectSingleNode was taking 23ms a call while the sum of the methods it was calling took 5ms. SelectSingleNode is a very simple method however it contains a (dynamic) down cast. I replaced the (Cstyle/prefix) cast with a 'as' cast and this seem to reduce the method time by about 7ms. // With 'Cstyle' cast 39672.303 1717 23.106 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager) Callers (with count) that contribute at least for 1%: 1717 100 % System.Xml.XmlNode::SelectSingleNode(string) // With 'as' cast 29238.117 1880 15.552 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager) Callers (with count) that contribute at least for 1%: 1880 100 % System.Xml.XmlNode::SelectSingleNode(string) I read that this is because 'as' cast generates IL instr 'isinst' while 'cstyle' cast generates 'castclass'. The msdn documentation about XmlNode.SelectSingleNode doesn't state that an InvalidCastException, can/could be thrown. Is this a sensible thing to do? If so could someone review/commit my patch as I believe it will make a fairly major difference for applications that make much use of SelectSingleNode. Thanks Tom ___ 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 ___ 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] GroupBy Bug (Bug 601101)
Hey More than 50% of your patch is whitespace noise which makes it hard to see what exactly it is you're fixing. Could you submit a patch without all the extra whitespace changes? Secondly, I'd personally view any code which relies on the element ordering in a dictionary as being a bug and should be fixed. As for the actual patch, I have no comments ;) Alan On 29 Apr 2010, at 22:18, Richard Kiene richard.ki...@logos.com wrote: I have filed Bug 601101 https://bugzilla.novell.com/show_bug.cgi?id=601101 for this issue. In addition; I have attached a patch which resolves the issue. That said, I'm not really sure this patch is the most desirable way to fix the bug. If you would like to use the patch I release it under the MIT/X11 License. Also worth noting is that a Dictionary is used to create the groups, but Dictionary as defined by MSDN does not preserve element ordering. It appears that the mono implementation of Dictionary does and that is why it is used, is this correct? Thanks, Richard Kiene GroupBy.patch.txt ATT1..htm ___ 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] Some demo examples do not work!
Hey, As per error message, you're missing libgdiplus. If you install that everything should work fine. Alan On 19 Apr 2010, at 06:12, Lyndon Lu lyndon...@gmail.com wrote: Hi All, I have installed mono 2.6.3 from source files in CentOS 5. I can see that test web page Welcome to Mono XSP by running http://hostname/demo . While clicking Authtest-index.aspx, I got the error The web page cannot be found. If clicking Authtest-login.aspx, I got the error message: Server Error in '/demo' Application gdiplus.dll Description: HTTP 500. Error processing request. Stack Trace: System.DllNotFoundException: gdiplus.dll at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong ,System.Drawing.GdiplusStartupInput ,System.Drawing.GdiplusStartupOutput) at System.Drawing.GDIPlus..cctor () [0x0] in filename unknown:0 Version information: Mono Runtime Version: 2.6.3 (tarball Thu Mar 25 14:31:21 EST 2010); ASP.NET Version: 2.0.50727.1433 The example Webcontrol-calendar also does not work. Other examples seem working. Does anyone know how to get them working? Thanks in advance. Cheers, Lyndon. ___ 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] Socket.BeginReceive never throw Exception
Hey,
It really does look like a valid issue but as it stands there's no
testcase to reproduce the issue. I do this *all* the time in the
testcases for MonoTorrent and my callbacks are always invoked. I
explicitly test for this in some of my testcases. There are times when
EndReceive is not supposed to throw an exception even though the
socket is not connected. Maybe you're hitting this case. It's just
impossible for me to see this bug happening so it's impossible for us
to fix it.
I'm not asking you to defend your bug report, i'm just asking you to
make it easy for us to fix it. You have a testcase which can reproduce
the bug 100% of the time. If that testcase could be supplied as part
of the bug report, it would be so much easier to resolve the issue.
All you need to do is put the testcase in a console app so that we can
just compile and run it to see the issue.
Thanks,
Alan.
On Mon, Apr 12, 2010 at 9:22 AM, Stefan [At] swieser1...@gmail.com wrote:
Is there a testcase for this? This works fine for me, I'm inclined to
believe there's a bug in the testcase.
My code relying on the callback on disconnect works fine with Microsoft's
.NET and it doesn't work with Mono because the callback never occurs. Thus,
the behaviour from both frameworks deviate. I think my original message
never posted to the mailing list, so essentially, this is the code I'm
using:
Socket socket = server.AcceptSocket();
socket.NoDelay = true;
socket.Blocking = false;
[...]
socket.BeginReceive(receive_buffer, 0, buffer_size, 0, new
AsyncCallback(ReceiveDone), socket);
[...]
public void ReceiveDone(IAsyncResult result) {
Socket socket = (Socket)result.AsyncState;
int bytes_read = socket.EndReceive(result);
[...]
}
The workaround to run through all Sockets and check for the Connected
property being set to false works with Mono and isn't needed for Microsoft's
.NET (as the event properly fires). Sockets are set into NoDelay,
NonBlocking mode and then use asynchronous calls with BeginReceive and
EndReceive. Maybe it is that particular constellation, or maybe the g++
compiler, or maybe the host system.
bash-3.2# mono --version
Mono JIT compiler version 2.6.1 (tarball Thu Apr 8 13:02:55 UTC 2010)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC and Parallel Mark)
SIGSEGV: altstack
Notifications: epoll
I know, this is not the most recent version ATM, but the OP replied that
this behaviour occurs with 2.6.3 as well and I do trust their judgement.
I've never gotten into the notion on having to defend my bug reports. I do
my own test cases and testing, but you are welcome to put it down as a bug
in my code. As I only need Mono for a quick internal use case in two weeks'
time, I'll get away using a workaround. Good luck getting this fixed (should
you decide to treat it as a valid issue), and take care ;)
--
View this message in context:
http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1836801.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] Socket.BeginReceive never throw Exception
Is there a testcase for this? This works fine for me, I'm inclined to believe there's a bug in the testcase. Alan. On Fri, Apr 9, 2010 at 4:21 PM, Stefan [At] swieser1...@gmail.com wrote: socket.BeginReceive(receive_buffer, 0, FlockNode.buffer_size, 0, new AsyncCallback(ReceiveDone), socket); If the Socket gets disconnected by the remote host, ReceiveDone is called, and EndReceive will throw a SocketException; thus you know that your socket is now disconnected without having to poll it. With Mono, no exception is thrown. Just to be a bit more clear about this, not only no exception is thrown, ReceiveDone isn't called either. -- View this message in context: http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1819481.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] Build Microsoft Visual Studio Solution under Mono
A visual studio compiled binary and mono compiled binary are more or less identical. Just copy/paste the compiled code to a linux system and execute it there. Alan. On Thu, Apr 8, 2010 at 9:17 AM, Matt Dargavel m...@shout-telecoms.com wrote: Hi, I suggest you start here: http://www.mono-project.com/Main_Page Especially: http://mono-project.com/Start http://mono-project.com/FAQ:_General http://mono-project.com/Moma But to give you a quick answer, .NET binaries produced by Visual Studio will run under Mono depending on the feature set used. MoMA will analyse these binaries and tell you if they use any features that aren't currently supported under Mono. Regards, Matt. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of The87Boy Sent: 25 March 2010 9:34 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Build Microsoft Visual Studio Solution under Mono I have developed a program under Microsoft Visual Studio, but as I have to move the Business and Data-part to the server, I need it to compile to Mono as the server runs Linux. The reason is, that I will only allow DB-Connection on Localhost. My question is now, how do I compile the program? Are there any programs to develop to Mono, I can use under Windows, or how can I do this? I hope you understand my question -- View this message in context: http://n4.nabble.com/Build-Microsoft-Visual- Studio-Solution-under-Mono-tp1691343p1691343.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Threading parameters? Fill a DataGridView via Invoke very slow
Can you provide a testcase demonstrating the issue. Thanks, Alan. On Thu, Mar 25, 2010 at 2:59 PM, Stifu st...@free.fr wrote: MonoDevelop on Windows uses .NET by default, not Mono. boolean wrote: Another solution with delegates instead of invoke brings no advantages. It´s curious on Windows and Mono Develop it´s comperable fast like on .NET. -- View this message in context: http://n4.nabble.com/Threading-parameters-Fill-a-DataGridView-via-Invoke-very-slow-tp1680691p1690764.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] Socket.BeginReceive never throw Exception
Can you provide a testcase demonstrating the bug or more clearly explain what you mean by using code samples? Thanks, Alan On Wed, Mar 24, 2010 at 1:50 AM, Pigo Chu pigo_...@hotmail.com wrote: I am designing a simple http server use Async Socket model. And test performance use ab (apache benchmark) Like ab -c 1000 -n 10 -k http://myserver... when ab request end , but my http server never got disconnect signal many times. Why happend this ? because Socket.BeginReceive no throw exception when I have not write try ... catch code But on MS.Net , Socket.BeginReceive will throw exception when I have not write try catch My test os is ubuntu 9.10 , mono version is 2.4.2.3 This bug also happend on mono 2.6.3 with debian 5. -- View this message in context: http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1679973.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] Error compiling WebConnection.cs
This is a known issue in our build system. run make clean and/or make distclean and then autogen and build again. That'll resolve the problem. Alan. On Mon, Mar 1, 2010 at 10:03 PM, Neale Ferguson ne...@sinenomine.net wrote: Just updated to head, did get-monolite-latest and getting this during the build: System.Net/WebConnection.cs(361,82): error CS0246: The type or namespace name `CertificateValidationCallback2' could not be found. Are you missing a using directive or an assembly reference? ___ 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] Mono process crashes after closing client socket
Hey, Firstly, could you try with a newer mono. If there is a bug in 2.0, there's not a chance of a new 2.0 release being made and it's also quite possible that the issue has been fixed since then. If the bug is still there in mono 2.6+ then file a bug report with all relevant info. You could also try running your app in GDB (http://www.mono-project.com/Debugging) to try and catch the place where it blows up. Alan. On Thu, Feb 19, 2009 at 3:46 PM, FirstName LastName mousse_...@hotmail.com wrote: Hi, I'm working with mono 2.0 on a ARM. I'm seeing a strange problem. I have a client application that receives a HTTP MJPEG stream from my ARM. Sometimes, when closing the client, the tcp socket is properly handled in mono. But sometimes, the mono process stop instantly with no trace. I noticed that in this situation, every time it happens, the signal SIG_PIPE is raised. So, my question is: 1) Does mono handle gracefully the SIG_PIPE signal? Thanks. Upgrade to Hotmail Plus and share more photos with bigger attachments. Click here to find out how Click here to find out how ___ 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] Summer of Code / C++ Interop
Hey, Join us in the #monosoc channel on irc (http://www.mono-project.com/IRC). Also, I believe the deadline for proposals is tomorrow so you should probably submit a proposal asap which can be updated/modified later on as required. If you miss that deadline, there's not a chance of the project being selected. Alan. On Thu, Apr 8, 2010 at 10:25 AM, Alex Corrado alexander.corr...@gmail.com wrote: Dear Mr. de Icaza and the Mono Developer Community, First, I would like to salute you for producing an excellent, open platform for software development. Second, I would like to apologize for bothering anyone who is not interested in a student's proposal to improve it. I appreciate your time and any feedback you might give. I am proposing to expand Mono's C++ interop support to enable the creation of managed wrappers directly around native C++ objects. This would make C++ libraries callable directly from managed code without the need for wrapping them in a flat C API, COM interface, or requiring the use of mixed binaries (C++/CLI). In fact, this could also provide a way to implement the C++/CLI language, including IJW, in a cross-platform manner. The first place I read about calling C++ functions directly from managed code was on Mono's Interop with Native Libraries page. It suggested setting the EntryPoint of the DllImport attribute to the C++ mangled function name to call that function directly through P/Invoke. However, it wasn't until I read this blog post by Jim Springfield that I realized that, not only could this be a viable technique, but that by messing with virtual tables, native C++ classes could effectively be subclassed by managed code. This technique could allow for seamless managed wrappers around native C++ classes. Jim Springfield's example is tied completely to Microsoft's Visual C++ compiler, and this illustrates the largest problem with this approach: that C++ ABIs are different among different compilers and even between different versions of the same compiler. To help ameliorate this issue, I have taken the basic principles in Springfield's design and abstracted out any ABI-specific components into an abstract class. A different subclass of this CppAbi class can then be implemented to support each compiler's different name mangling schemes and other idiosyncrasies. At runtime, the correct CppAbi instance can be chosen when loading the C++ library depending on platform or other conditions. Reflection.Emit is then used to generate the P/Invoke code and implement trampolines to facilitate virtual method calls. Eventually I hope to support seamless exception handling and other features supported by C++/CLI on Windows. I realize this sounds very ambitious, but I've already implemented a proof-of-concept based on a simple C++ class, similar to the one Jim Springfield uses in his example. It is hosted on Google code at http://code.google.com/p/cppinterop/. Please note that this really is just a proof-of-concept-- I've only implemented the Itanium C++ ABI, and only in part. If you are using a recent version of GCC to compile C++, you should be able to compile the example and call it directly from managed code. I've only tested this on an Intel Mac running OS X 10.4.11. I would include some details about myself, but I feel like this email is already long enough. So if there is anything in particular you would like to know, or any feedback you might have, please feel free to contact me. Thank you very much for your time. Sincerely, Alexander Corrado Undergraduate Student at the University of Oregon alexander.corr...@gmail.com http://code.google.com/p/cppinterop/ ___ 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] Your help needed for our upcoming release.
This bug was fixed for 2.4.3 but has regressed again. https://bugzilla.novell.com/show_bug.cgi?id=583451 Would it be possible to get this fixed for 2.4.4+ ? It does work in the 2.6 branch as of r151801, so no need to prioritise this one now ;) Alan. On Tue, Feb 23, 2010 at 11:04 PM, Miguel de Icaza mig...@novell.com wrote: Hello guys, I changed the subject of this email, since Andrew's call to action is important and it applies to everyone: Just a reminder: If you've been assigned a bug or you know of a bug that's been fixed and needs to be backported please do so before the end of this week. There's a good chance we'll try to release 2.6.3 from the 2.6 branch early next week. The QA team is still testing this branch but testing doesn't fix bugs, it can only find them. Please do your part. On Tue, 2010-02-02 at 10:57 -0700, Andrew Jorgensen wrote: Hello Happy Coders, We are planning to make a new release from the 2.6 branch in the near future (probably before the end of the month?). If there are bugs that you know ought to be backported (customer issues, regressions, and embarrassments especially) please do so in the next week or so. As you backport please keep in mind that we are trying to stabilize the 2.6 branch. Be conscientious and thorough and use your own best judgment in your area of expertise and consult your colleagues where you have doubts. Also don't neglect other platforms like Mac, Windows, and Linux s390x. 2.6.x will eventually be used as a Novell-supported release for the Mono Extension for SLE and other products. We will be doing some testing of the 2.6 branch during this time. If QA approaches you regarding a bug please remember that we will also need time to verify the fix after you check it in. In other words: please give us any priority you can. And don't forget to close bugs as you fix them and file them as you find them. Hmm, I should get someone to fix the booc crasher on x86_64... Oh and thanks so much to those who pitched in to get our Xen x86_64 crasher fixed! Best Regards, Andrew Jorgensen Release / Packaging Guy Novell, Inc. ___ Ximian-mono-list mailing list ximian-mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/ximian-mono-list ___ 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] Custom Uri Parsing
Hey, On Fri, Feb 12, 2010 at 6:52 PM, Matt Dargavel m...@shout-telecoms.comwrote: Thanks for the info Alan. At the moment I’ve put together a very quick and dirty version that uses IsPredefinedScheme to decide whether to use the existing parsing code or use the registered Parser class when the Uri is first created (and parsed). That might be the best way to get started alright. I was wondering whether something along the lines of moving the existing parsing routine in to DefaultUriParser and use this for the predefined schemes might be possible. You might then be able to replace this with the proper Parser classes for the built in schemes one by one. This would allow people to write parsers for unsupported schemes, and would hopefully pass the existing tests. It's quite possible that this will be the easiest (and best) way to start off. I'm interested in any progress you make on this as I'll be able to fix some long-standing issues with the System.IO.Packaging API in the WindowsBase assembly when this is implemented. It needs a proper UriParser subclass which isn't possible right now. Thanks, Alan. Anyway, I’ll look in to it a bit more and see if I can come up with a more definite suggestion. Cheers, Matt. *From:* Alan McGovern [mailto:alan.mcgov...@gmail.com] *Sent:* 11 February 2010 11:45 PM *To:* Miguel de Icaza *Cc:* Matt Dargavel; mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Custom Uri Parsing Hey, The main reason why I didn't actually do any work on this at the time is that it would probably take 1 man month to do the rewrite, pass the existing tests and write more tests for the new behaviours and I didn't have a month free to do it ;) Proper support for the new parser API is required to properly support System.IO.Packaging, so I'd be willing to offer any advice if you want to take on the task. The biggest problem (as I saw it at the time) is that this is an all or nothing kind of patch. It might be impossible to do this one uri scheme at a time without making things ridiculously complicated internally. While the existing code will be useful as a guide, you will end up chopping it up into tiny pieces and moving it around into the different parser subclasses. Alan. p.s. The above should be mostly accurate, but the last time I looked at this was when I sent the original email ;) On Thu, Feb 11, 2010 at 5:09 AM, Miguel de Icaza mig...@novell.com wrote: Hello, Some searching also threw up this post to the list back in October 2008: http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg18617.html . I’ve looked in to the Mono implementation in svn, and it still appears that most of the Uri class decodes specific Uri content itself rather than delegating to Uri parsers. I do not believe we ever moved to that scheme of Uri parsing. I was wondering if anyone knew if the post above was ever followed up, or whether the suggestion wasn’t implemented for some reason? I guess this should probably be filed as a bug, as the functionality was added in .NET 2? If you’d welcome a patch I could probably submit something based on Alan’s suggestion. I would love to see a patch based on Alan's patch. It should be simpler these days since Mono trunk has dropped support for 1.0 compatibility ___ 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] Questions about csharp-sqlite - port of the SQLite library from C to C#
Hey, Questions 1-3 would be best directed at the developer of csharp-sqlite. He is not affiliated with mono in any way (that I know of). As for the final question, I'm not aware of anyone writing an ADO.NETwrapper for csharp-sqlite. If someone were interested in creating one, i'm sure it'd be appreciated by the community though. Alan. On Sat, Feb 13, 2010 at 9:22 PM, Daniel Morgan monodanm...@yahoo.comwrote: I have asked some questions at the FAQ for csharp-sqlite. http://code.google.com/p/csharp-sqlite/wiki/FrequentlyAskedQuestions csharp-sqlite is a C# port of the SQLite library. This is NOT a wrapper to a native library. It is a 100% port of the C library to C#. http://code.google.com/p/csharp-sqlite/ 1. Can you provide the source zipped up in a .zip file or tarball as .tar.gz please? 2. Is there a online forum or mailing list for this project? I have a feeling my questions here are not in the appropriate place. Is there a Google Group for these questions? 3. Can you provide a Download link and Download page listing packages that are zipped up or tarballs of sources and/or binaries please? I really want to try csharp-sqlite out, but I do not want to install HG (Mercurial). 4. Is anyone working on an ADO.NET wrapper of csharp-sqlite where you have only one assembly that is a class library? Preferably based on .NET Framework 2.0. I have did an internet search, but I have not found anyone. The closest thing is what Tim did for Silverlight, but it does not use System.Data. All the incarnations of Mono's Sqlite libraries do not work for me because they still use native code. And I do not think System.Data.SQLite from http://sqlite.phxsoftware.com/ has support for csharp-sqlite. Does anyone know if phxsoftware will add support for csharp-sqlite? ___ 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] Custom Uri Parsing
Hey, The main reason why I didn't actually do any work on this at the time is that it would probably take 1 man month to do the rewrite, pass the existing tests and write more tests for the new behaviours and I didn't have a month free to do it ;) Proper support for the new parser API is required to properly support System.IO.Packaging, so I'd be willing to offer any advice if you want to take on the task. The biggest problem (as I saw it at the time) is that this is an all or nothing kind of patch. It might be impossible to do this one uri scheme at a time without making things ridiculously complicated internally. While the existing code will be useful as a guide, you will end up chopping it up into tiny pieces and moving it around into the different parser subclasses. Alan. p.s. The above should be mostly accurate, but the last time I looked at this was when I sent the original email ;) On Thu, Feb 11, 2010 at 5:09 AM, Miguel de Icaza mig...@novell.com wrote: Hello, Some searching also threw up this post to the list back in October 2008: http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg18617.html . I’ve looked in to the Mono implementation in svn, and it still appears that most of the Uri class decodes specific Uri content itself rather than delegating to Uri parsers. I do not believe we ever moved to that scheme of Uri parsing. I was wondering if anyone knew if the post above was ever followed up, or whether the suggestion wasn’t implemented for some reason? I guess this should probably be filed as a bug, as the functionality was added in .NET 2? If you’d welcome a patch I could probably submit something based on Alan’s suggestion. I would love to see a patch based on Alan's patch. It should be simpler these days since Mono trunk has dropped support for 1.0 compatibility ___ 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] BufferedStream.ReadByte and WriteByte are extremely inefficient
Hey,
This patch does three things:
1) Optimises away some allocations - good
2) Added extra checks which throw exceptions - without providing testcases -
bad
3) A fair few whitespace changes - bad
Would you be able to submit two patches instead? The first should do the
optimisation, the second should add the test+exception for CanRead and
CanWrite as well as adding some nunit test cases which show that this is
required.
Also:
+ if (1 = m_buffer.Length) {
+ return m_stream.ReadByte ();
That should really be: if m_buffer.Length == 0 as the case where the Length
is = 0 is already handled. It makes things easier to understand.
Thanks,
Alan.
On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot tom.phil...@logos.com wrote:
Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange
support turned my This is contributed under the MIT/X11 license into an
attachment.
For the record, the code in this patch is contributed under the MIT/X11
license
___
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] BufferedStream.ReadByte and WriteByte are extremely inefficient
Actually, ignore the part about the 1 = m_buffer.Length. On second reading
that's fine ;)
Alan.
On Mon, Jan 11, 2010 at 11:24 PM, Alan McGovern alan.mcgov...@gmail.comwrote:
Hey,
This patch does three things:
1) Optimises away some allocations - good
2) Added extra checks which throw exceptions - without providing testcases
- bad
3) A fair few whitespace changes - bad
Would you be able to submit two patches instead? The first should do the
optimisation, the second should add the test+exception for CanRead and
CanWrite as well as adding some nunit test cases which show that this is
required.
Also:
+ if (1 = m_buffer.Length) {
+ return m_stream.ReadByte ();
That should really be: if m_buffer.Length == 0 as the case where the Length
is = 0 is already handled. It makes things easier to understand.
Thanks,
Alan.
On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot tom.phil...@logos.comwrote:
Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange
support turned my This is contributed under the MIT/X11 license into an
attachment.
For the record, the code in this patch is contributed under the MIT/X11
license
___
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] LLVM Expectations
Hey, 1) Is the LLVM back-end intended to be a long term solution to code optimization for performance sensitive code in mono? 2) How confident are you that the issues described can be resolved without kludge? 3) Would success with the LLVM back-end necessarily curtail efforts to improve code optimization in the pure mono JIT engine? Apart from any issues mentioned in that page, LLVM is (currently) just too slow to be used as a JIT. This is why it's limited to AOT only at the moment. To the best of my knowledge, monos standard jit is still the primary target for optimisations and will be for a long time. Alan. -- View this message in context: http://old.nabble.com/LLVM-Expectations-tp26930912p26930912.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] Announcing the release of Mono 2.4.3
There were two commits to SVN with regards to this bug so it looks like it was accidently not closed. CC'ing the guy who committed those fixes as he'd be the one to know whether it should be closed or not. Alan. On Wed, Dec 9, 2009 at 10:41 PM, Oskar Berggren oskar.bergg...@gmail.comwrote: The release notes lists the following issue as fixed: 467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView in VirtualMode uses too much memory and is slow But the bug report is still marked as NEW and there is no comment indicating that a fix has been checked in. What is the interpretation of this? /Oskar 2009/12/9 Andrew Jorgensen ajorgen...@novell.com: Yesterday we released Mono 2.4.3. This release contains a large number of bug fixes, including fixes for security bugs. The release notes are here: http://go-mono.com/archive/2.4.3 and downloads are available here: http://go-mono.com/mono-downloads/ We have not released LiveCD or Appliance images because we are working toward a 2.6 release in the near future. Thanks to all those who contributed to this release! ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] StyleCop incompatibility
According to the rule - any using statement starting with System. should be sorted first. It's nothing to do with the assembly that the namespace comes from. Alan. On Tue, Dec 8, 2009 at 11:27 AM, Andrew Mikhailov and...@vitche.com wrote: The MS defines a code-style rule for the order in which the “usings” must be sorted: http://www.thewayithink.co.uk/stylecop/sa1208.htm The MonoDevelop application’s “Sort Usings” functionality simply sorts using in the alphabetical order but does not consider this rule. Related problems: How does Mono know which assemblies are system-ones? The question appears because the ported project’s source code may include unknown assemblies. ___ 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] Why not build official site on ASP.NET? Mono should enhance server performance and stability!
Hey, MonoTorrent uses the standard .NET threadpool for all asynchronous sockets. It's all standard Socket.BeginReceive/Socket.EndReceive calls. I've run it with ~150 open connections in the past with no issues, though it's worth noting that 150 open connections != 150 actively transferring connections. If you're seeing issues with running out of threads and connections being dropped as a result, just export MONO_THREADS_PER_CPU=100 to increase the maximum number of allowed threads and see if that helps. Feel free to vary the number up or down as appropriate. Alan. On Mon, Dec 7, 2009 at 5:12 PM, Rafael Teixeira mono...@gmail.com wrote: You could look at the source of MonoTorrent, and also of XSP that does use a separate ThreadPool AFAIR. Rafael Monoman Teixeira --- To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it. Osho On Sun, Dec 6, 2009 at 11:21 PM, Laser Lu laser...@163.com wrote: Thanks for your reply ;-) I’m now using the latest version 2.4.2.3. This is the program I’m developing: http://linktalk.net. In this program, IHttpAsyncHandler, ThreadPool, and TCP Sockets are heavily used. I tried to host my program under Apache/XSP, but it had a really poor performance. So, I tried the HttpListener class, but still not good, and had lots of SocketExceptions thrown compared to the Windows counterpart. Lastly, I implemented a simple web server by myself, using Socket listening and parsing directly. It works better, however, async requests usually become unresponsive. It seems the ThreadPool is not as good as the .NET implementation, or maybe there needs some special configuration I don’t know. Under Windows/.NET the program can handle more than 2000 online IM users concurrently, but on Linux/Mono less than 100 conrrent users, and usually become unresponsive… From: Miguel de Icaza [mailto:mig...@novell.com] Sent: Monday, December 07, 2009 9:03 AM To: Laser Lu Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Why not build official site on ASP.NET? Mono should enhance server performance and stability! Hello, The problem is that we would have to migrate the contents. We tried once to move to MindTouch's Deki, but we lost too much in the translation and there were too many problems with the translation so we abandoned that plan. We are doing the new web sites using Mono though, http://monodevelop.com, http://wiki.monotouch.net, http://monotouch.net, and http://forums.monotouch.net are all running with Mono powered software. As for stability and performance, which version of Mono are you running? I was just wondering, why the mono official site was not built on ASP.NET/C#? That would be a good demonstration. Currently, I’m developing a Web IM program, and it works fine on Windows/.NET. However, the same code had a poor performance on Linux/Mono, and seems very unstable. So I doubt whether Mono is suitable for developing server programs which should be able to handle a huge amount of concurrent requests. I wish the Mono team would pay much more attentions to server applications, and enhance the server stability or just concentrate on server applications, not just catching up with Microsoft’s new cool features. Because Linux/Unix is used as server under 90% circumstances, performance and stability is the most import thing! ___ 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 ___ 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] Why not build official site on ASP.NET? Mono should enhance server performance and stability!
Just to add, while MonoTorrent doesn't use it's on threadpool, it doesn't hog ThreadPool threads by blocking inside the async callbacks. As soon as a message is received and my callback is invoked, I queue the message to be processed and allow thread to return to the ThreadPool. As such, even with a large number of actively transferring connections ( 50) I only need a handful of threadpool threads. If you starve the threadpool, your performance will suffer accordingly ;) Alan. On Mon, Dec 7, 2009 at 8:17 PM, Alan McGovern alan.mcgov...@gmail.comwrote: Hey, MonoTorrent uses the standard .NET threadpool for all asynchronous sockets. It's all standard Socket.BeginReceive/Socket.EndReceive calls. I've run it with ~150 open connections in the past with no issues, though it's worth noting that 150 open connections != 150 actively transferring connections. If you're seeing issues with running out of threads and connections being dropped as a result, just export MONO_THREADS_PER_CPU=100 to increase the maximum number of allowed threads and see if that helps. Feel free to vary the number up or down as appropriate. Alan. On Mon, Dec 7, 2009 at 5:12 PM, Rafael Teixeira mono...@gmail.com wrote: You could look at the source of MonoTorrent, and also of XSP that does use a separate ThreadPool AFAIR. Rafael Monoman Teixeira --- To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it. Osho On Sun, Dec 6, 2009 at 11:21 PM, Laser Lu laser...@163.com wrote: Thanks for your reply ;-) I’m now using the latest version 2.4.2.3. This is the program I’m developing: http://linktalk.net. In this program, IHttpAsyncHandler, ThreadPool, and TCP Sockets are heavily used. I tried to host my program under Apache/XSP, but it had a really poor performance. So, I tried the HttpListener class, but still not good, and had lots of SocketExceptions thrown compared to the Windows counterpart. Lastly, I implemented a simple web server by myself, using Socket listening and parsing directly. It works better, however, async requests usually become unresponsive. It seems the ThreadPool is not as good as the .NET implementation, or maybe there needs some special configuration I don’t know. Under Windows/.NET the program can handle more than 2000 online IM users concurrently, but on Linux/Mono less than 100 conrrent users, and usually become unresponsive… From: Miguel de Icaza [mailto:mig...@novell.com] Sent: Monday, December 07, 2009 9:03 AM To: Laser Lu Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Why not build official site on ASP.NET? Mono should enhance server performance and stability! Hello, The problem is that we would have to migrate the contents. We tried once to move to MindTouch's Deki, but we lost too much in the translation and there were too many problems with the translation so we abandoned that plan. We are doing the new web sites using Mono though, http://monodevelop.com, http://wiki.monotouch.net, http://monotouch.net, and http://forums.monotouch.net are all running with Mono powered software. As for stability and performance, which version of Mono are you running? I was just wondering, why the mono official site was not built on ASP.NET/C#? That would be a good demonstration. Currently, I’m developing a Web IM program, and it works fine on Windows/.NET. However, the same code had a poor performance on Linux/Mono, and seems very unstable. So I doubt whether Mono is suitable for developing server programs which should be able to handle a huge amount of concurrent requests. I wish the Mono team would pay much more attentions to server applications, and enhance the server stability or just concentrate on server applications, not just catching up with Microsoft’s new cool features. Because Linux/Unix is used as server under 90% circumstances, performance and stability is the most import thing! ___ 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 ___ 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
Re: [Mono-dev] Problem with PackagePart URI containing spaces
Hi,
Thanks for the bug report. Would you be able to file the issue on bugzilla
(with the testcase) and assign it to me (amcgov...@novell.com). That way I
can fix it and have the paper trail to verify the fix works.
If you come across any other issues, just assign them directly to me on
bugzilla.
Thanks,
Alan.
On Mon, Nov 23, 2009 at 11:53 AM, mhartmann mhartm...@vr-web.de wrote:
Hi,
I'm trying to read packages that were created with System.IO.Packaging on a
Windows machine using .NET.
It seems that that there is a problem with PackageParts that contain spaces
in the specified package URI.
Using the following code produces different results on .NET / Mono:
string fileName = Test.zip;
Uri uri = PackUriHelper.CreatePartUri(new Uri(/My Folder/Test.txt,
UriKind.Relative));
using (Package package = Package.Open(fileName, FileMode.Create))
{
PackagePart part = package.CreatePart(uri,
System.Net.Mime.MediaTypeNames.Text.Plain);
using (StreamWriter sw = new StreamWriter(part.GetStream()))
{
sw.WriteLine(Hello World);
}
}
On Linux using Mono the ZIP file contains a folder My Folder, but with
Windows and .NET the name of the folder is escaped (My%20Folder).
Best regards
Martin
--
View this message in context:
http://old.nabble.com/Problem-with-PackagePart-URI-containing-spaces-tp26476712p26476712.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] Problem with PackagePart URI containing spaces
You want to file it under Mono: Class Libaries product. Unfortunately
there's no component for the WindowsBase dll, so for the moment just use
'System'. I'm going to get in touch with our bugzilla guy and try to get a
WindowsBase component put up there. If you are filing bugs, do look out for
it as it should be there within a day or so.
Thanks,
Alan.
p.s. You forgot to hit 'reply-all' with your last email. I've added the
mailing list back into the CC but just look out for that in future.
On Mon, Nov 23, 2009 at 2:51 PM, mhartm...@vr-web.de wrote:
Hi,
can you give me a hint which Product / Component shall I use when I'm
entering a new bug?
Thanks,
Martin
Alan McGovern-2 wrote:
Hi,
Thanks for the bug report. Would you be able to file the issue on
bugzilla
(with the testcase) and assign it to me (amcgov...@novell.com). That way
I
can fix it and have the paper trail to verify the fix works.
If you come across any other issues, just assign them directly to me on
bugzilla.
Thanks,
Alan.
On Mon, Nov 23, 2009 at 11:53 AM, mhartmann mhartm...@vr-web.de wrote:
Hi,
I'm trying to read packages that were created with System.IO.Packaging
on
a
Windows machine using .NET.
It seems that that there is a problem with PackageParts that contain
spaces
in the specified package URI.
Using the following code produces different results on .NET / Mono:
string fileName = Test.zip;
Uri uri = PackUriHelper.CreatePartUri(new Uri(/My Folder/Test.txt,
UriKind.Relative));
using (Package package = Package.Open(fileName, FileMode.Create))
{
PackagePart part = package.CreatePart(uri,
System.Net.Mime.MediaTypeNames.Text.Plain);
using (StreamWriter sw = new StreamWriter(part.GetStream()))
{
sw.WriteLine(Hello World);
}
}
On Linux using Mono the ZIP file contains a folder My Folder, but with
Windows and .NET the name of the folder is escaped (My%20Folder).
Best regards
Martin
--
View this message in context:
http://old.nabble.com/Problem-with-PackagePart-URI-containing-spaces-tp26476712p26476712.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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
Quoted from:
http://old.nabble.com/Problem-with-PackagePart-URI-containing-spaces-tp26476712p26478275.html
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Should we replace MemoryStream?
Hey, On Mon, Nov 9, 2009 at 6:29 PM, Avery Pennarun apenw...@gmail.com wrote: On Mon, Nov 9, 2009 at 1:10 PM, Miguel de Icaza mig...@novell.com wrote: I just blogged about a memory fragmentation issue here: http://tirania.org/blog/archive/2009/Nov-09.html And I am wondering: since MemoryStream is one of these sources of problems, we could replace this implementation with MindTouch's ChunkedStream. Probably stupid question: why is a compacting garbage collector actually needed? C programs have survived for a *long* time without any ability whatsoever to compact memory, simply by carefully optimizing their allocation algorithms to avoid fragmentation. Is the mono allocator very non-optimal in this respect? One of the causes is that in a garbage collected language you allocate when you need something and discard it when you're done. If you do this with large buffers which are pinned in memory and have just the wrong allocation pattern, you can bloat your memory usage. There's nothing mono can do in this case as essentially it's the user causing the bloat. One thing you can do is keep a cache of buffers yourself and re-use them. For example if your application allocates 10 chunked memory streams a second and Dispose () them when you're done, you could add/remove the 'chunks' from a cache. This way you'd only ever allocate 10xsizeof (chunked stream) bytes of memory and you'd constantly re-use them. Alan. Like I said, I feel like this is a stupid question. But I'm curious about the answer, and neither your blog post nor the linked page on the sgen collector addresses it. Thanks, Avery ___ 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] faster than hashtable?
If the key is random, a hashtable is the fastest way. You may be able to eke some extra speed out of the DictionaryK, V class by ripping all the code to support generic keys and instead hardcode the key to always be a long. That should save a bit of time, though whether it'd be noticable or not I don't know. Alan. On Wed, Oct 28, 2009 at 8:25 AM, Tom Spink tsp...@gmail.com wrote: 2009/10/27 psant...@codicesoftware.com psant...@codicesoftware.com: Hi, If you need to store key/value pairs, where the key will be ALWAYS a unique long (no collisions), is there anything better than a Hashtable? Thanks pablo Presumably, though, the key can span the entire range of a long? If it's an acceptably small range, you could use an array. -- Tom Spink ___ 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] faster than hashtable?
Really what you need to do is benchmark all of the different options using your expected workload. It's near useless us telling you X is faster or Y is better without knowing the workload involved. Alan. On Wed, Oct 28, 2009 at 2:40 PM, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Excellent. Is there a wrapper for C#? Is it worth? Felipe Lessa wrote: On Tue, Oct 27, 2009 at 11:58:31PM +0100, psant...@codicesoftware.comwrote: If you need to store key/value pairs, where the key will be ALWAYS a unique long (no collisions), is there anything better than a Hashtable? There are always Judy arrays, see http://judy.sourceforge.net/. -- Felipe. ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] faster than hashtable?
Hey, On Wed, Oct 28, 2009 at 4:30 PM, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Sure Alan! So, basically, the options are: - Use a sorted ArrayList and a binary search For this option the same story applies as for Dictionary K,V. If you write a strongly typed sorted list where the key is hardcoded as long, you might be able to gain a few % in performance. It depends on whether the extra %'s (if any) are worth the increased maintainer burden. If this is a super-critical lookup, then it might be worth it. - Reimplement hashtable focusing on long keys - Write a wrapper to Judy Alan. Alan McGovern wrote: Really what you need to do is benchmark all of the different options using your expected workload. It's near useless us telling you X is faster or Y is better without knowing the workload involved. Alan. On Wed, Oct 28, 2009 at 2:40 PM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Excellent. Is there a wrapper for C#? Is it worth? Felipe Lessa wrote: On Tue, Oct 27, 2009 at 11:58:31PM +0100, psant...@codicesoftware.com mailto:psant...@codicesoftware.com wrote: If you need to store key/value pairs, where the key will be ALWAYS a unique long (no collisions), is there anything better than a Hashtable? There are always Judy arrays, see http://judy.sourceforge.net/. -- Felipe. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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 mailto: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] Why system.net.webresponse not implemented?
What makes you think it's not implemented? If you're attempting to subclass WebResponse and are seeing NotImplemented exceptions, it's because you must override those particular methods (and not call the base method!) and you have not done so. The behaviour is the same on MS.NET. Alan. On Fri, Oct 23, 2009 at 10:38 AM, APS dev.ma...@apsystems.it wrote: Hi, just a curiosity. Trying to interface with an Axis web service I found that System/System.Net/WebResponse is not implemented. Why so? I think it's a useful library, there's some particular issue on implementing it? ___ 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] Big performance gaps between .NET, Mono (Suse/Debian) ?
Calling 'ToString' is just a GC benchmark. Yes, the current mono GC is slower than the .NET GC in this scenario. Your other tests also do a fair bit of allocating, so it's quite possible the entire performance loss you're seeing is just from the GC kicking in. If you want to test how fast you can add elements to a Dictionary, pre-allocate all the objects first and then time just the addition. Alan. On Tue, Oct 6, 2009 at 10:15 AM, Lionel Cuir lionel_em...@aulofee.comwrote: Hello, Can anybody help me to understand why, on simple performance tests, I see so different results between .NET and Mono on various Linux platforms? Are my tests incorrect? Did I have no luck and simply fall on some methods/functionality better implemented by MS? And why is there such a difference between Suse and Debian for the IPAddress dictionary? Any help appreciated (please, no trolling, no political debate - just ideas about how to improve things or ideas to point out methodology errors I would have made in my tests) Regards, Lionel A few hints on how I did my tests: - the OS are: a bare XP SP3, a bare OpenSuse (kernel 2.6.27), a Debian with a lightened kernel (2.6.30) - bare = the OS is up-to-date but no other software installed - all OS were running as vmware guest (in vm workstation 6.5) with two cpus (dual-core T7200) and 512Mo of RAM - Mono version was 2.4.2.3 on Suse, and 2.5 (compiled from SVN r140059) on Debian. .NET version is 3.5 - On Suse and Debian, I both run the tests with the exe compiled with csc (.net) and with the exe compiled with gmcs - the results were the same. You'll find attached the sample code I used - I test basically adictionary of int, a dictionary of IPAddress and the IPAddress.ToString method. The duration of the test (in millisec are: int32 Dictionary test 4812 DotNet 9493 Mono on light Debian 9815 Mono on Suse IPAddress Dictionary test 13500 DotNet 29533 Mono on light Debian 41732 Mono on Suse IPAddress.ToString test 2453 DotNet 16665 Mono on light Debian 17747 Mono on Suse ___ 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] 2.6 preview 1
Hey, On Thu, Oct 1, 2009 at 6:56 PM, LKeene lionel.ke...@gmail.com wrote: Has the Task Parallel Library been performance tested on OSX? I've been having a tough time getting any kind of performance out of my threads on the Mac+Mono platform. Maybe this is the solution? Unlikely. I mean this in a constructive way, but the problem is more likely just a bad threading implementation. Altering how you split data up between threads and/or how you manage the threads would likely be the best way of improving performance. Performance of Mac + Mono should be very close to Linux + Mono. If you're seeing a huge difference in the exact same code it might be worth filing a bug. Alan. -L Andrew Jorgensen-4 wrote: The first preview build of 2.6 has been published to http://mono.ximian.com/monobuild/preview/download-preview/ The windows installer in this build is known to contain a number of problems, including but not limited to: * Has an older build (2.4.x) of gluezilla * Does not contain mono-tools (monodoc browser, gsharp, gendarme, etc.) or gnome-sharp * Is larger than it was previously despite missing mono-tools, etc. We are working through these problems but felt that it was more important to get the build (and the preview tarballs) out into your hands. SLE_10 and openSUSE_10.3 binary packages have been dropped (mono-tools now requires a more recent gtk than available in SLE_10 and 10.3 will be end-of-life around the time we publish 2.6-final). The DRAFT release notes are here: http://www.mono-project.com/Release_Notes_Mono_2.6 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/2.6-preview-1-tp25692276p25703738.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] .NET / Mono runtime multi-cast differences.
Hi,
Unless I'm missing something, you haven't actually described what the
problem is. Nor have you mentioned what exactly happens on windows, what
happens on linux and what you actually expected to happen. Your example also
appears to be missing information which might help figure out what issue it
is you're seeing, what are listenChannel and listenEndpoint?
Alan.
On Mon, Aug 24, 2009 at 3:20 AM, James P Michels III
james.p.mich...@gmail.com wrote:
I have observed a difference in behavior between the Mono runtime and
.NET runtime with respect to multi-cast support.
Unless the Socket.Bind operation is modified to bind to a different end
point based on the runtime, no packets will be received. The workaround
that I am using is shown in the attached code section.
I took a look at Mono's source code. Additionally, I wrote a short C
program with the equivalent functionality. The C version for Linux
exhibits the same behavior. It is my impression that the behavior is due
to differences between the Windows socket implementation and the Linux
socket implementation. It is also my impression that these differences
are being realized by both the .NET and Mono runtime which ultimately
consume them.
I have 2 questions.
1) Am I wrong? Is there a runtime agnostic way to do this? (Binding to
IPAddress.Any does not work on Windows to my knowledge)
2) If I am not wrong, what steps, if any, should be taken to resolve
these differences?
Thanks
Jim
-begin code sample
listenSocket = new Socket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);
listenSocket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, true);
if (IsMonoRuntime())
{
listenSocket.Bind(listenChannel);
}
else
{
listenSocket.Bind(listenEndpoint);
}
listenSocket.SetSocketOption(SocketOptionLevel.IP,
SocketOptionName.MulticastInterface, listenInterface.GetAddressBytes());
listenSocket.SetSocketOption(SocketOptionLevel.IP,
SocketOptionName.AddMembership, new
MulticastOption(listenChannel.Address, listenInterface));
-end code sample
___
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] ParallelFx initial code drop
Hey, On 28 Jul 2009, at 18:36, Miguel de Icaza mig...@novell.com wrote: Hello Jérémie, Why are the files in System.Core, could we not put the files in their final location (which seems to be mscorlib) from the start? Fromyalkibg to jeremie earlier, i think it's partially because of legacy reasons. Some of the parallel fx files already exist in that location and it'd be a pain to move them all to the 'correct' location now. Alan. Miguel seems to have the same idea as me apart that I commit the new types directly instead of providing a patch. The new types can be added directly to SVN, and we can review them asynchronously; Since you own the feature, there is no need to do a review since it is not going to touch code that already exists. The only review that we need is for cases where you touch an existing class, modify an existing class, or provide your own class, or modify the behavior of an existing class. So I say: start committing the code to the real location (mscorlib) and adding it to the build as long as it does not modify existing code. For anything that modifies existing code, post a patch for discussion. ___ 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] ParallelFx initial code drop
Hey, On 28 Jul 2009, at 22:07, Miguel de Icaza mig...@novell.com wrote: Hello, Why are the files in System.Core, could we not put the files in their final location (which seems to be mscorlib) from the start? Fromyalkibg to jeremie earlier, i think it's partially because of legacy reasons. Some of the parallel fx files already exist in that location and it'd be a pain to move them all to the 'correct' location now. Sure, but for the sake of committing this code into Mono, we should just put them on the final destination now, there is no point in putting them in System.Core if they need to go into mscorlib anyways. Pretty much exactly what my thoughts were on it ;) I just figured that since he's gotten multiple conflicting suggestions on what he should do, then he should email and clarify which one exactly he should follow. Alan. P Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Regex not working the same as MS .NET
Hey,
Could you take that testcase and info a file a bug report on
bugzilla.novell.com
. This way the isse won't be forgotten about and will be dealt with
properly.
Alan.
On 26 Jul 2009, at 17:50, St4rNin3 st4rn...@gmail.com wrote:
I am having some issues with Regex processing. It seems that the
Mono engine
and the .NET engine get different results.
The code below works just fine on my Windows PC, but gets no matches
on my
Linux System.
I am using Mandriva 2009 Spring, with the 2.2 version of Mono. I
have not
downloaded the latest 2.4 release. I was trying not to have to
manually
install on Mandriva (2.2 is the latest in their package system)
I have taken a snippet of code (with some hard coded data) for
demonstration
purposes.
=
string sData =
@-
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
001-0151 :LastNameHolder;FirstnameHolder :Address Holder;
string sPattern;
sPattern = @---+\r\n(?AccountNumber\d{3}-\d{8}).*?;
MatchCollection mc;
mc = Regex.Matches(sData, sPattern,
RegexOptions.IgnoreCase |
RegexOptions.Singleline);
label1.Text = string.Format({0} matches found, mc.Count);
Any Ideas?
Dan Gentry
--
View this message in context:
http://www.nabble.com/Mono-Regex-not-working-the-same-as-MS-.NET-tp24629584p24629584.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] library vs module
Hey, On Wed, Jul 15, 2009 at 1:00 AM, Jon Shemitz jon.shem...@access-company.com wrote: Thanks - someone sent me that privately, and it did the trick. *cough* whoops, I thought I had hit reply to all ;) Glad it's working anyway. Alan. Perhaps `gmcs --help` could explain this better. It gave me the strong impression that all options came before all file names. -Original Message- From: Stefanos A. [mailto:stapos...@gmail.com] Sent: Tuesday, July 14, 2009 4:59 PM To: Jon Shemitz Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] library vs module On Tue, 2009-07-14 at 16:40 -0700, Jon Shemitz wrote: It looks like I want to build A.cs to a module, then somehow build the library from B.cs and the A.netmodule, but I can't seem to figure out the gmcs command line syntax. Try this: gmcs A.cs B.cs /out:Foo.dll ___ 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] Simple implementation of network interface properties for Mac OS X
Hey, On Tue, Jun 30, 2009 at 4:09 PM, Alex Shulgin alexander.shul...@yessoftware.com wrote: Alex Shulgin wrote: Alex Shulgin wrote: Hi, In the current version System.Net.NetworkInformation.NetworkInterface provides limited information about network interfaces on the system (their names only). The attached patch adds support for NetworkInterfaceType and GetPhysicalAddress() on Mac OS. Oops, I've almost forgot about IPv6... and missed the added file MacOsNetworkInterfaceMarshal. Please see the fixed patch instead. This worked fine, until one user reported a crash on Array.Copy in NetworkInformation.MacOsNetworkInterface.ImplGetAllNetworkInterfaces(). I traced this down to that I believe is a problem with non-standard length interface name: thus the 12-byte buffer sockaddr_dl.sdl_data is not enough. I've noticed that sockaddr_dl contains sdl_len member which holds the length of the whole sockaddr structure. With that we can use Marshal.Copy instead of Array.Copy to access data past default 12-byte data array. A patch against trunk is attached. I didn't have a chance to try it with the problematic user, but still would like someone to review the patch and comment on it. -- Alex PS: is there more appropriate way to increment IntPtr value w/o using ToInt64()? You could use a loop and Marshal.ReadByte (IntPtr ptr, int offset); Alan. ___ 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] Compiling olive branch SVN trunk/
Hey, On Fri, May 22, 2009 at 6:02 PM, Brian A. Seklecki sekle...@noc.cfi.pgh.pa.us wrote: All: I haven't hacked on mono before; it's definitely amateur night over here. Would it be unsound to try to compile the Olive branch against a vanilla install of Mono 2.0.1 (FC11 or FreeBSD)? I'm assuming that I need to be tracking trunk/ of Mono in order to get the olive/ stuff to compile? Yup, that's your best bet. I'm not sure whether or not using mono from SVN will fix your issue, but it's still advisable to be running something newer than 2.0 when developing against olive. One good reason is that mono 2.2+ has much better support for all the new language features in .NET 3.0 which code in olive uses. Alan. With yesterday's code, I see the following build error: gmake[5]: Entering directory `/root/olive/nunit24/ClientUtilities/util' MONO_PATH=../../../class/lib/net_3_0:$MONO_PATH resgen2 `echo Transform.resx | cat` Read in 1 resources from '/root/olive/nunit24/ClientUtilities/util/Transform.resx' Writing resource file... Done. Thread 802802560 has exited with leftover thread-specific data after 4 destructor iterations MONO_PATH=../../../class/lib/net_3_0:$MONO_PATH gmcs /codepage:65001 /resource:Transform.resources,NUnit.Util.Transform.resources -r:nunit.core.dll -r:nunit.core.interfaces.dll -r:System.dll -r:System.Xml.dll -r:System.Runtime.Remoting.dll /d:MONO /d:StronglyNamedAssembly -d:NET_1_1 -d:NET_2_0 -debug+ /noconfig -target:library -out:../../../class/lib/net_3_0/nunit.util.dll @nunit.util.dll.sources AggregatingTestRunner.cs(20,75): error CS0433: The imported type `NUnit.Core.TestRunner' is defined multiple times /usr/local/lib/mono/gac/nunit.core/2.2.0.0__96d09a1eb7f44a77/nunit.core.dll (Location of the symbol related to previous error) /root/olive/class/lib/net_3_0/nunit.core.interfaces.dll (Location of the symbol related to previous error) AggregatingTestRunner.cs(20,87): error CS0433: The imported type `NUnit.Core.EventListener' is defined multiple times /usr/local/lib/mono/gac/nunit.core/2.2.0.0__96d09a1eb7f44a77/nunit.core.dll (Location of the symbol related to previous error) /root/olive/class/lib/net_3_0/nunit.core.interfaces.dll (Location of the symbol related to previous error) SummaryVisitor.cs(21,39): error CS0433: The imported type `NUnit.Core.ResultVisitor' is defined multiple times /usr/local/lib/mono/gac/nunit.core/2.2.0.0__96d09a1eb7f44a77/nunit.core.dll (Location of the symbol related to previous error) /root/olive/class/lib/net_3_0/nunit.core.interfaces.dll (Location of the symbol related to previous error) Compilation failed: 3 error(s), 0 warnings gmake[5]: *** [../../../class/lib/net_3_0/nunit.util.dll] Error 1 gmake[5]: Leaving directory `/root/olive/nunit24/ClientUtilities/util' gmake[4]: *** [do-all] Error 2 gmake[4]: Leaving directory `/root/olive/nunit24/ClientUtilities/util' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/root/olive/nunit24' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/root/olive' gmake[1]: *** [profile-do--net_3_0--all] Error 2 gmake[1]: Leaving directory `/root/olive' I can provide a tee(1) of the full build and/or config.log, but I was hoping to get some quick advice on a sound build environment? The goal here is to setup up internal nightly autobuilds a la http://mono.ximian.com/monobuild/ Have a great weekend all! ~BAS ___ 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] General questions about mono
The starting point for what exactly? Do you want to know how mono uses threads for its GC, or how managed threads interact with the jit/gc. How unmanaged threads can be registered with the runtime so they can work safely with managed code? Or maybe you just want to understand how you can write threaded managed code? You're going to have to be a little more specific than Tell me about how mono handles threads. Alan. On Tue, May 5, 2009 at 6:06 AM, Friedrich Dominicus fr...@q-software-solutions.de wrote: Miguel de Icaza mig...@novell.com writes: Hello, I'm still trying ot understand. How thread handling is done in Mono. Have I overseen some pages on the mono home pages? This is a very open-ended question. What exactly do you need to know? Just the starting point. Where and how is this starting point documented. Or where can one read more about it, I'd like to do that before starting to ask stupid questions because they may have documented... Just I've no idea where this docs should be Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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] Mono 2.4 Windows - SerialPort.BytesToRead NullReferenceException
Hi,
Could you attach that testcase to a bug report and add a verbal description
of what exactly is wrong at http://bugzilla.novell.com . Also mention the
version of windows you're on (which is it?). That's the best way to get the
issue fixed.
Thanks,
Alan.
On Wed, Apr 29, 2009 at 7:50 AM, Rytis Ilciukas (rick) ziba...@gmail.comwrote:
I'm trying to run a very simple SerialPort test app (see the code below) on
Windows using Mono and i get
System.NullReferenceException: Object reference not set to an instance of
an
obj
ect
at (wrapper managed-to-native)
System.IO.Ports.WinSerialStream:ClearCommError
(int,uint,System.IO.Ports.CommStat)
at System.IO.Ports.WinSerialStream.get_BytesToRead () [0x0]
at System.IO.Ports.SerialPort.get_BytesToRead () [0x0]
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPort:get_BytesTo
Read ()
at PortGrindTest.Program.ThreadFunction () [0x0]
I've searched the forum and only found posts dating back to 2008 and Mono
1.x So here's my 2ct. It seems that Mono is still very very unstable :( By
the way maybe this isn't the place to post bugs?
Code:
SerialPort port = new SerialPort(COM6);
port.ReadTimeout = 2000;
port.WriteTimeout = 1000;
Console.WriteLine(Thread {0} opened port,
Thread.CurrentThread.ManagedThreadId);
lock (this)
{
port.Open();
}
try
{
port.WriteLine(ATE);
port.WriteLine(AT);
do
{
string line = port.ReadLine();
Console.WriteLine(Received {0}, line);
} while (port.BytesToRead != 0);
}
catch (TimeoutException e)
{
Console.WriteLine(Thread {0} {1} {2},
Thread.CurrentThread.ManagedThreadId, freePort.Name, e.Message);
}
--
View this message in context:
http://www.nabble.com/Mono-2.4-Windows---SerialPort.BytesToRead-NullReferenceException-tp23291526p23291526.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] Incremental build for mono compiler
Hey, Out of interest, is this a gsoc project? Alan. On Fri, Apr 10, 2009 at 6:03 AM, Bartosz Lipinski baalaza...@gmail.comwrote: It is OK because till last week of May I am going to familiarize myself with the whole code and trying to create some prototype from stable version. The real part of work is placed between end of May to August. On 4/9/09, Miguel de Icaza mig...@novell.com wrote: So I am asking for Your help with my few questions: * Which is the best place to start ? * Potential problems ? * Some guidelines to do this in the Mono way for future integration. The major problem is that we are currently doing a major refactoring in the compiler that will have a severe impact on any code that tries to do this. It would be best if you could wait some 2-3 months for the work to settle as you would be able to leverage some of our current work. -- Bartosz Lipinski ___ 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] Incremental build for mono compiler
Hey, The only reason I ask is that miguel pointed out that the compiler is undergoing substantial refactoring which will take 2-3 months. That would mean that the work should be complete about the end of June, 4-5 weeks from the end of gsoc. So, if you are going to go ahead with this, I'd recommend getting in touch with whoever is working on the compiler and getting their input on how best to proceed. They may have some useful advice on where to start and what major changes are going to be implemented which will affect your project. Alan. On Fri, Apr 10, 2009 at 3:35 PM, David Srbecky dsrbe...@gmail.com wrote: Yes, it is. Do you think we can figure something out so that we all benefit? David Alan McGovern wrote: Hey, Out of interest, is this a gsoc project? Alan. On Fri, Apr 10, 2009 at 6:03 AM, Bartosz Lipinski baalaza...@gmail.commailto: baalaza...@gmail.com wrote: It is OK because till last week of May I am going to familiarize myself with the whole code and trying to create some prototype from stable version. The real part of work is placed between end of May to August. On 4/9/09, Miguel de Icaza mig...@novell.com mailto:mig...@novell.com wrote: So I am asking for Your help with my few questions: * Which is the best place to start ? * Potential problems ? * Some guidelines to do this in the Mono way for future integration. The major problem is that we are currently doing a major refactoring in the compiler that will have a severe impact on any code that tries to do this. It would be best if you could wait some 2-3 months for the work to settle as you would be able to leverage some of our current work. -- Bartosz Lipinski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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] [Mono-olive] Bugs + fixes for System.IO.Packaging
Hi, I've fixed a number of the issues you've mentioned. The ones I haven't applied fixes for are listed below with explanations: Resolved issues: 1, 2, 3, 4, 5, 9, 10, 11, 12 Unresolved issues: 6, 7, 8 6) (Package.LoadRelationships - operation not valid) I can't replicate this issue. Can you verify that it's still there and if so create a small testcase to demonstrate the issue 7) Duplicate [Content_Types].xml I didn't apply the fix because this PackagePart should never be in the 'Parts' dictionary. If you are seeing it in the dictionary, could you create a testcase which replicates the issue so that I can fix it. 8) content type is always application/xml I have an NUnit test, PackagePartTest.CheckPartProperties () which tests content types are loaded correctly and the test is passing. Can you supply a testcase which demonstrates the issue? I'm just going to deal with your newer emails now. Alan. p.s. Thanks for the very detailed bug report. It was very easy to derive NUnit tests from your descriptions to prevent these issues from surfacing again. On Mon, Mar 16, 2009 at 10:52 AM, Alan McGovern alan.mcgov...@gmail.comwrote: Hi, Great stuff! I'm going to review this today and commit it if all goes well. If you have any more bugs, just fire an email to the mono-devel list (CC'ed) in case I'm not around to deal with them. Alan. On Sun, Mar 15, 2009 at 12:22 AM, Yves Dhondt yves.dho...@gmail.comwrote: Hello, I worked a bit more on the thing and came up with several more bugs and fixes. I extended my original document to include those as well. With the current set of fixes, it is possible to open an existing Word 2007/2008 document with ReadWrite permission and close it again without corrupting it. I have not tested it on other types of packages (Excel, Powerpoint) but they should work as well. Regards, Yves On Sat, Mar 14, 2009 at 12:56 PM, Yves Dhondt yves.dho...@gmail.comwrote: Hello, This is probably not the best way of bug reporting but I could not find any track on bugzilla for olive to submit this under. The included pdf contains the description and possible fixes I came across when trying to use the olive WindowsBase.dll. Note that I only fixed those things to work for my needs and in some cases, more in-depth testing might be required (especially in PackUriHelper.ResolvePartUri). If you have any questions, feel free to contact me. Regards, Yves ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in Package.cs due to update in PackageProperties.cs (System.IO.Packaging / Olive)
Should be fixed properly in SVN. Let me know if it's not.
Alan.
On Mon, Mar 16, 2009 at 7:36 PM, Yves Dhondt yves.dho...@gmail.com wrote:
Hello,
Revision 129478 fixes the NSPackageProperties string to correctly load
PackageProperties. However, the string is also used by Package.cs for
LoadRelationships. The change has broken that function as the string
used to be correct there.
In Package.LoadRelationships, the line:
if (r.RelationshipType ==
System.IO.Packaging.PackageProperties.NSPackageProperties) {
should become:
if (r.RelationshipType ==
http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties
)
{
Regards,
Yves
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for ZipPackagePart.GetStreamCore in System.IO.Packaging (olive)
Working on this one now.
Thanks!
Alan.
On Mon, Mar 16, 2009 at 7:21 PM, Yves Dhondt yves.dho...@gmail.com wrote:
Issue:
---
ZipPackagePart.GetStreamCore in System.IO.Packaging does not handle
Filemode mode input parameter (correctly).
Test program (requires an existing openxml document, for example
test.docx as input):
---
I'm not that good with unit testing, but the following code should be
easily translated into 4 tests.
using System;
using System.IO;
using System.IO.Packaging;
namespace MonoOpenXmlExperiment
{
class Program
{
static void Main(string[] args)
{
// Warning do this with a document which can be damaged!!!
Package pack = Package.Open(args[0]);
PackagePart part = pack.CreatePart(new Uri(/somepart.xml,
UriKind.Relative), application/xml);
try
{
Stream s2 = part.GetStream(FileMode.CreateNew, FileAccess.Write);
}
catch (Exception ex)
{
// An ArgumentException should be throw as CreateNew is an
unsupported mode.
Console.WriteLine(Expected ArgumentException, got {0}.,
ex.GetType().ToString());
}
try
{
Stream s3 = part.GetStream(FileMode.Truncate, FileAccess.Write);
}
catch (Exception ex)
{
// An ArgumentException should be throw as Truncate is an
unsupported mode.
Console.WriteLine(Expected ArgumentException, got {0}.,
ex.GetType().ToString());
}
try
{
Stream s4 = part.GetStream(FileMode.Append, FileAccess.Write);
}
catch (Exception ex)
{
// An ArgumentException should be throw as Append is an
unsupported mode.
Console.WriteLine(Expected ArgumentException, got {0}.,
ex.GetType().ToString());
}
Stream s = part.GetStream(FileMode.OpenOrCreate, FileAccess.Write);
StreamWriter sw = new StreamWriter(s);
sw.Write(testaaa/test);
sw.Flush();
Stream s5 = part.GetStream(FileMode.Create, FileAccess.ReadWrite);
StreamWriter sw2 = new StreamWriter(s5);
sw2.Write(testbbb/test);
sw2.Flush();
// Verify that the part got overwritten correctly.
Stream s6 = part.GetStream();
StreamReader sr = new StreamReader(s6);
Console.WriteLine(Expected testbbb/test, got {0}.,
sr.ReadToEnd());
pack.Close();
}
}
}
Expected output:
Expected ArgumentException, got System.ArgumentException.
Expected ArgumentException, got System.ArgumentException.
Expected ArgumentException, got System.ArgumentException.
Expected testbbb/test, got testbbb/test.
Output currently given by mono:
-
Expected testbbb/test, got testbbb/test.
Remarks:
-
The last test is especially important as it indicates that a create
would only overwrite part of stream.
Solution:
Replace function by:
protected override Stream GetStreamCore (FileMode mode, FileAccess access)
{
MemoryStream stream;
switch (mode)
{
case FileMode.CreateNew:
throw new ArgumentException(FileMode not supported,
CreateNew);
case FileMode.Truncate:
throw new ArgumentException(FileMode not supported,
Truncate);
case FileMode.Append:
throw new ArgumentException(FileMode not supported, Append);
case FileMode.Open:
if (Package.PartStreams.TryGetValue(Uri, out stream)) {
return new ZipPartStream(Package, stream, access);
}
else {
throw new IOException(); // Verify that this is the
correct exception.
}
case FileMode.OpenOrCreate:
case FileMode.Create:
// Check if a stream is already loaded. If not, load it or
create an empty one.
if (!Package.PartStreams.TryGetValue(Uri, out stream)) {
stream = new MemoryStream();
try
{
using (UnzipArchive archive = new
UnzipArchive(Package.PackageStream))
{
foreach (string file in archive.GetFiles())
{
if (file != Uri.ToString().Substring(1))
continue;
using (Stream archiveStream = archive.GetStream(file))
{
int read = 0;
byte[] buffer = new
byte[Math.Min(archiveStream.Length, 2 * 1024)];
while ((read = archiveStream.Read(buffer, 0,
buffer.Length)) != 0)
stream.Write(buffer, 0, read);
}
}
}
}
catch
{
// The zipfile is invalid, so just create the file
// as if it didn't exist
stream.SetLength(0);
}
Re: [Mono-dev] [Mono-olive] Bugs + fixes for System.IO.Packaging
Hi, Great stuff! I'm going to review this today and commit it if all goes well. If you have any more bugs, just fire an email to the mono-devel list (CC'ed) in case I'm not around to deal with them. Alan. On Sun, Mar 15, 2009 at 12:22 AM, Yves Dhondt yves.dho...@gmail.com wrote: Hello, I worked a bit more on the thing and came up with several more bugs and fixes. I extended my original document to include those as well. With the current set of fixes, it is possible to open an existing Word 2007/2008 document with ReadWrite permission and close it again without corrupting it. I have not tested it on other types of packages (Excel, Powerpoint) but they should work as well. Regards, Yves On Sat, Mar 14, 2009 at 12:56 PM, Yves Dhondt yves.dho...@gmail.comwrote: Hello, This is probably not the best way of bug reporting but I could not find any track on bugzilla for olive to submit this under. The included pdf contains the description and possible fixes I came across when trying to use the olive WindowsBase.dll. Note that I only fixed those things to work for my needs and in some cases, more in-depth testing might be required (especially in PackUriHelper.ResolvePartUri). If you have any questions, feel free to contact me. Regards, Yves ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Delegates very slow on Mono 2.2/Linux (but not on Mono 2.4/Windows)
Just to clarify, you're using a comma as a decimal separator and a dot as a thousands seperator? So: 766.6697 ns/call = ~766 thousand ns/call and 13,0416 ns/call = ~13 ns/call Alan. 2009/3/15 StApostol stapos...@gmail.com Hi all, I just ran some tests to measure performance in OpenTK.Graphics and Tao.OpenGl and uncovered some surprising results. Some background first: OpenGL exports functions either statically (core functions) or dynamically (extensions). While you use a simple [DllImport] to invoke core functions, you have to invoke extensions through function pointers. Different platforms, video cards, even drivers expose different subsets of OpenGL as extensions, which means you have to handle this issue during runtime. To deal with this problem, the aforementioned libraries implement a relatively complex solution: - The union of all core functions is declared as [DllImport] in a private class named Core. - The union of all core and extension functions are declared as delegates in a private class named Delegates. - Each delegate has one or more wrapper functions. This is the public API for the user. - During initialization, we probe each OpenGL function and arm the relevant delegate with Marshal.GetDelegateForFunctionPointer, a function from the Core class or null (if it exported dynamically, statically or not at all, respectively). Most of the types used in OpenGL interop are blittable, which makes most pinvokes pretty fast. The main bottleneck is the delegate call, which should be plenty fast (or so we thought). To test the performance of this approach, I wrote a simple test that simulates OpenGL calls (attached). The test measures the call overhead for two function prototypes that are very common in OpenGL: - void SendFloat(int, int, int, float*) - void Send(int, int, int, int, void*) The first function is wrapped as void SendFloat(int, int, int, float[]) and the array is pinned and passed as a simple pointer. The second becomes void Send(int, int, int, int, object) and the last parameter is also pinned (with GCHandle.Alloc) and passed as a simple pointer (we assume 'object' is a blittable struct). Each of these functions is tested twice, first through a delegate (as outlined above) and then directly with a simple pinvoke. The results are measured on a 2.66GHz Core 2 Duo with each function called 10^6 times (not nearly enough for ns accuracy, but the problem is nonetheless obvious). The binaries were compiled with gmcs 2.2 (every test used the same executable). The unmanaged dll was compiled with gcc on Linux (x86_64) and msvc on Windows (x86): [Mono 2.2, Linux x86_64] Timing SendFloat (delegate): 0.797 seconds (766.6697 ns/call) with 3/3/3 collections. Timing SendFloat (direct): 0.0170575 seconds (17.0575 ns/call) with 3/3/3 collections. Timing Send (delegate): 1.3894752 seconds (1389.4752 ns/call) with 3/3/3 collections. Timing Send (direct): 0.2461236 seconds (246.1236 ns/call) with 3/3/3 collections. [Mono 2.4 RC1, Windows x86 (VirtualBox)] Timing SendFloat (delegate): 0,0130416 seconds (13,0416 ns/call) with 1/1/1 collections. Timing SendFloat (direct): 0,0140448 seconds (14,0448 ns/call) with 1/1/1 collections. Timing Send (delegate): 0,1033469 seconds (103,3469 ns/call) with 1/1/1 collections. Timing Send (direct): 0,1063392 seconds (106,3392 ns/call) with 1/1/1 collections. [.Net 3.5 SP1, Windows x86 (VirtualBox)] Timing SendFloat (delegate): 0,0117486 seconds (11,7486 ns/call) with 0/0/0 collections. Timing SendFloat (direct): 0,0070824 seconds (7,0824 ns/call) with 0/0/0 collections. Timing Send (delegate): 0,1087277 seconds (108,7277 ns/call) with 0/0/0 collections. Timing Send (direct): 0,095304 seconds (95,304 ns/call) with 0/0/0 collections. As you can see, Mono 2.2 on Linux x86_64 is 5 - 40 times slower when calling a delegate - nearly 1us for a single delegate call! In comparison, calling a delegate on Windows x86 seems comparable to a simple virtual call (1 - 3ns overhead). A typical, state-of-the-art 3d program may contain somewhere between 1000-5000 draw calls per frame. Assuming the above results hold, the interop layer will consume between 5-30% of your total frame bugdet (16.6ms) - not good! Is there an explanation for this discrepancy? Can we expect better performance in some future version of the runtime? Should we bite the bullet and rewrite the bindings in ilasm (replacing pinvokes with calli instructions)? Any possible workarounds / alternatives? Thanks for your time! ___ 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] Re moting between dotnet framework and mono framework
Hi, I just want to know if my serialiazed objects will come through client MS dotnet and server MONO without problem. The first response by Robert said: They are supported. and You can expect 100% compatibility with custom classes (those you've designed yourself). So yes, you can expect it to work. Alan Thanks Jerome Haltom wrote: These questions are all answered on MSDN in the documentation describing how works. Look into MarshalByRefObjects, ObjRef, transparent proxies and real proxies. On Wed, 2009-03-11 at 08:36 -0700, Eric45 wrote: Hi Perhaps i was not enough precise in my question. I want to make a DOTnet client on windows running above Microsoft DOTnet framework 2.0. Then i have a DOTnet server on linux running above MONO. So i am asking myself if remoting will be compliant. Lets take an example. If the client pass a serialized object (one of my ISerializable class) lets named it Class1. How the MONO server make the link with its own class Class1 (exactly the same) to reconstruct it ? How it makes the link between Class1 on Windows DOTnet and the Class1 on MONO ? Because the class has same name in same dll name and same namespace ? That i do not understand. For reference, MarshalledByRef, i think all is ok because it is only a pointer on a proxy and an Interface. So i imagine it works. Thanks Robert Jordan wrote: Hi, Eric45 wrote: Is it possible to have a remoting MONO server working on linux being contacted by a DONET windows remoting client ? Yes. If yes how the compliance is made between objects passed by reference ? I don't understand this question. Do you mean MarshalByRefObjects? They are supported. Same question about objects passed by serialization ? You can expect 100% compatibility with custom classes (those you've designed yourself). Basic BCL classes (ArrayList, Hashtable) are also compatible, but it's safer to not depend on classes that are not under your control. Robert ___ 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 -- View this message in context: http://www.nabble.com/Remoting-between-dotnet-framework-and-mono-framework-tp22451273p22458037.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] Architectural decisions behind mod_mono
Hey, They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. So if there's a bug in your filter which caused every 100th request to bluescreen the computer, yes you're right. Your computer would be no more useful than a doorstop. But if every 100th request just crashed the process, you could just restart the process and continue fine for the next 99 requests. Which solution is better? Does performance even come into the equation here? Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SVN upgraded to subversion 1.5.x
Hey,
SVN commits have been taking well over 60 seconds to complete all day. Is
this just a temporary thing or is there an issue with the upgrade?
Thanks,
Alan.
On Tue, Feb 24, 2009 at 5:15 PM, Jonathan Pryor jonpr...@vt.edu wrote:
On Tue, 2009-02-24 at 11:36 +0100, Robert Jordan wrote:
Since older clients are not updating svn:mergeinfo, merge tracking
could be easily broken if an old client is allowed to commit to
/branches.
You may want to block those clients with a start-commit hook:
---8---
#!/bin/bash
svnpath=$1
capabilities=$3
if [ ${svnpath:0:9} = /branches ]; then
if [ ${capabilities/mergeinfo//} = ${capabilities} ]; then
echo Please update to SVN = 1.5 /dev/stderr
exit 1
fi
fi
exit 0
---8---
Alas, = 1.5 is insufficient, as OpenOffice.org has seen -- file
movements have been *lost* during merges. See [0] and [1]. [2]
mentions:
Please note, subversion-1.5.1 is known to break things in the
Openoffice.org context and subversion-1.5.3 has been hastily
replaced by the subversion developers because it can break
mergetracking.
So from the OpenOffice.org's perspective, 1.5.4 is the minimum version
that should be considered...which is unfortunate, as openSUSE only
provides 1.5.2.
I'm not sure if or how this would impact Mono, but it is something to
keep in mind...
- Jon
[0] http://www.openoffice.org/issues/show_bug.cgi?id=97012
[1] http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=23807
[2] http://wiki.services.openoffice.org/wiki/SVNMigration
___
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] Mono.SIMD
Hey,
The big issue you're having is that you haven't implemented a SIMD algorithm
;) I spent 15 mins 'optimising' your code and came up with this. Notice that
I made everything a SIMD operation. There is no scalar code in the method
anymore. This tripled performance as compared to the non-SIMD version. On my
machine:
-FLOAT 00:00:00.3888930 Color
-SIMD 00:00:00.1266820 Mono.Simd.Vector4f
You'd want to double check the result just in case I made a mistake with my
alterations.
Alan.
public static Vector4f GradientSIMD()
{
Vector4f finv_WH = new Vector4f (1.0f / (w*h), 1.0f / (w*h),
1.0f / (w*h), 1.0f / (w*h));
Vector4f ret = new Vector4f();
Vector4f a = new Vector4f(0.0f, 0.0f, 1.0f, 1.0f);
a += new Vector4f(0.0f, 1.0f, 0.0f, 1.0f);
a += new Vector4f(1.0f, 0.0f, 0.0f, 1.0f);
a += new Vector4f(0.5f, 0.5f, 1.0f, 1.0f);
//Process operator
Vector4f yVec = new Vector4f (h, h, 0, 0);
Vector4f yDiff = new Vector4f (-1, -1, 1, 1);
for (int y=0; yh; y++)
{
Vector4f factor = yVec * finv_WH;
yVec += yDiff;
Vector4f xVec = new Vector4f (w, 0, w, 0);
Vector4f xDiff = new Vector4f (-1, 1, -1, 1);
for (int x=0; xw; x++)
{
ret += (a * xVec * factor);
xVec += xDiff;
}
}
return ret;
}
On Fri, Feb 20, 2009 at 8:12 AM, Johann_fxgen jnadalu...@gmail.com wrote:
I have done some performance tests of SIMD under windows.
Results tests in ms:
In MS C 235 (Visual Studio Release Mode With SIMD)
In MS C 360 (Visual Studio Release Mode With 4D Float)
In Mono C#453 (With Mono SIMD)
In Mono C#562 (With Mono 4D Float)
In MS C# 609 (Visual Studio With 4D Float)
In MS C 672 (Visual Studio Debug Mode)
I'm just surprise by difference between C SIMD and mono SIMD version.
Is Mono.SIMD under linux speeder than under windows ?
Johann.
My mono code for test:
using Mono.Simd;
using System;
using Mono;
public struct Color
{
public float r,g,b,a;
};
public class TestMonoSIMD
{
public Color m_pixels;
const int w = 4096;
const int h = 4096;
public static void Main ()
{
//Debug
Console.WriteLine(AccelMode: {0},
Mono.Simd.SimdRuntime.AccelMode );
//Without SIMD
DateTime start1 = DateTime.Now;
Color ret1 = Gradient();
TimeSpan ts1 = DateTime.Now - start1;
Console.WriteLine(-FLOAT {0} {1}, ts1, ret1);
//With SIMD
DateTime start2 = DateTime.Now;
Vector4f ret2 = GradientSIMD();
TimeSpan ts2 = DateTime.Now - start2;
Console.WriteLine(-SIMD {0} {1}, ts2, ret2);
}
public static Color Gradient()
{
float finv_WH = 1.0f / (float)(w*h);
Color ret = new Color();
ret.r=ret.g=ret.b=ret.a=0.0f;
Color a = new Color();
Color b = new Color();
Color c = new Color();
Color d = new Color();
a.r=0.0f; a.g=0.0f; a.b=1.0f; a.a=1.0f;
b.r=0.0f; b.g=1.0f; b.b=0.0f; b.a=1.0f;
c.r=1.0f; c.g=0.0f; c.b=0.0f; c.a=1.0f;
d.r=0.5f; d.g=0.5f; d.b=1.0f; d.a=1.0f;
//Process operator
for (int y=0; yh; y++)
{
for (int x=0; xw; x++)
{
//Calc percent A,B,C,D
float pa = (float)((w-x)*
(h-y)) * finv_WH;
float pb = (float)((x) *
(h-y)) * finv_WH;
float pc = (float)((w-x)*
(y)) * finv_WH;
float pd = (float)((x) *
(y)) * finv_WH;
float cr= ((a.r*pa) + (b.r*pb) +
(c.r*pc) + (d.r*pd));
float cg= ((a.g*pa) + (b.g*pb) +
(c.g*pc) + (d.g*pd));
float cb= ((a.b*pa) + (b.b*pb) +
(c.b*pc) + (d.b*pd));
float ca= ((a.a*pa) + (b.a*pb) +
(c.a*pc) + (d.a*pd));
Re: [Mono-dev] Mono.SIMD
Hey,
The C++ code seems very similar to the C# SIMD code, so I don't know what
would make the C# version any faster. This question would be best directed
at jit guys, who may know what causes the difference.
If you want to try speeding up the mono version, you should just use trial
and error to see if you can rewrite things so that you can get better
performance. For example, unrolling the loop may improve performance
noticably.
Alan.
On Mon, Feb 23, 2009 at 1:16 PM, Johann Nadalutti jnadalu...@gmail.comwrote:
Hey,
thanks a lot for your modifications.
I have now SIMD x3 faster than 4DFloat version !
I make the same code in C++ and It's x3 more faster than Mono.SIMD.
I just want to know why and how to optimize my Mono code.
What do you use as IDE to develop and debug Mono ?
My Visual C++ code for test:
class VectorSIMD
{
public:
VectorSIMD();
VectorSIMD(float x, float y, float z, float w);
VectorSIMD operator*(const VectorSIMD other)
{
VectorSIMD r;
r.vec = _mm_mul_ps(vec, other.vec);
return r;
}
VectorSIMD operator*(float f)
{
VectorSIMD r;
__m128 b = _mm_load1_ps(f);
r.vec = _mm_mul_ps(vec, b);
return r;
}
VectorSIMD operator+(const VectorSIMD other)
{
VectorSIMD r;
r.vec = _mm_add_ps(vec, other.vec);
return r;
}
//Datas
union
{
__m128 vec;
struct { float x, y, z, w; };
};
};
VectorSIMD::VectorSIMD()
{
}
VectorSIMD::VectorSIMD(float _x, float _y, float _z, float _w)
{
x=_x;y=_y; z=_z; w=_w;
}
VectorSIMD GradientSIMD()
{
VectorSIMD finv_WH(1.0f / (_W*_H), 1.0f / (_W*_H), 1.0f / (_W*_H), 1.0f /
(_W*_H));
VectorSIMD ret(0.0, 0.0, 0.0, 0.0);
VectorSIMD a(0.0f, 0.0f, 1.0f, 1.0f);
a =a + VectorSIMD(0.0f, 1.0f, 0.0f, 1.0f);
a =a + VectorSIMD(1.0f, 0.0f, 0.0f, 1.0f);
a =a + VectorSIMD(0.5f, 0.5f, 1.0f, 1.0f);
//Process operator
VectorSIMD yVec(_H, _H, 0, 0);
VectorSIMD yDiff(-1.0f, -1.0f, 1.0f, 1.0f);
for (int y=0; y_H; y++)
{
VectorSIMD factor = yVec * finv_WH;
yVec = yVec + yDiff;
VectorSIMD xVec(_W, 0, _W, 0);
VectorSIMD xDiff(-1.0f, 1.0f, -1.0f, 1.0f);
for (int x=0; x_W; x++)
{
ret=ret+(a*xVec*factor);
xVec=xVec+xDiff;
}
}
return ret;
}
Johann.
2009/2/23 Alan McGovern alan.mcgov...@gmail.com
Hey,
The big issue you're having is that you haven't implemented a SIMD
algorithm ;) I spent 15 mins 'optimising' your code and came up with this.
Notice that I made everything a SIMD operation. There is no scalar code in
the method anymore. This tripled performance as compared to the non-SIMD
version. On my machine:
-FLOAT 00:00:00.3888930 Color
-SIMD 00:00:00.1266820 Mono.Simd.Vector4f
You'd want to double check the result just in case I made a mistake with
my alterations.
Alan.
public static Vector4f GradientSIMD()
{
Vector4f finv_WH = new Vector4f (1.0f / (w*h), 1.0f / (w*h),
1.0f / (w*h), 1.0f / (w*h));
Vector4f ret = new Vector4f();
Vector4f a = new Vector4f(0.0f, 0.0f, 1.0f, 1.0f);
a += new Vector4f(0.0f, 1.0f, 0.0f, 1.0f);
a += new Vector4f(1.0f, 0.0f, 0.0f, 1.0f);
a += new Vector4f(0.5f, 0.5f, 1.0f, 1.0f);
//Process operator
Vector4f yVec = new Vector4f (h, h, 0, 0);
Vector4f yDiff = new Vector4f (-1, -1, 1, 1);
for (int y=0; yh; y++)
{
Vector4f factor = yVec * finv_WH;
yVec += yDiff;
Vector4f xVec = new Vector4f (w, 0, w, 0);
Vector4f xDiff = new Vector4f (-1, 1, -1, 1);
for (int x=0; xw; x++)
{
ret += (a * xVec * factor);
xVec += xDiff;
}
}
return ret;
}
On Fri, Feb 20, 2009 at 8:12 AM, Johann_fxgen jnadalu...@gmail.comwrote:
I have done some performance tests of SIMD under windows.
Results tests in ms:
In MS C 235 (Visual Studio Release Mode With SIMD)
In MS C 360 (Visual Studio Release Mode With 4D Float)
In Mono C#453 (With Mono SIMD)
In Mono C#562 (With Mono 4D Float)
In MS C# 609 (Visual Studio With 4D Float)
In MS C 672 (Visual Studio Debug Mode)
I'm just surprise by difference between C SIMD and mono SIMD version.
Is Mono.SIMD under linux speeder than under windows ?
Johann.
My mono code for test:
using Mono.Simd;
using System;
using Mono;
public struct Color
{
public float r,g,b,a;
};
public class TestMonoSIMD
{
public Color m_pixels;
const int w = 4096
Re: [Mono-dev] Mono Develop native menus on Mac OS X
Hey, That can be fixed by using a dllmap to reroute the native library to the correct one for macos. If you can create a patch to update the dllmap to pick up the correct libraries on MacOS and attach it to bugzilla, it might be possible to enable the SVN addin by default. http://www.mono-project.com/Config_DllMap Alan. 2009/2/19 Kris Ray k...@landmarkdigital.com That would be a great idea. I use MonoDevelop primarily on Linux, but I will also have to release Mac versions of our software. Currently, Mac monodevelop is a bit flaky. Nothing major (beyond what was intentionally removed), but it is very annoying at times. Also, it looks like the version control add-in should be included in the MAc version. It works fine - you just currently have to trick it into working by creating symbolic links from fake libapr*.so and libsvn*.so files to libapr*.dylib and libsvn*.dylib. thanks, Kris -- *From:* mono-devel-list-boun...@lists.ximian.com on behalf of Miguel de Icaza *Sent:* Wed 2/18/2009 1:35 PM *To:* Joachim Ante *Cc:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Mono Develop native menus on Mac OS X Hello, Are you guys planning to switch to Mac OS X native menus and hotkeys that fit existing Mac applications for Mono Develop 2.0? (bug 367030) Maybe this seems like a minor nuisance, but I think that if we were to include Mono Develop in Unity with menus as they are now on Mac OS X instead of in the menu bar, our users would most likely fly to Denmark and put us on a pitchfork. It's actually a really serious issue for us. It's kind of cultural difference but Mac people care about this. Funny you would mention this, we were just discussing that at lunch today, and we want to make this happen. My major concern is not as much the menu itself, but any other bugs that we might not be aware of in MonoDevelop/Mac, since none of us use a Mac as our main system. We only hear reports through the grapevines and would like to have more actionable data on what might be broken on MD. Maybe we should get a Mac for someone in the MonoDevelop team as their main machine to make sure that all of these issues get fixed. Miguel ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Hey, I pinged the maintainers of the kdebindings package for opensuse and asked if they were building qyoto. Turns out it's disabled by default by them. They are now taking a look at creating qyoto packages for opensuse. I assume this will cover 11.0 and higher. So if you're interested in this, let them know: http://www.kdedevelopers.org/node/3896 Alan. On Thu, Feb 12, 2009 at 4:32 PM, Arno Rehn mono-de...@arnorehn.de wrote: On Wednesday 11 February 2009 23:12:52 you wrote: Hi Arno, I think Qyoto is a really great initiative and a really strong point to make Mono shine. But I wonder if you have plans (and resources) to: - Relaunch a website with information/tutorials/downloads. It doesn't matter how good Qyoto is if no one can easily find it. We will definitely put up stuff on techbase.kde.org, but I don't know if we'll relaunch a full blown website. Maybe something on sourceforge, we'll see. - Publish builds on the different OSs. IMHO what makes Qyoto rock is being able to create native GUIs for Solaris/Linux/Windows/Mac with a single codebase and minor tweaks. If we only have Linux, then sticking to WinForms or GTK# is still better, if only Mac I guess monoobjc is the right solution, and so on. Yes, we'll do that once we have time to build it on windows and os x. I think monoobjc is the perfect example: they've a solid website, full of samples, which gives a very good feeling when you enter it. You immediately think hey, this is a solid solution. Regards, pablo Arno Rehn escribió: On Linux it's pretty straight forward. Download a recent kde-bindings tarball and extract it somewhere. Build it as every other KDE module with cmake. Create a build directory, do cd build-dir; ccmake src-dir. Disable the stuff you don't want/don't need, like Soprano or Nepomuk bindings. Then just make; make install as usual. We haven't tried building on Solaris yet. On OS X someone got it working, but there seem to be issues with header files not being correctly found. You might have to play a bit to get it working there. On Friday 06 February 2009 20:36:29 pablosantosl...@terra.es wrote: are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
But it's the hacks that you added to your program which are causing the issue in the first place ;) You want a hack to make your hack work. What you really need is another hack which will work in all cases. Unfortunately I can't think of a way which will work in all cases. Alan. (p.s. i'm not arguing for or against the change, just pointing out the above) On Thu, Feb 12, 2009 at 1:45 PM, Stifu st...@free.fr wrote: I think that'd be a quite bad solution, because it'd add a lot of confusion, and possibly divide the user base. I can already imagine debugging user problems, like Are you using Mono standard edition or the Mono modded by SomeRandomGuy? I'd rather add hacks in the program than having more frameworks to worry about. Paige Thompson wrote: maybe field names should be driven off of an XML file at compile time or something instead of hard coded. I mean yeah that dances on the line of still having to modify mono but at least in that case it wouldn't be hard coded. Then everybody could be happy. I guess what I'm trying to say is, perhaps rather than arguing about who's is better and more worth efforts rather have a compatibility layer for the inorite way and the tried and true. -Adele On Thu, Feb 12, 2009 at 5:13 AM, Stifu st...@free.fr wrote: I have to agree. Reverse-engineering complicated algorithms for the sake of matching MS .NET perfectly is one thing, and may not be worth the time and efforts, but simply changing a string to improve compatibility is an easy win. Many things in the past of Mono have been done to improve compatibility with existing .NET apps and get Windows developers interested (such as Windows.Forms support, for example). Simply put, it doesn't make much sense to me to try that hard to catch high-hanging fruits if you're going to ignore low-hanging ones. Lucas Meijer-4 wrote: Hey, Our team has been busy porting some unit testing related frameworks to mono. porting is probably not the right word, it's mostly creating repro cases of mono bugs, reporting them, and waiting for them to be fixed. (Which happens fast by the way. Thanks!) So far we're looking at NInject, Moq and xUnit. There are / have been bugs in mono that prevent all of these projects from running. Most of them are valid mono bugs, nothing special here. In addition to real mono bugs, there's also the fact that many of these frameworks, use this commonly used trick: FieldInfo remoteStackTraceString = typeof(Exception).GetField(_remoteStackTraceString, BindingFlags.Instance | BindingFlags.NonPublic); This doesn't work on mono, since in mono the private field storing the stacktrace is called remote_stack_trace. This issue has been reported before as issue 425512 ( https://bugzilla.novell.com/show_bug.cgi?id=425512 ) One could argue, and the reason for the wontfix status of the issue does so, that these folks rely on undocumented internals. They shouldn't do it, and Mono shouldn't rename it's own private field to match that of the CLR. However, in the real world(tm), this prevents many projects from running on Mono unmodified. I would like to argue that in this specific case, where the (percieved by me, maybe incorrectly) amount of work for mono to change it's private fieldname to match that of the CLR, is a reasonable cost for enabling this quite frequently found in the wild trick of grabbing the internal stack trace of an exception. Maybe I'm underestimating the amount of work to rename the mono fieldname to match the clr one. If that's the case, please consider this message as another datapoint of three useful .net frameworks unable to run on mono unmodified. Here's a bit more info on the trick: Here is a bit more background on the trick: http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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 -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21976367.html Sent from the Mono - Dev mailing list archive at
Re: [Mono-dev] Developing using Mono/Gtk# Vs Mono.WinForms (Windows Linux)
2009/2/12 Daniel Espinosa eso...@gmail.com We are working on a project using Mono/C# for a GUI independent library, but in parallel one library to use GUI objects (the presentation layer) witch will use the first library as a data provider. The GUI must works on Linux/Windows among other OSs and both libraries will be free software. What could be better to use Gtk# or Winforms? I'd personally prefer GTK#, though it can look out of place on windows. Similarly Winforms definitely looks out of place on linux. It's a tradeoff. The ideal option would be for you to create a UI using both toolkits so it looks native on both platforms, but this may not be an option due to limited resources etc. How to allow other users to contribute to the project if they will work on Windows and others (me) on Linux? On windows, use VS/SharpDevelop. On linux use MonoDevelop. I know projects' format diferencies between MS Visual Studio, SharpDevelop and MonoDevelop. How help this IEDs to work with the same project and code base? All three IDEs support the Visual Studio project format, so just use that. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] idea summary: Swing in Mono?...
The only good response to that email is summarised pretty well by this blogpost. http://www.jprl.com/Blog/archive/development/mono/2009/Jan-19.html The only addition I'll make is to ask this question: Have you ever created/distributed a CD which contains a hyperlink? If so, you've just infringed a patent! http://www.techdirt.com/articles/20070417/112812.shtml If something so trivial can be patented, than I think it's safe enough to assume that if your application is more than 1000 LOC, you've unwittingly infringed on at least one patent. So if you really are worried about patents, then you really should not be a software developer. Alan. On Sun, Feb 8, 2009 at 8:45 PM, BGB cr88...@hotmail.com wrote: - Original Message - From: Chris Toshok tos...@gmail.com To: BGB cr88...@hotmail.com Cc: Michael Hutchinson m.j.hutchin...@gmail.com; Stefanos A. stapos...@gmail.com; mono-devel-list@lists.ximian.com Sent: Monday, February 09, 2009 6:35 AM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... what legal risks? without specifics it's impossible to discount this claim, and if it's just the usual vague threat of software patents, you'll run into that regardless of the path you choose. MS patents nearly everything, and without them clearly making it free for everyone (as they had done with CIL and C# via ECMA-334 and 335), I am not so inclined to mess with it... (this is actually for a long time I had not looked much into Mono...). so, my usual approach is if there is a risk of patents, I will usually look for something else which serves my purposes, or design something clean (and working hard to avoid any patented designs I am aware of...). luckily, for most things, the implementation can be made generic and a thin wrapper can be provided for any patented APIs, such that one can easily remove it if any cease and desist orders show up... (although, sadly, there are far too many SW patents to be aware of all of them, or when certain ones expire, ...). but, yes, to me upholding copyrights and patents is an issue much like that of maintaining clean and modular code. messy code is bad; interdependencies and/or external dependencies are bad; uncertain copyrights are bad; possible patent violations are bad; .. or such... ___ 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] Logging profiler (statistical mode) stuck at exit
Hi, I reported the same issue yesterday to the developer in charge of the logging profiler and it is actively being looked at. Hopefully it'll be fixed soon. If you have issues in future, usually filing a bug on http://bugzilla.novell.com would be the recommended thing to do. Alan. On Sat, Jan 17, 2009 at 4:02 PM, Paul Melis mono-de...@assumetheposition.nl wrote: [This got previously sent from an unregistered e-mail address accidentally, so if this mail is delivered twice I apologize] Hi, With mono 2.2 I'm having pretty reproducable behavior where using the statistical profiler hangs when my program is done. The stacktrace is: (gdb) bt #0 0xe424 in __kernel_vsyscall () #1 0xb7e4e5ae in pthread_join () from /lib/libpthread.so.0 #2 0xb7cea6fb in profiler_shutdown (prof=0x830a628) at mono-profiler-logging.c:4726 #3 0x08160b8e in mono_profiler_shutdown () at profiler.c:512 #4 0x0805b8e5 in mini_cleanup (domain=0x25ee0) at mini.c:14721 #5 0x080ef24c in mono_main (argc=4, argv=0xbf878da4) at driver.c:1667 #6 0x0805b071 in main (argc=Cannot access memory at address 0x0) at main.c:34 A .mprof file is written, but it seems to be slightly corrupted, as I get: ERROR: DecodingException in block of code 0, length 0, file offset 119376, block offset 0: unknown block code 0 at Mono.Profiler.BlockData.Decode[LoadedClass,LoadedMethod,UnmanagedFunctionFromRegion,UnmanagedFunctionFromID,ExecutableMemoryRegion,LoadedElementHandler`7,HeapObject,HeapSnapshot] (IProfilerEventHandler`8 handler) [0x0] Attempting to decode data printing block contents... Current block of type 0 (file offset 119376, length 0) While attempting decoding, got exception unknown block code 0 Stopping decoding after a DecodingException in block of code 0, length 0, file offset 119376, block offset 0: unknown block code 0 No allocations reported (on 1503 classes) No execution time reported (on 1615 methods) No jit time reported (on 1615 methods) No statistical hits reported (on 1616 items) [...] when running mprog-decoder on it. The program profiler is a command-line thingy and does not use threads. Should I file a bug report in the tracker for this? I can provide the executable if needed... Regards, Paul Platform: Gentoo Linux, kernel 2.6.26, glibc 2.6.1 ___ 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] simd: more accelerated classes
I really doubt that kind of specific optimisation would ever make it into
mono. Have you tried benchmarking the existing SIMD implementation and
seeing what the raw performance of that is as compared to using the XNA
structs with Mono.SIMD in the background? The difference shouldn't be that
big. Something like this would be the implementation of the Xna struct:
struct XNAVector4f {
float X, Y, Z, W;
public XNAVector4f Multiply (XNAVector4f other)
{
Mono.Simd.Vector4f v1 = (Mono.Simd.Vector4f) this;
Mono.Simd.Vector4f v2 = (Mono.Simd.Vector4f) other;
return *((XNAVector4f *) Mono.Simd.Vector4f.Multiply (v1, v2));
}
}
Alan
On Tue, Jan 13, 2009 at 8:25 PM, crashfourit crashfou...@gmail.com wrote:
Rodrigo Kumpera wrote:
On Tue, Jan 13, 2009 at 5:50 PM, crashfourit crashfou...@gmail.com
wrote:
crashfourit wrote:
I was wondering what it would take to use simd to acclerate this
Vector4f {
public float X;
public float Y;
public float Z;
public float W;
//...
}
instead of this
Vector4f {
internal float x;
internal float y;
internal float z;
internal float w;
public float X {get {return x;} set {x = value;}}
public float Y {get {return y;} set {y = value;}}
public float Z {get {return z;} set {z = value;}}
public float W {get {return w;} set {w = value;}}
//...
}
Any sugestions?
Also, I was wondering is there any interest in accelerated versions of
high
level math constructs?
Like, QuaternionF, QuaternionD, Matrix4f, Matrix4d, etc?
--
I would love to see a library with such high level constructs that
exploit
Mono.Simd. I would
help with it for sure, but it shouldn't be bundled with mono.
Why shouldn't it be bundled with mono? I'd at least like to have those
higher level math structs in the Mono.Simd.Math or Mono.Math name space
or something similar, and and have the jit engine be more agressive when
inline methods in those classes. Or, have the jit engine act on those
classes in a similar way to the Vector* classes in the Mono.Simd name
space.
On a side note, what do you think of the idea of the jit engine acting more
aggressive to inline getters and setters than normal? I looked at the
inline
detection code, and realized this could be easily done.
--
View this message in context:
http://www.nabble.com/simd%3A-more-accelerated-classes-tp21442105p21443769.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] simd: more accelerated classes
There's no benefits to using mono as opposed to using any of the free
hosting ones out there. Mono doesn't come with a bug tracker, it doesn't
come with space to host downloads, it doesn't come with a wiki of any kind.
You really should consider using a free hosting that gives you all that. For
example google code, github, whatever.
Alan.
On Wed, Jan 14, 2009 at 12:09 AM, crashfourit crashfou...@gmail.com wrote:
Rodrigo Kumpera wrote:
On Tue, Jan 13, 2009 at 9:26 PM, crashfourit crashfou...@gmail.com
wrote:
Hurliman, John wrote:
-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of
Rodrigo Kumpera
Sent: Tuesday, January 13, 2009 12:00 PM
To: crashfourit
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] simd: more accelerated classes
On Tue, Jan 13, 2009 at 5:50 PM, crashfourit crashfou...@gmail.com
wrote:
crashfourit wrote: I was wondering what it would
take to use simd
to acclerate this Vector4f { public float X;
public float Y;
public float Z;public float W;//...
}
instead of
this Vector4f { internal float x; internal float y;
internal
float z; internal float w; public float X {get
{return x;} set
{x = value;}} public float Y {get {return y;} set {y =
value;}}
public float Z {get {return z;} set {z = value;}} public float
W
{get
{return w;} set {w = value;}} //... } Any
sugestions?
Also, I was wondering is there any interest in accelerated
versions
of high
level math constructs?
Like, QuaternionF, QuaternionD, Matrix4f, Matrix4d, etc?
--
I would love to see a library with such high level constructs that
exploit Mono.Simd. I would help with it for sure, but it shouldn't be
bundled with mono.
I would be willing to help with this as well. I currently maintain a
library called OpenMetaverseTypes (code is at
http://www.openmetaverse.org/viewvc/index.cgi/omf/libopenmetaverse/trunk/OpenMetaverse/Types/
)
which implements Vector2/3/4, Quaternion, Matrix4, Color4, Ray, and a
few
collections. In the future I'd like to accelerate as many of these as
possible. Sharing code with another library on top of Mono.Simd would
be
a
good start.
John
Is that code under the X11/MIT license? If so, we can start there. I
will
set up a sourceforge project for that purpose if the mono team does not
want
the code on there svn server.
--
Let me explain the implications of shipping such library.
First, it would require to be API stable, which will be a pain in the
neck
during the initial ramp up while the design is flushed out.
Second, we really really want to stop adding non essential libraries to
the
shipping mono. This only increases the load on our QA team at near to no
benefit for the end user.
Third, as Novell offers commercial support over the entire mono stack,
adding stuff increase the load on all of us mono developers that are
Novell
employees. This is, for me, the major reason not to add it to our core
stack. It will increase the support load on my shoulders at little gain.
This is only strict related to the inclusion of such library into the lib
shipped with mono. It's not the first time this issues has come before us
with other libraries, such as Mono.Rocks for example, and the consensus
was
the same: it would be in the best interest of all parties involved to not
have it included.
But this doesn't mean the library can't be endorsed as the preferred one
for
high level usage of Mono.Simd. From the very begging we already have
realized that almost everyone would not be willing to use it directly, as
the lib itself is just some building blocks.
As for hosting the project in the mono svn server, there isn't much of an
advantage for it, really. I, for one, would rather use github for
example.
But if you really fancy it, please talk to Miguel, as he is the one that
can
make such arrangement.
What would be really nice is to make a single effort for such library and
make sure that the Mono.Simd side of the things are well fit for such
library. Keep me posted on your efforts and I'll try to help as much as I
can.
Cheers,
Rodrigo
I, for one, would prefer the library on the mono svn if it is going to have
the unofficial nod, but I'm going to see what the others here that wanted a
similar library have to say.
--
View this message in context:
http://www.nabble.com/simd%3A-more-accelerated-classes-tp21442105p21447449.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Re: [Mono-dev] simd: more accelerated classes
That was included in the 'whatever' ;) There are probably a dozen more out
there that haven't been mentioned yet. It's up to the people who'll be
contributing to this project (or at least the guy who gets off his ass and
takes charge) to decide which one suits them best ;) I'm just saying that
there are much better options out there for new projects.
Alan.
On Wed, Jan 14, 2009 at 12:15 AM, crashfourit crashfou...@gmail.com wrote:
Good point, what about sourceforge?
Alan McGovern-2 wrote:
There's no benefits to using mono as opposed to using any of the free
hosting ones out there. Mono doesn't come with a bug tracker, it doesn't
come with space to host downloads, it doesn't come with a wiki of any
kind.
You really should consider using a free hosting that gives you all that.
For
example google code, github, whatever.
Alan.
On Wed, Jan 14, 2009 at 12:09 AM, crashfourit crashfou...@gmail.com
wrote:
Rodrigo Kumpera wrote:
On Tue, Jan 13, 2009 at 9:26 PM, crashfourit crashfou...@gmail.com
wrote:
Hurliman, John wrote:
-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of
Rodrigo Kumpera
Sent: Tuesday, January 13, 2009 12:00 PM
To: crashfourit
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] simd: more accelerated classes
On Tue, Jan 13, 2009 at 5:50 PM, crashfourit
crashfou...@gmail.com
wrote:
crashfourit wrote: I was wondering what it
would
take to use simd
to acclerate this Vector4f { public float X;
public float Y;
public float Z;public float W;//...
}
instead of
this Vector4f { internal float x; internal float y;
internal
float z; internal float w; public float X
{get
{return x;} set
{x = value;}} public float Y {get {return y;} set {y =
value;}}
public float Z {get {return z;} set {z = value;}} public
float
W
{get
{return w;} set {w = value;}} //... }
Any
sugestions?
Also, I was wondering is there any interest in accelerated
versions
of high
level math constructs?
Like, QuaternionF, QuaternionD, Matrix4f, Matrix4d, etc?
--
I would love to see a library with such high level constructs that
exploit Mono.Simd. I would help with it for sure, but it shouldn't
be
bundled with mono.
I would be willing to help with this as well. I currently maintain
a
library called OpenMetaverseTypes (code is at
http://www.openmetaverse.org/viewvc/index.cgi/omf/libopenmetaverse/trunk/OpenMetaverse/Types/
)
which implements Vector2/3/4, Quaternion, Matrix4, Color4, Ray, and
a
few
collections. In the future I'd like to accelerate as many of these
as
possible. Sharing code with another library on top of Mono.Simd
would
be
a
good start.
John
Is that code under the X11/MIT license? If so, we can start there. I
will
set up a sourceforge project for that purpose if the mono team does
not
want
the code on there svn server.
--
Let me explain the implications of shipping such library.
First, it would require to be API stable, which will be a pain in the
neck
during the initial ramp up while the design is flushed out.
Second, we really really want to stop adding non essential libraries
to
the
shipping mono. This only increases the load on our QA team at near to
no
benefit for the end user.
Third, as Novell offers commercial support over the entire mono stack,
adding stuff increase the load on all of us mono developers that are
Novell
employees. This is, for me, the major reason not to add it to our core
stack. It will increase the support load on my shoulders at little
gain.
This is only strict related to the inclusion of such library into the
lib
shipped with mono. It's not the first time this issues has come before
us
with other libraries, such as Mono.Rocks for example, and the
consensus
was
the same: it would be in the best interest of all parties involved to
not
have it included.
But this doesn't mean the library can't be endorsed as the preferred
one
for
high level usage of Mono.Simd. From the very begging we already have
realized that almost everyone would not be willing to use it directly,
as
the lib itself is just some building blocks.
As for hosting the project in the mono svn server, there isn't much of
an
advantage for it, really. I, for one, would rather use github for
example.
But if you really fancy it, please talk to Miguel, as he is the one
that
can
make such arrangement.
What
Re: [Mono-dev] greetings (new here)... a few things...
I am also not all that likely to re-use the existing CLI engine, as personally I find the code... displeasing... The time taken to submit patches to make the code pleasing to you would be significantly less than the time taken to rewrite from scratch. If the patches are good, they'll be accepted. Why not give that a shot and see if you can advance your own project *and* mono at the same time, at a much much faster rate than you could by by rewriting from scratch. Just my opinion ;) Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GetHashCode() implementation for class string
On Mon, Dec 1, 2008 at 9:44 PM, CarGa [EMAIL PROTECTED] wrote: Hello, all! I was directed here by Atsushi Eno from mono-olive list with this question/request about GetHashCode() method. DependencyProperty class (that lays at the very base of entire WWF and WPF libraries) heavily depends on quality of GetHashCode() method since we use it to find any particular DependencyProperty in some huge Dictionaryint, DependencyProperty of others. Small test shows, that there are HUGE amount of 2, 3 and 4 letter strings that have the same hash. I tested this with fresh mono built from SVN and I found thousands of words (quite short in fact) that have the same hash. For example Pattern 'gCat' has the same hash 3135983 as 'fbbU' Pattern 'gCc6' has the same hash 3135983 as 'gCat' Pattern 'gCbU' has the same hash 3135983 as 'gCat' Pattern 'gDD6' has the same hash 3135983 as 'gCat' Pattern 'gDBt' has the same hash 3135983 as 'gCat' Pattern 'gDCU' has the same hash 3135983 as 'gCat' Pattern 'fbc6' has the same hash 3135983 as 'gCat' Pattern 'fbat' has the same hash 3135983 as 'gCat' Pattern 'fbbU' has the same hash 3135983 as 'gCat' Pattern 'fcD6' has the same hash 3135983 as 'gCat' Pattern 'fcBt' has the same hash 3135983 as 'gCat' Pattern 'fcCU' has the same hash 3135983 as 'gCat' About 700 MBytes of wrong matches for words from 1 to 7 characters with alphanumeric alphabet of 63 symbols. This fact may lead to unpredictable and ununderstandable failures not only for WWF and WPF (we can rewrite our searching at the end), but to any application that is being ported to mono. There is also at least one blog in Net which points attention to this fact. Do YOU know about the issue? Do you plan to fix it? And one more. =) I tried to write some system statistics to console. Total memory, total available memory, total virtual memory and used physical and virtual memory. But the only answear was 0 bytes. I have heard, that Mono v2.0 is completely compatible with Framework 2.0 and that it implements every of Ms classes and methods... But this is not true, isn't it? I have to know for myself to be sure when we argue with guys about different OSes for true-developers. =) Here is the snippet: var currentProcess = System.Diagnostics.Process.GetCurrentProcess(); Console.WriteLine (\tPrivate Memory Size: + currentProcess.PrivateMemorySize64); Console.WriteLine (\tPaged Memory Size: + currentProcess.PagedMemorySize64); Console.WriteLine (\tVirtual Memory Size: + currentProcess.VirtualMemorySize64); Console.WriteLine (\tWorking Set: + currentProcess.WorkingSet64); Is it possible to return correct memory size? I have 8 GB of physical memory and about 32 GB of swap partition. I am very interested to measure the memory limits of my program before OS will terminate the process. =) Best regards, Anton. ___ 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] GetHashCode() implementation for class string
On Mon, Dec 1, 2008 at 9:44 PM, CarGa [EMAIL PROTECTED] wrote: Hello, all! I was directed here by Atsushi Eno from mono-olive list with this question/request about GetHashCode() method. DependencyProperty class (that lays at the very base of entire WWF and WPF libraries) heavily depends on quality of GetHashCode() method since we use it to find any particular DependencyProperty in some huge Dictionaryint, DependencyProperty of others. If i understand correctly, you're using the hashcode fo a DP as a unique identifier. This is wrong. Hashcodes are by definition *not* a unique identifer and should not be used as such. You're completly misusing the hashcode in this case. Your code will never run correctly if you are using .GetHashCode() to supply the 'int' in Dictionaryint, DependencyProperty Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Incoming changes to Mono.Simd
The second issue is a limitation of the C# language, which require extension methods to be defined of sealed classes. This would mean that code written against mono 2.2 version of Mono.Simd might not compiler with newer versions. 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. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MD not packaging binaries correctly though it could be mono at fault
What error? You're too vague with what is going wrong for a solution to be proposed. Alan. 2008/11/30 Paul [EMAIL PROTECTED]: Hi, I'm using 1.9.1 with Fedora rawhide. I've just built a game using MD (source is available at http://www.all-the-johnsons.co.uk/mono-bugs/NetterPillars.tar.bz2 ) and after fixing a few problems with fixed paths, it builds fine and other than not having focus for the window (so Keys.Right/Left/Up/Down don't work), the binary runs OK. Transfer it to a Windows XP box and it's a different matter. The splash screen comes up, but as soon as you try and run the game, it comes up with an error. It's not a big error, just it means that the background isn't drawn - the game still plays. If I rebuild the package using VS 2005 or 2008, everything works fine. Is this a mono-2.2 problem or an MD problem? Advice please before I file a BZ on it. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! ___ 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] MD not packaging binaries correctly though it could be mono at fault
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 [EMAIL PROTECTED]: Hi, What error? You're too vague with what is going wrong for a solution to be proposed. On Linux, the binary compiles without an issue and other than not having focus (so the game can't actually be played), it runs without issue. If I transfer the binary to a windows box, the game starts, but as soon as you click Start Game, an error comes up saying that a resource file is missing (it is the background for the game area). If the source is then rebuilt using VS 2005 or 2008, the resulting binary works without issue under both Win32 and Linux. I'm unsure if the resource file problem is a resgen issue or an MD issue. The keys one is a winforms problem. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! ___ 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] Mono SIMD Function Declarations and Timing
Hey, Would you care to do the same tests on Mono and .Net using class instead of struct to see what happens? It would be interesting to look at. Also, include object creation in that as well. Thanks. There's nothing new here. Passing a struct which is larger than the size of a pointer by value will always be slower than passing a class. Passing a Vector4d by value, which is 8 times larger than a pointer on a 32bit system, is going to be slower than passing it by ref. There's nothing that can be done about that other than using a different overload for adding. static void Vector4d Add (ref Vector4d first, ref Vector4d second, out Vector4d result) Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Simd - slower than the normal implementation
Hey,
On Sat, Nov 15, 2008 at 3:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Alan,
-Getters and setter are a hint of ill vectorized code.
In this particular scenario, I'm not sure how i can get rid of the use
of getters/setters unless I use even more unsafe code. I don't know
whether it's feasible or not, but it'd be great to be able to use this
API without having to use unsafe code. At the moment, I don't think
it's really possible to use this API without getters and setters.
The last part of your unsafe code should use temps for the intermediate
results.
Do you mean that I should copy the vector 'e', which i got from
XOR'ing my values, into another Vector4ui using the store operation?
Then I should do my bitshifting/storing into uint[] from that one?
-For the safe case we still miss proper integration with arrays, in the form
of methods to
extract and store vectors from them.
I was thinking that the API could expose something like:
Vector4ui.Create (uint[] array, int offset, ref Vector4ui result)
which could be changed into:
result = *((Vector4ui*)array [offset]);
Though I'm sure you have ideas already on this ;) A similar method for
storing the result into a uint[] would be great too.
Your code looks a bit strange, the Vector4ui constructor indexes in
particular. Have you checked that
the output of the 3 methods are the same?
Yes, there is a bug in my implementation there, I left out a bracket
when setting the value of buff[t+3]. There should be an additional
bracket around (e.W 1) | (e.W 31). Other than that, the
implementation is correct. I've pasted the correct implementation of
the unsafe and safe SIMD versions below. Just for reference purposes.
I'll work on the Mono.Simd issues next week, getting setters to be
accelerated, some methods
to better integrate with arrays and other things like element extractors.
Great stuff. Give me a shout when you've done that and I'll try to
improve the above implementation. Though if you have time to spare
while writing the SIMD code, you could take a look at it yourself ;)
Thanks,
Alan.
Reference implementations (non buggy ;) ):
public static void FillBuffSafe(uint[] buff)
{
for (int t = 16; t buff.Length; t += 4)
{
Vector4ui e = new Vector4ui(buff[t - 3], buff[t - 2],
buff[t - 1], buff[t - 0]) ^
new Vector4ui(buff[t - 8], buff[t - 7],
buff[t - 6], buff[t - 5]) ^
new Vector4ui(buff[t - 14], buff[t -
13], buff[t - 12], buff[t - 11]) ^
new Vector4ui(buff[t - 16], buff[t -
15], buff[t - 14], buff[t - 13]);
e.W ^= buff[t];
buff[t] = (e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = ((e.W 1) | (e.W 31)) ^ ((e.X 2)
| (e.X 30));
}
}
public unsafe static void FillBuffUnsafe(uint[] buffb)
{
fixed (uint* buff = buffb)
{
for (int t = 16; t buffb.Length; t += 4)
{
Vector4ui e = *((Vector4ui*)buff[t - 3]) ^
*((Vector4ui*)buff[t - 8]) ^
*((Vector4ui*)buff[t - 14]) ^
*((Vector4ui*)buff[t - 16]);
e.W ^= buff[t];
buff[t] = (e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = ((e.W 1) | (e.W 31)) ^ ((e.X
2) | (e.X 30));
}
}
}
Rodrigo
On Sat, Nov 15, 2008 at 12:13 AM, Alan McGovern [EMAIL PROTECTED]
wrote:
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort to unsafe code,
it's actually substantially slower! I've attached three
implementations of the method here. The original, the safe SIMD and
the unsafe SIMD. The runtimes are as follows:
Original: 600ms
Unsafe Simd: 450ms
Safe Simd: 1700ms
Also, the method is always called with a uint[] of length 80.
Is this just the wrong place to be using simd? It seemed ideal because
i need 75% less XOR's. If anyone has an ideas on whether SIMD could
actually be useful for this case or not, let me know.
Thanks,
Alan.
The original code is:
private static void FillBuff(uint[] buff)
{
uint val;
for (int i = 16; i 80; i += 8)
{
val = buff[i - 3] ^ buff[i - 8] ^ buff[i - 14] ^ buff[i -
16];
buff[i] = (val 1) | (val 31);
val = buff[i - 2] ^ buff[i - 7] ^ buff[i - 13] ^ buff[i -
15];
buff[i + 1] = (val 1) | (val 31);
val = buff[i - 1] ^ buff[i - 6] ^ buff[i - 12] ^ buff[i -
14];
buff[i + 2] = (val
Re: [Mono-dev] Mono.Simd - slower than the normal implementation
Here's my benchmarking file anyway, it may prove useful.
Alan.
On Sun, Nov 16, 2008 at 2:37 AM, Alan McGovern [EMAIL PROTECTED] wrote:
Hey,
On Sat, Nov 15, 2008 at 3:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Alan,
-Getters and setter are a hint of ill vectorized code.
In this particular scenario, I'm not sure how i can get rid of the use
of getters/setters unless I use even more unsafe code. I don't know
whether it's feasible or not, but it'd be great to be able to use this
API without having to use unsafe code. At the moment, I don't think
it's really possible to use this API without getters and setters.
The last part of your unsafe code should use temps for the intermediate
results.
Do you mean that I should copy the vector 'e', which i got from
XOR'ing my values, into another Vector4ui using the store operation?
Then I should do my bitshifting/storing into uint[] from that one?
-For the safe case we still miss proper integration with arrays, in the form
of methods to
extract and store vectors from them.
I was thinking that the API could expose something like:
Vector4ui.Create (uint[] array, int offset, ref Vector4ui result)
which could be changed into:
result = *((Vector4ui*)array [offset]);
Though I'm sure you have ideas already on this ;) A similar method for
storing the result into a uint[] would be great too.
Your code looks a bit strange, the Vector4ui constructor indexes in
particular. Have you checked that
the output of the 3 methods are the same?
Yes, there is a bug in my implementation there, I left out a bracket
when setting the value of buff[t+3]. There should be an additional
bracket around (e.W 1) | (e.W 31). Other than that, the
implementation is correct. I've pasted the correct implementation of
the unsafe and safe SIMD versions below. Just for reference purposes.
I'll work on the Mono.Simd issues next week, getting setters to be
accelerated, some methods
to better integrate with arrays and other things like element extractors.
Great stuff. Give me a shout when you've done that and I'll try to
improve the above implementation. Though if you have time to spare
while writing the SIMD code, you could take a look at it yourself ;)
Thanks,
Alan.
Reference implementations (non buggy ;) ):
public static void FillBuffSafe(uint[] buff)
{
for (int t = 16; t buff.Length; t += 4)
{
Vector4ui e = new Vector4ui(buff[t - 3], buff[t - 2],
buff[t - 1], buff[t - 0]) ^
new Vector4ui(buff[t - 8], buff[t - 7],
buff[t - 6], buff[t - 5]) ^
new Vector4ui(buff[t - 14], buff[t -
13], buff[t - 12], buff[t - 11]) ^
new Vector4ui(buff[t - 16], buff[t -
15], buff[t - 14], buff[t - 13]);
e.W ^= buff[t];
buff[t] = (e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = ((e.W 1) | (e.W 31)) ^ ((e.X 2)
| (e.X 30));
}
}
public unsafe static void FillBuffUnsafe(uint[] buffb)
{
fixed (uint* buff = buffb)
{
for (int t = 16; t buffb.Length; t += 4)
{
Vector4ui e = *((Vector4ui*)buff[t - 3]) ^
*((Vector4ui*)buff[t - 8]) ^
*((Vector4ui*)buff[t - 14]) ^
*((Vector4ui*)buff[t - 16]);
e.W ^= buff[t];
buff[t] = (e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = ((e.W 1) | (e.W 31)) ^ ((e.X
2) | (e.X 30));
}
}
}
Rodrigo
On Sat, Nov 15, 2008 at 12:13 AM, Alan McGovern [EMAIL PROTECTED]
wrote:
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort to unsafe code,
it's actually substantially slower! I've attached three
implementations of the method here. The original, the safe SIMD and
the unsafe SIMD. The runtimes are as follows:
Original: 600ms
Unsafe Simd: 450ms
Safe Simd: 1700ms
Also, the method is always called with a uint[] of length 80.
Is this just the wrong place to be using simd? It seemed ideal because
i need 75% less XOR's. If anyone has an ideas on whether SIMD could
actually be useful for this case or not, let me know.
Thanks,
Alan.
The original code is:
private static void FillBuff(uint[] buff)
{
uint val;
for (int i = 16; i 80; i += 8)
{
val = buff[i - 3] ^ buff[i - 8] ^ buff[i - 14] ^ buff[i -
16];
buff[i] = (val 1) | (val 31);
val = buff[i - 2] ^ buff[i - 7] ^ buff[i - 13] ^ buff[i -
15
[Mono-dev] Mono.Simd - slower than the normal implementation
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort to unsafe code,
it's actually substantially slower! I've attached three
implementations of the method here. The original, the safe SIMD and
the unsafe SIMD. The runtimes are as follows:
Original: 600ms
Unsafe Simd: 450ms
Safe Simd: 1700ms
Also, the method is always called with a uint[] of length 80.
Is this just the wrong place to be using simd? It seemed ideal because
i need 75% less XOR's. If anyone has an ideas on whether SIMD could
actually be useful for this case or not, let me know.
Thanks,
Alan.
The original code is:
private static void FillBuff(uint[] buff)
{
uint val;
for (int i = 16; i 80; i += 8)
{
val = buff[i - 3] ^ buff[i - 8] ^ buff[i - 14] ^ buff[i - 16];
buff[i] = (val 1) | (val 31);
val = buff[i - 2] ^ buff[i - 7] ^ buff[i - 13] ^ buff[i - 15];
buff[i + 1] = (val 1) | (val 31);
val = buff[i - 1] ^ buff[i - 6] ^ buff[i - 12] ^ buff[i - 14];
buff[i + 2] = (val 1) | (val 31);
val = buff[i + 0] ^ buff[i - 5] ^ buff[i - 11] ^ buff[i - 13];
buff[i + 3] = (val 1) | (val 31);
val = buff[i + 1] ^ buff[i - 4] ^ buff[i - 10] ^ buff[i - 12];
buff[i + 4] = (val 1) | (val 31);
val = buff[i + 2] ^ buff[i - 3] ^ buff[i - 9] ^ buff[i - 11];
buff[i + 5] = (val 1) | (val 31);
val = buff[i + 3] ^ buff[i - 2] ^ buff[i - 8] ^ buff[i - 10];
buff[i + 6] = (val 1) | (val 31);
val = buff[i + 4] ^ buff[i - 1] ^ buff[i - 7] ^ buff[i - 9];
buff[i + 7] = (val 1) | (val 31);
}
}
The unsafe SIMD code is:
public unsafe static void FillBuff(uint[] buffb)
{
fixed (uint* buff = buffb) {
Vector4ui e;
for (int t = 16; t buffb.Length; t += 4)
{
e = *((Vector4ui*)(buff [t-16])) ^
*((Vector4ui*)(buff [t-14])) ^
*((Vector4ui*)(buff [t- 8])) ^
*((Vector4ui*)(buff [t- 3]));
e.W ^= buff[t];
buff[t] = (e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = (e.W 1) | (e.W 31) ^ ((e.X 2) | (e.X 30));
}
}
}
The safe simd code is:
public static void FillBuff(uint[] buff)
{
Vector4ui e;
for (int t = 16; t buff.Length; t += 4)
{
e = new Vector4ui (buff [t-16],buff [t-15],buff
[t-14],buff [t-13]) ^
new Vector4ui (buff [t-14],buff [t-13],buff
[t-12],buff [t-11]) ^
new Vector4ui (buff [t-8], buff [t-7], buff
[t-6], buff [t-5]) ^
new Vector4ui (buff [t-3], buff [t-2], buff
[t-1], buff [t-0]);
e.W ^= buff[t];
buff[t] =(e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = (e.W 1) | (e.W 31) ^ ((e.X 2) |
(e.X 30));
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Simd - slower than the normal implementation
I forgot to mention that I'm on a 1.86GHZ core2duo and i was running
with --optimize=simd.
Alan.
On Sat, Nov 15, 2008 at 2:13 AM, Alan McGovern [EMAIL PROTECTED] wrote:
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort to unsafe code,
it's actually substantially slower! I've attached three
implementations of the method here. The original, the safe SIMD and
the unsafe SIMD. The runtimes are as follows:
Original: 600ms
Unsafe Simd: 450ms
Safe Simd: 1700ms
Also, the method is always called with a uint[] of length 80.
Is this just the wrong place to be using simd? It seemed ideal because
i need 75% less XOR's. If anyone has an ideas on whether SIMD could
actually be useful for this case or not, let me know.
Thanks,
Alan.
The original code is:
private static void FillBuff(uint[] buff)
{
uint val;
for (int i = 16; i 80; i += 8)
{
val = buff[i - 3] ^ buff[i - 8] ^ buff[i - 14] ^ buff[i - 16];
buff[i] = (val 1) | (val 31);
val = buff[i - 2] ^ buff[i - 7] ^ buff[i - 13] ^ buff[i - 15];
buff[i + 1] = (val 1) | (val 31);
val = buff[i - 1] ^ buff[i - 6] ^ buff[i - 12] ^ buff[i - 14];
buff[i + 2] = (val 1) | (val 31);
val = buff[i + 0] ^ buff[i - 5] ^ buff[i - 11] ^ buff[i - 13];
buff[i + 3] = (val 1) | (val 31);
val = buff[i + 1] ^ buff[i - 4] ^ buff[i - 10] ^ buff[i - 12];
buff[i + 4] = (val 1) | (val 31);
val = buff[i + 2] ^ buff[i - 3] ^ buff[i - 9] ^ buff[i - 11];
buff[i + 5] = (val 1) | (val 31);
val = buff[i + 3] ^ buff[i - 2] ^ buff[i - 8] ^ buff[i - 10];
buff[i + 6] = (val 1) | (val 31);
val = buff[i + 4] ^ buff[i - 1] ^ buff[i - 7] ^ buff[i - 9];
buff[i + 7] = (val 1) | (val 31);
}
}
The unsafe SIMD code is:
public unsafe static void FillBuff(uint[] buffb)
{
fixed (uint* buff = buffb) {
Vector4ui e;
for (int t = 16; t buffb.Length; t += 4)
{
e = *((Vector4ui*)(buff [t-16])) ^
*((Vector4ui*)(buff [t-14])) ^
*((Vector4ui*)(buff [t- 8])) ^
*((Vector4ui*)(buff [t- 3]));
e.W ^= buff[t];
buff[t] = (e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = (e.W 1) | (e.W 31) ^ ((e.X 2) | (e.X
30));
}
}
}
The safe simd code is:
public static void FillBuff(uint[] buff)
{
Vector4ui e;
for (int t = 16; t buff.Length; t += 4)
{
e = new Vector4ui (buff [t-16],buff [t-15],buff
[t-14],buff [t-13]) ^
new Vector4ui (buff [t-14],buff [t-13],buff
[t-12],buff [t-11]) ^
new Vector4ui (buff [t-8], buff [t-7], buff
[t-6], buff [t-5]) ^
new Vector4ui (buff [t-3], buff [t-2], buff
[t-1], buff [t-0]);
e.W ^= buff[t];
buff[t] =(e.X 1) | (e.X 31);
buff[t + 1] = (e.Y 1) | (e.Y 31);
buff[t + 2] = (e.Z 1) | (e.Z 31);
buff[t + 3] = (e.W 1) | (e.W 31) ^ ((e.X 2) |
(e.X 30));
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WindowsBase in mcs
The only other option is for there to be a place on disk which is: A) Guaranteed to be writable B) Guaranteed to have enough space to create the package. If those guarantees can be given, I'll gladly make the change. If they can't, then I don't want to completely break this API just to save memory. Alan. On Mon, Nov 10, 2008 at 6:17 PM, Paolo Molaro [EMAIL PROTECTED] wrote: On 11/06/08 Alan McGovern wrote: However this use case is likely to never be hit in System.IO.Packaging. The API requires that when you 'write' data to a zip archive, the data is also kept in memory. If you did try to use a 2gb file with this API, you'd end up trying to allocate a 2gb block of memory. There is no requirement in the API that data is kept in memory, this bug needs to be fixed, if you don't know how, at least file a bug report in bugzilla so we don't forget about it. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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] WindowsBase in mcs
Also, If you're actually writing the package to disk, you need free space == size (package) * 2 as you will have to store a temporary full copy of the package as well as the final copy. Alan. On Mon, Nov 10, 2008 at 7:01 PM, Alan McGovern [EMAIL PROTECTED]wrote: The only other option is for there to be a place on disk which is: A) Guaranteed to be writable B) Guaranteed to have enough space to create the package. If those guarantees can be given, I'll gladly make the change. If they can't, then I don't want to completely break this API just to save memory. Alan. On Mon, Nov 10, 2008 at 6:17 PM, Paolo Molaro [EMAIL PROTECTED] wrote: On 11/06/08 Alan McGovern wrote: However this use case is likely to never be hit in System.IO.Packaging. The API requires that when you 'write' data to a zip archive, the data is also kept in memory. If you did try to use a 2gb file with this API, you'd end up trying to allocate a 2gb block of memory. There is no requirement in the API that data is kept in memory, this bug needs to be fixed, if you don't know how, at least file a bug report in bugzilla so we don't forget about it. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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] WindowsBase in mcs
Done. Alan. On Thu, Nov 6, 2008 at 3:17 AM, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, 1) Most of the ZipPackage/Package tests will fail because libminizip.so doesn't exist. This needs to be compiled from source. How should this be integrated with the build? This will also have to be distributed with mono in some form. This needs to go into mono/support, can you please include it there? ___ 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] WindowsBase in mcs
Hi, On Thu, Nov 6, 2008 at 3:02 PM, Paolo Molaro [EMAIL PROTECTED] wrote: On 11/05/08 Alan McGovern wrote: 2) minizip exposes 'long' types in it's public API. At the moment I've wrapped these as IntPtr types. This will run on all platforms except Win64. To resolve this, we'd need to create a wrapper API which exposes the 'long' types as int64_t. When dealing with file offsets long is the wrong type to use, since it's broken for 32 bit systems too, not only for win64. int64_t should be used (or gint64...), but the code must be changed to fix this issue, there is no point in adding a wrapper API, which wouldn't solve the problem. However this use case is likely to never be hit in System.IO.Packaging. The API requires that when you 'write' data to a zip archive, the data is also kept in memory. If you did try to use a 2gb file with this API, you'd end up trying to allocate a 2gb block of memory. But yes, this is should be fixed regardless of that because long types are unportable. What we need is to either submit a patch against zlib/minizip or just patch our local copy to change all 'long' types to int64_t. The other alternative is to use a different zip backend. Alan. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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
[Mono-dev] WindowsBase in mcs
Hey, Now that WindowsBase has been moved to mcs, I assume we want its NUnit tests to be run by the build bot. This poses two problems: 1) Most of the ZipPackage/Package tests will fail because libminizip.so doesn't exist. This needs to be compiled from source. How should this be integrated with the build? This will also have to be distributed with mono in some form. 2) minizip exposes 'long' types in it's public API. At the moment I've wrapped these as IntPtr types. This will run on all platforms except Win64. To resolve this, we'd need to create a wrapper API which exposes the 'long' types as int64_t. Anyone have any suggestions/advice on these issues? Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Contributing Code for ObservableCollection
Ok, so here's my comments (so far ;) ):
1) Xml comments are a no-go in the source files. If you want to commit
documentation (which is always appreciated!) you should add it to monodoc
and submit it as a separate patch. It should be possible to import your XML
comments into monodoc automatically so you don't have to re-type them. Once
they've been imported to monodoc, you'll have to strip them from the source
files.
2) You've duplicated some of the helper methods in your tests
(ObservableCollectionTest/NotifyCollectionChangedEventArgsTest). You could
create a base class which implements this helper methods and just have your
two test fixtures inherit from this, or you could define the methods
publicly in some static class and reference them from there. Less
duplication == good.
3)
+public void Enter()
+{
+count++;
+}
+
+public void Dispose()
+{
+count--;
+}
In Reentrant, are you sure this is the right behaviour? Can you make a
testcase where you call BlockReentrancy twice and then double dispose the
object given from the first call. Also, it might be worth writing a test to
ensure the exact same object is returned every time.
Other than that, it looks good to commit. When you've completed those
changes, send the updated patch here and I'll get to work on committing it.
Thanks for the great work,
Alan.
On Tue, Nov 4, 2008 at 1:39 PM, Brian O'Keefe [EMAIL PROTECTED] wrote:
Hi,
There are indeed 3 test case files; I forgot to svn add them. I made a new
patch file with all of the files this time. I'll attach the new one.
~Brian
On Tue, Nov 4, 2008 at 4:25 AM, Alan McGovern [EMAIL PROTECTED]wrote:
Hey,
Maybe i'm just confused, but in your original email you said there were 3
testcase files, but I'm only seeing 1 modified testcase file.
Is this right, or did you forget to svn add the new files before you
submitted the patch?
Thanks,
Alan.
On Mon, Nov 3, 2008 at 11:36 PM, Brian O'Keefe [EMAIL PROTECTED]wrote:
Hello,
I've updated my code to conform to the coding guidelines. My tests pass
under both mono and the MS framework. I'll attach the patch file for my
changes.
~Brian
On Sat, Nov 1, 2008 at 6:59 PM, Alan McGovern [EMAIL PROTECTED]wrote:
Hey,
Read here: http://www.mono-project.com/Contributing and also here
http://www.mono-project.com/Coding_Guidelines.
Though my word is most definitely *not* the final word in any
discussion, I will say that if the code isn't covered by NUnit tests, it
won't be committed ;) So just ensure that for every method you've
implemented, there are one or more tests for it. From your email, it looks
like you've already done this, which is great!
Also, just to verify, do all the tests pass when run under both the MS
framework and mono?
Thanks.
Alan.
2008/11/1 Brian O'Keefe [EMAIL PROTECTED]
Hello,
I've been following the Mono project for a while, and had some free
time, so I figured I'd use some of that time to contribute. I've used the
ObservableCollection class frequently
(WindowsBaseSystem.Collections.Specialized.ObservableCollection) and
noticed that it wasn't implemented in Mono. This seemed like a fairly
simple class to implement, so I thought I'd start there. I have some code
for ObservableCollection and its backing infrastructure (the
NotifyCollectionChanged* classes) and matching test cases.
What would be the best way to contribute the changes I made? There are
six modified files and three test case files.
~Brian
___
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] Contributing Code for ObservableCollection
Hey, Read here: http://www.mono-project.com/Contributing and also here http://www.mono-project.com/Coding_Guidelines. Though my word is most definitely *not* the final word in any discussion, I will say that if the code isn't covered by NUnit tests, it won't be committed ;) So just ensure that for every method you've implemented, there are one or more tests for it. From your email, it looks like you've already done this, which is great! Also, just to verify, do all the tests pass when run under both the MS framework and mono? Thanks. Alan. 2008/11/1 Brian O'Keefe [EMAIL PROTECTED] Hello, I've been following the Mono project for a while, and had some free time, so I figured I'd use some of that time to contribute. I've used the ObservableCollection class frequently (WindowsBaseSystem.Collections.Specialized.ObservableCollection) and noticed that it wasn't implemented in Mono. This seemed like a fairly simple class to implement, so I thought I'd start there. I have some code for ObservableCollection and its backing infrastructure (the NotifyCollectionChanged* classes) and matching test cases. What would be the best way to contribute the changes I made? There are six modified files and three test case files. ~Brian ___ 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
[Mono-dev] UriParser.cs - Threading fixes
There are a few thread-unsafe accesses to the hashtable which I've fixed.
I've also cleaned up how the initial table is populated by removing
redundent calls to CreateDefaults ().
Is this ok to commit?
Index: UriParser.cs
===
--- UriParser.cs(revision 117256)
+++ UriParser.cs(working copy)
@@ -38,7 +38,7 @@
public abstract class UriParser {
static object lock_object = new object ();
-static Hashtable table;
+static Hashtable table = CreateDefaults ();
private string scheme_name;
private int default_port;
@@ -211,11 +211,8 @@
// static methods
-private static void CreateDefaults ()
+private static Hashtable CreateDefaults ()
{
-if (table != null)
-return;
-
Hashtable newtable = new Hashtable ();
InternalRegister (newtable, new DefaultUriParser (),
Uri.UriSchemeFile, -1);
InternalRegister (newtable, new DefaultUriParser (),
Uri.UriSchemeFtp, 21);
@@ -229,13 +226,8 @@
InternalRegister (newtable, new DefaultUriParser (),
Uri.UriSchemeNntp, 119);
// not defined in Uri.UriScheme* but a parser class exists
InternalRegister (newtable, new DefaultUriParser (), ldap,
389);
-
-lock (lock_object) {
-if (table == null)
-table = newtable;
-else
-newtable = null;
-}
+
+return newtable;
}
public static bool IsKnownScheme (string schemeName)
@@ -245,9 +237,10 @@
if (schemeName.Length == 0)
throw new ArgumentOutOfRangeException (schemeName);
-CreateDefaults ();
string lc = schemeName.ToLower (CultureInfo.InvariantCulture);
-return (table [lc] != null);
+
+lock (lock_object)
+return (table [lc] != null);
}
// *no* check version
@@ -280,14 +273,16 @@
if ((defaultPort -1) || (defaultPort = UInt16.MaxValue))
throw new ArgumentOutOfRangeException (defaultPort);
-CreateDefaults ();
-
string lc = schemeName.ToLower (CultureInfo.InvariantCulture);
-if (table [lc] != null) {
-string msg = Locale.GetText (Scheme '{0}' is already
registred.);
-throw new InvalidOperationException (msg);
+
+lock (lock_object) {
+if (table [lc] != null) {
+string msg = Locale.GetText (Scheme '{0}' is already
registred.);
+throw new InvalidOperationException (msg);
+}
+
+InternalRegister (table, uriParser, lc, defaultPort);
}
-InternalRegister (table, uriParser, lc, defaultPort);
}
internal static UriParser GetParser (string schemeName)
@@ -295,10 +290,10 @@
if (schemeName == null)
return null;
-CreateDefaults ();
-
string lc = schemeName.ToLower (CultureInfo.InvariantCulture);
-return (UriParser) table [lc];
+
+lock (lock_object)
+return (UriParser) table [lc];
}
}
}
Index: UriParser.cs
===
--- UriParser.cs (revision 117256)
+++ UriParser.cs (working copy)
@@ -38,7 +38,7 @@
public abstract class UriParser {
static object lock_object = new object ();
- static Hashtable table;
+ static Hashtable table = CreateDefaults ();
private string scheme_name;
private int default_port;
@@ -211,11 +211,8 @@
// static methods
- private static void CreateDefaults ()
+ private static Hashtable CreateDefaults ()
{
- if (table != null)
-return;
-
Hashtable newtable = new Hashtable ();
InternalRegister (newtable, new DefaultUriParser (), Uri.UriSchemeFile, -1);
InternalRegister (newtable, new DefaultUriParser (), Uri.UriSchemeFtp, 21);
@@ -229,13 +226,8 @@
InternalRegister (newtable, new DefaultUriParser (), Uri.UriSchemeNntp, 119);
// not defined in Uri.UriScheme* but a parser class exists
InternalRegister (newtable, new DefaultUriParser (), ldap, 389);
-
- lock (lock_object) {
-if (table == null)
- table = newtable;
-else
- newtable = null;
- }
+
+ return newtable;
}
public static bool IsKnownScheme (string schemeName)
@@ -245,9 +237,10 @@
if (schemeName.Length == 0)
throw new ArgumentOutOfRangeException (schemeName);
- CreateDefaults ();
string lc = schemeName.ToLower (CultureInfo.InvariantCulture);
- return (table [lc] != null);
+
+ lock (lock_object)
+return (table [lc] != null);
}
// *no* check version
@@ -280,14 +273,16 @@
if ((defaultPort -1) || (defaultPort = UInt16.MaxValue))
throw new ArgumentOutOfRangeException
[Mono-dev] Uri.cs and UriParser.cs - .NET 2.0 changes
Hey,
In .NET 2.0, Uri parsing has been moved to designated classes all derived
from UriParser. This makes it possible to have custom parsers for new Uri
schemes. Currently mono doesn't support this properly.
What I think would be the best thing to do would be to change parsing under
all profiles to use this new API. In the .NET 1.1 profile, we'd just mark
these classes as internal, so this gives one codepath to maintain.
In .NET 1.1 Uri.Parse () would would be replaced by calls to the new parser
classes so that existing behaviour isn't changed. Under .NET 2.0, I believe
an approach similar to what I've prototyped in the attached patch should be
what is implemented. Basically each of the properties of Uri will call into
the parser to get the required component. The results of this call could be
cached locally for increased performance.
The other benefit is that it should also reduce the shotgun approach to
parsing, i.e. the special casing in the parse logic for different schemes.
This might make things more maintainable.
An example parser is also attached in Test.cs and is implemented as a
console app. If you apply the above patch to mono, you can parse the pack
schema. Note, the patch *will* break all other Uri parsing as i hardcoded a
pack parser.
Does anyone have any thoughts on this?
Alan.
Index: System/Uri.cs
===
--- System/Uri.cs (revision 117256)
+++ System/Uri.cs (working copy)
@@ -116,6 +116,7 @@
public Uri (string uriString) : this (uriString, false)
{
+Parser = UriParser.GetParser (pack);
}
protected Uri (SerializationInfo serializationInfo,
@@ -405,22 +406,7 @@
public string AbsolutePath {
get {
#if NET_2_0
-EnsureAbsoluteUri ();
-switch (Scheme) {
-case mailto:
-case file:
- // faster (mailto) and special (file) cases
- return path;
-default:
- if (path.Length == 0) {
- string start = Scheme + SchemeDelimiter;
- if (path.StartsWith (start))
- return /;
- else
- return String.Empty;
- }
- return path;
-}
+return GetComponents (UriComponents.Path | UriComponents.KeepDelimiter, UriFormat.Unescaped);
#else
return path;
#endif
@@ -428,7 +414,10 @@
}
public string AbsoluteUri {
- get {
+ get {
+#if NET_2_0
+return GetComponents (UriComponents.AbsoluteUri, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
if (cachedAbsoluteUri == null) {
cachedAbsoluteUri = GetLeftPart (UriPartial.Path);
@@ -438,28 +427,42 @@
cachedAbsoluteUri += fragment;
}
return cachedAbsoluteUri;
+#endif
}
}
public string Authority {
- get {
+ get {
+#if NET_2_0
+return GetComponents (UriComponents.HostAndPort, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
return (GetDefaultPort (Scheme) == port)
? host : host + : + port;
- }
+#endif
+ }
+
}
public string Fragment {
- get {
+ get {
+#if NET_2_0
+return GetComponents (UriComponents.Fragment | UriComponents.KeepDelimiter, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
-return fragment;
+return fragment;
+#endif
}
}
public string Host {
- get {
+ get {
+#if NET_2_0
+return GetComponents (UriComponents.Host, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
-return host;
+return host;
+#endif
}
}
@@ -485,8 +488,13 @@
public bool IsDefaultPort {
get {
+#if NET_2_0
+string s = GetComponents (UriComponents.Port, UriFormat.Unescaped);
+return s == ? true : int.Parse (s) == Parser.DefaultPort;
+#else
EnsureAbsoluteUri ();
return GetDefaultPort (Scheme) == port;
+#endif
}
}
@@ -590,29 +598,46 @@
public string PathAndQuery {
get {
+#if NET_2_0
+return GetComponents (UriComponents.PathAndQuery, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
return path + Query;
+#endif
}
}
public int Port {
- get {
+ get {
+#if NET_2_0
+string s = GetComponents (UriComponents.Port, UriFormat.Unescaped);
+return s == ? Parser.DefaultPort : int.Parse (s);
+#else
EnsureAbsoluteUri ();
-return port;
+return port;
+#endif
}
}
public string Query {
- get {
+ get {
+#if NET_2_0
+return GetComponents (UriComponents.Query | UriComponents.KeepDelimiter, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
-return query;
+return query;
+#endif
}
}
public string Scheme {
- get {
+ get {
+#if NET_2_0
+return GetComponents (UriComponents.Scheme, UriFormat.Unescaped);
+#else
EnsureAbsoluteUri ();
-return scheme;
+return scheme;
+#endif
}
}
@@ -1295,13 +1320,21 @@
// This parse method will throw exceptions on failure
//
private void Parse (UriKind kind, string uriString)
- {
+ {
+#if NET_2_0
+ if (Parser == null)
+ {
+if (UriParser.IsKnownScheme
Re: [Mono-dev] Using Mono.Options in MS.NET
It's 100% pure managed code, and also a single .cs file. That makes it trivial to just include as part of your build. You can reference it using an svn:external (or equivalent) so you always have the latest from svn aswell, which minimises the need to keep in sync with the working copy. There's no need to lug around an extra assembly when it's so easy to compile it right in :) Alan. On Fri, Oct 17, 2008 at 8:03 AM, Petit Eric [EMAIL PROTECTED] wrote: 2008/10/17 Avery Pennarun [EMAIL PROTECTED]: On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza [EMAIL PROTECTED] wrote: Now that Mono.Options is included in Mono 2.2, will it still be available separately? If not, it will be hard to build Windows-compatible programs that use it, unless people go digging throug the mono sources and extracting the libraries they like. I think it might be helpful to separate mono libraries that add functionality to any .Net application and mono libraries that implement the MS class library into two different projects. Am I missing something? You can always pull the code using the AnonSVN user interface from the web, it can produce tarballs of just the things that you need. Our todo list includes Make it easier to release components independently, would love to do it, we just need the spare cycles to make it happen in a general way for everything that we need. I think the tarball solution is pretty good, and we could just bundle solutions or files for the more complicated modules (Mono.Options is really easy to use). I don't know if Mono.Option made P/Invoke, but if not you can simply set , assembly property to Locale copy as it, the dll will folow the .exe and so ... Thanks, that answers my question. Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Cordially. Small Eric Quotations of the days: --- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --- Few people are done for independence, it is the privilege of the powerful ones. --- No key was wounded during the drafting of this message. ___ 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] Implement .NET 2.0 API for UnixListener and UnixClient
Hey,
This isn't a full review, it's just me point out some stuff I notice. Here
it goes:
+public IAsyncResult BeginAcceptSocket (AsyncCallback callback,
object state)
+{
+if (server == null)
+throw new ObjectDisposedException (GetType ().FullName);
+
+return(server.BeginAccept (callback, state));
Why not just call CheckDisposed () as is done in BeginAccept ()?
+#if NET_2_0
+public Socket Server
+#else
+protected Socket Server
+#endif
I think the usual way to write this is:
+#if NET_2_0
+public
+#else
+protected
+#endif
Socket Server
2008/10/17 Vlad Hociota [EMAIL PROTECTED]
Hi Jonathan.
This is a stab at doing the updates we've discussed: implement new
properties and methods for UnixListener and UnixClient similar to those
exposed by TcpListener and TcpClient in .NET 2.0 . Please review.
Thanks,
Vlad
___
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] String.GetHashCode Discussion.
Hey,
With the recent talk on GetHashCode(), I was just taking a look at the code.
I decided to try my hand at seeing what would happen performancewise if i
made the function work with an int* as opposed to char*. Turns out i ended
up with something which was 50% slower, but also had 50% less collisions on
a rather large english dictionary dataset (17mb of words, probably a few
dupes).
Just in case it's of any use, i've attached it here, though i'd say there
are much better ones out there. This was purely accidental ;)
public unsafe static int GetHashCode(string s)
{
int h = 0;
int rem = s.Length 3;
fixed (char* c = s)
{
int* start = (int*)c;
int* end = start + s.Length - rem;
for (int* i = end; i = start; i--)
h = (h 5) - h + *i;
char* cc = c + s.Length - rem;
for (char* i = cc + rem; i = cc; i--)
h = (h 5) - h + *i;
return h;
}
}
On Mon, Jul 21, 2008 at 12:33 PM, Marek Safar [EMAIL PROTECTED] wrote:
Hello Andreas,
Imho we should revert the change, especially as MS seems to also have an
implementation with low collisions (and in fact this will be what people
are
expecting from a hashcode without any further explanation) we should do
the
same. Otherwise this might drive some implementations into huge perf
problems.
I reverted my changes for now to produce same bad/good results. However,
I tried to port another implementation which seems to produce much more
better results for both scenarios but it still needs more testing. I'll
send a patch for review when I am done.
Marek
___
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
[Mono-dev] BigInteger speedup
Attached is a tiny patch for BigInteger which removes an unnecessary instantiation. Anything which makes use of the ModPow operation will benefit from this. Alan. bigintopt.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] BigInteger speedup
Done. Thanks, Alan. On Sat, May 31, 2008 at 2:45 PM, Sebastien Pouliot [EMAIL PROTECTED] wrote: Good catch, please commit! On Sat, 2008-05-31 at 12:34 +0100, Alan McGovern wrote: Attached is a tiny patch for BigInteger which removes an unnecessary instantiation. Anything which makes use of the ModPow operation will benefit from this. Alan. ___ 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
[Mono-dev] Removing unsafe code in BitConverter and speedups
];
+c.b6 = value [startIndex + 1];
+c.b7 = value [startIndex + 0];
-return ret;
+return c.d;
}
- PutBytes ((byte *) ret, value, startIndex, 8);
+ PutBytes64 (ref c, value, startIndex);
- return ret;
+ return c.d;
}
public static string ToString (byte[] value)
@@ -456,3 +562,4 @@
}
}
}
+
Index: ChangeLog
===
--- ChangeLog (revision 102166)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2008-05-10 Alan McGovern [EMAIL PROTECTED]
+
+ * BitConverter.cs: Replace unsafe code with safe equivalents. Improves
+ performance of DoubleToInt64Bits and Int64BitsToDouble.
+
2008-04-26 Zoltan Varga [EMAIL PROTECTED]
* Array.cs (LastIndexOf): Return GetLowerBound (0) -1 instead of -1.
//
// System.BitConverter.cs
//
// Author:
// Matt Kimball ([EMAIL PROTECTED])
//
//
// Copyright (C) 2004 Novell, Inc (http://www.novell.com)
//
// Permission is hereby granted, free of charge, to any person obtaining
// a copy of this software and associated documentation files (the
// Software), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace Test
{
public
#if NET_2_0
static
#else
sealed
#endif
class BitConverter
{
#if !NET_2_0
private BitConverter ()
{
}
#endif
[StructLayoutAttribute(LayoutKind.Explicit)]
private struct Convert16
{
[FieldOffsetAttribute(0)]
public bool boolean;
[FieldOffsetAttribute(0)]
public char c;
[FieldOffsetAttribute(0)]
public short s;
[FieldOffsetAttribute(0)]
public ushort us;
[FieldOffsetAttribute(0)]
public byte b0;
[FieldOffsetAttribute(1)]
public byte b1;
}
[StructLayoutAttribute(LayoutKind.Explicit)]
private struct Convert32
{
[FieldOffsetAttribute(0)]
public int i;
[FieldOffsetAttribute(0)]
public float f;
[FieldOffsetAttribute(0)]
public uint ui;
[FieldOffsetAttribute(0)]
public byte b0;
[FieldOffsetAttribute(1)]
public byte b1;
[FieldOffsetAttribute(2)]
public byte b2;
[FieldOffsetAttribute(3)]
public byte b3;
}
[StructLayoutAttribute(LayoutKind.Explicit)]
private struct Convert64
{
[FieldOffsetAttribute(0)]
public double d;
[FieldOffsetAttribute(0)]
public long l;
[FieldOffsetAttribute(0)]
public ulong ul;
[FieldOffsetAttribute(0)]
public byte b0;
[FieldOffsetAttribute(1)]
public byte b1;
[FieldOffsetAttribute(2)]
public byte b2;
[FieldOffsetAttribute(3)]
public byte b3;
[FieldOffsetAttribute(4)]
public byte b4;
[FieldOffsetAttribute(5)]
public byte b5;
[FieldOffsetAttribute(6)]
public byte b6;
[FieldOffsetAttribute(7)]
public byte b7;
}
static readonly bool SwappedWordsInDouble = DoubleWordsAreSwapped ();
public static readonly bool IsLittleEndian = AmILittleEndian ();
static bool AmILittleEndian ()
{
// binary representations of 1.0:
// big endian: 3f f0 00 00 00 00 00 00
// little endian: 00 00 00 00 00 00 f0 3f
// arm fpa little endian: 00 00 f0 3f 00 00 00 00
Convert64 c = new Convert64 ();
c.d = 1.0;
return c.b0 == 0;
}
static bool DoubleWordsAreSwapped ()
{
// binary representations of 1.0:
// big endian: 3f f0 00 00 00 00 00 00
// little endian: 00 00 00 00 00 00 f0 3f
// arm fpa little endian: 00 00 f0 3f 00 00 00 00
Convert64 c = new Convert64 ();
c.d = 1.0;
return c.b2 == 0xf0;
}
public static long DoubleToInt64Bits (double value)
{
Convert64 c = new Convert64 ();
c.d = value;
return c.l;
}
public static double Int64BitsToDouble (long value)
{
Convert64 c = new Convert64 ();
c.l = value;
return c.d;
}
internal static double InternalInt64BitsToDouble (long value)
{
return SwappableToDouble (GetBytes (value), 0);
}
public static byte[] GetBytes (bool value)
{
return value ? new byte[] { 1 } : new byte[] { 0 };
}
public static byte[] GetBytes (char value
Re: [Mono-dev] JIT and Inlining - why doesn't it happen?
Hi,
That makes sense. I was just quite surprised at the time that the methods
were not being inlined as they were only simple maths operations. I checked
monodis for one of the methods and it turned out to be 8 IL instructions,
which is probably 24 bytes, which would explain why it wasn't inlined.
Alan.
On Thu, May 1, 2008 at 12:24 AM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Well, the inliner basically eliminates the penalty from using properties
and empty constructors.
Increasing the inline threshold is tricky and might now be worthy as there
are too many situations that abort 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 then don't ask me what kind of method *could* be
inlined by the JIT.
Alan.
On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera [EMAIL PROTECTED]
wrote:
Mono only inline 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 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 inlined! Each of these methods is only called once in the code.
By
manually inlining those method calls, performance increased
significantly -
about 70%. Why isn't mono inlining these methods? Can mono be made
inline
these?
Alan.
[1]
http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462view=markup
___
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] JIT and Inlining - why doesn't it happen?
Hi,
The method ch does get inlined alright:
INLINE START 00B23210
System.Security.Cryptography.SHA256Managed:ProcessBlock (byte[],int) -
System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint)
created temp 24 of type System.UInt32
method to IR System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint)
created temp 25 of type System.Security.Cryptography.SHA256Managed
created temp 26 of type System.UInt32
created temp 27 of type System.UInt32
created temp 28 of type System.UInt32
INLINE END System.Security.Cryptography.SHA256Managed:ProcessBlock
(byte[],int) - System.Security.Cryptography.SHA256Managed:Ch
(uint,uint,uint)
However, if i manually replace:
Ch(e, f, g);
with
((ef) ^ (~eg))
I get an 10% performance boost (give or take). Surely if the method was
getting inlined, that wouldn't be the case. Could it be that the temp
variables (25-28) aren't being dropped and there is excess variable copying
going on?
Alan.
On Thu, May 1, 2008 at 12:47 PM, Zoltan Varga [EMAIL PROTECTED] wrote:
Hi,
On my amd64 machine, that method does get inlined. You can check the
output of mono -v -v -v -v for INLINE lines to see what gets inlined.
Zoltan
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 at 11:32 PM, Rodrigo Kumpera [EMAIL PROTECTED]
wrote:
Mono only inline 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 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 inlined! Each of these methods is only called once in the code.
By
manually inlining those method calls, performance increased
significantly -
about 70%. Why isn't mono inlining these methods? Can mono be made
inline
these?
Alan.
[1]
http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462view=markup
___
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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SHA256 - small perf boost
Change in plan, how does a speedup of 70% sound?
Strangely enough, mono wasn't inlining the static helper methods. As each of
those helpers was only being called once, i inlined them manually and
performance went through the roof. It may be worth grabbing a JIT guy and
figuring out why mono 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 of the ideas from the SHA1 patch to sha256 left me with
a 15% performance boost. Is this good to commit? It passes the nunit
tests.
Alan.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Index: SHA256Managed.cs
===
--- SHA256Managed.cs (revision 102233)
+++ SHA256Managed.cs (working copy)
@@ -39,7 +39,6 @@
private const int BLOCK_SIZE_BYTES = 64;
private const int HASH_SIZE_BYTES = 32;
private uint[] _H;
- private uint[] K;
private ulong count;
private byte[] _ProcessingBuffer; // Used to start data when passed less than a block worth.
private int _ProcessingBufferCount; // Counts how much data we have stored that still needs processed.
@@ -53,44 +52,6 @@
Initialize ();
}
- private uint Ch (uint u, uint v, uint w)
- {
- return (uv) ^ (~uw);
- }
-
- private uint Maj (uint u, uint v, uint w)
- {
- return (uv) ^ (uw) ^ (vw);
- }
-
- private uint Ro0 (uint x)
- {
- return ((x 7) | (x 25))
-^ ((x 18) | (x 14))
-^ (x 3);
- }
-
- private uint Ro1 (uint x)
- {
- return ((x 17) | (x 15))
-^ ((x 19) | (x 13))
-^ (x 10);
- }
-
- private uint Sig0 (uint x)
- {
- return ((x 2) | (x 30))
-^ ((x 13) | (x 19))
-^ ((x 22) | (x 10));
- }
-
- private uint Sig1 (uint x)
- {
- return ((x 6) | (x 26))
-^ ((x 11) | (x 21))
-^ ((x 25) | (x 7));
- }
-
protected override void HashCore (byte[] rgb, int start, int size)
{
int i;
@@ -159,6 +120,8 @@
uint a, b, c, d, e, f, g, h;
uint t1, t2;
int i;
+ uint[] K1 = SHAConstants.K1;
+ uint[] buff = this.buff;
count += BLOCK_SIZE_BYTES;
@@ -163,10 +126,10 @@
count += BLOCK_SIZE_BYTES;
for (i=0; i16; i++) {
-buff[i] = ((uint)(inputBuffer[inputOffset+4*i]) 24)
- | ((uint)(inputBuffer[inputOffset+4*i+1]) 16)
- | ((uint)(inputBuffer[inputOffset+4*i+2]) 8)
- | ((uint)(inputBuffer[inputOffset+4*i+3]));
+buff[i] = (uint)(((inputBuffer[inputOffset + 4 * i]) 24)
+ | ((inputBuffer[inputOffset + 4 * i + 1]) 16)
+ | ((inputBuffer[inputOffset + 4 * i + 2]) 8)
+ | ((inputBuffer[inputOffset + 4 * i + 3])));
}
@@ -171,7 +134,12 @@
for (i=16; i64; i++) {
-buff[i] = Ro1(buff[i-2]) + buff[i-7] + Ro0(buff[i-15]) + buff[i-16];
+t1 = buff[i - 15];
+t1 = (((t1 7) | (t1 25)) ^ ((t1 18) | (t1 14)) ^ (t1 3));
+
+t2 = buff[i - 2];
+t2 = (((t2 17) | (t2 15)) ^ ((t2 19) | (t2 13)) ^ (t2 10));
+buff[i] = t2 + buff[i - 7] + t1 + buff[i - 16];
}
a = _H[0];
@@ -184,8 +152,10 @@
h = _H[7];
for (i=0; i64; i++) {
-t1 = h + Sig1(e) + Ch(e,f,g) + SHAConstants.K1 [i] + buff[i];
-t2 = Sig0(a) + Maj(a,b,c);
+t1 = h + (((e 6) | (e 26)) ^ ((e 11) | (e 21)) ^ ((e 25) | (e 7))) + ((e f) ^ (~e g)) + K1[i] + buff[i];
+
+t2 = (((a 2) | (a 30)) ^ ((a 13) | (a 19)) ^ ((a 22) | (a 10)));
+t2 = t2 + ((a b) ^ (a c) ^ (b c));
h = g;
g = f;
f = e;
Index: ChangeLog
===
--- ChangeLog (revision 102233)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2008-04-30 Alan McGovern [EMAIL PROTECTED]
+
+ * SHA256Managed.cs: Inlined helper methods removed
+ unnecessary casts and made a field a local var.
+ Gives about 1.75x faster performance.
+
2008-04-27 Alan McGovern [EMAIL PROTECTED]
* SHA1CryptoServiceProvider.cs: Performed loop unrolling and
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] JIT and Inlining - why doesn't it happen?
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 at 11:32 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Mono only inline 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 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 inlined! Each of these methods is only called once in the code. By
manually inlining those method calls, performance increased significantly -
about 70%. Why isn't mono inlining these methods? Can mono be made inline
these?
Alan.
[1]
http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462view=markup
___
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] SHA256 - small perf boost
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 near identical (between them) and looks a lot like SHA256 I'm slowly working my way through the classes and applying the same changes as i go. If you know certain classes are more important than others (i.e. used internally in the runtime or used extensively in other code), i could check through them next rather than just randomly selecting one i haven't looked at and seeing what i can do there. Thanks, Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
